反复改稿才是耗时大头：AI 设计协作要补的是批注与素材权属管线
一、生成快不等于交付快，时间堆在决策链上
据公开报道，有团队实测了一款设计协作工具的新版本，作者的原话大意是：生图、改图这几步已经被压得很短，真正还占着工时的，是找灵感、跟人沟通、以及一轮一轮地改。我们不完全复述这篇实测的具体功能，只把里面那条对我们最有用的判断拎出来：把生成速度提到再高，交付也不会按比例变快，因为耗时大头从来不在“把图画出来”，而在“这一版到底算不算过、谁说了算、上一次的修改为什么被推翻”。
这件事在做软件交付的人身上有直接对应。我们给客户做界面、做视觉规范、做工业产品的外观方案时，模型出十张图是一下午的事，但要在这十张里选一张、并且说清为什么是它、以及过一阵子有人回来问“这里为什么是这个颜色”时能给出答案，靠的是一整套留痕机制。缺了这套机制，快的部分省下的时间，会被慢的部分成倍吃回去——而且吃掉的往往不是设计师的时间，是客户的信任和项目排期。
所以要补的不是一个更会画图的模型，而是两条管线：一条管批注（谁在哪一版上提了什么要求、这条要求最后落到哪里、有没有关闭），一条管素材权属（每一块素材从哪来、能用到什么程度、改过之后归谁）。下面逐条说。
二、改稿的四类耗时来源，各自要治的地方
把“改稿慢”当成一句话说出来是没有用的，得拆开才知道往哪儿使劲。我们内部复盘返工案例时，基本能把耗时归到四类来源，每一类的治理动作完全不同。
| 耗时来源 | 典型表现 | 根因 | 治理动作 |
|---|---|---|---|
| 要求本身没定 | 同一处被反复改方向，每次都有新说法 | 提要求时脑子里没有终态，只有“不像” | 先要一句“改到什么程度算对”的可判定描述，不接受只说“再大气一点” |
| 口头要求无归属 | 改完没人认账，过两天又被追“我没这么说过” | 要求散在聊天和会议里，没落到可查的对象上 | 口头意见当场转成一条带提出人的批注，未落字面的不进改动队列 |
| 素材不可用 | 选定的方案临交付被卡，因为某块图/字体不能商用 | 授权状态在设计中途没人查，到集成才暴露 | 素材一进项目就登记授权范围，缺证据的先用占位，不默认能用 |
| 验收时点缺失 | 改了十几版仍不知道“哪版是最终稿” | 没有把“定稿”定义成可验证条件 | 明确每一轮的验收边界与定稿标记，标记后改动走变更而不叫改稿 |
这四类里，前三类靠流程就能压下去，第四类最难，因为它要求团队承认“定稿”是一个决策而不是一个感觉。我们的做法是：一个改动请求进来时，先问它属于哪一类。属于第一、二类的，处理的是“把要求变成可判定句子”；属于第三类的，处理的是“补授权证据”；属于第四类的，处理的是“重新对齐验收边界”。把三类混在一起当成“再改一版”，是返工循环打不破的根本原因。
三、批注必须成为一等对象，否则一定烂尾
很多工具都支持“在图上写句话”。但只有正文、没有处置结论的批注系统，几乎必然烂尾——原因是它不能回答一个致命问题：这条意见，最后是照办了、还是被否了、还是没人管？ 一旦回答不了，批注就退化成聊天记录，过一阵子没人敢信。
要让批注能被引用、被统计、被关闭，它就得是一个有字段的结构化对象，而不是一段挂在图层上的文本。这是我们要求的最小字段集：
| 字段 | 含义 | 没有它会怎样 |
|---|---|---|
| 锚点 | 指向具体对象（图层/区域/坐标/组件），而非整张图 | “左上角那个再调调”无法定位，换一版就失效 |
| 提出人 | 这条意见是谁提的 | 出现“我没说过”时无法追溯 |
| 涉及版本 | 针对哪一版提的、被哪一版响应 | 无法区分“这是对旧版的评价”还是“对新版的要求” |
| 要求文本 | 要改成什么，尽量是可判定句 | 只剩“再大气一点”这类形容词 |
| 处置结论 | 照办 / 部分照办 / 驳回并说明理由 / 转入待议 | 批注永远是开着的，无法判定它完成了没有 |
| 关闭时间 | 处置被确认的时间与确认人 | 无法算“从提出到关闭”的真实周期 |
| 关联改动 | 落实这条意见的那次具体修改 | 无法回答“这条要求最后落到哪里” |
其中“处置结论”和“关联改动”是两个最容易被省掉、却决定系统生死的字段。一条没有处置结论的批注，等于一条永远欠着的债：它既不能被计入已完成，也不能被安全忽略，隔一阵子所有人对批注系统失去信任，回到在群里喊话。我们的落地顺序是：先逼团队把“要求文本”写成可判定句子（这一步会挡掉大量不该提的意见），再要求关闭时必须有处置结论，最后才谈加优先级、加指派、加提醒这些锦上添花的东西。前两步没做到，后三步只会制造更多未关闭的条目。
四、版本模型有三种，选错比没选更费人
批注要有“涉及版本”这个字段，前提是版本模型本身是清楚的。设计资产的版本模型常见三种，各有适用人群，混用会出事。
- 线性快照：每一版存一个不可变快照，只能在末尾追加。好处是谁都能看懂、谁都不会改错别人的东西；代价是分支式的探索（“同时试两个方向”）只能靠复制文件，很快就乱。适合一到三人、交付物相对单一的小团队。
- 分支加合并：允许从某一版拉出平行方向，选定后再并回主线。好处是能同时试多套方案且各带批注；代价是合并时同一处的两条批注会打架，需要人来裁决，工具解决不了。适合有明确设计负责人、要并行比稿的团队。
- 只留最终稿加历史：界面上只呈现定稿，旧版本折叠成一条时间线。好处是新人不会被十几版淹没；代价是“为什么定这版”的依据如果没进批注字段，就随折叠一起消失了。适合已经有稳定批注机制、只是想把噪音压下去的团队。
选型判据其实很简单：团队里能不能有一个人对“合并时谁听谁的”负责。负得起，用分支加合并；负不起，宁可用线性快照，也别用只留最终稿去掩盖分歧——第三种模型的隐含前提是历史已经有人看管好了。
五、素材权属三条线，缺一条都可能返到成品阶段
改稿改到一半被叫停，最贵的不是审美分歧，是素材根本不能用。素材的权属要拆成三条独立的线分开查，它们各自失效的方式不同，别指望一张授权书全盖住。
| 权属线 | 必须确认的问题 | 要留的证据 | 最常见的漏 |
|---|---|---|---|
| 生成物可用性 | 工具/模型这一版生成的图，许可允许我用在哪（是否要求署名、是否禁止商用、是否禁止用于竞品） | 生成时的条款快照与批次记录 | 把“能下载”当成“能商用”，条款中途改了自己不知道 |
| 外部素材授权范围 | 引入的图、字体、音乐、贴图，授权覆盖哪些媒介、地域、年限、能不能二次分发 | 原始授权凭证与可授权字段的清单 | 只记住“买过”，没记住买的是哪种用途的授权 |
| 进过模型的素材 | 用于参考/微调/合成的素材，是否允许被再训练、允许到什么范围 | 素材来源标注与再训练许可的确认 | 把客户未授权的素材喂进模型，事后无法证明没被记住 |
这三条线里，第三条是 AI 协作时代新增的、也最容易被忽略的一条。一块素材“能不能用一次”和“能不能进模型”是两个许可，前者是交付权，后者可能涉及再训练权，很多外部素材只给了前者。我们的处理办法是把它们登记成两个独立字段，任何一个为空就不许那块素材进入参考集，宁可先用形状占位。这看着拖慢了开工，但省下的是一次“成品交付后被告知素材来源有问题、整体重做”的灾难。
六、返工成本要能被记账，“定稿”要能被验证
前面所有字段凑齐，最终是为了两件能对外交代的事：把返工成本记出来，把“定稿”定义清楚。
返工成本不该是一句“改了很多次”的抱怨，而应是三个能统计的量：
- 按需求变更次数：处置结论为“驳回并重开”的批注数，衡量“要求本身没定”的代价。
- 按未定项数量：进入改动队列时仍带“待议”结论的条目，衡量带着多少没定的东西就开工。
- 按素材替换率：因权属线补不齐而被替换的素材占比，衡量素材盘点的漏洞。
这三个数不用给别人看也要自己记，因为它决定报价和排期：一个客户平均要变更多少次、有多少要求是开着口子进来的、素材问题暴露得多晚，直接对应我们在合同里该把哪些验收条件前置。
至于“定稿”，它必须是一组可验证条件，而不是形容词。我们用的判据是：所有指向该版本的批注都有处置结论且已关闭；三条素材权属线的证据齐全；关联改动都能反查到具体修改；版本被显式打上定稿标记并锁定，之后的变化一律走变更而不叫改稿。这四条同时成立，才允许把“定稿”两个字写出去。能不能回答“哪一版被谁为什么事改掉”，是区分“设计过程被管住了”和“只是碰巧出了个能用的结果”的唯一标准——前者在洹拓的交付里是可以复用到下一个项目的资产，后者每次都得从头赌一遍。