在过去的很长一段时间里，”写测试”几乎是程序员的职业底线。但这两年，当我一次次把需求丢给 AI，看着它在几秒钟内吐出几百行代码时，一个念头开始反复出现：如果代码都不再是我自己写的，那么测试，又该测试些什么？
作为一个已经和 AI 结对编程快两年的开发者，我想认真聊聊这个被问得越来越多的问题——不是给出”该不该写测试”的非黑即白答案，而是记录下我在这个转型期的真实观察和几条正在被验证的思路。
## 一、问题不是”要不要测试”，而是”测试的重点变了”
很多人对 AI 编程的担忧，来自一个朴素直觉：AI 生成的代码没人看懂，怎么保证质量？但过去一年的实际体验告诉我，真正的风险点恰恰相反——**代码本身往往并不算致命，真正容易出问题的，是不确定的需求理解和对边界的假设。**
AI 在”把明确需求翻译成代码”这件事上确实越来越强，但它有一个固执的毛病：它会在你不知道的地方，替你做了很多”合理”的假设。比如某个接口到底该同步返回还是异步回调，某条数据缺失时该报错还是兜底，某个权限边界该放大还是收紧。这些假设在大多数情况下无伤大雅，可一旦踩中,往往就是线上事故的温床。
所以现在我的测试重心,从”验证我写的代码没有错”,转向了”验证 AI 理解的需求没有偏”。
## 二、与其纠结怎么写测试，不如先学会”给测试提需求”
过去我们写测试，是在开发生命周期的末端为代码兜底。而在 AI 工作流里,我渐渐发现**把测试前置,反而比写更多测试更有效。**
具体做法很朴素:在我把需求交给 AI 之前,我会先自己列出三到五条”必须满足的验收标准”——不是那种含糊的”功能要正常”,而是可以量化验证的边界条件,比如”并发 100 请求时响应时间低于 200ms””空字符串入参必须返回统一的错误码”。这些验收标准,其实就是一个最朴素的测试骨架。
当 AI 生成的代码跑完这组测试,我会继续把它当成”审稿人”——让评审意见也反过来约束它。经过一段时间,你会发现 AI 会越来越”懂”你所在的项目,一开始那些危险的隐性假设,会被慢慢驯化成稳定的工程约定。
## 三、未来质量保障的方向:让”机器验证机器”
说到底,当代码大量由 AI 生成,还用传统的人工测试去打勾,效率会跟不上的。我正在尝试的第三种思路,是**让系统自己给自己出具”体检报告”**:把测试、静态检查、回归、性能基线统统接一条自动化流水线。任何一次 AI 生成的代码提交,都要先过这条流水线,不达标就直接打回。
这套做法真正的好处,是把”质量”从人的主观判断,变成了可量化的客观门槛。AI 负责快速产出,机器管道负责冷酷把关,而我——负责定义清楚什么是”好”,然后从繁琐的重复劳动中抽身出来,去解决那些真正需要判断力和创造力的难题。
## 结语
几年后回看,也许”AI 时代还需不需要手工写测试”会变成一个伪命题。因为这场变革里,真正被淘汰的不是测试这个动作,而是那种”写完就万事大吉”的盲目自信,和靠肉眼扫代码找问题的低效方式。
留下来的,是对需求的敬畏,对边界的敏感,以及一套让机器替我们守好底线的工程方法。而测试这件事,也终于从”负担”变成了我们与 AI 顺畅协作时,最可靠的那道护栏。