夜雨聆风
有开发者公开分享过这样一段经历：AI在自动补全代码时，把全局状态管理写成了一个闭包陷阱——在某种并发场景下，前一个请求的上下文会泄露到下一个请求里。代码写得行云流水，他自己审代码时也没看出问题，最后整整排查了六个小时才定位到根源。
这类案例很容易让人联想到一个更大的问题：如果有一天，写代码、审代码、测代码这几件事都彻底交给AI——软件真的就不会再有bug了吗？
一、先把"bug"拆开看：有一类bug，从来不是"测得不够"导致的
讨论"AI能不能消灭bug"时，大多数人想到的是覆盖率不够、场景没测全。但现实里相当一部分缺陷，根本不是因为没测到，而是因为需求或规格本身就是模糊、矛盾甚至错的——这种情况下，无论是人还是AI，都没有一个"标准答案"可以拿来对照判断对错，因为正确性本身没被定义清楚。
另一类常见的bug，则来自真实世界的不确定性：并发时序、网络抖动、规模上来后的性能拐点、不同硬件和环境下的差异。前面那个闭包陷阱就是典型代表——它不是逻辑写错了，而是在特定并发条件下才会暴露的行为，测试环境里很难完全复现真实流量的所有时序组合。这两类bug有一个共同点：缺的不是"执行测试"这一步，而是缺一把能拿来判断对错的尺子，AI再快也快不出一把本来就不存在的尺子。
二、再往底层看："全部测一遍"在数学上就不可能
图灵在停机问题上给出的结论是：不存在一个通用算法，能对任意程序在任意输入下的行为做出确定性判断。由此延伸开来，也不存在一个通用程序，能自动验证任意一段代码在所有可能输入下都完全符合某个规约——这不是工程能力不够，而是被数学证明过的边界。计算机科学家迪克斯特拉很早就提出过一个判断：测试能证明程序里存在bug，却没办法证明它不存在bug。这句话放到AI测试的时代依然成立，AI能做的是把"采样"做得更密、更快，而不是把"全集"穷举出来。
三、当AI又写代码又测代码：会不会产生新的"同源盲区"
人类开发和人类测试之间天然存在一种对抗关系——测试人员会刻意用和开发者不同的视角去找漏洞。但当写代码和测代码都交给AI，两者很可能基于相似的训练分布、相似的"常见用法"假设，于是对同一类边缘场景产生相似的盲区——这是一种新的、更隐蔽的相关性失效，而不是过去那种"测试没覆盖到"的简单遗漏。
这并非空想。GitClear在分析超过1.5亿行代码后发现，AI辅助编码普及期间，代码"两周内被回滚或修复"的比例明显上升；斯坦福大学也有研究指出，使用AI编程助手的开发者写出的代码安全性更低，但他们反而更相信自己写的是安全代码。代码产出量上去了，缺陷反而没有同步减少，这本身就说明"写得更快"和"写得更对"不是一回事，AI测试要面对的也是同一个问题。
四、新的失控点：当"为什么这么写"这件事，没人说得清
华为云码道团队在做代码智能体时观察到一个现象：AI生成代码时的架构意图，往往只存在于当时那个对话上下文里，没有留在代码库本身，后来的人很难还原"这段代码为什么这么写"。开源引擎Godot的维护者也公开吐槽过，他们正被大量结构完整、注释齐全，但提交者自己也说不清原理的AI生成代码淹没。
这对测试是个新麻烦：判断"这是不是bug"，本质上要先知道"原本想做成什么样"。当代码背后的意图丢失，无论测试由谁来执行，验证"对不对"这件事本身的难度都在上升，跟测试速度快不快没有关系。
五、所以测试真正在做的事，从来不是"消灭bug"
把这些放在一起看，答案已经比较清楚：测试从来没有，也不可能保证一个系统零缺陷，它的作用一直是把风险降到可接受的范围，并为"能不能发布"这个决策提供依据。AI让执行这件事变得更快、更便宜，但没有改变软件本身会不断演进、需求会模糊、真实世界会比测试环境复杂这些底层事实。即便有一天AI能把测试执行的成本降到几乎为零，"该不该为了某一类小概率风险投入资源去堵"这个取舍判断，依然得有人来做——执行变便宜了，判断反而更值钱了。
对从业者来说，这意味着当AI接管了执行层的工作，真正稀缺的能力会进一步往"定义什么是对的""判断哪些风险值得投入资源去堵"这一侧聚集——这恰恰是过去被埋在大量手工执行工作里、容易被忽视的那部分测试能力。
结语
如果AI完全取代手工测试，软件还会有bug吗？答案是会，而且这些bug大多不会是因为AI"不够努力"，而是来自需求本身的模糊、真实世界的复杂、以及代码意图的丢失——这些问题从来不是靠测试速度能解决的。测试真正的价值，不在于把bug数量清零，而在于持续帮团队搞清楚"我们到底想做对什么"。
