把写单元测试交给 AI 自动生成之后，我总结了三个它最容易让我上线即翻车的坑

上个月我图省事，让 AI 根据几个核心函数直接生成单测，跑完覆盖率从 0 拉到 87%，绿得发亮。我美滋滋合了进去。结果上线当天就出 bug，那个出问题的分支，恰恰是 AI 生成的测试"覆盖"过的。

从那以后我没敢再全信 AI 写的测试。它确实把写测试的苦力活包了，但生成的东西有三处隐蔽的坑，不细看根本发现不了。

第一个坑：只测 happy path，边界和异常一个没有。 AI 生成的测试大多走正常输入、正常返回，覆盖率数字好看，实际上异常分支全空着。我那个上线翻车的函数，挂在一句超时处理上，而 AI 一个超时的 case 都没写。覆盖率 87% 只是装饰——它测的是"正常时不出错"，不是"出错时兜得住"。现在我让 AI 生成前先逼它列边界：空值、超限、超时、并发，列不全我补齐再让它写。

第二个坑：mock 过度，把被测逻辑自己都 mock 掉了。 有一版测试，AI 图省事把被调的函数整个打桩返回固定值，等于"测了调用关系、没测任何真实逻辑"。断言通过，但该炸的地方不炸。这种测试合进去比没写还危险——它给你一种"我很稳"的错觉。现在我会专门看一眼它 mock 了谁，只要是业务核心逻辑被 mock 掉的，一律打回重写。

第三个坑：断言太弱，等于没断言。 最常见的是 assert result is not None 就算通过，或者只校验返回类型不校验值。函数明明返回了错误结果，测试照样绿。我后来养成习惯：AI 写的每条 assert，我都要能回答"它在拦什么错"——答不上来的就是废断言，直接删。

我的判断很明确：AI 适合写测试骨架和样板代码，但断言逻辑和边界设计必须人来定，这两样交出去就等于把质量关也交出去了。我现在只让 AI 出骨架，断言和异常 case 自己补，写完反而比纯手写快。

你们觉得 AI 生成的单测覆盖率数字，到底能不能信？我现在的态度是：信它省了体力，别信它保了质量。