发出去之前，人要在固定节点签字
发布流程里，如果签核节点仍是生成完觉得可以就发出，结果往往是没有人承担最后一次判断。
文章 · AIGC 内容 · 科技
先核对事实，再打磨语气
生成后的修改里，如果事实核对仍是先把句子写顺，结果往往是顺的句子把没有核对的事实一起送了出去。更稳妥的做法是流程上事实核对在语气打磨之前，并用核对单把这个选择固定下来。
核心要点
- 在生成后的修改里，事实核对不该继续停留为先把句子写顺。
- 放着不管，就会反复出现同一件事：顺的句子把没有核对的事实一起送了出去。
- 起点换成：流程上事实核对在语气打磨之前。
- 把选择写进核对单，由审校人。
- 以后只按一个问题验收：这句话里的事实是否已经有来源。
01把事实核对拆成模块
把事实核对只看成先把句子写顺，系统就建不起来。在生成后的修改里，它应被拆开，否则说不清问题在哪：顺的句子把没有核对的事实一起送了出去。
拆开不是为了更复杂，而是为了让流程上事实核对在语气打磨之前可以落在不同的层里。
流程上事实核对在语气打磨之前。做不到这一点，事实核对就还停在先把句子写顺。
02事实核对的模块如何对接
事实核对的上下层要有接口。上一层规定不能让渡的部分，下一层才知道自己可以变哪里。
没有接口时，每个场合都会重新解释事实核对，先把句子写顺就从接口的空隙里回来。
03事实核对要规则而不是样本
规则要能执行，样本只能举例。团队若只收藏喜欢的成品，遇到新场合仍会回到旧问题：顺的句子把没有核对的事实一起送了出去。
所以核对单里写的是条件，不是某一张参考。
04事实核对的执行层
执行层要让普通人用得了。每条发布前，检查核对单是否还指向流程上事实核对在语气打磨之前。
执行层一旦只服务熟练的人，事实核对就会再次变成少数人的先把句子写顺。
05事实核对如何迭代而不散掉
迭代时改规则，不改原则的名字。审校人。
每一轮结束都回到同一个问题：这句话里的事实是否已经有来源。能回答，系统就还是完整的。
框架图
事实核对的四层结构
从不可让渡的部分到现场可用的工具，每一层只回答一个问题，避免把事实核对重新写成先把句子写顺。
L1事实
这一层写明事实核对里什么不能让渡。
L2来源
这一层把事实核对收成可检查的条件。
L3尚未核对
这一层规定事实核对在不同场合可以变什么。
L4不能发布
这一层把事实核对交给使用的人，并写明例外。
注：本图为概念框架示意，用于说明思考结构，不代表任何统计数据。来源：清美未来洞察团队。
行动建议
行动 01
先看现场
在生成后的修改里标出事实核对真正被调用的时刻，不要从改写先把句子写顺开始。
行动 02
收成一页
用核对单代替更长的说明，只保留能支持「流程上事实核对在语气打磨之前」的内容。
行动 03
按一个问题验收
每条发布前，只问：这句话里的事实是否已经有来源。答不上来，就还不是决策。
行动 04
写明维护人
审校人。没有维护人的事实核对，会在冲突里被悄悄改掉。
相关
全部洞察相关洞察
审校对照原则，而不是对照个人口味
内容审核里，如果审校仍是审校人按自己喜不喜欢修改，结果往往是标准随人变化，团队无法预期。
生成内容的来源和使用权要能说清
素材入库里，如果使用权仍是先用起来，权属以后再补，结果往往是一旦被问到来源，没有人答得上。