用 AI 写单元测试（2026）：一套抓 bug、而不只是刷覆盖率的工作流

AI 写单元测试很快，这恰恰是它在你不小心时危险的原因：很容易生成一墙几乎证明不了什么的绿勾。覆盖率不等于正确性。一个跑了代码却没有对其行为做有意义断言的测试套件，给你一份你没挣来的信心。这套工作流用 AI 写真正抓 bug 的测试——通过指定行为、审查每一条断言、验证代码错误时测试会失败。

核心风险：覆盖率表演

要防的失败模式是「执行了代码却不检查它是否正确」的测试。AI 很擅长产出这种——它能生成一个调用函数、拿到结果、断言结果等于函数当前返回值的测试。那会通过、增加覆盖率、什么都抓不到，因为它断言的是实现而非预期行为。如果函数本就有 bug，这种测试把 bug 锁进去。下面工作流的全部要点就是避免用真实的安全换一个覆盖率百分比。

第 1 步：指定行为，不是实现

告诉 AI 代码应该做什么，用输入和预期输出来表述，而不是让它「给这个函数写测试」。后一种说法诱导它照抄当前实现；前一种逼出对预期行为的断言。对一个定价函数，说「10.005 的总额应四舍五入到 10.01」，不是「测 calculateTotal」。基于行为的提示产出能与有 bug 代码相抵触的测试——这正是测试的全部价值。

第 2 步：审查每一条断言

像读任何 AI 代码改动一样读生成的测试——一条断言一条断言地读。对每条问：这检查的是有意义的行为，还是只是复述代码碰巧做的事？删掉或重写锁定实现的断言。这次审查是 AI 生成测试变得可信的地方；跳过它，就是一个满是绿勾的套件最终什么都保护不了的原因。

第 3 步：验证测试能抓到真实 bug

最强的信心检查是手动变异：故意弄坏代码——翻转一个比较、改一条四舍五入规则、返回错误值——并确认至少一个测试失败。如果你破坏了逻辑而一切仍然通过，那测试什么都没在测。这一步是「看起来有保护」和「真有保护」的套件之间的区别，也是支撑好的调试和诚实工具评估的同一套「复现并验证」纪律。

第 4 步：推过 happy path

放任 AI 自己发挥，它倾向于测明显的成功用例。明确要求边界情况——空输入、边界、无效数据、错误路径、相关时的并发——因为真实的 bug 住在那里。好的提示点名类别：「包含空输入、最大边界，以及参数为负时报错的测试。」happy path 在生产里很少失败；未处理的边界情况才会。

常见问题

结论：AI 让单元测试更快，但只有你的验证让测试成为真的。按行为而非实现提示、审查每条断言、证明你弄坏代码时套件会失败、推过 happy path 进入边界和错误情况。覆盖率是起点，不是终点——一个抓不到 bug 的绿套件比一个诚实的缺口更糟。这是方法指南，不是工具排名；本文把事实标为 2026-07-15。