安然的代码笔记

图片生成器项目实践：面向论文配图与教学交付的效率工具

Sun, 17 May 2026 00:00:00 GMT

图片生成器项目实践：面向论文配图与教学交付的效率工具#

线上地址：

http://tools.anrdev.cn/

这段时间我重新梳理了一下自己在做的这个图片生成器项目。和一般的“在线画图工具”相比，它更像一个面向论文配图、课程设计和教学交付场景的图表工作台。对我来说，这个项目值得记录的地方，不是它支持了多少图种，而是它在工程上逐渐形成了几条比较清晰的设计原则。

一、问题不是“生成一张图”，而是“如何减少交付链路里的重复劳动”#

如果只从功能表面看，这个项目做的是：

ER 属性图
学术三线表
系统架构图
流程图
数据流图
用例图
类图
时序图

但真正驱动我继续做下去的，不是“图种数量”，而是一个更具体的问题：

当用户已经有了 SQL、表结构、字段说明或系统设计信息时，能不能不要再重复拖拽、重复排版、重复导出。

所以这个项目从一开始就不是按自由绘图工具的逻辑去做的，而是按“结构化输入 -> 预览 -> 正式生成 -> 导出”的链路来组织。也正因为这样，它的很多实现选择都偏向工作流，而不是偏向画布交互。

二、前端不是多个孤立页面，而是统一工作台#

前端基于 Vue 3 + Vite，顶层入口在 src/App.vue。这里一个很关键的决定是：没有把不同图种拆成完全独立的小应用，而是统一挂在同一个工作台壳层下。

这样做的直接收益有几个：

登录、账户、反馈、管理后台只需要维护一套
图种切换时可以复用相同的状态管理和交互模式
配额、会员、导出、弹窗这些横切能力不用重复实现
后续加新图种时，接入成本更可控

如果项目只是一个本地 demo，这种组织方式会显得偏重；但如果目标是持续迭代的线上工具，它反而能让演进路径更稳定。很多“越做越乱”的工具站，问题不在某个功能点，而在顶层没有把公共能力提前收拢。

三、结构化输入是这个项目最重要的前提#

我比较认同的一点是，这类工具如果要求用户从空白画布开始操作，效率往往并不高。真正能拉开体验差异的，通常是能不能直接消费已有结构。

以 ER 工作区为例，系统不是让用户重新画表，而是优先接 CREATE TABLE 结构，然后走解析、预览和导出流程。这个思路本质上是在做一次“结构到图”的转换，而不是做一个通用画板。

这背后的取舍很明确：

放弃一部分“完全自由”的编辑能力
换取更稳定的生成结果
让已有资料可以直接复用
把时间花在交付结果上，而不是花在重复输入上

这个思路在三线表工作区也一样成立。三线表最难的部分通常不是“画出来”，而是“导出的结果能不能直接放进 Word 或论文里”。所以它更像是一个面向交付的结构化文档生成问题，而不是一个普通表格编辑问题。

四、预览和正式生成分离，是我最想保留的一个边界#

这个项目里有一个我现在依然觉得很重要的设计：预览接口和正式生成接口分离。

原因不复杂。只要项目里开始出现配额、会员、导出、AI 调用这些生产级规则，预览和正式生成就不应该继续混在一起。

项目里的接口封装大致是这样：

1
export async function parseDiagramByServer(type, input) {
2
  const result = await requestJson('/api/preview/diagram/parse', {
3
    method: 'POST',
4
    body: JSON.stringify({ type, input })
5
  });
6

7
  return result?.data;
8
}
9

10
export async function generateParsedDiagramByServer(type, input) {
11
  const result = await requestJson('/api/generate/parse', {
12
    method: 'POST',
13
    body: JSON.stringify({ type, input })
14
  });
15
  return result?.data;
16
}
17

18
export async function generateSqlDiagramByServer(input) {
19
  const result = await requestJson('/api/generate/sql-parse', {
20
    method: 'POST',
21
    body: JSON.stringify({ input })
22
  });
23
  return result?.data;
24
}

展开收起

这段代码表面上只是多了几个路径，但它实际解决的是接口语义和业务边界问题：

预览阶段允许低成本试错
正式生成阶段才进入额度消耗链路
前端调用时不会把“看看效果”和“真正产出”混成一个动作
后端更容易接入日志、计费、风控和异常补偿

很多工具项目后期难维护，原因往往不是算法复杂，而是链路边界一开始就没有分开。预览、生成、导出、计费混在一起以后，任何规则变更都会影响整条链路。

五、后端真正承担的是规则协调，而不是单纯转发请求#

后端目录在 license-server/，入口是 proxy.js。虽然名字看起来像代理层，但它实际承担的是一层比较完整的业务协调逻辑。

