08 · AI 生图之后：把一次性好图变成可复用的素材生产线

定位：实现复盘。 主要依据攀岩聊天、日常表情、菇勇者与小菇撑的源码和测试。目录中有生成资产，不等于本次调用了生成服务；本文没有重跑远程生图，也没有逐张审查全部图片。

第一张符合预期的图，通常最容易让人产生“项目快完成了”的错觉。真正进入一个表情包、品牌包或平台交付后，问题才开始出现：背景没有抠干净，小图认不出角色，换一张姿态角色就变了，改完原图却仍沿用旧审批。

这些问题不是继续堆提示词就能解决的。claude-demo 的多个素材项目逐渐形成了一条更接近软件构建的路线：保留来源，用确定性步骤生成派生资产，再让验证与版本对应起来。

一、把生成与加工拆成两个系统

远程生成负责提供候选，具有随机性、服务依赖和成本；本地处理负责裁剪、背景清理、尺寸归一化、动画与导出，应尽量可重复。

可以用以下资产关系理解仓库中的共同结构，但不同项目并不都实现了所有节点：

flowchart LR Reference["角色参考与场景约束"] --> Raw["原始候选图"] Raw --> Review["人工确认母稿或关键姿态"] Review --> Clean["背景及边缘处理"] Clean --> Master["归一化母版"] Master --> Static["静态派生图"] Master --> Motion["动画帧"] Static --> Package["平台包与清单"] Motion --> Package Package --> Check["预览与验证记录"]

关键是不要把生成结果直接当成唯一成品。保留母稿、处理参数和派生关系，才能在平台规格改变时重做输出，而不是在压缩过的成品上继续压缩。

仓库中存在分镜提示词与独立关键帧，但这不能证明已经有通用网格检测或自动切片器。例如岩壁招式构建器直接读取清单指定的独立姿态文件，这个输入准备步骤必须如实保留。

二、角色一致性需要“定义”和“版本”两道约束

攀岩金针菇的提示与参考规则包含明确的角色形态；生成过程接入角色参考，并划分角色、样片等审批阶段。这比只在每次请求里写“保持一致”更可检查。

更关键的是，审批绑定实际资产摘要。测试先审批文件，再修改其内容，要求旧审批失效。这样“已经确认过”就不再是脱离文件版本的一句聊天记录。

不过，哈希只证明审查对象是否改变，不能识别角色是否正确。菌柄数量、脸的位置、装备和表情仍需要视觉核对。不同专辑也有不同角色设定，不能把某一套形态约束强行应用到全部金针菇或软团角色。

这套机制可以推广到设计稿、音频样片和模型文件：审查结论必须指向一个不可含糊的资产版本。

三、抠图的进步：颜色距离与连通性结合

早期处理按特定背景色的通道特征生成透明度。这种方法简单、可解释，但如果角色内部也有近似颜色，就可能误删前景。

攀岩聊天的实现组合了两条分支：先按颜色距离对全图生成基础 Alpha，再对边界连通的同色相候选追加消除。边界传播利用了一个先验——底色通常从画布边缘延伸，而封闭轮廓内部的相似色相未必属于背景。

连通性只约束附加的色相处理，不能保护所有内部同色像素。如果封闭区域与目标底色完全相同，全图颜色距离分支仍会清除它。本次用合成图核对：深色轮廓内的底色像素被清为透明，而另一种有足够颜色距离的紫色被保留。准确理解两条分支的叠加，比笼统宣称“连通抠图不会误删内部颜色”更重要。

这种规则不是通用语义分割。主体贴边、前景与底色接近、轮廓出现缺口时，先验仍可能失效。因此测试应包含内部同色区域、细部缝隙和边界主体，而不只是一张干净色块。

图 08：原创合成图说明两分支的叠加逻辑：深色封闭轮廓内若与底色相同，仍会被全图颜色距离分支清除；颜色距离足够大的区域可以保留。不是实际抠图输出截图。

四、透明背景之外，还有颜色污染

菇勇者处理链进一步处理半透明边缘。一个边缘像素可能已经混合了前景和底色；仅降低 Alpha，并不会自动把混入的底色去掉。

用近似混色关系说明：

observed_color ≈ alpha * foreground_color
                 + (1 - alpha) * background_color

在估计背景与 Alpha 后，可以尝试反推前景色。源码对极小 Alpha 做保护，并结合前景颜色传播及局部规则修正边缘。它仍然依赖估计，不是可以无损恢复任意前景的通用方法。

缩放也有影响。如果透明像素中残留高饱和背景色，直接过滤 RGB 可能让颜色重新渗入边缘。premultiplied_resize() 先将颜色乘 Alpha 再缩放，之后恢复颜色，减少这类污染。相关测试检查的是具体抗锯齿场景，不代表所有素材已经无杂边。

五、数据驱动还需要找出隐藏的硬编码

日常表情项目用清单组织文案、命名、源图与动画，是数据驱动生产的实际案例。但平台分流仍含编号范围规则；关系表情打包也使用明确的成员白名单。

因此，从 16 项扩展到 23 项或更多时，不是只改 JSON 数组长度。还要检查编号、专辑/单品分组、压缩包枚举、预览顺序和验证器。

更合理的扩容验收是：清单中的每一项都能追踪到来源、派生物和包成员；包中也没有清单之外的意外文件。参数化不是目的，完整的资产映射才是目的。

六、资产家族应该分别理解

项目家族	主要技术贡献	不应混称的能力
阿岩与头像资产	裁剪、尺寸派生、角色识别度	不是动画引擎
攀岩聊天	参考约束、阶段审批、模块化处理	不是自动理解所有姿态
日常表情	批量清单与平台分流	不是完全无硬编码流水线
菇勇者	边缘去污染、分层动画与审核	不是自动审美判定
小菇撑系列	关系语义、纯图变体与多端派生	文件数量不等于独立生成次数

早期程序化角色、三姿态动作和单图动效的区别，下一篇再展开。先把每条生产线的输入合同讲清楚，才能讨论效果和成本。

七、怎样复用，而不立即产生生成费用

建议先使用已有母稿和合成测试图，验证本地处理层。以攀岩聊天项目为例，在具备 Pillow 等项目依赖的环境中，可从以下测试开始：

cd wx/enoki-climbing-chat-v1
PYTHONPATH=src python3 -m unittest discover -s tests -p 'test_image_ops.py'
PYTHONPATH=src python3 -m unittest discover -s tests -p 'test_approval.py'

这些检查围绕图像处理和审批，不应被替换成一次完整生图调用。后续扩展时，还应记录处理版本、输入摘要、失败原因及输出规格，并避免把访问凭证写进源码或交付清单。

结语

生成服务提供的是候选能力，生产系统提供的是可复用能力。把二者分开之后，项目才能从“再试一张”进入“知道怎样重建、怎样检查、怎样交付”的阶段。