AI-Native游戏开发(2)：角色美术生产链

0. 系列文章导航

3句话，AI给我生成了一个galgame
AI-Native游戏开发(1)：为什么选择图数据库
 AI-Native游戏开发(2)：角色美术生产链
 AI-Native游戏开发(3)：角色声音生产链
 AI-Native游戏开发(4)：场景与BGM生产链
 AI-Native游戏开发(5)：剧情台词生产链
 AI-Native游戏开发(6)：叙事图自增长

1. 角色不是一张图，是一组有依赖的资产

第一个要打破的直觉：AI 生图早已不是瓶颈，一致性才是。

一个角色在 Galgame 里需要的不是「一张立绘」，而是：一套固定外貌（同一张脸、同一个发型，出现在所有图里）、若干套着装（日常、工作、剧情特殊场合）、每套着装下的多个表情动作变体。玩家对这些图的期待不是「每张都好看」，而是「这几十张图是同一个人」。

如果让 AI 每次从文字描述直接出图，即使描述一字不差，多次生成的脸也会各走各的——文生图的随机性决定了「文字一致性」兑换不来「图像一致性」。

我们的解法是把角色视觉资产拆成一条有依赖关系的链，让每张图都有明确的上游，让「像不像同一个人」这个难题尽量由链的结构解决，而不是靠提示词祈祷：

graph TD CH[角色] --> AP[外貌设定] CH --> CO[着装方案] CH --> LS[语言风格] AP --> DS[三视图设计稿] DS --> ID[着装立绘设计] CO --> ID ID --> SI[表情/动作立绘] LS --> SI EV[事件] -.-> CO

实线边全部参与级联（上游变更会作废下游重做）；唯一的虚线（事件 → 着装方案）不参与级联——剧情事件决定角色穿什么，这是叙事事实，不因美术产物作废而消失。

五种节点，两两之间的关系都是「派生」。这条链的每一跳都有明确的工程理由，下面逐段拆开。

2. 概念层先行：文字便宜，图片贵

链条的最上游是三个纯文字节点：AppearanceStyle（固定外貌）、CostumeStyle（着装方案）、LanguageStyle（语言风格，供第 3 篇的声音链和本篇的立绘表情参考使用）。

它们由概念设计 skill 从 Character 的设定推导生成：外貌写身高、体型、脸型、五官、发型发色、身体特征；着装按事件的着装需求分组设计；全部是结构化标签加自由文本，没有任何图片。写入即 status=1，不走审批。

这里有个值得展开的设计判断：为什么文字节点不审批？

因为成本结构完全不同。文字生成几乎免费，改起来也几乎免费，AI 可以整体重读一个角色的全部设定再重写；图片则贵得多——生成要花钱花时间，且一旦错了，下游所有引用它的图一起报废。审批门控应该按「错误的代价」分层：文字层用轻量的「人随时可改」代替流程化审批，图片层才上 10 待审 → 人工 → 11 批准的正式闭环。如果所有节点都走人工审批，人会被淹没在低价值确认里，真正需要看图的时刻反而看不过来。

所以概念层的验收方式很朴素：它躺在图里，人在治理后台随时能浏览编辑；而编辑本身会触发第 1 篇讲的 sync 级联——改了外貌，下游三视图、立绘设计全部自动作废。用级联的威慑代替事前审批，是这个分层的另一半逻辑。

3. DesignSheet：三视图是全链的视觉锚点

链上第一个图片节点是 DesignSheet——角色的三视图设计稿。它的生产方式是文生图：提示词由 AppearanceStyle 组装，出一张 1024×1024 的三视图。

为什么全链只有这里是文生图？因为三视图的使命就是把文字一致性兑换成图像参考一致性。从这一步往下，所有出图全部改为图生图——以三视图为参考图（立绘设计阶段），再以立绘设计为参考图（单张立绘阶段）。脸和体型的一致性由参考图链传递，文字提示词只负责增量信息（换什么衣服、什么表情、什么姿势）。

