接手三年的老项目，测试覆盖率不到8%——我用AI两周补齐了测试骨架

一个真实的困境

去年年底接手一个维护了三年的老项目，四万行代码，测试覆盖率不到8%。打开测试目录，只有零星几个文件，最后一次提交还是一年半前。

摆在我面前的任务很明确：接下来的大规模重构必须以测试为安全网。但按传统方式补测试，我估算了一下工作量——项目里有三百多个函数，每个函数手写测试平均需要20到40分钟（包括读代码、理解逻辑、写用例、跑通验证），全部做完需要200多个小时。对一个人或三人的小团队来说，这意味着两三个月不能碰任何新功能。

这就是老项目的典型困境：

• 时间黑洞：补测试是重要但不紧急的事，永远排不上日程
• 心智负担重：读别人写的（甚至自己三年前写的）代码非常耗神
• 外包不划算：外包理解不了业务上下文，写出来的测试要么是废话测试，要么跑不过
• 风险倒挂：不补测试，重构就是在裸奔

AI改变了这笔账

我的做法不是让AI“全自动”生成测试，而是让AI承担最耗时的部分：生成测试骨架，把人的精力留给真正需要判断力的部分。

第一步：批量提取函数清单

先写了个脚本，用AST解析把项目里所有函数的签名、参数、返回类型提取成清单。这一步十分钟的脚本工作，换来的是三百多个待办条目的清晰视图。

第二步：分批喂给AI

把函数按模块分组，每次给AI一个模块的代码，让它生成测试骨架。注意是骨架——包括测试文件结构、describe/it组织、边界情况清单、mock建议，而不是直接声称能跑通的完整测试。

第三步：人工审查与补全

AI生成的骨架平均完成度在60%到70%：测试结构合理、边界情况覆盖思路正确，但具体的断言值、业务期望往往需要人工校准。我只需要按骨架填肉，验证业务逻辑。

实测的时间对比

最终我用两周的碎片时间完成了原本预计三个月的工作量，测试覆盖率从8%提升到63%。省下的150多个小时，相当于一个小团队一个月的开发量。如果按接入API的方式计算，整个任务的模型调用成本大约相当于几杯咖啡（具体以官网价格页为准），和省下的时间相比几乎可以忽略。

我用的提示词模板

直接可复制的版本，适配大部分语言：

你是一位资深测试工程师。我会给你一段项目代码，
请为其中指定的函数生成单元测试骨架。

要求：
1. 使用 {测试框架}（如 pytest / JUnit / Jest）
2. 每个函数生成测试文件结构、describe/分组组织
3. 列出正常路径、边界值、异常输入三类用例的清单，
   每个用例写清「输入 → 期望行为」，断言处用 TODO 标注
4. 识别函数的外部依赖（数据库、网络、时间），
   给出 mock/patch 建议，但不要过度 mock
5. 不确定的业务逻辑，明确标注「需人工确认」，
   不要编造期望值
6. 输出格式为可直接保存的代码文件

以下是待测代码：
{粘贴代码}

几个关键心得：

• 要骨架不要成品。让AI编造断言值是最大陷阱，期望值必须由懂业务的人确认
• 标注不确定点比假装确定更有价值
• 按模块分批效果好于一次性全丢给AI，上下文太长质量会明显下滑
• 用便宜模型跑骨架生成完全够用，贵的模型留给复杂逻辑分析

前后对比：不只是速度

纯手写模式的问题不只是慢，还有启动阻力——一想到要读几万行旧代码，就本能地拖到“下个季度”。AI辅助之后，启动成本降到“复制粘贴一段代码”的程度，这件事从心理账户里的“大工程”变成了“顺手的小事”。

更重要的是质量下限被抬高了。AI生成的边界用例清单常常提醒我漏掉的情况：空数组、负数、并发调用、时区边界。手写测试时，人在疲惫状态下最容易跳过的恰恰就是这些边角。

当然也别神化：AI不理解你的业务历史，不知道某个看起来诡异的if分支背后是2019年某次线上事故的补丁。人工确认环节不能省，我把AI定位成一个不知疲倦的初级测试工程师，它负责铺量，你负责把关。

结语

老项目补测试这件事，过去的答案永远是“没时间”，现在答案变成了“花两周碎片时间能干完”。对于独立开发者和小团队，这类高重复、有明确模式的工作正是AI最能释放价值的地方——它不替你思考，但它替你熬那些没人想熬的钟点。

如果你也想试试用API方式批量处理这类任务，可以在这里注册一个账号开始动手：https://api.thistoken.ai/register

---

想直接跑通示例？访问 https://api.thistoken.ai/register 注册 ThisToken.AI，获取 API Key 后即可开始。