企业级AI开发工作流落地实战-用集成测试把控 AI 代码质量

代码审查#

我要求团队每周至少安排一次固定时间的代码审查。

插一句题外话。软件工程是一门在实践中学习的学科。大学时，我死记硬背 Spring Boot 和 Kubernetes 部署，却不理解框架为什么存在，也不理解我们为什么需要集群。主要原因很简单：我还没亲自遇到那些问题。

没见过大流量，就难以理解集群。只写过脚本，就难以理解框架。没维护过不断增长的代码库，就很难体会抽象、模块化和清晰边界的价值。

在 AI 时代入行的工程师，仍然需要这些“过时”的知识。代码审查不只是检查质量，也帮助整个团队理解每次变更，以及代码库的分层。

AI 出现之前，代码审查就无法发现所有 bug，现在更不可能。因此，我把它的重点从发现 bug 转向了教学。

单元测试#

我已经基本不再投入精力写单元测试。AI 写完业务逻辑，再照着同一套逻辑写单元测试，测试就只是在确认代码按自身的逻辑运行。

公平地说，集成测试也存在同样的陷阱。AI 如果读取了有 bug 的代码，再据此生成测试，所有测试都会通过，bug 也就被“验证”了。所以，真正的原则不在于选择单元测试还是集成测试，而在于预期行为必须有实现之外的依据：需求、产品规则、真实的线上请求。对于跨服务、多步骤的业务流程，我把大部分精力投入到集成测试中。

集成测试驱动开发#

大多数人把 TDD 理解为单元测试驱动开发。我逐渐转向了集成测试驱动开发。

在公司里，要求每个人为自己用 AI 生成的代码负责，是一种不错的管理理念。但作为团队负责人，我必须假设大家并不总能承担起这份责任。在这个前提下，测试就成了安全网。

正因如此，集成测试处于我们团队工作流的核心。公司内部的基础设施支持自定义 API 调用链、控制调用间隔，以及模拟下游服务，让我们能尽可能贴近真实的线上请求。

顺序需要说明清楚：对于存量代码，我们事后补充生成集成测试；对于新需求，先根据需求确定预期流程，再让代码通过这些测试。只有后一部分才是真正的测试驱动开发。

AI 的业务理解#

我不希望 AI 通过人工维护的 Wiki 来理解业务。这些文档会逐渐偏离实际，往往直到系统出了问题才有人发现。我更愿意让它以代码、API 契约和真实的运行行为为依据。

代码最忠实地记录了系统当前的行为。它未必符合系统应有的行为，所以需求仍然需要参与其中。难点在于让 AI 从庞大的代码库中找到一条业务流程，并把它转化为集成测试步骤。

前端代码与数据流#

我的答案是：前端代码加数据流。

前端代码记录了 API 的调用顺序、各字段的数据来源，以及失败时的处理方式。它是最接近真实用户的一层。

很多共享后端服务根本没有前端。这时，数据流就是契约。API 调用传递数据，推动状态机流转。沿着数据流和状态变化，就能还原 API 的调用序列。

工作流#

首先，我们为存量代码生成一套完整的集成测试。此后，每个新需求都要根据需求本身和它涉及的流程生成集成测试，新代码必须通过这些测试。测试生成现在已经纳入了我们的需求流程。

这套方法正在发挥作用。我们已经发现了真实的 bug。

在我看来，集成测试正在成为 AI 时代防范生产事故最重要的保障之一。