从当前结构看，后端至少已经拆成了这些模块：

services/parse
services/build
services/layout
services/export
services/auth
services/redeem
services/share
services/feedback

这类拆分说明一件事：项目的问题域已经不是“请求进来，生成一张图再返回”这么简单了。它还要处理：

身份状态
使用额度
正式生成与预览的边界
导出失败时的补偿
反馈和运营链路
兑换码和会员逻辑

也就是说，真正把项目复杂度拉上去的，不是图种本身，而是这些围绕线上工具运行而出现的规则系统。

六、AI 在这里更像结构化处理器，而不是聊天入口#

这个项目也接了 AI，但它不是以对话为中心来设计的。我更愿意把它看成一个嵌入工作流的结构化处理器。

它更适合做的事是：

优化原始 SQL
收敛字段数量
补字段注释
把不规整的输入转换成更容易解析的结构

这类场景下，AI 的价值不在于“能聊”，而在于它能不能帮用户少做几轮机械调整。只要它能把脏输入整理到更适合后续解析和导出的状态，它就是有效的。

七、从工程形态看，它已经更接近一个垂直 SaaS#

虽然我还习惯叫它“图片生成器”，但从系统形态看，它已经不只是一个单点工具。除了图表工作区本身，它还在持续吸收这些能力：

游客与注册用户的额度体系
会员无限制逻辑
登录、会话、账户中心
分享活动与奖励
兑换码系统
反馈管理
后台管理

这意味着它的核心问题已经从“功能能不能做出来”转成“这套工具如何长期在线运行”。这也是为什么我现在更愿意从工作流、权限边界和可维护性来审视它，而不是只看图表渲染效果。

八、现阶段最值得继续打磨的点#

如果后面继续投入，我更关注的不会是机械地增加图种，而是下面这些更偏工程质量的方向：

生成结果的稳定性
导出结果的交付质量
预览与正式生成链路的一致性
AI 辅助的可控性
用户在真实交付流程中的卡点

对这类项目来说，真正决定体验上限的，往往不是“会不会画”，而是“会不会在最后一步掉链子”。

结语#

这次回头看这个项目，我比较确定的一点是：它要解决的并不是“如何在线画图”，而是“如何把已有结构更高效地变成可交付结果”。

从工程视角看，比较关键的几件事其实已经逐渐清晰了：

用结构化输入替代重复拖拽
用统一工作台承载多图种能力
用预览/正式生成分离守住业务边界
用后端规则系统托住额度、导出和运营逻辑

后面即使继续扩功能，我也更倾向于守住这些边界，而不是把它重新做回一个“大而杂的在线画板”。

编写了一个根据网站内容生成广告图的Skill，成功调用image2模型

Sun, 17 May 2026 00:00:00 GMT

编写了一个根据网站内容生成广告图的Skill，成功调用image2模型#

最近我补了一个比较有意思的 Skill，目标不是直接“生成一张图”，而是把一个网站首页转换成一套更适合宣传和投放的广告素材。

如果把这个过程拆开看，它其实是一条很明确的链路：

读取网站首页内容
提取产品定位、卖点和页面语气
重组为广告标题、短文案和视觉方向
组织出图提示
调用 image2 模型生成广告图

这篇文章想记录的重点，不是“我又接了一个模型”，而是这个 Skill 在技术上怎么把“网页内容理解”和“图像生成”接成了一条稳定链路。

一、这个问题的关键，不是生图，而是先把网页理解对#

很多人第一反应会把这个 Skill 理解成一个广告图生成器，但真正难的部分并不在最后的出图，而在前面那一步：如何从网站首页里提取出适合营销表达的内容结构。

网站首页里的文案通常面向产品介绍，特点是信息完整，但不一定适合直接转成投放素材。它可能有这些问题：

信息分散在多个区块
语气偏产品说明，不够适合传播
重点信息和次要信息混在一起
页面视觉风格和文案风格不一定天然适合广告图

所以这个 Skill 的第一阶段，实际上更接近一次针对首页的结构化分析，而不是一次简单摘要。

我要拿到的不是“这个页面讲了什么”，而是下面这些更适合后续生成的问题答案：

这个网站到底在卖什么
首页最想强调的能力点是什么
哪一句话最接近核心卖点
页面更适合什么样的视觉调性
适合产出海报、封面图还是社媒宣传图

如果这一步拿错了，后面文案和图像都会偏掉。也就是说，前置理解质量决定了后续整条链路的上限。

二、文案生成阶段，本质上是在做“营销表达重组”#

在这个 Skill 里，我没有把网页原文直接喂给图像模型，而是加了一层中间结构，把页面信息先整理成广告表达需要的字段。

这一层通常会产出这些内容：

主标题
副标题
卖点短句
行动按钮文案
画面关键词
目标受众描述

