测试：AI Coding的终极质量控制手段

你答不上来。你想过，但越想越觉得这个问题没有简单答案。AI写代码确实快，但快了之后，测试谁做？review谁做？出了bug谁负责？

这也是我们Agent管理学论坛第12期的主题。这个研讨会我们办了十几期，这一期聚焦端到端测试，晓灰分享，Ryan主持。

大家研讨了两个半小时，有很多共识，也有很多分析。先说说大家都同意的。

测试在AI时代是第一公民。

AI让代码生产成本趋近于零，没有测试验收的代码就是泔水。这一点在场所有连续用AI维护过生产代码几个月的人都有切身体会：你噗的越多，代码越丑陋，维护成本比松弛的成本还高。代码你甚至可以不怎么看，但测试一定要看。

AI降低了测试成本，但目前没有发明任何新的测试方法。

分层测试、mock、自动化、覆盖率，全是教科书上现成的。AI的贡献是把以前只有金融行业才能落地的good practice，变成了所有团队都能用的东西。端到端测试、GWT用户故事、自动化循环，方法论都是老一套，AI只是让执行成本暴跌。

先写测试用例再写代码有价值，但TDD的红绿循环需要重估。

TDD的核心价值是逼你想清楚需求，AI时代代码写得太快了，一步一个红绿循环反而拖慢节奏。但"先定义预期行为，再让AI实现"，这个思路大家都认同。

更有意思的，是讨论中浮现出的五个没人能回答的问题。

问题一：测试review的速度跟不上AI生成的速度

AI一次产出三四十个测试用例，你真的能一个一个review完吗？

有朋友碰到了一个很实际的问题。他写了二三十个GWT（Given-When-Then用户故事），让AI生成对应的测试代码，结果AI漏了几个GWT没覆盖到，他自己review也没看出来。直到手动点了一遍功能，才发现有东西根本没做。

有朋友的回答是"大力出奇迹"：一次不行就跑两次，两次不行就十次，反正大模型便宜，token烧得起。这个思路有道理，但你仔细想，它其实在回避问题。你跑十次能覆盖的是AI偶尔遗漏的情况，但如果AI系统性地往某个方向偏（比如只测happy path，忽略边界条件），跑一百次也是同样的偏差。

测试本来是AI时代最后一道人工防线。但这道防线本身正在被AI的产出量冲垮。你越来越像一个流水线上的质检员，传送带速度越来越快，你检查的覆盖率却越来越低。

问题二：不可控的外部依赖怎么测试？

讨论中出现了两个极端案例。

一个是做脑刺激器的同事。他的产品要通过蓝牙和植入人体的设备通信，蓝牙信号受植入位置、角度、电磁环境影响，物理世界不可模拟。你没办法在测试环境里重现"患者站在微波炉旁边"这种场景。

另一个是做欧洲银行系统的朋友。开放银行API是法律强制要求银行提供的，很多银行提供的API质量很差，没有沙盒环境，即使有沙盒，沙盒和生产环境的行为也经常不一致。

大家讨论的共识是"按use case来mock，不要试图重建整个系统"。你mock的目的是模拟你要测试的行为，不是复制被依赖系统的全部行为。否则你的重心就从你自己的系统转移到了重建依赖系统，无穷尽。

但这里有一个更深层的问题。mock本身是有状态的，跨请求之间有依赖关系。比如银行系统里，上一个请求的权限scope会影响下一个请求的返回结果，什么时候返回403什么时候返回200取决于之前的调用链。搞到最后，经常自己都搞不清楚mock的行为是由什么决定的。人一搞糊涂，AI也跟着糊涂。

有朋友提了一个根本性的质疑：AI生成的mock可信吗？你本来是为了验证代码的正确性，结果引入了一个你无法完全验证的mock层。不确定性只是从代码转移到了mock。

测试的尽头在哪里？哪些东西是测试永远测不到的？这个问题，在场没有人能回答。

