AI测试为AI开发的结果买单,那谁为AI测试的结果买单?

导语：为了让测试跟上开发的速度，我把 AI 引入测试流程。然后我发现，这个决定本身就是个陷阱——AI 写代码，AI 做评审，AI 写测试，看似多重保障，实则是多重确认同一套盲点。这篇文章不只是在追问谁来买单，而是记录一个人在 AI 时代怎么为自己的产品建防线。

一、速度是礼物，也是诅咒

去年开始，我一个人负责 AI老板这个产品，从需求分析到用户上线，全链路独自完成。

今年上半年引入 AI 辅助开发后，短短三个月，版本更新次数就达到了上百次。

这是 AI 带来的开发速度——相比过去，大约 10 倍的提升。

但速度是有代价的。

开发速度 ×10，测试速度没有 ×10。原来我每写 3 个功能，会配套写 1 个测试。现在我每写 30 个功能，还是只能配套写 1 个测试。

测试覆盖率不是线性增长的，它在指数下滑。

二、我以为找到了解法

问题是显而易见的：测试跟不上。

其实我已经在用"不同 AI"来互相制衡了——Claude 写代码，GPT 做代码评审。两个模型，两套视角，理论上能发现对方的盲点。

但评审通过了，问题依然出现在线上。

所以我又往前走了一步：既然已经引入了 AI，为什么不让 AI 直接写测试？

我试了。效果出乎意料地好。

几分钟内，AI 生成了几十个测试用例，覆盖了各种输入场景、边界条件、权限控制。我的项目从零散的测试，迅速扩充到了 399 个用例，全部通过。

我以为问题解决了。

三、同一个盲点

直到有一天，我在排查一个线上 bug 时，意识到一件事：

这个 bug，我的测试一个都没捕到。

AI 写测试，本质上和 AI 评审是同一个问题。

评审是 AI 读代码，判断"这段逻辑有没有问题"。测试是 AI 读代码，判断"这段逻辑应该怎么验证"。两件事都基于同一份代码，都受限于 AI 对这份代码的理解。如果代码的逻辑本身有问题，AI 看不出来；那它写出来的测试，也会顺着这个有问题的逻辑去验证——然后通过。

这就是"同一个盲点"：

当你用 AI 写代码，再用 AI 评审、AI 写测试，你得到的不是多重保障，而是多重确认——反复确认同一套假设是正确的。

传统开发里，开发、评审、测试是三个不同的人，不同的视角，不同的假设。评审质疑逻辑，测试质疑功能——三个角色共同构成 独立的质疑体系。

AI 做不到这件事。它只能测"代码写了什么"，不能测"代码应该做什么"。这个差距，换哪个模型都填不上，只能靠人。

四、那出了事，谁负责？

这个问题我认真想过。

传统答案是：开发为功能负责，评审把关逻辑，测试为质量兜底。三个角色，三道防线，出了生产事故，责任有据可查。

但现在这条责任链断了。

AI 写代码，AI 做评审，AI 写测试。整个链条上，每一个环节都是 AI——而 AI 不承担责任。

那谁来负责？

法律上：公司负责。

现实中：做上线决策的人负责。

对我来说，那个人就是我自己。

每一次按下部署按钮，都是我在说："我认为这个版本是安全的。"——不管代码是谁写的，测试是谁写的，最终判断是我做的。

这个认知让我清醒了很多。

五、一个人的测试防线：分层对冲

既然每一层 AI 都有盲点，答案不是放弃它们，而是用分层来对冲。

每一层捕捉不同类型的问题，每一层也有各自的局限。组合起来，才是完整的防线。

第一层：AI 交叉评审（不同模型，不同视角）

Claude 写代码，GPT 做评审。两个模型的训练偏好不同，能互相发现一部分对方的逻辑盲点。

局限： 都在读同一份代码，根本性的逻辑错误两者可能都看不出来。

第二层：AI 写测试（覆盖已知路径）

让 AI 快速生成覆盖各种输入场景的测试用例。速度快，能覆盖大量路径。

局限： 和代码同一个盲点——它想不到的边界情况，测试也不会有。

第三层：人工定义核心路径测试 + 上线前完整走一遍（绕过 AI 盲点）

这一层分两步，都由人来完成。

第一步，自动化：人来定义测什么，不依赖 AI 的判断——直接问自己，用户最不能接受挂掉的路径是哪几条？写成自动化用例，全程 mock 外部依赖，快速验证系统结构没有崩。我的产品：15 个用例，1.2 秒跑完。

第二步，手动：上线前把核心业务流程完整走一遍，哪怕花时间。不是跑脚本，是真实操作产品，用用户的视角确认它能用。花多久都值——因为这一步是你在对自己说"我确认过了，可以上线"。

价值： 这是整条防线里唯一完全不受 AI 盲点影响的层。机器验证系统活着，人验证它真的能用。

围绕这套思路，我为 AI老板建了一套 Tier 0～Tier 5 的分层自动化测试体系，目前共 399 个用例：Tier 0 守核心路径（15个，1.2秒）、Tier 1 守安全权限（94个）、Tier 2 验问答管线行为、Tier 3 做 LLM 答案质量评估、Tier 4 验生成器不崩溃、Tier 5 验数据库边界（243个）。每一层测不同的东西，没有一层是万能的。

第四层：部署后监控（捕捉漏网之鱼）

前三层都是部署前的防线。漏过去的 bug，靠监控来捕捉：核心接口错误率、响应时间异常、关键日志告警。

发现得越快，损失越小。

底层心态：从"防所有 bug"到"发现快，恢复快"

没有人能拦住所有 bug，更不用说一个人。

接受这个现实之后，真正重要的能力是：bug 出现后多快能发现、多快能回滚。不追求零失误，追求失误后的最小损失。