用 AI 写业务代码和补测试，不是偷懒，而是提升效率

很多团队现在对 AI 编程的态度很分裂。

一边是开发者每天偷偷用 AI 写代码、补注释、查报错、生成单测；另一边是技术负责人开会时还在强调：“核心代码不能交给 AI，质量不可控。”

这两种态度都不够成熟。

AI 写业务代码这件事，既不是银弹，也不是洪水猛兽。它真正的价值，不是让程序员少敲几行代码，而是把研发流程里那些低价值、重复性强、但又必须认真完成的环节重新组织起来。

其中最典型的场景，就是自动补齐测试用例，提高单测覆盖率。

因为在真实团队里，单测不是没人知道重要，而是经常没人愿意写、没时间写、写得不系统、维护成本高。结果就是代码越写越多，测试债越滚越大，最后每次发版都靠人肉回归和祈祷。

AI 介入之后，真正值得做的不是“让 AI 替你随便写代码”，而是让 AI 帮团队把业务代码、边界条件、测试用例和质量门禁串成一条更稳定的工程流水线。

一句话：

AI 编程最先成熟的落点，不是自动开发一个系统，而是让已有系统的质量债变得可治理。

一、为什么单测覆盖率长期上不去

很多管理者喜欢把单测覆盖率低归因于开发者不重视质量。

这话只说对了一小部分。

真实情况更复杂。

第一，业务代码变化太快。

互联网业务、企业内部系统、SaaS 产品，很多需求都是边跑边改。今天加字段，明天改状态，后天调整计费规则。开发者连业务逻辑都刚理顺，很难再花同等时间写完整测试。

第二，历史代码太重。

很多系统不是从零开始，而是已经跑了三五年。里面有大量 service、manager、util、handler、controller，依赖复杂，状态隐含，边界模糊。你让新人给这些代码补单测，第一反应不是写测试，而是先问：“这段代码到底想干什么？”

第三，测试样例设计比写断言更难。

写一行 assertEquals 不难，难的是知道应该测哪些场景。正常路径、异常路径、空值、边界值、权限、幂等、事务回滚、外部接口失败、并发冲突，这些都需要经验判断。

第四，Mock 成本高。

业务代码一旦依赖数据库、缓存、消息队列、第三方 API、文件系统，测试就会变麻烦。很多团队最后不是不想写，而是写一个测试要 Mock 半天，性价比太低。

第五，覆盖率指标被滥用。

有些团队把覆盖率当 KPI，最后开发者写了一堆“调用一下不报错”的测试。覆盖率上去了，质量没上去。这种测试不但没价值，还会增加维护负担。

所以，单测覆盖率上不去，不是简单的态度问题，而是工程系统问题。

AI 能解决一部分，但前提是要把它放在正确的位置。

二、AI 写业务代码最适合从“受约束场景”切入

让 AI 完整开发一个复杂业务模块，风险很高。

因为业务代码不是算法题，它背后有大量上下文：领域模型、历史兼容、权限规则、异常处理、事务边界、性能要求、团队代码风格。

如果直接对 AI 说“帮我实现订单退款功能”，它大概率会写出一段看起来完整、实际不能上线的代码。最危险的是，这类代码表面很像真的，Review 时稍不注意就会漏掉关键问题。

但如果把任务拆小，AI 的价值会非常明显。

比如：

• 根据已有接口补 DTO、VO、Mapper；
• 按团队风格生成 CRUD 代码；
• 根据业务规则补充条件分支；
• 根据异常枚举补错误处理；
• 根据已有方法生成类似方法；
• 根据代码生成单测初稿；
• 根据覆盖率报告补漏测分支；
• 根据 Review 评论修改代码。

这些场景的共同点是：上下文明确、模式稳定、质量可校验。

这就是 AI 写业务代码的关键原则：

不要让 AI 在高不确定性里自由发挥，要让 AI 在强约束下提高产出。

技术团队应该把 AI 当成一个执行力很强的初级开发，而不是一个可以替代架构判断的专家。你要给它清晰的上下文、明确的边界、可验证的目标和必要的反馈。

在这种模式下，AI 不是降低代码质量，而是把开发者从大量重复劳动中解放出来，让他们把精力放在业务判断和架构设计上。

三、AI 自动补测试的真正价值：从“写用例”到“识别风险”

很多人使用 AI 补单测，只是把代码贴进去，让它生成几个测试方法。

这当然有用，但价值有限。

真正成熟的做法，是让 AI 不只是写测试，而是先分析风险。

比如一个订单折扣计算方法，AI 不应该直接生成测试代码，而应该先识别测试维度：

• 商品金额为 0、负数、超大值；
• 折扣为空、折扣为 0、折扣超过上限；
• 会员等级不同；
• 优惠券是否可叠加；
• 活动是否过期；
• 结果是否需要四舍五入；
• 金额精度是否存在浮点问题；
• 异常输入应该抛错还是返回默认值。

这些才是测试价值所在。

如果 AI 只是生成 happy path 测试，覆盖率可能提升了，但线上风险没有下降。好的测试用例应该覆盖业务分支、异常分支和边界条件。

