AI编程 实战案例分享｜生产环境实测

当 AI 编程工具从“写 Demo 很快”走向“生产环境可用”，真正的挑战才刚刚开始。本文结合一次真实的生产环境落地案例，分享 AI 编程在需求分析、代码生成、测试补全、性能优化、故障排查和团队协作中的实践经验，并总结可复制的方法论。

一、为什么要在生产环境中尝试 AI 编程？

过去一年，AI 编程工具快速普及。很多开发者已经习惯让 AI 帮忙生成函数、解释报错、编写 SQL、补全单元测试，甚至直接根据需求生成一整个模块。

但在企业级生产环境中，大家对 AI 编程往往仍然保持谨慎态度，原因也很现实：

1. 业务复杂度高：生产系统不是独立脚本，涉及历史逻辑、权限、数据一致性、并发、灰度发布等问题。
2. 代码质量要求高：代码不仅要能跑，还要可维护、可测试、可回滚。
3. 安全风险不可忽视：AI 可能生成不安全的接口、错误的权限判断、低效的 SQL。
4. 团队协作成本：AI 生成的代码如果风格不统一，可能增加 Code Review 和维护成本。
5. 结果不可控：AI 有时会“自信地犯错”，如果缺乏验证机制，容易埋下隐患。

因此，本文讨论的不是“AI 能不能写代码”，而是更关键的问题：

AI 编程如何在生产环境中真正提升效率，同时保证质量和稳定性？

二、项目背景：一个后台订单管理模块的改造

本次实战案例来自一个中型 SaaS 系统的后台管理平台。系统主要服务企业客户，核心业务包括订单管理、客户管理、账单结算、权限配置和运营数据分析。

1. 技术栈概况

项目采用前后端分离架构：

• 前端：Vue 3 + TypeScript + Vite + Element Plus
• 后端：Java 17 + Spring Boot + MyBatis Plus
• 数据库：MySQL 8.0
• 缓存：Redis
• 消息队列：RabbitMQ
• 部署方式：Kubernetes + GitLab CI/CD
• 监控体系：Prometheus + Grafana + ELK

2. 改造需求

原有订单管理模块已经运行两年，存在以下问题：

• 查询条件越来越多，代码变得臃肿；
• 订单状态流转逻辑散落在多个 Service 中；
• 导出功能性能较差，大数据量时容易超时；
• 缺少完整的单元测试和集成测试；
• 新增字段时前后端改动点多，容易遗漏；
• 运营人员希望支持更灵活的筛选和批量操作。

本次迭代目标包括：

1. 重构订单查询接口；
2. 抽象订单状态机；
3. 优化订单导出能力；
4. 补全关键路径测试；
5. 增加批量审核与批量标记功能；
6. 保证兼容已有接口，不影响线上客户使用。

三、AI 编程的使用方式：不是“替代开发”，而是“增强开发”

在本次项目中，我们没有让 AI 直接接管整个开发流程，而是将 AI 放在几个明确的环节中使用。

1. 需求拆解

我们首先把产品需求文档输入给 AI，让它协助提炼功能点、边界条件和潜在风险。

例如，我们给 AI 的提示词大致如下：

你是一名资深后端架构师。请根据以下订单管理需求，拆解出后端接口、数据库字段、状态流转规则、异常场景和测试用例清单。要求考虑生产环境中的兼容性、权限控制和性能风险。

AI 输出的内容包括：

• 接口清单；
• 参数校验规则；
• 状态流转表；
• 可能的异常场景；
• 权限控制点；
• 数据库索引建议；
• 测试用例列表。

这些结果并不是直接采用，而是作为团队评审的基础材料。相比人工从零开始整理，AI 帮我们节省了不少前期分析时间。

2. 生成代码骨架

对于标准化较强的 CRUD 代码，AI 的效率非常明显。

比如订单查询功能，需要涉及：

• QueryDTO；
• ResponseVO；
• Controller；
• Service；
• Mapper；
• XML 动态 SQL；
• 前端查询表单；
• 表格字段渲染；
• 分页逻辑。

这类代码结构固定、重复性高，非常适合交给 AI 生成第一版。

