验证：当人不再能兜底

🚧 本章正在开发中。本文是章节开篇，子节内容陆续补充。

卷一的验证体系把规约作为锚点，用测试和 code review 检查代码是否忠实于 spec。最后一道兜底是人。Agent 漂移了，测试覆盖不到的角落，人凭对项目的理解能补上。卷一最后给出的画面是 26/28 项合规通过，剩下两条是人 review 时发现的。

这条兜底前提在卷二不再成立。原因有两个，任何一个单独都足以打破前提。

第一个是带宽。多个 Agent 并行，每条线程都在产出。人盯不过来。卷一时一天三四个 feature，review 的时候每段代码都能过一遍眼。卷二里每天可能有几十段代码同时落地，人就是想看也看不完。

第二个是知识盲区。卷一里项目通常是开发者自己熟悉的领域，一份 spec 出来看着对不对，凭业务理解能判断。换到完全陌生的领域，情况完全不一样。一个全栈开发者去做编程工具，里面 99% 的判断点都是知识盲区。代码看起来对不对、PRD 写得行不行，都没有判断力。这种情况下让人当兜底，不是兜底，是放过。

带宽和盲区任意一个出现，卷一的验证体系都会失效。卷二里这两个常常同时出现。

单层验证一定会漏

人不能兜底之后，验证就要全部交给机制。但任何一种机制单独存在都有它的盲区。

单元测试覆盖代码行为，覆盖不了意图。代码漂亮地实现了一个错的需求，测试照样通过。

Code review 覆盖代码意图，但 review agent 自己有 attention 限制。让一个 agent 同时读 spec 和几千行代码，它会漏。漏在哪儿你不知道。

脚本检查不会漏，但只能查格式和结构，看不懂语义。模型检查反过来，能看懂语义，但模型自己会 attention 漂移，会丢三落四。

每一种机制单独看都有自己的盲区。区别在于不同机制的盲区不一样。这是 defense in depth 的工程基础：不是因为重复的检查更可靠，是因为不同层抓的是不同类型的漏。多层叠加之后，任意一层的盲区被另外几层覆盖。

每一层都要尽量做强，但承认每一层都不完备。这是这一章的工程姿态。

后面五节从原则到落地，最后一节用一条完整路径走通。

第一节把 defense in depth 的设计原则讲透：层之间的关系不是冗余，是分工。每一层覆盖什么、漏什么、靠哪一层补。

第二节讲两类不可替代的检查：脚本驱动的硬门禁和模型驱动的软门禁。这一节具体讲两者怎么叠加，各自负责什么，叠加之后还会剩下哪些漏。

第三节讲结构化输出。一份漂亮散文写的 PRD 没法机械化检查。要让脚本能查，文档格式本身必须机器可读。这一节具体讲怎么把 spec 设计成可被脚本逐项验证的形态。

第四节讲并行审计。当审计任务本身要读长文档时，审计 agent 也会 attention 漂。解法是拆成多个独立 context 的 subagent，每个只负责一个角度，各自独立审，然后汇总。

第五节讲集成验证。多线程产出的合并不是文件级别的合并，是检查每条线程做出的局部决策互相不矛盾。集成验证的对象是决策边界的兼容性，落地是 API 契约 + 泳道隔离 + Mock 替代。

最后一节走完一条产出从生成到通过验证的完整路径。

Harness Engineering Playbook · AgentsZone Community