（注：本文为小报童精选文章。已订阅小报童或加入知识星球「玉树芝兰」用户请勿重复付费）

发现

2 月 17 号，我让 Claude Code 检查一项复杂产出作品的质量 —— 一部融入了大量真实世界调研的小说，需要核查叙事逻辑、事实准确性、人物行为归因等多个维度。

主 Agent 自己查了一遍，报告说没什么问题。

我不放心。补了一条指令：启动独立的 Agent，做完全相同范围的检查 —— 主观维度（叙事视角、行为归属、事实准确性）和客观维度（格式、拼写、文件完整性）都要覆盖，跟主 Agent 的职责一模一样。

同样的检查范围。不同的检查者。

独立 Agent 找到的问题，和主 Agent 自己能找到的，完全不在一个量级。

那天晚上，我给这套做法想了个名字：产出者 ≠ 审查者。

这六个字听起来平平无奇，就像「考试要检查」一样 —— 谁不知道呢？

但第二天发生的事，让这六个字从一条直觉变成了一条铁律。

翻车

2 月 18 号晚上，我在 Telegram 上给自己的 OpenClaw^[1] 机器人布置了个任务。

跑是跑了，但结果迟迟没推过来。我主动去问，它才说做完了 —— 但结果包也没发给我。

这种毛病得修。我让 Claude Code 去排查原因。

它很快扫了一眼日志，发现了几个「问题」：一个空的配置文件，一份不完整的行为说明。然后 —— 没等我反应过来 —— 它已经开始重写文件、重启服务了。

我当时没拦。心想，快刀斩乱麻嘛。

修完之后，我又给 OpenClaw 机器人派了个新任务。做完了。

还是不主动发结果。

一模一样的症状。

Claude Code 又开始调查。看了几行代码，说发现了两个新线索，然后它又准备动手改了。

我拦住了它，提要求：

「别急着去改。调查、调研、列计划并进行校验，之后没有问题再去动手。」

第一次修的时候，它看到的那些「问题」 —— 空配置文件、不完整的说明 —— 并不是根因，只是恰好撞见的表面症状。它重写了三个文件，重启了一遍服务，忙活了一通 —— 但真正导致消息不推送的根因，压根没碰到。

这不是能力问题。Claude Code 的调查能力其实很强。问题出在节奏上：它一边调查一边就开始改，调查做了一半就动手了。而且 —— 这才是关键 —— 它完全没有让任何人来校验它的修复方案。

自己看出问题，自己拟方案，自己执行。全程都是一个「脑子」在思考和规划。

叫停之后，我让 Claude Code 换了个做法。不许自己动手，先派两个独立的 Agent 去做深度调查。

Agent 1 追到了心跳调度模块的源码，发现 Agent 选择逻辑有两条不同的路径，只有一条能正确触发推送。

Agent 2 追到了媒体文件验证逻辑，发现有五个硬编码的允许目录，而工作区路径恰好被排除在外。

两条根因都找到了。形成了一份完整的调查报告和三步修复计划。我确认后才执行。

这次修好了。

同一个工具，同样的调查能力。区别只在于：第一次是自己查自己改，第二次是独立 Agent 先查、形成方案后再改。

这件事之后，我让 Claude Code 把一条规矩写进了系统指令（用户目录下的 CLAUDE.md） —— 写在最高优先级的位置：

在完成全部调查和计划校验之前，禁止执行任何修改操作。

但我关注的焦点，其实不对。

后面发生的事让我意识到，「先调查后动手」只解决了一半问题。更深层的问题是：谁来做校验？

冰山

我找到的答案是：换一个完全独立的 Agent，让它从头审视。

2月20号， 我用 Skill 做了一份深度调研报告，分享到了社区。有读者告诉我，报告里第 73 行的超链接有问题 —— 链接指向的 GitHub issue 里根本没有报告声称的内容。

读者就反馈了这一处错误。

我本能的反应是直接改掉这个链接。但我克制住了 —— 我给自己立了一条规矩：「出现了问题不要只想着修结果，要找到根因修机制，然后再修结果。」

所以我先让 Claude Code 去修 Skill —— 教它做特定任务的规则集。在事实核查模块里补上一条新规则：「每个超链接必须指向实际包含该声明的具体页面」。

然后，我让一个独立 Agent 拿着这条新规则去回扫全文。

它找到了 7 处错误。

注意，不是 1 处。是 7 处。

其中有一处，报告说「Meta banned OpenClaw」然后挂了一个韩国时报的链接 —— 但那篇韩国时报的文章里根本没提 Meta。还有两个法律引用链接，一个指向了 Congress.gov 的首页而非具体案例页，一个指向了司法手册的目录。还有一处，把输入价格写成了输出价格……

那个我最初发现的错误，只是冰山一角。独立 Agent 用全新的眼光回扫了一遍，发现已知错误的 7 倍。

多悬啊。

接下来这个例子，暴露的不是「漏了多少」，而是「为什么会漏」。

2 月 17 日，我发现产出物的开头出现了一个不该有的「总帽」 —— 就是那种概括全文的导引段落 —— 而且删掉了一些生动的原始内容。要知道，对于小说而言，这种总帽无异于剧透啊。

我去查了规则文档。规则确实写得清清楚楚：「禁止在第一个 H2 之前插入总帽段落」、「不得删除原始内容」、「工具名称必须具体化」。五条 BLOCKING 规则，白纸黑字。

但是，负责终审的 Proofreader —— 整条流水线上唯一的质量关口 —— 它的 18 项检查清单里，根本没有这五条。

规则写了。但负责执行检查的人不知道要查这些规则，等于没有写。

这就是「工作流内校验」的致命缺陷：你在文档里写了检查步骤，但检查步骤本身可能是有漏洞的。如果产出者和审查者是同一个系统，这个漏洞可能永远不会被发现 —— 因为那个系统会认为自己的检查是完整的。

超链接核查、工作流审计 —— 两个完全不同类型的任务，暴露出同一个问题。只要没有独立的 Agent 从头审视，任何一次严肃产出都可能藏着你看不到的错误。不只是某个环节特别容易出错所以需要加强计划，而是「自己查自己」这件事本身就不可靠。

为什么会这样呢？

原理