存量代码没测试就没人敢动？我们团队让AI先把覆盖率补上

一个管理者的真实困境

接手过老项目的人都懂这种感觉：代码库跑了五年，核心模块没有一行单元测试。团队成员接需求前先开半小时会讨论“这块逻辑能不能碰”，改一行代码要在测试环境手工回归半天。谁都不敢做第一个动手的人。

我所在的小团队去年就处在这种状态。核心业务系统约三万行存量代码，单测覆盖率不到 15%，而且仅有的测试大部分还是断言松散的“形式主义测试”。带来的连锁反应很典型：

• 需求排期越来越长：每次改动都要预留大量手工回归时间
• 新人上手慢：没有测试作为“行为说明书”，只能靠读代码和老员工口口相传
• 技术债利息越滚越高：越不敢改，代码越烂；代码越烂，越不敢改

招人专门补测试？小团队没有这个预算。让现有开发挤时间写？两个迭代之后就不了了之。直到我们决定认真试一次：用 AI 批量生成单元测试，把存量代码的覆盖率补起来。

AI 在这件事上到底能做什么

先把预期说清楚：AI 不能替你“保证质量”，但它能把你从 0 到 60 分这段最枯燥的路铺平。具体来说，它承担了四件事：

1. 读代码、理解逻辑。 三万行代码让一个新人读完要一个月，AI 几分钟就能给出一个模块的职责梳理、依赖关系和边界条件清单。这本身就很值钱——很多老代码连当初的作者都说不清了。

2. 生成测试骨架和用例。 正常路径、边界值、异常分支、空输入，AI 会主动枚举你可能想不到的场景，生成可直接运行的测试代码。

3. 解释“这段代码到底在干什么”。 对那些没有文档的老函数，AI 生成的测试用例本身就是一份可执行的行为描述。测试通过，就说明 AI 的理解是对的。

4. 持续协作修订。 测试跑挂了不用慌，把报错贴回去，AI 会判断是测试写错了还是代码本身有隐藏 bug——后者是意外收获，我们这次就揪出了三个潜伏多年的边界 bug。

我们的落地流程（可直接照搬）

作为管理者，我关心的不是某个工具多神奇，而是流程能不能标准化、风险可不可控。我们最终跑通的流程分五步：

第一步：圈定范围。 不要全库开干。按“改动频率 × 出过事故”两个维度挑出前 20% 的核心模块先做。我们选的是订单金额计算和库存扣减两个模块。

第二步：让 AI 先做代码理解，再生成测试。 一口气把整个文件丢给 AI 让它“写测试”，效果远不如分两步：先让它输出对代码的理解和测试计划，人工确认没有跑偏，再让它写具体用例。这一步人工确认是关键的风控点——AI 对老代码的误解如果直接沉淀成测试，会产生“看起来有覆盖、实际在验证错误行为”的伪测试。

第三步：跑测试，区分失败原因。 跑挂的用例分三类处理：AI 对代码理解偏差（修订测试）、测试环境问题（修 mock）、代码真有 bug（提 issue，不顺手改线上逻辑）。

第四步：人工审查合并。 所有测试代码走正常 code review 流程。AI 生成不等于免检，尤其是断言的强度——断言太松的测试是负资产。

第五步：把它变成常态。 之后每个改到存量代码的 MR，都要求附带 AI 生成的新增测试，覆盖率的欠账逐步还清，而不是再来一次“运动式补课”。

可复制的提示词模板

这是我们团队内部迭代了三个版本后固定下来的模板，配合任意主流大模型 API 使用皆可：

你是一位资深测试工程师，请为下面的存量代码生成单元测试。

【背景信息】
- 项目语言/框架：{例如 Java 8 + JUnit 5 + Mockito}
- 该模块的业务职责：{一两句话描述，帮助 AI 校准理解}
- 运行环境限制：{例如 无数据库依赖，需 mock 外部服务}

【请按以下步骤输出】
1. 先用不超过 5 条要点总结你对这段代码行为的理解，
   包括关键分支和边界条件，供我确认；
2. 列出测试计划：每个用例一行，标注
   [正常路径] / [边界值] / [异常分支] / [疑似代码隐患]；
3. 等我确认后，再生成完整可运行的测试代码。

【要求】
- 每个用例必须有明确的断言，禁止只调用不校验；
- 标注 [疑似代码隐患] 的用例单独说明理由，不要自行修改被测代码；
- mock 只用于外部依赖，不要 mock 被测对象内部逻辑。

【待测代码】
{粘贴目标函数或类}

模板的核心设计是强制分步：先确认理解，再生成代码，并且让 AI 把“疑似隐患”单独拎出来而不是默默绕过。这两个细节显著降低了伪测试的产出率。

前后对比：数字和体感

不编造漂亮数据，只说我们自己度量到的事实：

更重要的是团队协作方式的变化。以前测试是“额外负担”，现在 AI 写初稿、人做审查，测试变成了新人理解老代码的入口——新人 review AI 生成的测试，比裸读代码上手快得多。

管理者要盯住的三个风险点

最后给同行几句实话：

1. 警惕伪覆盖率。 覆盖率数字好看不等于安全，审查时重点看断言质量，一个 assertNotNull 撑不起任何信心。
2. AI 的理解错误会固化成“错误的行为基线”。 分步确认流程不是可选项，是必须项。
3. 别让团队产生“有 AI 就不用懂测试”的依赖。 AI 生成的是初稿，测试设计的判断力还得留在团队里。

关于工具成本：目前主流大模型 API 都支持这类代码任务，不同模型的价格和效果差异不小，建议先用小范围模块做效果对比再批量跑，具体费用以各平台官网价格页为准。

存量代码的测试欠账，过去是“知道该还但永远排不上”的债。现在 AI 把还债的成本压到了团队可以承受的区间——这可能是小团队今年最划算的一笔技术投资。

如果你想开始动手搭建自己的 AI 辅助开发流程，可以先注册一个统一的模型 API 服务，把上面这套提示词模板直接跑起来试试：https://api.thistoken.ai/register

---

本文的示例只需一个 API Key 就能复现：在 https://api.thistoken.ai/register 注册即用。