Claude Code Harness验证：从感觉走向证据

Claude Code Harness 08：Verify：从估算到实测交付

Plan稳固方向，TDD锁定行为。然而局部行为被锁，不等于整个系统能安全交付。

实际项目里Claude Code最常见的卡点不是“不会做”，而是“过早停手”。局部测试通过、代码读着合理、还能给出自洽的解释——系统随即判定“任务基本收敛”。但工程世界拒绝“基本”，只接受“已通过验证”。

本章核心目标：把Verify从“最后想起来补跑”升级为系统默认的闭合环节。

一、Plan和TDD之后，究竟还缺什么

举个真实场景：修复一个接口层缺陷。问题复现明确，写了失败测试，做了最小修复，局部测试通过。整条链路看起来很完整。

但如果直接收工，仍可能遗漏：typecheck未通过、某个lint规则被触发、其他测试因改动了公共依赖而失败，甚至前端调用链被连带破坏。

三者的职能划分如下：

Plan = 定地图，TDD = 锁局部行为，Verify = 验系统是否真正到站

缺少Verify关卡，Claude Code极易卡在“局部逻辑没问题，所以任务差不多完成了”的幻觉里。工程事故最偏爱这个“差不多”。

二、为什么Claude Code特别容易缺Verify

三个结构性原因导致这一缺陷。

偏向完成叙事。 强推理模型天生擅长把现有信息组织成看似完整的结论。一旦bug修了、部分测试通过、代码读着通顺，模型就会快速形成“任务基本收敛”的内部判断。这不是低级错误，而是生成系统的结构特性。

偏向推理而非检查。 模型更擅长分析、解释、生成，而非机械地执行一串命令并逐条核对结果。因此Verify必须设计成系统级机制，单靠一句“记得验证”的提示几乎无效。

缺乏固定顺序时，验证会退化。 先跑test觉得没问题，就不再跑typecheck；build过了，就跳过lint。问题不在于会不会验证，而在于没有固定顺序时验证最终退化为“跑哪个算哪个”。

三、给Verify设定一个固定顺序

不少团队声称“有验证”，实际操作则是“想起来就跑哪里，看到哪里顺手跑哪里”。要让Verify稳定生效，必须给一个固定的执行顺序：

Targeted behavior locked（TDD阶段完成）↓ Build ↓ Typecheck ↓ Lint ↓ Tests ↓ Review / Security Review（按需）↓ Ready or Not Ready

顺序的意义：把“完成”从一种感觉转化为流程的必然结果。

这里有一条深层设计原则——将“做”与“判”分离。生成者天然对自身产出偏乐观，Claude习惯把当前实现解释得合情合理，将局部成功包装成“任务完成”的叙事。更稳妥的做法：让生成和评估在明确阶段中隔离开。

四、任务清晰度 × 验证清晰度

判断Claude Code是否适合深入推进的四象限图：

验证清晰 低 高 任务清晰 +----------------------+ 低 | 高效跑偏 | 可探索 | 高 | 卡在人工验收 | 最适合Agent | +----------------------+

当任务清晰且验证清晰时，Claude Code最能释放价值。任务清晰但验证模糊，吞吐量通常卡在人工验收环节。验证清晰但任务模糊，系统可能高效跑偏。两者皆模糊时，不应扩大Agent自主度。

五、Verify在整个工作流中的位置

Task → Plan → Confirm → TDD / Minimal Implementation → Targeted test passes ↓ Verify ├── Build ├── Typecheck ├── Lint ├── Tests ├── Review └── Security Review（when needed） ↓ Ready / Not Ready

Verify不是收尾动作，而是“完成状态”的仲裁者。没有它，Claude Code口中的“完成”不过是一段自然语言输出。

六、一个真实案例

上一章锁住的结算逻辑测试通过了。此时若跳过Verify，Claude很可能会说“问题已修复”。但开发者仍需确认：这次改动是否影响了payout ledger的其他路径？类型定义有无连带破坏？通知逻辑是否正常？是否引入了新的lint错误？

TDD证明的是“这个行为现在对了”。而Verify证明的是“这个改动放回系统里依然站得住”。局部胜利，是最容易被误判为“整体完成”的陷阱。

七、/verify命令模板

直接固定在.claude/commands/verify.md中，内容如下：

# /verify 运行验证时遵守以下顺序： 1. Build 2. Typecheck 3. Lint 4. Tests 5. Review / Security checks（当相关时） 输出格式： ## 验证报告 - Build： - Typecheck： - Lint： - Tests： - Review： - Security： ## 结果 - Ready for delivery / Not ready ## 剩余问题 - ... 规则： - 验证完成前，不要说任务完成了。 - 任何步骤失败，立即停止并清晰报告。 - 不要把局部成功当作最终完成。

该模板固定了三件事：执行顺序、输出结构、失败时的行为。缺失这三项约束，Claude Code极易先跑最容易通过的步骤、只汇报好消息、失败时还继续硬跑。

八、Verify分层：基础版和扩展版

并非每个任务都需要重型审查。

基础Verify 适用于小功能、局部bugfix、低风险重构，包含build / typecheck / lint / tests。

扩展Verify 适用于鉴权、权限、支付、数据删除、涉及secret或PII的变更，额外包含review和security review。

同样，局部验证与全局验证也应分层。开发过程中先做局部收敛（targeted test、受影响模块的typecheck、相关路径的lint），在交付节点执行全局确认（全量build、全量test、完整review）。先局部、再全局，既不会一上来太重，也不会让交付边界越来越模糊。

九、怎么让Verify真正成为默认路径

仅在CLAUDE.md里写一句“完成前请先验证”，远远不够。需要三层配合：

Rules里立底线。 未验证前不得宣称完成；不得用解释替代验证证据。

Commands里立入口。 /verify作为固定触发点。

Hooks里做拦截。 Stop时提醒当前会话尚未verify；高风险变更前强提醒。

这套组合拳让Verify从“好习惯”进化为系统行为。

十、本章交付

Verify清单：

• 当前任务的targeted behavior是否已被锁住？
• Build是否通过？
• Typecheck是否通过？
• Lint是否通过？
• Relevant tests是否通过？
• 本次改动是否需要code review？
• 本次改动是否需要security review？
• 是否还有未解释的失败或跳过项？
• 能否明确判断为Ready / Not Ready？

社区参考方案：everything-claude-code仓库提供了三个相关命令——/verify（基础四项）、/quality-gate（将验证升级为门禁）、/eval（承接Generator/Evaluator分离）。先判断自己的项目缺少的是基础Verify，还是更成熟的评估闭环，再决定如何借鉴。

最小落地动作：创建.claude/commands/verify.md，先写死基础四项，将review / security review作为第二层补进去。

十一、小结

Plan锁方向，TDD锁行为，Verify锁交付。至此，工作系统开始具备“知道什么时候才算做完”的能力。

但一套系统只要还依赖人记得执行，就一定会退化。下一章进入Hooks：将高频、机械、易遗忘的动作系统化。

来源：互联网