写单元测试最耗时间的从来不是断言语法，而是想清楚「这个函数到底该测哪些情况」。想漏一条，线上就多一个事故现场。这件事恰好是 AI 的强项：它擅长穷举清单，你负责判断哪些情况真的会发生。把「列清单」和「写代码」分开交给它，补测试的效率会完全不一样。
先让 AI 看懂函数，再让它写测试
把被测函数连同它依赖的类型定义、常量一起贴给模型，同时说明三件事：用什么框架（pytest、Jest、JUnit 都行）、项目里的命名习惯、以及期望的覆盖数量。只贴一个孤零零的函数体，模型会自己脑补参数类型，写出来的测试跑都跑不起来。
提示词的结构可以固定下来：「这是被测函数……用 pytest 写……正常路径 2 条、边界 3 条、异常 2 条……只 mock 外部依赖，不许 mock 被测逻辑本身」。约束给得越具体，首稿可用率越高。
一个值得养成的顺序：先让 AI 列出「你打算覆盖哪些情况」，人工确认清单合理后，再让它生成测试代码。先清单后代码，比直接要代码再逐条返工省得多。
边界与异常：点名才覆盖
模型默认倾向写「一切顺利」的路径。想让它覆盖边界与异常，必须在提示词里逐个点名：空输入、零、负数、超大值、重复键、过期时间、非法 JSON、网络超时。点名之后它会逐条对应生成，漏掉哪条补问哪条即可。
举个例子：一个解析优惠券的函数，正常路径只有「满减生效」一条，真正值得测的却是「刚好等于门槛」「优惠后金额为负」「券已过期」「券与商品不适用」这四条边界——线上事故几乎都出在这里，也正是 AI 补测试最划算的产出。
从片段到可运行：接进项目
生成的测试先跑一遍再说。模型不知道你的 fixture 怎么命名、工具函数从哪个模块导入，首稿常有 import 错、路径错这类低级问题。把报错信息原样贴回给模型，两三轮基本能跑通，别自己逐行改。
接口统一走 https://api.aigcbreeze.cn/v1，编码场景可以选 glm-5.3 这类编码向模型，批量补测试、对成本敏感时用 deepseek-v4-flash。按模块分批送上下文，一次塞整个仓库只会让答案变得平庸。
审一遍再合入：三个常见毛病
一是断言跟着实现走：让 AI 先改实现再写测试，bug 会被测试固化下来。正确顺序是先定行为再动代码，测试表达的是「应该怎样」而不是「现在怎样」。二是空转断言：只调用不断言、assert True 这类测试跑绿了也证明不了任何事，审的时候重点看每条测试末尾有没有真断言。三是重复堆叠：模型喜欢把同一个场景换三种写法各写一遍，冗余用例会拖慢 CI，合并时删掉即可。
合入前的检查清单很短：每条测试都有明确断言；测试名能读出「什么条件下期望什么」；与既有用例重复的删掉；你点名的每条边界至少有一条对应测试。满足这四条，这批测试就值得进主干。
常见问题
AI 生成的测试跑不过，是测试错了还是代码错了？
都有可能，而这恰恰是测试的价值所在。先人工判断行为预期：如果测试表达的行为才是对的，把它当需求去修代码；如果代码是对的，让模型改测试。最忌讳不加判断就把断言改成「符合现状」——那等于把 bug 盖了章。
它会不会把业务逻辑都 mock 掉，测了个寂寞？
会，所以要提前立规矩：只允许 mock 外部依赖（网络、数据库、系统时间），不许 mock 被测对象本身。生成后扫一眼 mock 的目标列表，发现 patch 打到了被测函数上就整条退回重写。
老项目没有测试，能全靠 AI 补吗？
可以，但别追求一步到位。先挑改动频繁、出过 bug 的核心模块，一次一个文件；让 AI 边读代码边写测试，覆盖率从零到六成的价值，远大于从六成磕到八成。