但我们也制定了原则：

AI 生成代码只能作为草稿，不能直接合并到主分支。

开发人员必须检查以下内容：

• 是否符合团队代码规范；
• 是否存在 SQL 注入风险；
• 是否存在 N+1 查询；
• 是否正确处理空值；
• 是否有权限校验；
• 是否影响已有接口兼容性；
• 是否有足够的日志与异常处理。

3. 辅助重构

订单状态流转原本分散在多个方法中，例如：

• 创建订单后变为 WAIT_PAY；
• 支付成功后变为 PAID；
• 审核通过后变为 APPROVED；
• 发货后变为 SHIPPED；
• 完成后变为 FINISHED；
• 用户取消或系统关闭后变为 CANCELLED。

旧代码中经常出现这样的判断：

if (order.getStatus().equals(OrderStatus.WAIT_PAY)) {
    // do something
}

随着状态越来越多，判断逻辑逐渐失控。

我们让 AI 根据现有代码整理状态流转关系，并建议使用状态机模式。AI 给出的方案包括：

• 定义状态枚举；
• 定义事件枚举；
• 定义状态转移表；
• 在统一入口执行状态变更；
• 所有状态变更记录操作日志；
• 禁止业务代码直接修改订单状态。

最终我们没有完全照搬 AI 的实现，而是结合团队已有架构，设计了一个轻量级状态机组件。

示例结构如下：

public enum OrderStatus {
    WAIT_PAY,
    PAID,
    APPROVED,
    SHIPPED,
    FINISHED,
    CANCELLED
}

public enum OrderEvent {
    PAY_SUCCESS,
    AUDIT_PASS,
    SHIP,
    CONFIRM_RECEIVE,
    CANCEL
}

public class OrderStateMachine {

    private static final Map> TRANSITIONS = new HashMap<>();

    static {
        addTransition(OrderStatus.WAIT_PAY, OrderEvent.PAY_SUCCESS, OrderStatus.PAID);
        addTransition(OrderStatus.PAID, OrderEvent.AUDIT_PASS, OrderStatus.APPROVED);
        addTransition(OrderStatus.APPROVED, OrderEvent.SHIP, OrderStatus.SHIPPED);
        addTransition(OrderStatus.SHIPPED, OrderEvent.CONFIRM_RECEIVE, OrderStatus.FINISHED);
        addTransition(OrderStatus.WAIT_PAY, OrderEvent.CANCEL, OrderStatus.CANCELLED);
        addTransition(OrderStatus.PAID, OrderEvent.CANCEL, OrderStatus.CANCELLED);
    }

    public static OrderStatus next(OrderStatus currentStatus, OrderEvent event) {
        Map eventMap = TRANSITIONS.get(currentStatus);
        if (eventMap == null || !eventMap.containsKey(event)) {
            throw new BusinessException("非法订单状态流转");
        }
        return eventMap.get(event);
    }

    private static void addTransition(OrderStatus from, OrderEvent event, OrderStatus to) {
        TRANSITIONS
            .computeIfAbsent(from, k -> new HashMap<>())
            .put(event, to);
    }
}

这个实现不复杂，但价值很明显：状态规则集中管理，后续新增状态时只需要修改一个地方，并且可以围绕状态机写完整测试。

四、生产环境实测：AI 编程带来的效率变化

为了尽量客观评估效果，我们记录了本次迭代中部分开发任务的实际耗时，并与过往类似任务进行对比。

1. 需求分析阶段

过去，开发人员通常需要半天到一天时间整理接口、字段、状态规则和测试点。本次借助 AI 初步拆解后，团队评审时只需要针对关键问题讨论。

实际效果：

• 需求拆解时间减少约 40%；
• 边界场景覆盖更完整；
• 产品、测试、开发之间的沟通效率提升。

尤其是测试用例列表，AI 给出的初稿覆盖了不少容易被忽略的场景，例如：

• 批量审核时部分订单状态不允许审核；
• 导出任务重复提交；
• 查询时间范围为空或反向；
• 运营人员无权限操作部分租户数据；
• 订单状态变更与支付回调并发发生；
• 导出数据量超过限制时的降级处理。

