发布时间：2026-10-07T02:00:01.616Z
同一段业务代码，分别用对话补测试、IDE插件生成、CI流水线自动补三种方式跑通，比较覆盖率、误报率和维护成本，说说哪些代码适合交给AI。 让AI写单元测试，已经从不靠谱变成可用了。但“能用”和“好用”之间，接入方式决定体验。这次拿同一段真实的业务代码（一个带状态流转的订单服务），分别用三种方式跑了一遍，记录差异。 第一种，对话式。把代码贴给AI，让它补测试。优点是灵活，能边聊边调，让AI针对边界条件多写几个用例。缺点很明显：没有代码库上下文，AI看不到其他模块的接口定义，生成的测试经常 import 不存在的依赖，需要手动修。覆盖率能到七成左右，但修修补补花的时间不少。 第二种，IDE插件。在编辑器里右键“生成测试”，插件会读取当前文件和项目结构，上下文比对话式好很多。生成的测试直接可运行的比例高了不少，对接口调用、mock 的处理更靠谱。覆盖率跟对话式差不多，但返工少。问题是对复杂逻辑的理解有限，业务规则写进注释里它才认。 第三种，CI流水线自动补。在合并请求触发时让AI自动生成测试、自动跑、把结果贴在评论里。这个方式的独特价值是覆盖面稳定：每次改动都会触发，测试库持续增长，不会因为开发者忘了而断档。缺点是生成耗时，大仓库里等待时间长，而且误报需要人来筛。 三个方式不是替代关系，是可以组合的。日常开发用IDE插件即时补，关键模块上线前用对话式重点补边界，CI自动补作为兜底，把覆盖率稳步推上去。 经验上，AI写测试最划算的是纯逻辑代码：工具函数、状态机、数据转换，规则清晰，AI一次到位。最不划算的是强依赖外部系统的代码，大量mock写起来比手写还慢。先把这两类分清楚，接入AI补测的收益就能放大。