没核实的要显式列出来，并禁止 Agent 推测

2026-08-25

我这条内容流水线的分工是固定的：开工前我先把能核实的硬事实固化成一张事实卡，卡里每条标明来源；子代理只准使用卡内内容，卡里没有的不许补。这么分工的原因很实在——写作本身不是瓶颈，核实才是。让每个子代理各自去核，既慢，各自核出来的结论还会互相打架。

那一批我照例整理了一份条目清单。整理到后半程，有一部分条目卡住了：有的官网直连被挡住，只在第三方登记站点上找到彼此一致的记录；有的信息模糊，我一时判断不了。我当时的处理很自然——核到的写进卡里，没核到的先空着，想着回头补。

稿子交上来，空着的那几项，没有一项是空的。

补上去的内容，一点都不像补的

它们不是胡编乱造那种一眼假。填进去的东西句式工整、语气笃定，和我亲手核实过的条目放在一起读，看不出任何差别。没有”据称”，没有”可能”，没有任何一处留下”这里我不确定”的痕迹。

后来我把这一批的处置逐条记进了提交记录。有一条原先被写成开源，实际核下来官网上挂着软件著作权登记和商业模块，是闭源，得改回去；有一条我最终没能直连核到，改判成第三方交叉核实，如实标注”非直接核实”而不是当成核过；还有一条记的是我自己——我凭猜测给出了一个域名，这次流程错误也照样写进了记录。

最后那条我一开始不太想记。记完之后反而踏实了：一份规格的可信度，很大一部分来自它连自己的错也记。

是评审阶段撞出来的，不是读出来的

这一段我一定要写清楚，因为发现方式比问题本身更值钱。不过先说清记录的边界：具体是哪一天、卡在哪一篇上撞出来的，我没有留下记录。我能确认的只有它最后是以”处置”的形式被逐条登记下来的——而”登记处置”这个动作本身说明它是被翻出来的，不是自己浮上来的。

有一点我可以确定：不是通读稿子发现的。通读的时候它完全通顺，甚至比我自己写的更像回事。真正撞出来靠的是两条机制，都跟”读得好不好”无关。

第一条是评审员的抽查回源。我这条线上，实现者和评审员是两个互不通气的独立代理，评审员拿不到实现者的推理过程，只拿到落盘的文件和规格。规格里给它的动作不是”你判断这句话对不对”，而是”文章里出现的具体名称、路径、配置项，抽查若干处回到事实卡里找对应条目”。这个动作是机械的：找到了，过；找不到条目，报出来。它不需要判断真假，只需要判断有没有出处。恰恰是这种不带判断的核对，把那些语气笃定但无源可依的句子挑了出来。

第二条更靠后：我给评审员的权限里明确写了它可以质疑事实卡本身，而不只是核对文章符不符合卡。这一条真的救过场——有一次评审阶段反查出卡里某处内容本身是错的，而它已经被写进好几篇里，我得自己实测修正，再全批回查一遍。这类错误不止是数值写错：也可能是某处表述本身有问题，比如一节标题声明的条数和下面实际列的对不上，或者改卡时只改了一处、忘了回改上面那句，造成新旧两种说法并存。事实卡一旦错，错误会按已写篇数等比例放大，这是这套解耦机制的代价，也是评审员必须有权反查上游的原因。

两条机制的共同点是：它们都不依赖任何人读出”这句话有点虚”。补全的内容自带零信息量——它不会给你留标记，你只能靠结构化的回源动作把它撞出来。

缺口不会被报上来，它会被填上

事后想为什么，三层原因叠在一起。

第一层，任务书要的是一篇完整的成品。在下游眼里，一个没写内容的位置不是”允许留空的格子”，而是”待生成的部分”。我以为空白在表达”这里没有依据”，它读到的是”这里轮到你写”。

第二层，它没有核实能力，也不被允许有。我这条线上子代理是禁止联网的——联网工具挂起的时候不报错、不返回、一直显示运行中，被挂住的代理还会把已经写好的成品覆盖掉。识别信号是任务显示运行中但磁盘上零文件。核实这件事只能由我来做。所以面对缺口，它其实只有两条路：推一个出来，或者报缺。

第三层，也是我真正的失误：报缺这条路当时不存在。正文里没有一种合法写法能表达”这一项我没有依据”，返回的结构化字段里也没有一个位置让它说”我卡在这”。一条路不通的时候，另一条就成了唯一的路。它不是不老实，是我只给了它一个出口。

这三层里最该记住的是第一层：留白不是中立的。在一份要求完整交付的任务书里，留白等于默许下游自由发挥。

顺带一提，我凭猜测给出域名那次，走的是同一个机制。缺口落在谁手里，谁就有把它填上的冲动，跟是不是代理没关系。

我改成了什么

改动集中在事实卡和任务书两处，都是加东西，不是加叮嘱。

一、“没写”和”写了但未核实”变成两种可见状态。 卡里把未核实的项逐条列出来，每条后面跟一句”未核实，不许推测”。不再用空白表达”这里没有”——空白表达不了任何东西，它只会被理解成待办。写进去的那句禁令才是内容。

二、给报缺造一个出口，并且让它比编造更省事。 两个位置：正文里允许直接写”这一点我没有记录”；返回的结构化结果里固定留一个字段，专门写不确定的地方和需要我去核的东西。这里的关键是省事——如果报缺比推断更麻烦，出口就是摆设。现在写一句”我没有记录”，比编一段听着靠谱的话要省力得多，它自然会走这条路。

三、碰到未核实项时的默认动作定死为升级，不是自行处理。 加上评审员保留质疑事实卡本身的权限。这两条合起来，让”未核实”这一档在交付链条上始终是可见的，而不是走一道工序就悄悄变成”已核实”。

还有一条不算改动，算习惯：每次翻车都回写进规格。从零把规格想全是不可能的，但翻过的车不回写，同一个坑一定会再踩一次。我自己那次猜域名，就是按这条规矩记进去的。

能带走的那句话

要让下游报缺，先得给它一个报缺的位置，并且让报缺比补全更省事。

把”Agent”这个词去掉，这句话对人也部分成立——人遇到缺口也会想填。但人手里有一个默认动作叫”问”，而且问的成本通常低于编。下游代理没有”问”这个动作，除非你在任务书和返回结构里替它造一个。所以这条对代理更要紧，差别不在程度，在那条路存不存在。

现在我验收的时候换了个问法。不再问”这里写得对不对”——通顺的假话我读不出来；改成问”这句话的依据是卡里哪一条”。找不到对应条目的句子，无论多通顺，一律按没有依据处理。

这篇写的是我自己那套流程里的一次实际情况，不是通行做法。你的场景、工具和团队规模不同，结论未必适用，判断方式可能比结论更值得拿走。