「以图为参考再生图」比「按同一描述重复生成」稳定得多，这是一致性问题的核心解法。但参考图链也带来一个推论，恰好和级联机制咬合：上游图片一变，下游全部参考它生成的图都必须重做。所以 produces 边的 sync 恒为真——三视图被驳回重画，每套着装的立绘设计、每个表情立绘全部自动重置 -1。人工不需要记得这条依赖，图记得。

高亮的三视图是全链唯一的视觉锚点：它的稳定，决定了下游所有图的稳定；它的变更，通过级联自动作废下游全部——参考图链与 sync 链在这里完全同构，一条管「像不像」，一条管「该不该重做」。

链上第二个图片节点是 IllusDesign：把「固定外貌 × 某套着装」组合成着装立绘设计，每个（DesignSheet, CostumeStyle) 组合对应一个节点。它以三视图为参考图做图生图，同时解决一个纯文字解决不了的问题——衣服穿在这个人身上长什么样。着装设定写得再细，与体型结合的效果（正装穿在一个体态散漫的人身上是什么状态）只有图能回答。IllusDesign 还附带一个数值产物：展示缩放比例，由角色身高除以基准身高推算而来，发布时注入运行时——身高 190 的角色和身高 155 的角色同框时不会一样大，物理规格从设计期就跟着节点走。

最下游是 StandingIllustration：具体的表情、动作、姿态单张立绘，1024×1536 竖版，以 IllusDesign 为参考图图生图。LanguageStyle 到立绘还有一条容易忽略的 ref_style 边：语言风格里「说话时习惯挑眉」「惯用自嘲语气」这类文字，会作为表情变体的设计参考——角色「怎么说话」影响「说话时长什么样」。

4. 外貌与着装解耦：换装需求来自剧情，不来自美术预设

CostumeStyle 独立建模、通过 outfit_for 边「挂」到 IllusDesign 上，而不是把服装写死在外貌描述里——这个拆分是被剧情逼出来的。

看序章的真实结构：陆择在酒店客房醒来是一副清晨的居家状态，走到咖啡店与路口是日常的商务休闲，死后进入灵魂夹缝又换上「云雾蔽体」的灵魂形态——短短一章三节，着装就换了三段。如果服装混在外貌里，每次换装等于改外貌，全部资产作废；拆开之后，换装只是新增一个 CostumeStyle 节点和一条边，旧的着装立绘原封不动。

更关键的推论是：着装需求由叙事图的事件驱动，不由美术侧预设。Event 与 CostumeStyle 之间有一条 wears 边（「这个事件里角色穿这身」），概念设计 skill 在分析事件着装需求时会沿这条边发现「剧情推进到灵魂夹缝、陆择需要灵魂形态的着装，但还没有对应的着装方案」，进而创建缺口。美术不需要猜「未来剧情会用到什么衣服」——剧情先走，需求后到，图把两边接上。

两种模式的成本对照是鲜明的：预设制下，美术侧凭想象备一衣柜的衣服，其中大概率有若干套永远不会出现在任何事件里——每一套都是白付的生成费与审批时间；事件驱动制下，图上出现 wears 需求的那一刻才立项，每一套着装都有明确的事件锚点，审批时「为什么需要这身衣服」有据可答。需求滞后于决策，恰恰是控制库存的最优时序——这个判断第 5 篇的立绘按需生产会再次验证。

这也是为什么 wears 边刻意不参与级联：事件引用着装是叙事事实，三视图作废不影响「陆择在夹缝以灵魂形态示人」这件事本身。

5. 按需生产：立绘是资产，也是负债

链走到 StandingIllustration 时，有一个反直觉的决策：不做角色级批量备货。

很容易想到的方案是给每个角色预设一套「标准表情包」——喜怒哀惊讶害羞，一次性生成。我们没有这样做，立绘变体完全按需生产：剧本配音阶段，AI 逐句为台词挑选最贴切的立绘（第 5 篇详述），发现候选池里没有合适的变体时，才在图上创建一个 status=0 的缺口节点（附带变体氛围描述），再由立绘 skill 逐个交付生成。