这些点为后续测试设计提供了很好的基础。

2. 编码阶段

CRUD、DTO、VO、Mapper、前端表单这类重复代码，AI 能明显提升速度。

以订单高级查询功能为例，涉及 16 个查询条件，包括：

• 订单号；
• 客户名称；
• 手机号；
• 订单状态；
• 支付状态；
• 支付方式；
• 创建时间；
• 支付时间；
• 订单金额范围；
• 所属租户；
• 销售人员；
• 渠道来源；
• 发票状态；
• 退款状态；
• 标签；
• 备注关键字。

如果完全手写，需要不断在前端表单、后端 DTO、Mapper SQL 之间来回切换，非常容易遗漏字段。

使用 AI 后，我们先让它根据字段表生成前后端代码骨架，再由开发人员调整命名、类型、权限和查询逻辑。

实际效果：

• 基础代码生成效率提升约 50%；
• 字段遗漏明显减少；
• 代码风格仍需人工统一；
• 复杂业务判断仍必须由开发人员实现。

3. 测试阶段

AI 在测试补全方面表现非常突出。

我们让 AI 根据状态机代码生成 JUnit 测试用例，包括：

• 合法状态流转；
• 非法状态流转；
• 空参数；
• 边界状态；
• 扩展状态后的回归检查。

生成后的测试代码经过人工调整后，成功覆盖了核心状态变更逻辑。

示例测试思路如下：

@Test
void shouldTransferFromWaitPayToPaidWhenPaySuccess() {
    OrderStatus next = OrderStateMachine.next(
        OrderStatus.WAIT_PAY,
        OrderEvent.PAY_SUCCESS
    );
    assertEquals(OrderStatus.PAID, next);
}

@Test
void shouldThrowExceptionWhenInvalidTransition() {
    assertThrows(BusinessException.class, () -> {
        OrderStateMachine.next(
            OrderStatus.WAIT_PAY,
            OrderEvent.SHIP
        );
    });
}

最终订单状态机模块的单元测试覆盖率达到 90% 以上。更重要的是，后续修改状态规则时，只要测试失败，就能立即发现影响范围。

4. 性能优化阶段

订单导出是本次改造中的重点问题。旧版本导出逻辑是同步查询数据库，然后一次性生成 Excel 文件。数据量较小时没有问题，但当导出超过 5 万条记录时，就容易出现接口超时、内存上涨、数据库压力增大等问题。

我们让 AI 分析旧方案的风险，并提出优化建议。AI 给出的方向包括：

• 改为异步导出任务；
• 分页查询数据；
• 使用流式写 Excel；
• 限制单次导出最大数据量；
• 导出结果上传对象存储；
• 前端轮询任务状态；
• 对高频导出用户做限流；
• 导出字段按权限过滤；
• 增加导出任务日志。

最终我们采用了异步导出方案：

1. 用户提交导出请求；
2. 后端创建导出任务；
3. 任务进入队列；
4. Worker 分页查询订单数据；
5. 使用流式方式写入 Excel；
6. 文件上传对象存储；
7. 更新任务状态；
8. 用户在前端下载文件。

上线后实测结果如下：

这里需要强调，AI 并不是直接解决性能问题，而是帮助团队快速列出可选方案和风险点。最终方案仍然需要开发人员结合业务规模、基础设施和成本进行判断。

五、生产环境中的问题：AI 代码并不天然可靠

虽然本次实践整体效果不错，但过程中也遇到了一些典型问题。

1. AI 生成的 SQL 存在性能隐患

在高级查询功能中，AI 曾生成过类似这样的 SQL：

