AI 写单元测试看起来简单，但写法上的小偏差会明显影响结果。先回顾一下：用 AI 写单元测试是把函数代码和需求说明交给 AI，让它分析输入输出和边界情况，生成测试用例和测试代码。下面逐个拆解 5 个最常见的错误。

错误 1：不提供业务规则

问题在哪：不提供业务规则。这是最常见也最容易忽略的情况。

怎么改：说明函数的预期行为，AI 才能写出有意义的断言。

错误 2：直接接受所有生成的测试

问题在哪：直接接受所有生成的测试。这是最常见也最容易忽略的情况。

怎么改：判断每个用例是否合理，删除重复和无意义的测试。

错误 3：测试只断言“不报错”

问题在哪：测试只断言“不报错”这样做的结果通常是输出偏离预期，还得花时间返工。

怎么改：要求断言具体的输出值和状态。

错误 4：测试依赖外部服务

问题在哪：测试依赖外部服务。这是最常见也最容易忽略的情况。

怎么改：使用模拟对象，保证测试稳定可重复。

错误 5：测试失败就修改测试让它通过

问题在哪：测试失败就修改测试让它通过。看似省事，实际会让后续修改更费劲。

怎么改：先判断是代码错误还是测试错误。

这些错误的共同根源

AI 写测试的意外收获，往往是发现代码本身的问题。当它列出“如果输入为空会怎样”“如果两个参数相等会怎样”时，你可能会发现自己从没考虑过这些情况。所以用例清单阶段比生成代码阶段更有价值：认真看清单，才能真正提升代码质量。

顺带回答一个常见疑问——能为前端代码写测试吗？可以，说明使用的框架和测试工具即可，但交互类测试可能需要更多调整。

修正后的标准写法

把上面的修正综合起来，以游戏开发者的场景为例，一个更可靠的写法是：

请为下面这个函数编写单元测试，测试框架是[框架名]。
函数用途：处理游戏开发者工作中“关卡”相关的数据计算。
请：
1. 先列出测试用例清单：| 用例 | 输入 | 预期输出 | 类型（正常/边界/异常）|；
2. 至少包含：空输入、极大值、非法格式、重复数据等情况；
3. 等我确认清单后再写测试代码；
4. 测试命名清楚地表达测试意图。
函数代码：[粘贴]

如果你是游戏开发者，还要额外注意一点：写游戏逻辑时让 AI 给出伪代码和边界情况，再落实到具体引擎。

最后一个建议

测试数据使用虚构数据，不要用真实的用户信息。记住 AI 写单元测试的原理——写测试需要系统地思考各种输入情况，这正是 AI 擅长列举的部分；你再根据业务判断取舍，就能更快地得到质量较高的测试——遇到新情况时就能自己判断怎么写。

怎么自查

写完提示词后，用三十秒问自己：AI 知道我的读者是谁吗？知道成功的标准吗？知道哪些事不能做吗？三个问题有一个答不上来，就先补充再发送。游戏开发者在处理策划文档这类正式材料时尤其要过这一关。

相关阅读