生成流程里要写清谁出题、谁筛选、谁负责
团队分工里，如果生产角色仍是大家都点一下生成，结果往往是出了问题找不到责任落点。
文章 · AIGC 内容 · 教育
迭代次数要事先封顶
生成修改里，如果迭代上限仍是一直改到大家都累了，结果往往是没有标准的修改把时间耗尽，判断却没有增加。更稳妥的做法是事先写明最多改几轮，以及到点如何决定，并用轮次规则把这个选择固定下来。
核心要点
- 在生成修改里，迭代上限不该继续停留为一直改到大家都累了。
- 放着不管，就会反复出现同一件事：没有标准的修改把时间耗尽，判断却没有增加。
- 起点换成：事先写明最多改几轮，以及到点如何决定。
- 把选择写进轮次规则，由任务负责人。
- 以后只按一个问题验收：到了上限，是否有人有权按规则停止。
01迭代上限由谁负责
在生成修改里，迭代上限若没有明确的负责人，就会退化成一直改到大家都累了。大家都参与，也就没有人承担后果：没有标准的修改把时间耗尽，判断却没有增加。
负责不是亲自改每一句，而是有人有权在冲突时维持事先写明最多改几轮，以及到点如何决定。
事先写明最多改几轮，以及到点如何决定。做不到这一点，迭代上限就还停在一直改到大家都累了。
02迭代上限的交接物是什么
交接不能靠口头。上一环交给下一环的，应是轮次规则，而不是继续沿用一直改到大家都累了。
没有交接物时，每个团队都会按自己的理解处理迭代上限，接缝里冒出来的仍是：没有标准的修改把时间耗尽，判断却没有增加。
03迭代上限的节奏怎么排
节奏要固定。任务开始，比等到出了问题再开复盘会更节省注意力。
节奏一旦让给每一个临时战役，迭代上限就只在发布当天存在。
04迭代上限如何被使用
使用方式要简单。打开轮次规则的人，应能判断眼下这件事该不该做。
如果使用轮次规则还需要专人翻译，它就还是一直改到大家都累了，只是换了载体。
05迭代上限怎样算做完
做完的标准不是发出去了。标准是：到了上限，是否有人有权按规则停止。
任务负责人。人离开岗位时，轮次规则还在，迭代上限才没有停在某一次项目里。
框架图
迭代上限的四层结构
从不可让渡的部分到现场可用的工具，每一层只回答一个问题，避免把迭代上限重新写成一直改到大家都累了。
L1轮次
这一层写明迭代上限里什么不能让渡。
L2到点的决定
这一层把迭代上限收成可检查的条件。
L3可以加轮的条件
这一层规定迭代上限在不同场合可以变什么。
L4停止
这一层把迭代上限交给使用的人，并写明例外。
注：本图为概念框架示意，用于说明思考结构，不代表任何统计数据。来源：清美未来洞察团队。
行动建议
行动 01
先看现场
在生成修改里标出迭代上限真正被调用的时刻，不要从改写一直改到大家都累了开始。
行动 02
收成一页
用轮次规则代替更长的说明，只保留能支持「事先写明最多改几轮，以及到点如何决定」的内容。
行动 03
按一个问题验收
任务开始，只问：到了上限，是否有人有权按规则停止。答不上来，就还不是决策。
行动 04
写明维护人
任务负责人。没有维护人的迭代上限，会在冲突里被悄悄改掉。
相关
全部洞察相关洞察
从脚本到画面的交接要有一张纸
影像生产里，如果脚本交接仍是脚本和画面各做各的，结果往往是画面完成了，却没有回答脚本里的判断。
外部生成和内部判断不要混成一个角色
供应商合作里，如果内外分工仍是供应商既生成也替我们做判断，结果往往是内部失去了说不的位置。