我把AI生图做成了工程能力：better-imagegen的实战与判断

最近两周，我密集地用 AI 生成了几类差异很大的视觉资产：产品竞赛主视觉、Agent 角色分身、18px 菜单栏帧动画、macOS App Icon、动态壁纸、错误状态插画，以及博客和社交媒体封面。

一开始我以为问题只是“怎么写出更好的 Prompt”。做得越多，我越确定：Prompt 只是视觉交付链路里的一小段。真正费判断的是选什么工作流、怎样约束输出、如何处理透明通道、怎么保证角色一致、如何把一张图交付成前端和客户端能直接使用的资产。

这也是我持续完善 better-imagegen 的原因。它不是收藏 Prompt 的目录，而是一个面向 Agent 的视觉生成 skill：输入目标和交付类型，输出可以进入工程的图片、帧序列、元数据和平台产物。

一句话总结

AI 生图要从“抽卡”走向工程化，关键不是把 Prompt 写得更长，而是把类型路由、规格约束、模型回退、后处理、质量检查和产物封装变成稳定流程。

我最近到底拿它做了什么

我没有只扫描某一次会话，而是回看了近期 Codex 会话、项目资产和 better-imagegen 自身的 Git 演进。真实需求大致分成这些类型：

这些案例让我看到：同样叫“生成一张图”，背后的交付合同完全不同。

第一条经验：先判断产物类型，再选择模型

很多生图流程第一步就是选模型。我现在反过来：先问最终文件要被谁消费。

如果是博客封面，我需要 16:9、WebP、合适的压缩质量和可放标题的负空间；如果是 macOS 菜单栏图标，我关心的是透明通道、18px 下的轮廓和帧间稳定性；如果是动态壁纸，最终消费者是 macOS，不是浏览器，因此交付物应该是符合系统要求的 HEIC，而不是两张漂亮的 PNG。

目前 better-imagegen 把常见任务拆成独立工作流：

这样做的好处是：Agent 不再把所有需求都塞进同一个“万能生图 Prompt”。

第二条经验：Prompt 应该是一份 Asset Contract

一个可执行的 Prompt，不是堆“高级感、电影感、8K、杰作”这类形容词，而是写清一份资产合同。

我现在通常至少写这 6 类信息：

1
2
3
4
5
6

1. Subject：画面里必须有什么
2. Composition：主体位置、留白、视线方向、帧网格
3. Style：摄影、插画、像素、产品渲染等视觉语言
4. Delivery context：博客、社交媒体、菜单栏、桌面、App Icon、头像
5. Hard constraints：人数、透明背景、尺寸、帧数、角色身份
6. Negative constraints：不要文字、不要 Logo、不要水印、不要额外肢体

例如做 Argos 菜单栏猫头鹰动画时，“可爱猫头鹰”远远不够。真正决定可用性的约束是：横向精灵图、固定 6 帧、每格等宽、透明背景、暖橙色轮廓、18px 仍能辨识、首尾动作连续。

模型生成的是像素，但 Prompt 描述的是运行时约束。

第三条经验：准确文字不要交给图像模型

产品竞赛主视觉是一个典型转折点。画面里既要角色、空间感和产品 UI，又要大量准确中文。直接让模型把所有文字画出来，结果通常是：中文错字、字重漂移、对齐不可控，修改一个词还要整张图重抽。

我最后采用的流程是：

1
2
3
4
5
6
7

AI 生成无文字视觉底板
        ↓
HTML / CSS 叠加真实文本和品牌组件
        ↓
浏览器渲染并截图
        ↓
WebP 压缩 + 尺寸检查

这个方法没有“纯 AI 生图”那么浪漫，但交付质量稳定得多。图像模型负责它擅长的氛围、材质和构图；浏览器负责它擅长的字体、排版和像素级控制。

这其实很符合我从前端转 Agent 的经验：不要让一个模型承担完整系统里所有职责，边界清晰比单点能力更重要。

第四条经验：角色一致性必须走 Image Edit

在“小界”和“录制小界”的角色设计里，我需要同一角色拥有不同身份和动作：基础小界负责体验治理，录制小界负责根据目标自动探索操作路径并沉淀技能。

如果每次都从文本重新生成，脸型、发型、服装结构和整体年龄感都会漂。更可靠的方法是把现有角色图作为 reference，通过 image edit 只修改服装、姿态、表情或手持物。

我的判断标准很直接：

• 用户必须认出“还是同一个角色”时，使用 image edit。
• 只需要同类风格、不要求身份连续时，才用 text-to-image。
• 角色进入帧动画时，先锁定标准立绘，再做动作变化。

第五条经验：帧动画的验收单位不是大图，而是运行尺寸

我第一次给 Argos 做 RunCat 风格的菜单栏动画，生成的大图看起来不错，放进 macOS 菜单栏却几乎不可见。原因很简单：深色主体、细轮廓和轻微动作，缩到 18px 后全部丢失。