这个阶段我更关心的是“重组”，不是“润色”。

因为网页文案和广告文案的目标并不一样。前者追求完整表达，后者追求快速传达和点击意图。所以这里本质上做的不是改写句子，而是把原始页面内容重新映射到一个更适合营销场景的结构上。

从技术上看，这个中间层非常重要。它相当于把原本松散的网页内容，压缩成后续图像生成可以稳定消费的输入格式。

三、为什么我坚持把“文案生成”和“图像生成”拆成两步#

如果只是为了快速出图，完全可以把网站信息和一句“请生成广告图”的提示词直接扔给模型。但我没有这么做，原因主要有两个。

第一，链路不可控。

如果页面理解、卖点提炼、画面表达都挤在一次生成里，最后很难判断到底是哪一步出了问题。图不好看，可能是视觉提示不够；文案不准，可能是卖点提取错了；语气不对，也可能是页面理解偏了。

第二，可复用性差。

把中间层显式抽出来后，广告标题、短文案和画面方向都可以单独复用：

可以只取文案，不出图
可以同一套卖点生成多版画面
可以在不同平台上替换不同语气
可以后续再接别的图像模型

所以这一步其实是在做一个很典型的工程取舍：牺牲一点链路长度，换可解释性和可复用性。

四、成功接通 image2，意味着这条链路终于闭环了#

我在标题里强调“成功调用 image2 模型”，不是想突出模型名字本身，而是因为这代表流程已经从“理解和整理”走到了“实际出图”。

这件事的意义在于，Skill 的定位发生了变化。

在只做网页理解和文案生成的时候，它更像一个内容辅助器；接通 image2 之后，它才真正具备了素材生成能力。也就是从：

页面分析结果

变成了：

页面分析结果
广告表达结果
可直接预览的广告图结果

一旦最后一步打通，整个 Skill 才不只是“给建议”，而是开始真正产出可用素材。

五、这个 Skill 的本质，不是“AI 生图”，而是“内容到素材”的转换器#

从工程视角看，这个 Skill 更准确的定位不是图片生成器，而是一个 内容到素材的转换器。

它的输入不是一段手写 prompt，而是一个真实网站首页。它的输出也不应该只是一张随机图，而应该是一套围绕页面定位展开的宣传素材。

它想解决的问题其实是：

网站已经有内容了，为什么还要重复手工整理成广告语
卖点已经在页面里了，为什么还要重新总结视觉方向
文案已经成型了，为什么还要再单独写一版出图提示

如果这几步都能被串起来，Skill 的价值就不只是“快”，而是减少了内容生产流程里的上下文切换。

六、为什么适合做成 Skill，而不是一次性脚本#

我最后把这套东西做成 Skill，而不是简单的本地脚本，核心原因是它的输入模式非常稳定。

只要对象还是“网站首页”，这套流程就能重复使用：

个人博客
产品官网
SaaS 首页
工具落地页
活动宣传页

做成 Skill 之后，后续扩展空间也更大。比如：

按平台区分文案语气
按页面类型区分视觉风格
输出多套广告方案而不是单一结果
接入更多图像模型或审核规则

这说明它不是一个一次性的 prompt 模板，而是一条可以持续演进的工作流。

七、这次实践里最有价值的，不是单次结果，而是链路分层已经成立#

我现在回头看，这次最值得记录的不是某一张图生成得多漂亮，而是这条链路的分层已经比较清楚了：

页面理解
营销表达重组
视觉方向组织
图像模型调用

这几层一旦拆清楚，后面无论是改 prompt、换模型、加平台规则，还是做失败重试，都会更容易落地。

很多 AI 工具一开始能跑，但越改越乱，根本原因通常不是模型不行，而是链路没有分层，导致所有问题都堆在一次生成里。

八、后面还值得继续打磨的点#

后续如果继续往下做，我更关心的会是这些偏工程质量的问题：

首页理解的稳定性
文案表达和页面调性的一致性
出图风格与产品定位的匹配程度
同一页面多方案生成的可控性
失败场景下的降级策略

尤其是“页面理解错了怎么办”这个问题，后面大概率还要继续加约束和校验。因为对这类 Skill 来说，最怕的不是模型出图慢，而是前置语义已经偏掉了，后面整条链路都在放大错误。

结语#

这次写这个 Skill，对我来说更像是在验证一个思路：

能不能把网站首页里已经存在的信息，直接拉进一条可执行的广告素材生成链路。

现在看来，这件事至少已经具备了一个比较完整的最小闭环：

先理解页面
再重组表达
最后调用 image2 出图

后面即使继续扩展，我也更倾向于保持这种分层方式，而不是把它重新做回一个“什么都塞进一次 prompt”的黑盒流程。