理由有三层：

库存即负债。 每张立绘都是要审批、要维护、会因上游作废而重做的资产。预生成一堆用不上的变体，等于预支了一堆未来可能作废的审批和维护成本。
需求方更懂需求。 「这句话需要什么表情」的判断发生在读完全句台词的语境里，比美术侧提前几个月的预设准确得多。预生成的表情包里最常发生的事，是关键的没备、备了的没用。
生成成本趋零，延迟生成无惩罚。 AI 出一张图几分钟，等剧本需要时再生成，完全赶得上生产节奏。批量备货是「生成贵」时代的直觉，在 AI Native 流水线里是错位的。

按需模式的成立依赖一个前提：需求信号必须能变成结构化的图节点。缺口节点（status=0 + 氛围描述）就是这个信号——它一落地，调度器自然会发现「有待办」，生产 skill 自然会认领。需求从下游回灌上游，走的是图，不是人肉传话。

6. 分工模式：谁有权写图

这条链由多个 AI 角色协作完成，分工是刻意的三层，每一层的权限边界都明确到「能不能写图」：

编排代理（如 char-design）是纯分发层：解析角色名 → 只读查询全链 status → 按依赖顺序决定下一步调谁。它被明令禁止亲自写图、亲自调生成脚本——不是能力问题，而是调度和执行分离：调度者如果顺手干活，status 的更新时机就会变得随意，整个系统的可推理性崩塌。编排代理只被允许做一件事：把正确的生产 skill 加载进来，然后在 skill 的流程里执行。

生产 skill 是图与 status 的唯一写入者，内部统一为三段式：查状态（这个节点现在什么状态、上游是否就绪）→ 完成任务（组装提示词、出图、落盘）→ 保存结果（用幂等的「存在则更新、不存在则创建」语句兜底建节点建边，写产物路径与 status）。「兜底建」的意思是：节点已存在就复用更新，不存在才创建——同一 skill 被重复触发不会有副作用。

把三段式在美术链上具体化一遍，看它如何消化各种「不正常」的入口状态：

查状态：目标节点 status 是 0 或 -1 才推进（1/2/10/11 都意味着「不该由我此刻动手」）；同时核上游门控——出立绘设计前检查三视图是否已批准，未批准就停在这里汇报阻塞，而不是硬着头皮用一张可能要重画的三视图当参考。
完成任务：调纯产出层，提示词组装器先产提示词文件、图像生成器再出图——每一步的产物都落盘可查。失败在此止步：图没出来，就不会有下一步。
保存结果：确认图片文件真实存在之后，才把产物路径与新的 status 写进图。节点上从此同时挂着「指向产物的路径」与「对产物的判断（状态）」——真相与判断分离存放，但同址可查。

三段式的价值在于它是全流水线统一的生产协议：编排代理不需要知道每个 skill 内部怎么做，只需要知道每个 skill 都遵守「先查、后做、再存」——调度逻辑因此可以完全通用。第 4、5 篇的场景链与剧情链，用的正是同一份协议。

产物在文件系统侧的组织同样有纪律：每个角色一个目录，下面依次是设计提示词与三视图、按着装命名的子目录（各自的提示词与设计图）、再下一层的立绘变体（每个变体一份描述与一张图）。目录结构与图的层级一一对应——人找文件靠目录直觉，AI 找文件靠图上路径，两套索引指向同一批产物。

纯产出层是两个被抽出来的子技能：提示词组装器（把节点数据变成提示词文件）和图像生成器（调外部 API 出图）。它们不读写图、不写 status，输入输出都是文件与数据。这样抽的原因是复用——场景链（第 4 篇）同样需要出图，但场景链绝不该碰角色链的 status 逻辑；生成能力是通用的，图写权是各链私有的。

