让 AI 写单元测试，怎么保证测的是对的东西

这是用 AI 写测试最大的陷阱：它读你的实现，然后写一个「能让这个实现通过」的测试。代码有 bug，测试照样绿。覆盖率上去了，信心反而虚了。

陷阱：它测的是实现，不是需求

如果你说「给这个函数写单测」，它会照着现有逻辑写断言——包括把错误行为也断言成正确。

正确做法是先给它需求：「这个函数应该满足这几条规则」，再让它写测试。顺序反过来，测试才有把关价值。

三个提高有效性的方法

按效果排序：

• 先给需求再写测试：把业务规则写清楚，让它按规则写，而不是按代码写。
• 要求它列边界：金额为 0、负数、超大值、空集合、超长字符串——让它主动枚举，比你想得全。
• 反向验证：写完测试后，故意改坏一行代码，看测试会不会红。不会红说明这个测试没意义。

该测什么，不该测什么

别追求覆盖率数字。优先测：核心计算逻辑、边界条件、错误处理路径、以及历史上出过 bug 的地方。

不值得测：getter/setter、纯转发的适配层、框架本身的行为。测这些只是让报表好看。

和 CI 配合的一个细节

AI 生成的测试经常依赖真实时间、随机数、外部网络，跑起来不稳定。

让它统一用可注入的时钟和固定随机种子，跑一次能过、跑一百次也能过，这才是可用的测试。