AI编程与测试信任危机

AI × 软件 系列第 5 篇

有一个问题一直让我不安。

当 AI 编写了代码，我们用测试来验证代码是否正确。但如果测试也是 AI 写的呢？

你在用 AI 写的考卷来检验 AI 写的答案。如果 AI 对需求的理解有偏差，那么它写的代码和测试可能犯同样的错误——代码是错的，测试也是错的，但测试全部通过，一片绿色。

这不是理论上的担忧。这已经在真实项目中发生了。

· · ·

传统软件质量保证有一条清晰的信任链：

信任的关键在于独立性。写代码的人和写测试的人，至少思维方式不同。审查者是第三方视角。多个独立的人类大脑交叉验证，降低系统性偏差的概率。

现在这条链变成了：

独立性消失了。代码和测试出自同一个"大脑"，可能带有相同的认知盲区。

这不是说 AI 写的测试一定不好。问题在于：你无法通过 AI 自己写的测试来证明 AI 的代码是正确的——这是一个循环论证。

· · ·

这是最表层的问题，也是目前工具最多的层面。

AI 生成的代码在语法上几乎不会出错。在常见模式上（CRUD、API 对接、数据处理），准确率也相当高。问题出在边界情况和隐含假设：

这些问题 AI 不是不知道，而是不够可靠地知道。有时候它会主动考虑并发安全，有时候不会。有时候它会做输入校验，有时候会忘。

AI 生成代码的危险不在于它写得差，而在于它写得"几乎对"。90% 的完美往往比 60% 的粗糙更危险——因为后者你一眼就能看出问题，前者需要深入审查才能发现隐患。

单个模块都对，组合起来可能是灾难。这是软件工程最经典的挑战，AI 时代只会更严重。

原因：AI 处理单个任务时通常在"局部最优"，但缺乏对整个系统的全局视角。

这种问题在传统开发中也存在，但频率较低——因为人类开发者共享同一个架构认知，会在团队沟通中自然协调。AI Agent 之间没有这种隐式协调。

这是最深层的危机。

当越来越多的代码由 AI 生成，人类对自己系统的理解在逐渐降低。

三个月前 AI 生成的一个模块，当时审查通过了，现在需要修改。你打开代码，发现你不完全理解它的实现逻辑。你让 AI 解释，AI 的解释可能是对的，也可能是错的（它在解释别的 AI 写的代码，不一定准确）。

你敢改吗？你改了之后怎么确保没有破坏什么？

这是一种新形态的技术债：不是代码质量差，而是人类对代码的认知在退化。

传统的技术债可以通过重构来偿还。认知债怎么偿还？让 AI 重新生成一遍？那只是把债务转移了，不是消除了。

· · ·

传统单元测试失效的地方：当 AI 同时写代码和测试时，测试可能只覆盖了 AI "想到"的场景。

重建方向：Property-Based Testing（基于属性的测试）

不是断言具体输出值，而是定义输出必须满足的性质：

# 传统：脆弱的具体断言 def test_sort(): assert sort([3,1,2]) == [1,2,3] # 属性测试：不管输入是什么，输出必须满足这些性质 @given(lists(integers())) def test_sort_properties(lst): result = sort(lst) assert len(result) == len(lst) # 长度不变 assert all(result[i] <= result[i+1] # 有序 for i in range(len(result)-1)) assert set(result) == set(lst) # 元素不变

属性测试的优势：它定义的是不变量，不依赖于实现细节。即使代码和测试都是 AI 写的，只要属性是人定义的，信任链就没有断裂。

当 AI 一天生成几千行代码时，逐行审查不现实了。

重建方向：分层审查

关键原则：用不同