根因是理解缺口会贯穿全部产出#

Agent 根据当前上下文形成需求模型，再据此写代码和测试。如果最初遗漏了调用方、权限边界或兼容条件，它生成的测试也可能只验证同一份错误理解。

因此“让原 Agent 再检查一次”经常只能发现局部实现问题，无法证明问题范围本身完整。验证需要从代码、运行环境和独立评审中取得新证据。

四个阶段分别回答不同问题#

阶段顺序从便宜到昂贵。前一阶段未通过，就不把有缺陷的版本继续推向部署和外部系统。

独立审查与双向验证减少共同盲区#

代码审查使用干净上下文，避免继承实现过程中的解释和自我辩护。边界测试同时从需求向代码检查“是否实现”，也从代码调用路径向外检查“还有哪些真实行为未写进需求”。

两条方向的差集最有价值：

1
需求声明的范围
2
∩ 代码真实影响范围
3
∩ 测试与环境提供的证据

若三者不一致，应先补充问题模型，再修改代码，而不是只增加一条局部断言。

当前选择：验证强度由风险决定#

涉及共享状态、权限、并发、兼容性或外部副作用时，我会执行完整四阶段，并在每阶段保留结果。纯文案、注释和无副作用的小改动，只运行静态检查与直接预览。

这套流程增加了审查和环境验证成本，也不能保证发现所有语义错误。它的作用是让不同阶段使用不同证据，尽早暴露理解缺口，并限制错误进入真实环境后的影响范围。