分享一下我们的真实数字，不是为了炫，是为了给你一个参考锚点：

时间节点 覆盖率 备注
引入AI工具前 28% 全靠手写，主要是老代码
第一个月末 61% 主要靠Claude Code批量生成
第二个月末 82% 清理假断言、补边界用例后
清理后稳定值 76% 去掉无价值测试后的真实水位
注意最后一行：清理前是82%，清理掉假断言和pure-mock测试之后变成了76%。这6个点的差距，代表的是那些覆盖率贡献了数字但没有保护价值的测试。

76%的有效覆盖率，比82%的水分覆盖率实际上有价值得多。

另一个数据：用了Airwallex的思路（Claude Code Subagent多角色协作），他们做集成测试时把时间从2周压到了2小时，生成了4000+集成测试。这是多agent协作的路子，比单文件生成更系统。对于大型项目，这个方向值得研究。

常见问题
Q: 覆盖率应该定多少才合理？80%还是90%？

A: 看代码类型，不是一刀切。核心业务逻辑（订单、支付、权限）90%合理。工具类、配置类、DTO，50-60%就够了。统一要求所有代码80%以上，会逼人写大量低价值测试来凑数字，反而浪费时间。更好的做法是按包分层设定阈值。

Q: AI生成的测试，命名和编码风格跟我们团队不一致，每次都要手动改，麻烦吗？

A: Prompt里加"参考已有测试"这一项能解决80%的风格问题。给AI看几个你们团队的真实测试文件，它会自动学习命名约定、注释风格、断言偏好。剩下的20%用代码格式化工具（Checkstyle/golangci-lint）在CI里统一处理。

Q: 生成的测试跑不起来，报各种依赖注入错误，怎么办？

A: 这个最常见，通常是两个原因：一是Prompt里没有把测试上下文给清楚（Spring Boot项目要告诉AI这是Spring环境，需要加哪些注解）；二是AI选错了Mock方式（有时会混用@Mock和@InjectMocks的层次）。解决方法：把报错直接粘给AI，让它修复，通常1-2轮能解决。Go项目还要注意interface层级，AI有时会mock错误的interface实现。

Q: 测试写完了，但维护成本很高，每次改代码测试就大批报红，怎么处理？

A: 这是前面说的"坑二"的典型症状——AI对实现细节过度断言。解决方案分两步：一是用本文的Prompt约束来约束新生成的测试；二是对存量的脆化测试，让AI帮你重构（把verify调用改成对结果的assertEquals，删掉对调用顺序的断言）。这个重构过程我们花了大约两天，之后维护成本降了很多。