后来我把 sprite loop 的交付定义成了一组工程产物：

1
2
3
4

sprite-sheet.png        # 原始等分精灵图
frame-01.png ...        # 拆分后的独立帧
preview.gif             # 快速预览循环
manifest.json           # 帧数、尺寸、顺序、时长

并增加了 4 个验收条件：

1. 每个 cell 尺寸完全一致，不能靠肉眼切。
2. 首帧和末帧的姿态能自然衔接。
3. alpha 通道真实存在，不能用棋盘格“画透明”。
4. 必须在实际运行尺寸验收，而不是只看 512px 预览。

这条经验也适用于头像、favicon、状态图标：缩小后的信息密度，才是最终质量。

第六条经验：一张透明 PNG 还不是 macOS App Icon

macOS App Icon 是另一个很容易被低估的场景。模型能生成一个透明图标，不代表它可以直接放进 Xcode。

稳定流程至少包括：

1
2
3
4
5
6
7
8

生成透明源图
  → 检查 alpha 边缘
  → 裁掉异常透明留白
  → 设置视觉安全区
  → 生成 macOS squircle 底板
  → 输出 16 / 32 / 128 / 256 / 512 / 1024 尺寸
  → 组成 .iconset
  → 转换为 .icns

这里模型只完成了“源艺术”。后面的尺寸矩阵和系统封装，才决定它是不是一个可安装的 App Icon。

第七条经验：模型回退不是换个名字重试

better-imagegen 现在默认使用 GPT Image 2，失败后归一化 Prompt 重试一次，再回退到 Gemini，最后才考虑 Doubao。

但 fallback 不是无脑串行，因为不同模型的交付特性不同：

因此透明 Logo、Icon 和 sprite sheet 不应该回退到一个会破坏 alpha 或网格的模型。Fallback 的目标不是“总能出图”，而是“仍然能交付同一种资产”。

第八条经验：每张图都应该可追溯

最早生成完一张图，我只关心“保存在哪”。当使用频率变高后，这种方式很快失控：不知道用的哪个模型、不知道请求尺寸、分不清生成耗时和后处理、也无法复现一张突然很好的图。

所以我给每个产物增加了同名 JSON 元数据：

1
2
3
4
5
6
7
8
9
10

{
  "file": "cover.webp",
  "model": "gpt-image-2-all",
  "requested_size": "1536x1024",
  "actual_resolution": "1280x720",
  "generation_time_seconds": 38.8,
  "output_format": "webp",
  "postprocess": "center-cropped to 16:9; WebP quality 78",
  "prompt": "..."
}

元数据看起来是小事，但它让视觉生成从“聊天记录里的偶然结果”变成了可审计的工程产物。

我是怎样把一次成功沉淀成 skill 的

最近有一次生成结果特别好，我第一反应不是只保存图片，而是追问：这次为什么好？哪些步骤可以复用？

我会把过程拆成 4 层：

1. 类型层：这是封面、图标、壁纸还是动画？
2. Prompt 层：哪些构图和负向约束真正起作用？
3. 后处理层：裁切、透明、压缩、拆帧、系统封装做了什么？
4. 验收层：在真实博客、菜单栏、Dock、网页里效果如何？

然后把稳定部分写进对应 reference，而不是继续依赖我的临场记忆。better-imagegen 最近的演进也基本沿着这条路线：

这就是我理解的 Agent skill：不是一段“万能指令”，而是把成功经验变成一套带条件分支、失败处理和交付标准的操作系统。

better-imagegen 的能力边界

它目前很适合：

• 快速生成产品概念视觉、封面、角色和状态物料。
• 让 Agent 自主选择图像工作流并完成后处理。
• 把 sprite、App Icon、壁纸等非单图资产交付到工程。
• 在多模型之间做有约束的 fallback。
• 给生成结果补齐规格和元数据。

但它不是 Figma 的替代品，也不会自动解决所有品牌一致性问题。涉及精确排版、复杂 Design System、连续镜头或严格 3D 资产时，仍然需要专业工具和人工判断。

要不要用 / 我的判断框架

我的结论是：如果你每周都有两次以上视觉生成需求，值得把生图从 Prompt 升级成 skill。

判断是否值得工程化，我看 3 个问题：

对我来说，better-imagegen 最大的价值不是“让我更会画图”，而是让视觉生成开始拥有软件工程的确定性：知道该走哪条路径、失败时如何退、最后交付什么文件、下一次怎样复现。

从前端转向 Agent / AI Infra 后，我越来越相信一件事：超级个体的优势不在于每件事都亲手做，而在于能把判断沉淀成系统，再让 Agent 把执行力拉满。 better-imagegen 就是这套思路在视觉生成上的一次实践。