三层之间有一条最重要的铁律：先产物，后写图。凡产物由外部脚本生成（图片、音频），必须先落盘、校验成功，才允许写图与 status；生成失败禁止写 status。这条规则防的是最阴险的一类漂移：图上写着「图片完成」，文件系统里没有那张图。一旦图与文件系统失真，整个「图存真相」的地基就没了。反过来，LLM 直产的文本（提示词、设计描述）随写图语句内联交付，不受此限——文本没有「生成失败还写了状态」的中间态。

7. 验收与重做

美术节点的生命周期横跨五个状态：0 待处理 → 1 提示词完成 → 2 图片完成 → 10 待审 → 11 批准。从 2 到 10 是自动的——图片落盘校验成功即直写待审；从 10 到 11 只能是人：治理后台的审批中心里看图，批准或驳回。驳回回到 0，带批注重做。

一个真实的成本账，演示级联如何与人协作：某次三视图的美术方向调整（比如配色方向变更），AppearanceStyle 一改，级联 BFS 把三视图、每套 IllusDesign、全部立绘变体一次性重置 -1。接下来没有任何人需要去「通知」谁重做什么——编排代理下次查询时看到一片 -1 与 0，按依赖顺序逐个调用生产 skill 覆盖重生成，完成后重新变成一片 10。人的工作只有两件事：改设定（一次），然后在新一轮待审里逐张看图。

审批中心本身也按「人看图的直觉」设计：待审的立绘按角色与着装分组展示——同一变体的新旧版本、同组的不同表情并排可比，一眼看出哪张跑偏；批准是一键，驳回则带批注回流（「脸部轮廓偏了」「配色太灰」），批注会跟着节点走，重做时生产 skill 能读到上一次为什么被驳。驳回批注是全流水线里少数「人的判断」直接变成「机器输入」的通道之一——它的质量决定重做的命中率，所以界面鼓励写具体毛病，而不是笼统的「不行」。

这里再强调一次第 1 篇的教训在美术链上的形态：-1 必须覆盖，禁止因为文件已存在而跳过。作废的旧图会留在文件系统里（归档不删），调度只认 status。如果哪天有代码「聪明」到先看文件存在就跳过生成，那个角色的脸就会悄悄定格在上一个版本，而图的其余部分继续演进——一致性裂缝就此埋下。

8. 踩坑与演进

坑一：外部生成平台的安全审核，会反向塑造提示词工程。 我们用的商业生图 API 带内容安全审核，而 Galgame 的角色设定天然贴近边界。真实的教训是：提示词里含叙事情境（哪怕只是文字上略带暧昧的角色关系描述）时拒图率飙升，而把措辞聚焦到纯视觉词汇（剥离一切剧情语境，只描述画面元素）就能稳定通过。另一个发现更隐蔽：参考图本身的裸露程度会放大措辞敏感度，而且某些姿势（手臂横遮躯干一类）在审核模型眼里几乎必拒，且没有任何措辞能绕过——这类姿势只能从设定层面放弃。结论是反直觉的：在这条流水线里，提示词工程不只是「怎么描述得准」，还包括「怎么描述得让中间层满意」。生产链必须把外部平台当成有性格的合作方来适应。

坑二：概念稿与落地的偏差——生产链比想象中短。 原始概念稿里这条链更长：外貌、着装之外还有独立的设计流程节点。落地时发现节点数应该宁少勿多——每多一个节点，就多一层状态、一条级联边、一个审批位。最终链收敛为「三个文字概念节点 + 三个图片产物节点」，刚好覆盖一致性需求的最小结构。AI Native 流水线里，「图上的每个节点都是要被调度、被审批、被级联的活对象」，节点不是建模癖好的画布。

坑三：物理规格要跟着节点走。 早期立绘的显示比例是运行时手工调的，同框时大小关系靠目测。后来把「身高 → 展示缩放」的推算放进 IllusDesign 的生产流程，发布期自动注入运行时配置。小设计，但这类「设计期就该定、拖到运行期就变成手工债」的参数，在流水线里值得专门清点。

posted @ 2026-09-01 23:26 CrazyJinn 阅读(6) 评论(0) 收藏举报

刷新页面返回顶部

CrazyJinn