这次我们来看一个很有意思、也很要命的现象AI 编程工具已经能帮你把测试用例写到“全绿”代码 Review 的时候却发现整个实现烂到根本没法修只能推倒重来。如果你觉得“测试都过了代码还能差到哪去”那这篇文章就是给你写的。我会拆解这个坑是怎么形成的AI 生成代码为什么容易出现“假绿”以及从测试设计、Code Review、CI 门禁到 Prompt 写法到底怎么把质量防线补上。1. 现象复盘测试全绿代码为什么还要重写先还原一个真实工作场景。团队用 Cursor 辅助开发一个新模块需求是“根据用户等级和订单金额计算最终折扣”。开发同学把需求贴给 AI让它生成实现和单测。几分钟后代码写完了测试跑完一片绿。看起来效率很高对吧但到了 Code Review 阶段问题开始暴露核心计算逻辑只有一个 if-else 分支会员等级、优惠券叠加、金额上限这些业务约束全部没接住。测试全部在 mock 一个DiscountCalculator的私有方法实际上等于把生产代码抄了一遍到测试里。有一半测试是用assertTrue(result ! null)这种级别的断言跑不跑效果差不多。异常分支、边界值、并发调用、重复请求几乎没人测。这些代码如果合并进主干短期看测试是过了长期看就是技术债的源头。业务一旦在它上面迭代就得在错误的地基上盖楼最后只能推倒重写。这不是 AI 编程工具本身“不行”而是它生成的代码天然存在两个问题第一它更倾向于生成“看起来正确”的代码而不是“经得起推敲”的代码第二它生成的测试用例大多数时候是在迎合实现而不是在验证需求。换句话说测试全绿只能说明“代码按照它自己的逻辑跑通了”并不能证明“代码满足了业务要求”。2. 测试全绿的假象来源为什么测试全绿代码还是烂关键要分清“真绿”和“假绿”。下面这四类情况是最常见的假绿来源。2.1 断言太弱测试等于没写看一段常见代码Test public void testCalculateDiscount() { DiscountResult result discountService.calculate(Order.create()); Assertions.assertNotNull(result); }这个测试跑一百次都是绿的但它什么都没验证。它只告诉你“方法没有抛异常返回了一个非空对象”。至于折扣算得对不对、边界条件有没有处理完全没有覆盖。强断言的测试应该是这样的Test public void testVipUserWithHighAmountGetsMaxDiscount() { User vipUser User.create(VipLevel.GOLD); Order order Order.create(10000.0, Currency.CNY); DiscountResult result discountService.calculate(vipUser, order); Assertions.assertEquals(2000.0, result.getDiscountAmount()); Assertions.assertEquals(8000.0, result.getPayableAmount()); Assertions.assertEquals(DiscountRule.MAX_RATIO, result.getAppliedRule()); }对比一下就能看出来前一个测试是为了“跑绿”而存在的后一个测试才是为了“验证功能”而存在的。2.2 只测主路径不测边界和异常AI 生成测试时最典型的模式就是“给一个正常输入断言一个正常输出”。但真实系统里Bug 往往不在主路径上而在这些位置金额为 0 或负数。用户等级为空。折扣后金额出现负数。并发下产生重复订单。上游服务超时。数据库连接断掉。如果测试用例没有覆盖这些分支测试全绿没有任何意义。2.3 Mock 过多把关键链路全部打断AI 生成测试时特别喜欢 mock。因为它要保证测试能稳定跑过最省事的办法就是把网络、数据库、缓存全部 mock 掉。结果就是测试里跑的根本不是真实逻辑的组装结果。接口方法里最核心的那段查询逻辑被 mock 掉了而真实查询数据的 SQL 有没有问题、返回结果解析对不对测试完全感知不到。更严重的是有时候 AI 会把生产实现里的判断逻辑自动同步到测试里测试通过不是因为代码正确而是因为测试和生产代码犯了同一个错误。2.4 测试与生产实现共享同一套错误认知假设需求是“金额大于 100 元时免运费”。AI 写实现时可能理解成“金额大于等于 100 元时免运费”。然后它写测试时也按照“大于等于”来写。测试全绿因为实现和测试是同一个错误认知产物。Review 的人如果只看测试不看需求就会被误导以为逻辑没问题。这就是最危险的假绿它不是在验证需求而是在验证 AI 自己的理解。3. AI 编程工具的生成逻辑与质量盲区要避开这个坑得先理解 AI 编程工具生成代码的方式。3.1 工具的工作机制以 Cursor、GitHub Copilot、通义灵码等工具为例它们的核心是根据当前文件和已有上下文预测下一个 token。训练数据来自大量开源代码所以它很擅长生成“足够常见”的代码模式。问题就在这里常见不等于正确更不等于符合你的业务。AI 可以很流畅地写一个UserService但它不知道你系统里User状态的流转规则不知道订单金额必须保留两位小数不知道某些接口要求幂等。这些信息只能由开发者通过 Prompt 和代码上下文喂给它。喂得不够它就按自己的“平均理解”来写而这个平均理解和真实需求之间往往有偏差。3.2 AI 生成代码的常见病从大量 AI 编程实践来看AI 生成代码最容易出现以下问题问题类型表现为什么测试发现不了输入校验缺失参数直接塞进数据库查询测试传入的都是合法值错误处理随意异常被静默吞掉测试没有构造异常场景硬编码折扣率、超时时间直接写在代码里只测当前值不测配置变化复制粘贴式实现两个方法逻辑高度重复功能性测试能过维护时才发现并发处理缺失共享变量没有加锁单线程测试全绿逻辑边界错误边界判断使用而不是测试边界值覆盖不足结构混乱一个类几百行函数职责不清行为正确但难以扩展3.3 关键认知AI 生成的测试是用来“给自己交差”的AI 生成测试时它的优化目标是“让测试通过”不是“让代码可靠”。它甚至会为了通过测试而选择实现方式而不是为了正确满足需求而选择实现方式。这就导致测试的数量在增加质量却在下降。很多时候AI 生成的测试越多代码的“虚假安全感”越强反而更容易让团队放松 Code Review 的警惕。4. 识别“危险绿”的检查清单既然测试全绿不可信那 Review 的时候应该重点看什么我给你一份可以直接抄进团队 Code Review 清单里的内容。4.1 测试本身的检查项检查项通过标准断言强度每个测试至少有一个可验证业务结果的强断言而不是assertNotNull边界值覆盖有 0、负数、空值、最大值、超长文本等边界用例异常路径有超时、网络异常、数据库异常、非法参数触发场景Mock 范围Mock 只隔离外部依赖不 mock 待测方法内部的关键业务逻辑测试命名测试方法名能看出“在测什么场景、期望什么结果”测试独立性用例之间不共享可变状态可以随机顺序执行4.2 生产代码的检查项是否有输入参数校验校验失败时是否返回明确错误。是否把业务规则集中在明确的位置而不是散落在各个 if 里。是否处理了并发、幂等、超时等非功能性需求。是否有关键日志能支持线上排查问题。是否存在大函数、重复代码、过长参数列表。方法职责是否单一类是否臃肿。4.3 判断是否需要重写的信号信号说明测试改动牵一发动全身代码结构已经脆弱到“动一行测试崩十个用例”生产代码与测试重复度高测试只是在复述实现没有任何独立验证价值测试覆盖率“虚高”覆盖率 90%但核心业务分支一条没测到变更无法渐进完成加一个新特性必须大规模改代码而不是加分支如果出现这些信号不要因为“测试全绿”而舍不得重写。这时候重写的成本远低于在这堆代码上继续迭代的成本。5. 建立质量防线从“测试通过”到“可维护、可上线”要真正解决“测试全绿但代码烂”的问题不能只靠 Review 时人工判断还要把质量约束自动化。5.1 用变异测试暴露“假绿”变异测试Mutation Testing的思路很简单故意在源码里引入一个小改动比如把改成、删掉一个条件判断然后跑一遍现有测试。如果测试仍然全绿说明这个改动没有测试能捕获测试对这个逻辑是不敏感的。变异测试能直接告诉你测试到底“测没测到”代码。以 JaCoCo 只覆盖“代码执行了没有”而变异测试回答的是“测试能不能发现代码变了”。两者的价值完全不同。一个例子public int getDiscount(int amount) { if (amount 100) { return 10; } return 0; }现有测试Test public void testDiscountWhenAmountGreaterThan100() { assertEquals(10, discount.getDiscount(200)); }这个测试执行后 JaCoCo 显示对应行已覆盖但它只测了amount 100为 true 的分支。变异测试把条件改成amount 100后如果测试仍然通过说明边界值 100 这个场景没有被捕获。这就是“假绿”被暴露出来的过程。建议在 CI 里引入 PITJava或 StrykerJavaScript等变异测试工具对核心模块周期性运行把变异存活率作为质量门禁。5.2 静态检查和复杂度门禁在 CI 中加入静态检查工具能拦截很多 AI 生成代码的典型问题ESLint / SonarQube 检查未使用变量、重复代码、复杂度过高。设置圈复杂度阈值单个方法超过 10 就报警。检查魔法数字禁止硬编码折扣率、超时时间。检查 TODO/FIXME 数量防止 AI 生成一堆未完成代码混入主干。# 以 GitHub Actions 为例的阶段示意 name: quality-gate on: pull_request: jobs: check: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Run unit tests run: pnpm jest --coverage - name: Check coverage threshold run: pnpm jest --coverage --coverageThreshold{global:{lines:80}} - name: Run lint run: pnpm eslint . --max-warnings10 - name: Check complexity run: npx complexity-report src5.3 强制 Code Review而且必须 Review 测试代码很多团队 Review 时只盯生产代码测试代码扫一眼就过。这个习惯要改。Review 测试代码时重点看测试是不是真的在验证业务结果。测试里有没有把生产实现的逻辑复制一遍。测试覆盖率高的区域是不是集中在核心业务逻辑上。有没有“为了凑覆盖率”而写的垃圾断言。6. CI 中拦截“假绿”的实践建议光靠人盯是不够的要在 CI 流程里把质量约束变成自动化的“硬性条件”。6.1 覆盖率阈值要有但不能只盯着覆盖率覆盖率是个滞后指标。它有参考价值但容易被“凑”。更好的做法是给“关键模块”单独设置覆盖率阈值比如支付、订单、折扣、权限模块强制达到 90% 以上其他模块可以放宽。6.2 加入变异测试门禁对核心模块设置“变异存活率低于 10%”的目标。如果变异存活率太高说明测试的侦察能力太弱CI 直接失败。6.3 加入 API 契约测试AI 生成的内部代码即使单测全过集成时也可能因为接口定义不一致而崩掉。使用契约测试Contract Test保证服务间调用的输入输出结构一致。6.4 冒烟测试必须覆盖真实链路单测补不了的短板用冒烟测试来补。在测试环境跑一个最小链路发起请求、走真实数据库、返回真实结果。这个链路一定不要 mock。# 冒烟测试示例真实调用本地服务 curl -X POST http://localhost:8080/api/order/discount \ -H Content-Type: application/json \ -d {userId:u_001,amount:1000,vipLevel:GOLD}如果这个 curl 返回的结果和业务预期一致比十个 mock 测试都有说服力。7. 给 AI 编程者的实际建议回到最根本的问题怎么用 AI 编程才能减少这种“测试全绿但代码烂”的情况7.1 哪些任务适合交给 AI 写模板化代码Controller、DTO、Mapper 这类结构固定的代码。工具函数日期格式化、编码转换、字符串处理这类边界清晰的函数。测试数据构造生成基础测试数据、Mock 配置。重构辅助让它帮你拆函数、改命名但需要人工验证。7.2 哪些任务一定要自己写核心业务规则折扣计算、金额分摊、库存扣减、状态流转。涉及并发和事务的逻辑。与外部系统对接的签名和错误处理。安全相关的鉴权、越权校验。7.3 Prompt 里要求“测试先行覆盖边界”给 AI 下指令时不要只让它“写代码 写测试”要明确要求请按照 TDD 方式实现订单折扣功能 1. 先列出至少 6 个测试场景包括普通用户、VIP 用户、金额为 0、金额为负数、折扣后金额为负数、并发重复请求。 2. 每个测试必须使用明确断言禁止使用 assertNotNull 作为唯一断言。 3. 实现代码必须包含参数校验、异常处理和边界值判断。 4. 禁止 mock 方法内部的业务逻辑。 5. 输出后请自检如果修改边界条件哪些测试会失败这个 Prompt 的核心是逼着 AI 先想测试场景而不是先写实现。测试场景列得越全实现越不容易跑偏。7.4 绝不直接接受 diffAI 生成的代码必须先看、再改、最后提交。不要因为测试全绿就直接合入。最稳妥的流程是AI 生成代码。开发者阅读并理解每一行。开发者补充缺失的边界测试。修改生产代码直到测试和实现都符合业务理解。提交后交给另一个同事 Review。8. 常见误区和排查思路问题排查方式解决方案测试全绿但上线就出 Bug检查是否只测了 happy path是否 mock 掉关键链路补真实链路冒烟测试减少关键逻辑 mock覆盖率 90% 但还是漏测覆盖率统计的是“执行覆盖”不是“逻辑验证覆盖”引入变异测试查看测试对代码变异的感知力AI 生成的测试老是报错测试依赖顺序、共享状态导致不稳定重写为独立测试隔离外部依赖断言全绿但是感觉不踏实断言强度不足只验证非空或返回成功把断言改成具体业务结果数值修改一行代码大量测试失败测试耦合实现细节结构脆弱重构测试面向行为而非面向实现不知道代码该不该重写改动成本已经大于重写成本用“信号表格”逐项判断AI 生成的代码放进生产就报错缺少输入校验、边界处理、环境差异增加参数校验补边界测试增强 CI 门禁9. 最佳实践与合规边界用 AI 编程还有几个工程和合规层面的东西要提醒。9.1 敏感代码不要直接贴进云端 AI 工具很多 AI 编程工具会把代码上传到云端处理。涉及内部业务逻辑、数据库连接、用户数据的代码最好先做脱敏或者使用私有化部署的模型/IDE 插件。9.2 AI 生成代码的开源许可证风险AI 训练数据来自大量开源仓库生成的代码可能带有特定的开源协议约束。商用项目里对 AI 生成的关键代码要做一轮协议合规确认不确定时不要直接落进生产。9.3 测试数据不要用真实用户信息AI 生成测试数据时可能直接套用真实用户 ID、手机号、地址。这涉及隐私合规问题。测试环境一律使用脱敏数据或 mock 数据。9.4 发布前人工复核仍是底线无论 AI 多么熟练核心业务模块上线前必须由有经验的开发者做一次完整 Code Review并至少在测试环境跑一轮真实链路验证。“AI 生成 测试全绿”不能替代人工复核。10. 总结与下一步AI 编程的价值不需要怀疑但“测试全绿”只是一个结果指标不是质量指标。真正的质量防线是测试强度、Code Review 和 CI 门禁的组合。最先要验证的是你现在项目里的测试到底有多强。建议从一个小模块开始跑一次变异测试看看有没有“变异存活”。如果存活率很高那可以确定你们项目里可能存在不少“假绿”。最容易踩的坑是拿到 AI 生成的测试后直接信任。记住一个原则AI 生成的测试不是验收标准你的业务需求才是验收标准。下一步可以做的是在团队里推进三件事给 AI 编程定 Prompt 规范、在 CI 里加变异测试门禁、把测试代码纳入 Code Review 范围。这三件事做完测试全绿的假象也就不再是危险的坑了。建议收藏备用下次让 AI 写代码之前先把这套标准拿出来对照一遍。