验证：确保代码忠实于规约
上一章的 OKR 案例里，spec 经过两轮迭代修正，13 条 acceptance criteria 和 5 条 business rules 全部定义清楚。Agent 根据这份 spec 生成了 12 个后端文件、4 个前端文件。合规检查的结果是 26/28 PASS。
漏掉的两条不是偶然。BR-002 要求"每个目标最多 5 个 KR"，Agent 在前端做了 Element UI 提示，但后端没有加 ServiceException 校验。绕过前端直接调 API，就能突破限制。BR-004 要求"打开新增页面时默认选中当前季度"，Agent 没有实现这个默认值逻辑。
这两个问题有一个共同特征：代码本身写得很好，接口设计合理，命名规范，测试也能跑过。它们不是代码质量问题，是意图丢失。Spec 说了，代码没做。
规约解决的是"告诉 Agent 做什么"。验证解决的是"Agent 是不是真的做了"。
意图偏离：现有工具的盲区
这个问题不只是我们发现了。Anthropic 在 harness 设计的一系列文章中明确指出，把生成和评估分开是质量控制最有效的杠杆。行业共识已经形成：验证是 harness 工程中最核心的环节之一。
各框架在这个方向上做了大量尝试。BMAD 设计了三层信息不对称的代码审查，让不同的 reviewer 看到不同范围的信息来减少确认偏差。Spec Kit 用 constitution 治理和 10 类歧义检测在 spec 阶段就拦截质量问题。OpenAI 和 Anthropic 都发布了多 Agent 并行 code review 系统和 eval 框架。社区里 TDD、Trophy 测试、对抗式 review 的讨论也从未停过。
如果你在真实项目中大规模使用过这些验证工具，你会发现一件事：代码可以通过所有 lint、所有单元测试、所有对抗式 review，但它实现的功能和 spec 说的不是一回事。
null check 缺失、命名不规范、安全漏洞，这些代码质量问题 AI 自己就能发现并修复。真正难以检测的是意图偏离，spec 说要 A，代码实现了 B。上面的 BR-002 就是这类问题：代码写得很好，只是漏掉了 spec 里的一条业务规则。任何不看 spec 的 review 都不会发现它。
2026 年 3 月发表的 TDAD 论文提供了量化证据。研究者发现，告诉 Agent"请遵循 TDD 流程"这样的抽象流程指令，反而让回归率从 6.08% 上升到 9.94%。但如果用工具分析 spec，告诉 Agent 具体应该检查哪些测试，回归率降到了 1.82%。流程指令不是答案，spec 上下文才是。
这些工具失效的原因是同一个：它们的参照系都是代码本身，不是 spec。能回答"这段代码有没有 bug"，但回答不了"这段代码是不是 spec 要求的东西"。BR-002 的后端校验缺失不会被任何基于代码的检查发现，因为代码本身没有 bug，只是缺少了一个 spec 要求的功能。
验证的锚点是规约
要回答"代码是不是 spec 要求的东西"，需要一个代码之外的参照系。这个参照系就是规约。验证的 single source of truth 是规约，不是代码。
所有验证动作都在回答一个问题：这段代码和文档说的是不是一回事。测试在验证"代码是否实现了 spec 说的行为"，不是在验证"代码对不对"。Code review 在问"代码和 spec 一致吗"，不是在问"代码好不好"。脱离 spec 做 review，你只会得到"代码结构清晰，建议补充异常处理"这样正确但无用的反馈，因为它没有回答代码是否忠实于规约这个问题。
这也是为什么规约章在验证章之前。没有好的 spec，验证就没有锚点。
验证必须前置、过程中、模块化
验证基建必须在编码前就位，在执行过程中持续运行，并且按模块拆分。这个结论由 Agent 的两个结构性特征决定。
Agent 在执行中会漂移。规约章已经建立了这个概念：Agent 的输出随着 context 积累而偏移，小偏差在后续步骤中累积。在代码实现阶段，这意味着第十步的代码可能已经偏离了第一步参照的 spec。如果等全部写完再验证，你面对的是几十个失败的测试，每个指向不同的问题，修复成本远高于过程中修复。所以验证必须是过程中的，不是事后的。
Agent 的上下文容量有限。这个限制不仅适用于编码，也适用于验证。让 Agent 一口气写了 2000 行代码，再让另一个 Agent review，review Agent 需要同时理解 spec 的内容和 2000 行代码的实现，然后判断两者是否一致。这超出了它的有效处理范围。结果要么漏检，要么给你一堆"建议优化命名"的泛泛反馈。所以验证的粒度必须和执行的粒度匹配：执行拆成小块，验证跟着拆成小块。
这两个约束共同指向：先把 spec 转化为可执行的测试框架，让 Agent 从第一步开始就有反馈信号。DORA 2025 报告用大规模数据佐证了这一点：AI 是已有工程实践的放大器。有验证基建的团队，Agent 的速度放大的是产出。没有验证基建的团队，Agent 的速度放大的是混乱。
那么前置的验证基建具体包括什么？
测试和 code review 缺一不可
验证 spec 一致性需要两个机制，不是一个。社区中反复出现一种情况：团队只用了其中一个，体验不好，就得出"AI 编程不可靠"的结论。
只做 code review 不做测试的团队会发现：review 能发现代码和 spec 的偏离，但验证不了运行时正确性。Review 说"这个逻辑看起来对"，不等于代码跑起来真的对。
只做测试不做 code review 的团队会遇到另一个问题：测试能验证行为，但覆盖率很难达到 spec 的全部意图。Agent 可能用硬编码绕过测试，比如直接 return 预期值让测试通过。测试全绿，但代码里埋着只在特定条件下才会暴露的问题。
两个机制的目标相同：让 spec 变成可执行的约束。但它们覆盖的维度不同。测试验证行为正确性，spec 说的功能代码做到了吗。Code review 验证语义完整性，代码有没有偏离 spec 的框架，有没有做 spec 没说的事。
成本结构也不同。测试的成本低、运行速度快、反馈即时，是过程中持续验证的主力。Code review 成本更高，适合在阶段节点做。两者在成本和覆盖面上互补。
本章分别展开这两个机制。下一节讲测试基建：怎么在第一行业务代码之前，把 spec 变成可执行的测试框架，让 Agent 在执行的每一步都有反馈。之后讲 code review：怎么用独立的 Agent 审查代码和 spec 的一致性，补位测试覆盖不到的意图漂移。最后用 AILock-Step 框架的实践展示这两个机制的完整链路。
Harness Engineering Playbook · AgentsZone Community