让 AI 写完一段实现，它常在结尾补一句「以上代码测试通过，可以放心使用」。这句话听起来像验收报告，实际上多数时候只是模型的语言习惯。AI 没有在你的机器上运行过任何东西，所谓「测试通过」是在它的想象里完成的。测试结论必须本地复现，是使用 AI 编程的第一条硬纪律，原因拆开来讲有三层。
AI 的「测试通过」是怎么来的
语言模型的工作方式是预测下一段最像的文本，它生成代码时如此，生成「测试通过」这句话时也如此。三种常见的来源值得分清：一是延续语感——训练语料里代码示例后面常跟一句测试通过的说明，模型照着补全；二是脑内推演——模型在参数里「模拟」了一遍执行过程，模拟与真实执行之间隔着编译器版本、依赖行为、运行时差异；三是顺口承诺——为了显得回答完整而添加的收束语，与代码质量毫无关系。这和模型在评测集上的表现是两回事：基准分看着漂亮，落到你的具体任务上是另一套条件，落差怎么来的见基准分和实际任务的区别一篇。没有真实执行，就没有测试。
| 「测试通过」的来源 | 怎么产生 | 与代码质量的关系 |
|---|---|---|
| 延续语感 | 训练语料里代码示例后面常跟一句测试通过的说明，照着补全 | 无关，只是文本习惯 |
| 脑内推演 | 在参数里「模拟」了一遍执行过程 | 模拟与真实执行隔着编译器版本、依赖行为、运行时差异 |
| 顺口承诺 | 为了显得回答完整而加的收束语 | 毫无关系 |
环境差异为什么常翻车
同一段代码在不同环境里行为可以完全不同。依赖版本：模型按它见过的旧版 API 写调用，你的项目装的是新版，签名早已变更。运行环境：Windows 与 Linux 的路径分隔符、换行符、文件锁行为不一样，本地开发机能跑的脚本到 CI 上就挂。隐式约定：项目里的配置项、环境变量、自定义封装，模型一概不知道，它按通用写法生成的代码，恰好撞上项目的特殊约定。这类翻车有个共同点——AI 给出的测试结论越笃定，排查时越容易先入为主地信任代码本身，反而绕远路。模型对不确定性的表达方式，不确定性声明一篇讲过识别方法：回答里连一句「这取决于你的环境」都没有的，越要多留个心眼。
本地复现的标准动作
把 AI 的测试结论换成自己的，动作并不复杂。第一，代码先进分支，不合主干了再说。第二，跑一遍已有测试套件，退出码看一眼，别只扫输出里的 OK 字样。第三，AI 没写测试的关键路径，随手补两条断言，空值、边界、异常三个位置先覆盖。第四，涉及依赖调用的，先确认本地装的版本与模型假设的版本是否一致，不一致就按实际版本文档核对签名。做到这四步，AI 生成的代码才算经过了在你这个环境里的检验。复现过程发现的问题，贴回给 DeepSeek 或 Kimi 追问原因，模型解释报错的能力相当可靠，改完之后仍然回到本地再跑一遍——循环的终点始终是真实执行。
把 AI 结论当线索的协作习惯
团队协作里值得把这条纪律制度化：AI 生成的代码，提交说明里注明来源，测试结论一律以 CI 流水线为准，AI 的「通过」只算线索不算证据。code review 时对 AI 生成部分与人工代码一视同仁，标准见代码补全的正确打开方式一篇。个人层面也一样：豆包这类助手在结对讨论里很好用，但它说「测试通过」的时候，把它当成「建议你去测」来读，语义就对了。测试这件事没有捷径，可跑的代码比可听的结论值钱。
AI 测试结论四步复核
- 先进分支：AI 代码不直接合入主干
- 跑全套件：看退出码，不只看输出里的 OK
- 补断言：空值、边界、异常三处先覆盖
- 对版本：依赖版本与模型假设是否一致
测试复现快问快答
- AI 能不能直接在沙箱里跑测试？：部分工具提供了代码执行环境，能跑通是加分项，但沙箱环境与你的项目环境仍是两套条件，依赖、配置、数据都不一样，结论仍然要本地复核。
- 每次都本地跑一遍，AI 的效率优势还在吗？：在。AI 省的是写代码和查文档的时间，本地跑测试通常只要几分钟，与接受坏代码之后排查返工的成本相比，这道工序的性价比很高。
- AI 生成的测试代码可信吗？：当草稿用。它写的断言可能只覆盖正常路径，甚至为了让测试变绿而放宽条件，逐条检查断言是否真的在验证行为，而不是在迎合实现。
