很多人试过让 AI 写单测，结果是要么生成的用例只覆盖 happy path，要么断言写得含糊、跑起来就挂，最后还得自己重写一遍。问题通常不在模型，而在你没先划清楚「哪些分支必须测、什么算通过」。这篇按流程讲三件事：怎么把待测函数拆成可描述的行为、怎么给 AI 划覆盖边界、生成完用什么顺序验收。适合已经能跑通 API、正在把 AI 接进日常开发流程的工程师。
很多人第一次让 AI 写单测，回来的东西长得挺像样：命名规整、结构完整、断言也写了，结果跑起来一片红，或者更糟——全绿但把实现照抄了一遍，改一行代码测试照样过。问题基本不在模型，在于你没有先告诉它「哪些分支必须测、什么算通过」。这篇按流程讲三件事：怎么把待测函数拆成可描述的行为、怎么给 AI 划覆盖边界、生成完按什么顺序验收。适合已经能跑通 API、想把 AI 接进日常开发流程的工程师。
先说清边界：这篇文章只讲覆盖边界和验收流程，不讨论各家工具谁强谁弱。工具选型那种扩展盘点性质的对比，交给站内对应目录页去看，这里只解决你手上那个函数怎么落地。
先划边界，再让 AI 动手
直接一句「帮我写单测」，模型只能猜你想测什么。更稳的做法是自己先把函数拆成三类行为：正常输入、边界输入、异常路径。拆的过程本身就是一次代码审查，很多逻辑漏洞在这一步就露出来了，根本轮不到 AI。
| 行为类别 | 典型例子 | 交给 AI 时怎么说 |
|---|---|---|
| 正常输入 | 常见参数、默认值路径 | 列出 2 到 3 条代表性输入，说明预期返回 |
| 边界输入 | 空集合、极值、长度上下限、可选字段缺省 | 明确指出边界值，要求每条边界单独一个用例 |
| 异常路径 | 参数非法、依赖抛错、状态不满足前置条件 | 说明错误类型或错误码，要求断言具体错误而非仅断言抛错 |
- 明确告诉模型不要碰什么：外部网络调用、当前时间、随机数、数据库读写，这些必须走 mock 或先抽成可注入的依赖，别让 AI 自己编造一个假的实现类
- 如果这段代码连你自己都说不清预期输出，先停下来补需求或改设计，这种情况下 AI 只会把你的模糊原样放大成一份看起来完整的测试
- 顺手记下每个分支对应的输入是什么，这份清单后面验收时要一条条对
给 AI 的提示词该长什么样
提示词里缺的信息，模型会自己补，补出来的通常和你的项目不一致：换了个测试框架、断言库不对、文件放错目录、命名风格跟团队规范打架。所以风格约定要显式写进去，比如「用项目现有框架，测试文件放被测文件同目录，用例名用中文描述被测行为」。
- 先要清单，不要直接要代码要求它先输出用例清单，每条标明正在验证哪一类行为，你逐条核对后再让它写代码。这样返工成本最低，改清单比改代码便宜。
- 贴全函数上下文函数签名、入参类型、返回值、已知错误码、调用方约定一起给。只贴函数体，模型容易漏掉调用方依赖的契约。
- 一次只处理一个文件或一个类批量丢一堆文件进去，模型对不上上下文，生成质量会明显下降，还容易把不同类的依赖串错。
- 把禁区写进提示词明确列出「不要真实发请求、不要读真实配置、不要用当前时间」，比事后逐条检查省事。
mock 与测试数据的处理
AI 生成单测最容易翻车的地方就是 mock。它可能真的去发一个请求，也可能反过来 mock 得太狠，把被测函数内部的辅助方法也替换掉，于是这条用例实际上只在验证 mock 自己。生成完要专门花几分钟看这部分。
- 先 mock 后断言
- 所有外部依赖在用例开头显式替换，用例体内不允许出现真实 IO
- 测试数据可读
- 用小规模固定值，别用随机字符串，出问题时你要能一眼看出在测什么
- 过度指定
- 如果一个内部辅助方法也被 mock 了，说明这条用例没测到真实逻辑，退回重写
- 易碎用例
- 涉及时间、并发、排序的用例要单独挑出来，连续跑几遍看是否偶发失败
生成完怎么验收：一条可复用的顺序
验收顺序很关键，顺序错了容易得出错误结论。最常见的错误是测试没通过就先去改断言，结果把真正测出 bug 的信号给抹掉了。
- 先跑一遍，看能不能过跑不过时先判断是断言写错了还是代码真有问题。不要急着手改断言，先确认预期输出到底是什么。
- 做变异自查手动把被测函数里的一处逻辑改反，比如条件取反、返回值加一，看测试会不会挂。没挂说明这条用例根本没测到点上。
- 看覆盖率报告里的分支重点找 AI 没提到但代码里真实存在的 else、catch、默认值分支，这些通常是漏测重灾区。
- 人工过一遍断言内容凡是「只断言不报错」或者「断言某个方法被调用过」却没说清结果的，一律退回重写。断言要能说清被测行为的结果。
- 定上线门槛新代码的行覆盖与分支覆盖各定一条团队能接受的线。具体参考值不要凭感觉，去 和站内测评口径页核对当期数字。
什么情况下别指望 AI
AI 擅长的是把已经说清楚的行为翻译成代码，不擅长替你做判断。下面几类活儿，提示词写得再好也难有好结果，硬塞给模型只是浪费时间。
- 复杂业务规则的判定条件：AI 只会复述你给的代码，不会替你发现规则本身写错了
- 需要构造大规模状态或时序的用例，比如分布式一致性、事务回滚，生成的脚手架通常不能直接用
- 性能与安全类测试不属于单测范畴，别和功能测试混在同一个提示词里
- 团队还没有统一测试规范时，先把规范定下来再谈用 AI，否则每个人生成的东西风格各异，维护成本比手写还高
常见问题
AI 生成的单测能直接进代码库吗？
可以，但要过一遍验收。建议先跑通、再做变异自查、最后人工看断言。满足这几条就合并，不然就先放在草稿分支里改到你敢为它负责为止。别因为「是 AI 写的」就降低标准。
为什么我生成的用例看起来很多，覆盖率却不高？
多半是重复覆盖同一批 happy path。检查方式很简单：打开分支覆盖率报告，看没被覆盖的分支是不是恰好都是异常路径和边界值，再回头把提示词里那部分行为清单补全，重新生成一遍。
用哪种模型写单测更合适？
优先选代码能力强的模型，具体当期哪些适合，去 /models 和 /benchmarks 看对应任务的评测再定。写单测对上下文长度要求不高，但对代码理解要求高，别只看价格挑最便宜的档位。