AI 在这里的优势非常明显。

它能快速阅读代码结构，识别 if/else、异常抛出、外部依赖、枚举分支和边界判断，然后生成对应测试场景。对于历史代码，它还能帮助开发者理解“这段代码可能有哪些隐含行为”。

更进一步，AI 可以结合覆盖率报告工作。

比如 JaCoCo、Istanbul、Coverage.py 这类工具能告诉你哪些行没覆盖、哪些分支没覆盖，但它们不会告诉你该怎么补测试。AI 可以读取覆盖率报告、源码和已有测试风格，然后生成针对未覆盖分支的测试用例。

这比盲目追覆盖率更有价值。

因为目标不是让数字好看，而是让风险暴露。

四、一个可落地的 AI 单测补齐工作流

如果团队想真正落地 AI 补测试，我建议不要靠个人自由使用，而是设计成标准研发流程。

一个比较稳的工作流可以分成六步。

1. 代码上下文提取

AI 要写好测试，必须看到足够上下文。

仅给一个方法通常不够，它还需要看到：

• 被测类完整代码；
• 相关 DTO、枚举、异常类；
• 依赖接口定义；
• 已有测试样例；
• 团队测试框架和 Mock 风格；
• 关键业务规则说明。

上下文越完整，AI 生成的测试越接近团队真实代码。

但上下文也不能无限塞。更好的方式是由工具自动提取相关文件，并做裁剪。比如只保留方法签名、字段定义、枚举值、已有测试模式，而不是把整个仓库都丢给模型。

2. 风险点分析

生成测试前，先让 AI 输出测试场景。

这一步可以要求 AI 按维度列出：

• 正常路径；
• 边界条件；
• 异常输入；
• 外部依赖失败；
• 权限或状态限制；
• 幂等与重复调用；
• 数据精度问题。

开发者先看场景是否靠谱，再让 AI 写代码。

这一步能过滤很多无效测试，也能暴露开发者自己没想到的边界。

3. 测试代码生成

测试生成时，不要让 AI 自创风格。

应该明确要求它参考项目已有测试，包括命名方式、断言方式、Mock 框架、测试数据构造方式、目录结构。

比如 Java 项目可能使用 JUnit 5 + Mockito，前端项目可能使用 Jest + React Testing Library，Python 项目可能使用 pytest。不同技术栈的最佳实践差异很大，不能让 AI 混写。

生成的测试最好小步提交，一次只覆盖一个类或一个模块。不要一口气让 AI 改几十个文件，否则 Review 成本会爆炸。

4. 自动运行测试

AI 写完测试后，必须立刻运行。

这一步不能省。

很多 AI 生成的测试第一次都会有问题：Mock 不完整、依赖没注入、方法签名过期、断言不符合实际结果、测试数据构造失败。只有跑起来，才能进入有效反馈。

理想状态是工具自动执行：

mvn test

或者：

npm test

再把失败日志回传给 AI，让它修复。

5. 覆盖率反馈

测试通过不代表覆盖率有效提升。

必须生成覆盖率报告，并让 AI 根据报告继续补未覆盖分支。

例如：

mvn test jacoco:report

或者：

npm test -- --coverage

AI 可以根据报告判断哪些分支还没覆盖，并补充更精确的测试。

这里的关键是，不要只盯总覆盖率，要看核心业务类、关键分支和高风险方法。

一个支付核心模块 90% 覆盖率，比一堆 getter/setter 100% 覆盖率有价值得多。

6. 人工 Review 和入库

最后一步必须有人 Review。

AI 生成的测试可能会犯几类错误：

• 测试实现逻辑，而不是测试业务行为；
• 为了通过测试而复制源码逻辑；
• Mock 掉了真正应该验证的分支；
• 断言过弱，只验证不报错；
• 构造了不符合业务真实情况的数据；
• 忽略事务、并发和外部系统影响。

因此，AI 补测试可以提高效率，但不能取消工程师的责任。

工程师 Review 的重点不是代码写得漂不漂亮，而是测试有没有验证真实业务风险。

五、架构上怎么做：把 AI 放进 CI/CD，而不是停留在聊天窗口

如果 AI 补测试只停留在个人聊天工具里，很难形成团队能力。

成熟团队应该把它产品化，至少要接入研发流水线。

一个可行架构大概是：

• 代码仓库触发变更；
• 分析本次 MR/PR 改动文件；
• 找出新增或修改的业务方法；
• 读取已有测试和覆盖率报告；
• AI 生成测试建议和测试代码；
• 自动创建补测分支或评论到 MR；
• CI 执行测试与覆盖率检查；
• 开发者 Review 后合并。

这里有几个关键点。

第一，AI 不应该直接合并代码。

它可以提交建议、生成补丁、创建 MR，但最终合并权必须在人和 CI 手里。

第二，覆盖率门禁要分层。

新代码覆盖率可以要求高一些，比如 80%；历史代码不要一刀切，否则团队会被老债拖死。更合理的方式是“增量覆盖率”优先：本次改动的代码必须有测试，历史代码逐步补。

第三，核心模块要更严格。