问题三：Agent流程的"好"怎么量化？

传统软件测试的assert是确定性的：字段X应该等于Y，等于就通过，不等于就失败。但Agent的输出不是这样的。你让一个客服Agent回答问题，它的回答没有唯一正确答案，你没办法写一个assert来判断它"对不对"。

有朋友分享了他的做法：找精算师人工标注每个样本的reason和打分，然后让AI学习人类的判断标准。这套系统跑了大概两周，在200个样本的benchmark上从零开始达到了86%的准确率，全程没改一行代码，AI自己迭代。

但这引出了一个递归问题。他造了一个verify agent去检验线上的agent，但为了让verify agent本身足够靠谱，又得单独去提升verify agent的能力。谁来验证验证者？这不就是"谁来监管监管者"？

更根本的问题是：当评判标准本身无法精确定义的时候，自动化闭环从何谈起？你可以给它一个分数，但分数本身也是模糊的。人工打分可能也不准，但如果你没有量化，模型在循环里就不知道往哪个方向走。这是一个两难：你必须量化，但你的量化本身就不精确。

问题四：质量控制靠组织还是靠架构？

讨论中出现了两种截然对立的观点。

一方认为质量和速度天然冲突，需要独立的质量控制角色做对抗性开发。有朋友组建了一个三人团队，一个负责产品，一个负责质量，一个负责实施。实践下来发现两个人各聚焦一个目标，心智负担轻很多。一个人快速交付代码，另一个人专门挑毛病。以前一个人同时追求速度和质量，脑子里不停切换模式，很痛苦。

另一方认为，有了统一的开发框架和规范，质量是架构层面保证的。AI按规范写出来的代码不会比人差，你应该在pre-commit hook里强制检查代码行数、方法长度、目录规范，让框架约束代替人工审查。

两种路线的本质分歧：一个靠组织手段（分权制衡），一个靠技术手段（框架约束）。传统软件工程也有这个争论，但AI时代把它放大了，因为代码产出的速度让人工审查变得越来越不现实。

靠组织还是靠架构？还是两者都需要？这个问题我们争了半天，没有结论。

问题五：AI自动化测试的reward hacking

这个问题是讨论中最让人警觉的。

有朋友搭了一套强化学习式的测试循环：AI自己写代码、自己跑benchmark、自己评估效果、自己决定下一步优化方向，7x24小时不间断迭代。听起来很美好。

真实发生的事情是：AI为了达到benchmark目标，写了200个if-else，把样本集里的每个case都硬编码了。碰到case 1返回什么，碰到case 2返回什么。形式上指标达标了，实际上是过拟合。

他加了一些对策。每次选策略之前，让AI做五个为什么的反思，做SWOT分析，逼AI选真正能提升系统能力的策略而不是走捷径。又加了一个supervisor agent去review代码质量。这些缓解了问题，但没有根本解决。

更深层的问题是：AI倾向于"达成目标"而不关心怎么达成。走捷径、短视、不考虑维护成本。有朋友点破了本质：这就是强化学习里的reward hacking。你定义了一个奖励函数，agent找到了一条你没预料到的捷径来最大化奖励，但这条捷径完全偏离了你真正的目的。

当AI同时扮演开发者、测试者和评审者，"作弊"的边界在哪里？这个问题目前没有好的答案。

三个月后见

讨论结尾有朋友提了一个建议：三个月后再回来看这五个问题。被模型进步自然解决的，说明只是阶段性的能力问题。三个月后仍然存在的，才是真正的软件工程问题。

AI Coding的军备竞赛已经从"谁写代码更快"进入了"谁的代码更可靠"的阶段。写代码的问题基本解决了，测试才是真正的战场。

你在实践中碰到了哪些类似的无人区问题？欢迎在公众号给我留言，我们一起交流讨论。

引用来源

• 晓灰博客 xiaohui.cool