WHERE customer_name LIKE CONCAT('%', #{customerName}, '%')

这个写法本身没有语法问题，但在大表中如果没有合理索引或搜索方案，会导致查询变慢。

另外，对于多个可选条件组合查询，AI 初版 SQL 没有充分考虑索引命中顺序，也没有区分高频条件和低频条件。

最终我们做了这些调整：

• 对订单号、租户 ID、创建时间建立组合索引；
• 对客户名称模糊查询增加长度限制；
• 对部分模糊搜索改为走搜索服务；
• 查询默认限制时间范围；
• 大范围查询必须异步导出；
• 慢查询纳入监控。

2. AI 容易忽略权限边界

AI 生成的接口代码经常关注参数和返回值，却容易遗漏权限控制。例如批量审核订单时，必须校验当前用户是否有对应租户、组织或角色权限。

如果直接使用 AI 代码，很可能出现越权操作风险。

因此我们规定：所有 AI 生成接口必须经过权限清单检查，包括：

• 用户是否登录；
• 用户是否拥有菜单权限；
• 用户是否拥有操作权限；
• 用户是否能访问对应租户数据；
• 批量操作中每条数据是否都在权限范围内；
• 敏感字段是否需要脱敏。

3. AI 对历史业务理解有限

生产系统中的很多逻辑并不写在文档里，而是隐藏在历史代码、线上数据和运营习惯中。

例如某些订单状态虽然从业务上看已经废弃，但历史数据中仍然存在。如果 AI 根据当前文档生成枚举和状态流转，可能会遗漏这些历史状态，导致查询或导出异常。

所以，在使用 AI 重构旧模块时，必须结合：

• 数据库真实数据分布；
• 历史接口兼容要求；
• 线上日志；
• 客服和运营反馈；
• 老代码中的特殊判断。

AI 可以帮助理解和整理，但不能替代对业务上下文的掌握。

六、我们的 AI 编程工作流

经过这次实践，我们沉淀出一套相对稳定的 AI 编程工作流。

第一步：让 AI 做“分析助理”

在编码前，先让 AI 帮助拆解需求，而不是马上写代码。

输入内容包括：

• 产品需求；
• 当前系统架构；
• 数据库表结构；
• 相关接口文档；
• 已知约束；
• 非功能要求。

输出内容包括：

• 功能拆解；
• 接口设计；
• 数据模型；
• 风险列表；
• 测试用例；
• 性能关注点。

第二步：让 AI 写“代码草稿”

对于重复度高、规范明确的代码，可以让 AI 生成初版。

适合 AI 生成的内容包括：

• DTO / VO；
• Controller 基础结构；
• Mapper 动态 SQL；
• 前端表单；
• 表格列配置；
• 单元测试；
• 文档说明；
• 数据转换函数。

不建议完全交给 AI 的内容包括：

• 核心交易逻辑；
• 权限体系；
• 资金相关代码；
• 并发控制；
• 安全策略；
• 复杂性能优化；
• 跨系统一致性处理。

第三步：人工审查与重构

AI 生成代码必须经过人工审查，重点检查：

• 业务逻辑是否正确；
• 是否符合架构规范；
• 是否有安全问题；
• 是否有性能问题；
• 是否可测试；
• 是否可观测；
• 是否可回滚；
• 是否影响历史兼容。

第四步：用 AI 补测试

代码完成后，再让 AI 根据实现逻辑生成测试用例，而不是只根据需求生成测试。

这样可以覆盖：

• 正常路径；
• 异常路径；
• 边界条件；
• 参数校验；
• 权限场景；
• 并发场景；
• 历史兼容场景。

第五步：上线后用数据验证

生产环境中，不能只看代码是否合并成功，还要关注上线后的真实指标：

• 接口响应时间；
• 错误率；
• 慢 SQL；
• CPU 和内存；
• 队列堆积；
• 用户反馈；
• 日志异常；
• 业务数据是否符合预期。

AI 编程的价值，最终要通过生产环境数据来验证。

七、实测结论：AI 编程真正适合哪些场景？

通过本次生产环境实践，我们认为 AI 编程非常适合以下场景。

1. 标准化代码生成

例如增删改查、字段映射、接口文档、表单页面、测试样例等。这类任务规则明确，AI 可以快速完成初稿。

2. 需求和代码理解

面对陌生模块时，AI 可以帮助快速总结代码结构、调用链路和业务含义。但前提是输入足够准确，并且输出必须验证。

3. 测试用例补全

AI 对测试场景枚举很有帮助，尤其适合补充异常路径和边界条件。

4. 重构方案讨论

AI 可以提供多种设计思路，例如策略模式、状态机、责任链、异步任务、缓存优化等。开发者可以把 AI 当作“方案评审助手”。

5. 文档生成

接口说明、变更记录、上线说明、使用手册、故障排查文档等，AI 都能明显提升效率。

但 AI 不适合被无脑用于以下场景：

• 未经审查直接生成核心业务代码；
• 缺少上下文时设计数据库；
• 直接处理安全敏感逻辑；
• 直接编写资金结算规则；
• 替代架构评审；
• 替代线上监控和灰度验证。

八、团队协作中的经验总结

AI 编程不是单个开发者的效率工具，它会影响整个团队的研发流程。因此，团队需要制定一些基本规则。

1. 建立 AI 使用规范

例如：

• 哪些代码可以让 AI 生成；
• 哪些代码必须人工编写；
• AI 生成代码是否需要标记；
• 提交 MR 时是否说明 AI 使用范围；
• 安全和权限代码如何检查；
• 测试覆盖率要求是多少。

2. 建立 Prompt 模板

统一的 Prompt 可以提升输出质量。例如：

你是一名资深 Java 后端工程师。请基于以下需求生成 Spring Boot 代码。
要求：
1. 使用分层架构；
2. Controller 不写业务逻辑；
3. Service 需要参数校验和异常处理；
4. Mapper SQL 必须考虑索引；
5. 返回结果使用统一响应结构；
6. 需要补充单元测试；
7. 需要指出潜在风险。

比起简单地说“帮我写一个接口”，这种结构化输入更容易得到可用结果。

3. Code Review 更重要了

AI 降低了写代码的成本，也可能增加低质量代码进入项目的风险。因此 Code Review 不能弱化，反而要加强。

重点关注：

• AI 是否编造不存在的类或方法；
• 是否引入重复逻辑；
• 是否破坏原有架构；
• 是否遗漏异常处理；
• 是否存在安全风险；
• 是否造成性能退化。

4. 让 AI 参与 Review，但不替代人

我们也尝试让 AI 做预审，例如检查命名、重复代码、空指针风险、SQL 性能风险、测试缺口等。效果不错，但最终合并仍然必须由人负责。

九、最终收益与不足

1. 收益

本次订单管理模块改造上线后，整体效果如下：

• 开发周期缩短约 25%；
• 重复代码编写时间明显减少；
• 测试用例数量增加；
• 状态流转逻辑更加清晰；
• 导出性能明显提升；
• 需求评审和测试设计效率提升；
• 文档补全速度更快。

2. 不足

同时我们也看到一些问题：

• AI 输出质量高度依赖上下文；
• 对历史业务理解不足；
• 生成代码有时过度设计；
• 安全和权限逻辑需要重点审查；
• 对复杂 SQL 和性能优化不能完全信任；
• 团队需要花时间建立使用规范。

十、结语：AI 编程的核心价值是放大工程能力

经过生产环境实测，我们的结论是：

AI 编程不是替代程序员，而是放大优秀工程师的能力。

对于经验不足的开发者，AI 可以帮助快速入门，但也可能让人忽略底层原理和工程规范。对于经验丰富的开发者，AI 更像一个高效助手，可以承担重复劳动、提供思路、补充测试、生成文档，让开发者把精力集中在架构设计、业务抽象、质量保障和生产稳定性上。

真正有效的 AI 编程，不是简单地复制粘贴 AI 生成的代码，而是建立一套完整流程：

1. 用 AI 辅助分析；
2. 用 AI 生成草稿；
3. 用人工审查关键逻辑；
4. 用测试验证结果；
5. 用监控观察生产表现；
6. 用团队规范沉淀经验。

当 AI 编程进入生产环境，拼的不是谁更会“提问”，而是谁更懂软件工程。

未来，AI 一定会越来越多地参与研发流程。但无论工具如何演进，生产环境中的稳定性、安全性、可维护性和业务正确性，仍然需要工程团队负责。

AI 可以让代码写得更快，但只有工程能力，才能让系统跑得更稳。