支付、订单、权限、计费、数据同步这类模块，测试要求应该高于普通后台页面。AI 可以帮忙补，但规则要由团队定义。

第四，测试生成要有白名单。

不是所有文件都适合自动补测试。比如强依赖 UI、外部硬件、复杂异步流程、历史遗留超级类，可能需要人工先重构，再考虑 AI。

第五，所有 AI 行为要可追踪。

谁触发的、基于什么上下文生成的、改了哪些文件、测试结果如何、覆盖率提升多少，都应该记录下来。这不是形式主义，而是工程治理需要。

AI 进入研发体系后，本质上也是一个“自动化贡献者”。既然它能改代码，就必须接受同样的工程约束。

六、真正的坑：AI 生成的测试可能制造虚假安全感

AI 补测试最大的风险，不是写错，而是让团队误以为质量提高了。

覆盖率是一个很容易被美化的指标。

AI 可以快速生成大量测试，把覆盖率从 30% 拉到 70%。但如果这些测试只是调用方法、Mock 一切、断言非空，那它们对质量几乎没有贡献。

更糟糕的是，这些测试会增加维护成本。未来业务逻辑变了，测试跟着大量失败，开发者会觉得测试是负担，最后又开始批量删除或跳过。

所以团队必须建立测试质量标准。

一个有价值的单测，至少应该满足几个条件：

• 验证业务行为，而不是复制实现细节；
• 覆盖正常路径之外的边界和异常；
• 断言具体结果，而不是只断言不为空；
• Mock 外部依赖，但不 Mock 被测逻辑本身；
• 测试名称能表达业务场景；
• 失败时能帮助定位问题。

比如下面这种测试价值很低：

@Test
void testCalculate() {
    Order order = new Order();
    BigDecimal result = service.calculate(order);
    assertNotNull(result);
}

它几乎没有验证任何业务行为。

更好的测试应该表达明确场景：

@Test
void shouldApplyVipDiscountWhenCouponIsNotStackable() {
    Order order = orderWithVipLevelAndNonStackableCoupon();
    BigDecimal result = service.calculatePayAmount(order);
    assertEquals(new BigDecimal("90.00"), result);
}

这类测试能告诉后来的人：当会员折扣和不可叠加优惠券同时出现时，系统应该按什么规则计算。

AI 可以生成第二种测试，但前提是你要求它理解业务，而不是只追覆盖率。

七、团队该如何开始

如果你的团队想用 AI 写业务代码并自动补测试，我建议从一个小切口开始。

不要一上来全仓库扫描、全自动生成、全量提交。这种做法很容易制造一堆垃圾测试。

更稳的路径是：

先选择一个业务相对清晰的模块，比如优惠券、订单状态流转、用户积分、库存校验、账单计算。

然后整理该模块已有代码和测试风格，让 AI 学会团队的写法。

接着选取 5 到 10 个核心类，让 AI 先做测试场景分析，而不是直接写代码。

开发者 Review 场景后，再让 AI 生成测试。

生成后跑测试、看覆盖率、修失败、再 Review。

如果这条链路跑通，再接入 MR 流程，对新增代码做增量补测。

最后把成熟规则沉淀成团队内部的 AI 测试 Skill：

• 如何识别测试场景；
• 如何读取覆盖率报告；
• 如何生成符合团队风格的测试；
• 哪些代码不能自动补；
• 哪些断言标准必须满足；
• 如何处理 Mock；
• 如何输出测试说明。

当这个 Skill 稳定后，它就不再是某个开发者的个人技巧，而是团队工程能力的一部分。

结语：AI 编程的终局，不是替代程序员，而是提高工程下限

未来几年，AI 写代码会越来越普遍。

但真正拉开团队差距的，不是谁用的模型更大，也不是谁的插件更多，而是谁能把 AI 放进工程体系里，让它稳定地提高研发质量。

业务代码可以让 AI 写一部分，测试用例可以让 AI 补一部分，覆盖率可以让 AI 帮你提升一部分。但架构判断、业务取舍、风险识别和质量责任，仍然在工程团队手里。

技术管理者要警惕两种极端。

一种是拒绝 AI，把它当玩具，最后团队效率被同行拉开。

另一种是迷信 AI，把它当外包，最后代码库里堆满看似正确、实则脆弱的代码。

正确姿势是把 AI 当成工程体系里的“高效辅助开发者”：让它做重复劳动，让它补齐测试债，让它发现遗漏分支，让它生成初稿，但用代码规范、CI、覆盖率、Review 和业务规则约束它。

AI 不能替你建立工程文化，但可以放大已有工程文化。

如果你的团队本来就重视测试、重视 Review、重视架构边界，AI 会让你更快。

如果你的团队本来就混乱、没有规范、没人负责质量，AI 只会让混乱以更快速度扩散。

所以，用 AI 写业务代码和自动补测试，表面是工具升级，本质是研发体系升级。

真正值得追求的，不是“AI 帮我写了多少代码”，而是：

每一次 AI 参与之后，系统是不是更可测试，风险是不是更可见，团队是不是更敢改代码。

这才是单测覆盖率提升背后的真实价值。