验证闭环：AI 生成不等于交付

生成可以外包给模型，信任不能外包。验证闭环的工作，是把"看起来对"逼成"真的对"。

前面的章节让 AI 写出了GMV 清洗迁移链路。但工程上不能说"代码生成了，所以完成了"——你需要证明它满足规格、守住边界、不破坏系统。

一、机制：为什么"看起来对"是模型的强项

AI 生成的GMV 清洗迁移链路通常卖相很好：分层清楚、命名规范、有事务注解、本地能跑、还带几条通过的测试。要理解为什么这不构成信任，得回到模型的工作方式：

语言模型优化的目标是"像正确的代码"，而不是"是正确的代码"。

“像”与“是”的差距恰好落在验证最贵的地方——平台口径、预览副作用、部分失败和汇总门禁：这些性质在代码文本上不可见，只在运行行为与结果数据里显形。

这个机制差距有实证注脚：多项独立评测（如 Veracode 2025 年对上百个模型、多语言编码任务的安全测试）显示，接近半数的 AI 生成代码样本带有已知安全缺陷模式——而这些代码在功能上大多是"能跑的"。DORA 2024 观察到的"AI 采用度上升、交付稳定性下降"（见认知篇），合理的解释正是：生成速度上去了，验证没有等比例跟上。 验证闭环就是补上这个比例的环节。

二、原则：验证业务意图和边界，而不是代码风格

AI 已经能把风格做得很好，所以 review 的重心必须上移：

不要看代码像不像工程师写的，要验证它是否满足业务意图和边界条件。

验证的依据不是临场发挥，而是前面环节的产物——规格的 EARS 规则、边界规格、工作单的验收标准。这是规格驱动的结构性收益兑现的时刻：每条 WHEN…THEN…SHALL… 规则就是一条现成的测试用例，验收不需要重新发明标准。

三、四道验证闸门

闸门	检查什么	执行者	自动化程度
① 规格符合	是否仍在总控与平台执行器边界内、未改既有平台口径、目标表白名单与错误契约保留	Review Agent + ArchUnit	边界可全自动（CI），语义半自动
② 行为正确	EARS 规则逐条：预览、写入、未知平台、无效日期、部分失败、完整成功	测试套件	全自动
③ 风险暴露	目标表白名单、平台口径泄漏、汇总门禁、影响面与新旧结果差异	故障注入 + 静态分析 + 调用链与数据核对	半自动
④ 回归闭环	修复后全量回归；失败原因沉淀回上下文	CI + 人	执行自动，沉淀靠纪律

第④道闸门的后半句是"闭环"二字的含义：失败不只是要修掉，还要问"哪个环节本该拦住它"——是体检漏了维度、规格漏了规则、还是工作单漏了禁区。答案回流到对应环节，就是缺陷库的入库动作。修了但没沉淀，同一类缺陷下个迭代还会再来。

四、GMV 清洗迁移链路验收清单

【规格符合】
- [ ] 总控不直接依赖平台 Mapper，平台特例保留在执行器内（ArchUnit/Review）
- [ ] 错误码符合接口契约

【行为测试】（逐条对应 spec.md 的 EARS 规则）
- [ ] save=false 不删除、不写入、不刷新汇总
- [ ] save=true 只写入配置白名单中的目标表
- [ ] 未知平台返回 UNKNOWN_PLATFORM
- [ ] 无效日期返回 INVALID_DATE_RANGE
- [ ] continueOnError=true/false 两条失败路径符合契约
- [ ] 所选平台全部成功才刷新完整汇总

【异常与事务】
- [ ] 单平台失败返回平台、阶段和错误原因
- [ ] 任一失败时不把部分结果包装成完整成功
- [ ] 同范围重跑严格遵守已确认策略并保留运行记录

【回归】
- [ ] 原有 GMV 汇总查询通过
- [ ] 新旧链路按同平台、同日期范围核对行数、销售额、退款额和关键维度
- [ ] 未解释差异进入待确认清单，不宣称口径一致

五、测试有效性：测试必须能真实失败

验证闭环里最隐蔽的失效，是测试本身是假的。AI 完全能生成一组永远通过的测试——断言宽松、mock 掉关键路径、或者干脆和实现共享同一个错误假设。三条防线：

① 先证明测试能红。 任何失败路径测试，先构造触发条件让它失败一次，再验证修复后变绿。没红过的测试不能证明任何事——这是 TDD 红绿循环在 AI 场景下的新价值：它不再只是设计方法，而是对测试真实性的存在性证明。

② 测试与实现分离。 测试 Agent 独立上下文、禁改生产代码；实现 Agent 禁止为通过测试修改测试（见工作单的互设禁区）。

③ 用变异测试抽查测试质量。 变异测试（mutation testing，Java 生态有 PIT）向生产代码注入小改动（翻转条件、删掉回滚），看测试能否发现。覆盖率衡量测试跑过哪里，变异得分衡量测试守住哪里——对 AI 生成的测试，后者才是有效指标。这也顺带回答了覆盖率崇拜的问题：一套 90% 覆盖率、变异得分 40% 的测试，比 70% 覆盖率、变异得分 85% 的危险得多。

对照第一节的机制就清楚这三条防线在防什么：模型擅长生成"看起来对"的代码，同样擅长生成"看起来测了"的测试。

六、验证的成本分级

验证不是越多越好，它和执行一样遵循任务分级：

• S 级：现有测试套件回归 + 自测，不新增验证资产；
• M 级：闸门②③（行为测试 + 风险暴露），新增测试对应工作单验收标准；
• L 级（GMV 清洗迁移这类经营口径与存量链路）：四道闸门全过，故障注入与新旧数据核对必做，关键路径跑变异测试抽查。

判断依据仍然是缺陷逃逸代价：GMV 口径错误或部分结果被标记为完整会污染经营判断，验证投入不能省；错误提示文案写错，回归通过就够了。

七、本章小结

• 模型优化的是"像正确"而非"是正确"，差距恰好落在文本上不可见的行为性质（并发、事务、兜底）里；近半数 AI 生成代码带已知缺陷模式的评测结果是这个机制的注脚。
• 验证依据来自上游产物：EARS 规则即测试用例，边界规格即 ArchUnit 断言——规格驱动的收益在验证环节兑现。
• 四道闸门：规格符合、行为正确、风险暴露、回归闭环；闭环 = 修复 + 追问"哪个环节本该拦住" + 沉淀回流。
• 测试必须能真实失败：先红后绿、测试与实现互设禁区、变异得分优于覆盖率。
• 验证按 S/M/L 分级投入，与缺陷逃逸代价成正比。

下一章 AI 代码缺陷库，把验证中反复出现的失败沉淀成事前防线。

---

参考资料

• Veracode, GenAI Code Security Report（2025）——跨模型、跨语言编码任务的安全测试：近半数 AI 生成代码样本含已知缺陷模式。
• PIT (pitest)——JVM 生态的变异测试工具：用变异得分衡量测试套件的真实防御力。
• DORA, Accelerate State of DevOps Report 2024——AI 采用与交付稳定性的负相关观察。