这几天一直在忙着干我的本职工作，只分出了不到一半的时间在我的业余码字爱好中。发现我的正经工作也是需要很多码字的，幸好有【江湖儿女】这个小论坛在手。突然心血来潮，决定把这一套工作改头换面一下，稍微总结总结，似乎也能共享出来。挺好。
好。言归正传，现在很多人开始直接用AI进行编程。代码一下生成几千大行。以前那一套软件工程，总体设计、概要设计、详细设计，coding、单元测试、集合测试和系统测试等过程完全用不上，以前我们算工作效率，每天平均编码量到20～30 lines 就很了不起，这个值如果过高，品质测试部门是会投诉你的，说你一定是哪个过程稀里糊涂了。那个豪横，你还没地找人说理去。
现在好了，程序员开始都用 AI Coding Agent 写代码了，一个很明显的变化是：代码产出速度变快了，而且快得非常不适应。以前一个需求可能需要半天搭接口、改逻辑、补测试。现在描述清楚一点，AI 很快就能生成一批文件、改一串调用链、顺手补一些测试。效率确实提高了，但另一个问题也随之出现：我们该如何验证 AI 输出代码的质量？
如果 AI 一次生成几百行甚至上千行改动，让人再逐行 Review 一遍，成本会迅速高到不可接受。人的注意力会被大量 diff 消耗，最后很容易变成只看几个关键文件、扫一下大概逻辑、再相信测试结果。问题也就从“怎么更好地 Review AI 写的代码”，变成了：在 AI Coding 时代，代码质量到底应该怎么验证？ 答案越来越明确：代码阅读仍然有价值，但质量验证的主线却又必须放到如何测试AI的测试案例上。
人工逐行 CR 正在变得不现实
传统 Code Review 的默认前提是：代码变更量相对可控，人可以通过阅读 diff 理解改动意图、发现风险、提出修改建议。AI Coding 改变了这个前提。AI 很擅长一次性生成大量结构完整的代码。一个需求下来，它可能同时改业务逻辑、接口边界、数据结构、测试、配置和文档，还会顺手调整一些相关调用。产出端看起来效率很高，Review 端的压力也随之上来。
一个人面对大段 AI 生成代码时，常见状态是：看起来都挺合理，命名也还可以，测试也补了一些，但我不确定它是否真的满足需求。这才是关键问题。Code Review 能发现一部分问题，比如明显的坏感觉、重复逻辑、异常处理遗漏、命名不一致。但业务正确性往往藏在更具体的行为里。
如何解决呢？有一个核心思路是：用外部反馈判断结果
不要让AI依赖“自我感觉”判断结果，要通过外部反馈来约束它。放到 AI Coding 里，这个外部反馈最直接的形式就是测试。
判断标准如果停留在两类反馈上，风险会很高：AI 解释说这段代码已经满足需求，或者另一个 AI Review 后觉得没问题。更可靠的反馈应该来自工程系统本身：有一组测试或验收证据，能够证明这个需求被满足。这才是关键点：要让代码去面对现实系统的反馈，要减少对模型解释的依赖。
理想流程要从“AI 自我判断闭环”调整成“外部反馈闭环”。
这一步很重要，因为它把 AI Coding 从“语言层面的合理”拉回到“工程系统里的可验证”。不过，这里马上会遇到第二个问题。
问题转移了：测试用例本身可靠吗？
如果我们说“用测试判断 AI 代码质量”，下一个问题就是：测试是谁写的？在 AI Coding 场景里，测试通常就是 AI 写的。于是闭环可能变成：AI 写代码和AI写测试的互证风险。
这当然比没有测试好，但还不够。测试可能只验证了实现细节，或者只覆盖了最顺的 happy Path。更糟糕的是，如果 AI 对需求理解错了，它很可能会写出一组“和错误实现互相证明”的测试。测试通过了，业务却是错的。
所以重点从“有没有测试”继续往前推了一层：测试用例是否真的对应业务需求，测试覆盖的验收标准是否正确，有没有遗漏关键边界和异常路径。测试代码 的外部反馈不能只停留在“跑测试”。测试本身也要进入质量控制。
所以AI coding似乎是可以的，好像路径很happy，但测试案例如果完全交给AI的话，风险就会很大。
这就是我这几天在正经工作中悟出的一点道理，完全歪楼了。后面我打算继续在这条路上歪下去。个人觉得这是一个有意思的尝试。
