先让AI一口气生成500个测试，第二天全删了——老项目补单测的弯路与正路
一个反例开场
接手一个运行了六年的老项目，函数两百多个，单元测试覆盖率为零。我第一反应是：这不是AI最擅长的活吗？
于是我打开对话窗口，把整个代码目录一股脑丢给模型，输入一句足以载入个人失败史册的提示词：
> “帮我给这个项目所有函数生成单元测试。”
模型很努力，吐出了几百行测试代码。我满怀期待地跑了一遍 pytest——红色满屏。一半测试 import 报错，因为模型猜错了模块路径；另一半断言全挂，因为模型并不真正理解那些没有文档、命名混乱的遗留函数到底在做什么逻辑。还有相当一部分测试，断言写的是模型“想象中”函数应有的行为，而不是函数实际的行为。
那一晚我删掉了所有生成的测试，覆盖率依然是零。
失败做法的三个共性
复盘下来，这类“一把梭”式失败几乎必然发生，原因很典型：
第一，贪多。 一次让AI处理几十个函数，超出上下文有效工作范围，质量随函数数量递减。
第二，不给上下文。 老项目最缺的就是文档。函数签名看不懂、参数含义靠猜、隐含的前置条件没人知道——这些信息不喂给AI，它只能靠“通用想象”补全，写出来的测试自然对不上现实。
第三，要求含糊。 “生成单测”这四个字里，没说测试框架、没说是否需要mock数据库、没说边界用例的优先级。AI只能自己发挥，而发挥的方向往往不是你要的。
换句话说，AI在这件事上的能力是够的，用错了姿势。
正确路径：小批量、带上下文、先骨架后血肉
调整策略后，我把流程改成了四步，效果立竿见影。
第一步，先让AI做“体检”而不是“动刀”。 挑三五个有代表性的函数（一个纯函数、一个依赖数据库的、一个依赖外部API的），连同它们用到的类型定义、常量、上下游调用代码一起喂给AI，请它先输出：这个函数的可测性如何、依赖了什么、建议从哪里mock。这一步的产出是理解，不是代码。
第二步，明确约定测试骨架的规范。 测试框架用什么、命名规则、mock策略、每个函数至少覆盖哪几类用例（正常路径、边界值、异常输入），全部写进提示词。这是后面可以批量复制的那份“模具”。
第三步，小批量循环。 每次只处理三到五个函数，生成一批、跑一遍、修一批。AI写的骨架里最常见的错误是mock对象的行为和真实依赖不一致，这种问题在小批量下几分钟就能修完；在大批量下会堆积到你崩溃。
第四步，先骨架、后断言。 我最终采取的折中方案是：让AI生成完整的测试骨架——测试类、测试函数、用例命名、输入数据构造、mock搭建，全部就绪；而关键断言留给人工确认或让AI基于“实际运行输出”来补。这样AI的效率优势（搭结构、造数据、覆盖枚举各种情况）充分发挥，而它不擅长的部分（判断遗留代码的真实意图）由人把关。
可复制的提示词模板
这是我沉淀下来的骨架生成模板，替换方括号内容即可用：
你是一个资深测试工程师。请为下面的函数生成单元测试骨架。
## 项目约定
- 测试框架：[pytest / JUnit5 / vitest 等]
- mock 库：[unittest.mock / Mockito 等]
- 测试文件命名：test_<模块名>.py，测试函数命名：test_<被测函数>_<场景>
- 遵循 Arrange-Act-Assert 结构
## 生成要求
1. 为每个函数至少生成：正常路径 1 个、边界值 2 个、异常输入 2 个用例
2. 所有外部依赖（数据库、网络、文件、时间）必须 mock，不许真实调用
3. 每个测试函数体内：Arrange 和 Act 部分写完整可运行的代码，
Assert 部分先写 TODO 注释，标注“需要人工确认期望值”
4. 不要修改被测函数本身
5. 如果函数存在你无法确定的行为，在测试文件顶部用注释列出疑问清单
## 被测函数及其依赖代码
[粘贴函数代码]
[粘贴相关的类型定义、常量、被调用的下游函数签名]关键在第3条和第5条：断言留TODO，逼着自己看一眼AI列出的疑问清单——那往往是老项目里最危险的隐含逻辑。
用AI前后对比
之前（纯手写）： 给一个中等复杂度的函数（带一个数据库依赖、两个分支）手写测试，包括读懂逻辑、搭mock、调试，平均要25到40分钟。两百个函数，想都不敢想，所以六年覆盖率一直是零。
第一次用AI（错误姿势）： 一晚上生成500个测试，第二天花了一整天调试，全部删除。净收益为负，唯一收获是教训。
之后（正确姿势）： 每批5个函数，AI生成骨架约一两分钟，人工确认断言和修mock平均每个函数5到8分钟。两周的业余时间，主业务模块的测试覆盖率从零拉到了可维护的水平，且每一个进仓库的测试我都理解它在验证什么。
结论很清楚：AI不是替你写测试的员工，而是替你搬走搭骨架、造数据这些重体力活的助手。分工想清楚，效率翻倍；分工想不清楚，就是删代码练手速。
几条实操建议
- 覆盖率是伪目标，先给最常出bug的模块补，而不是按文件顺序扫。
- 生成结果一定要本地跑一遍再进仓库，AI没有执行环境，永远存在“看起来对”的代码。
- 如果使用API批量处理，把模板固化成系统提示词，函数代码作为用户消息传入，token消耗更可控。费用方面，以官网价格页为准。
- 疑问清单比测试代码本身更值钱——它是老项目隐含逻辑的挖掘机。
如果你也在还老项目的技术债，或者想让团队把AI真正用进日常开发流程而不是只当聊天玩具，可以试试 Thistoken 平台，聚合多家模型API，注册即用：https://api.thistoken.ai/register
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。