最近不少开发团队都有一种很矛盾的感受：

代码确实写得越来越快，项目却不一定交付得更快。

以前需要一两天完成的Controller、Service、数据库表和管理后台页面，现在交给AI编程工具，几个小时就能生成一个可运行版本。

接口能调通，页面能打开，基础流程也能跑。

但到了联调和业务试用阶段，问题开始集中出现：

状态流转不完整，权限模型不符合实际管理要求，异常场景没有处理，统计口径与业务理解不一致。随后产品修改需求，开发调整接口，测试重写用例，数据库结构也跟着变化。

有些项目第一版只用了几天，后续修改却持续了几个月。

问题并不是AI写代码不够好。

更准确地说，是AI同时放大了两种原本就存在的问题：

一种发生在代码之前，叫需求债。

另一种发生在代码之后，叫技术债。

一、AI能快速生成代码，但不能替企业做业务决定

假设一家企业要增加订单退款功能。

需求文档里只有一句：

支持订单退款。

将这句话交给AI，它很快就能生成退款按钮、退款接口、退款记录表以及订单状态更新逻辑。

从开发结果看，功能已经做出来了。

但进入真实业务以后，马上会遇到一系列问题：

• 支持全额退款还是部分退款？
• 已发货订单能否直接退款？
• 一个订单中的部分商品能否单独退款？
• 退款需不需要主管审批？
• 退款后库存什么时候恢复？
• 优惠券、积分和赠品如何处理？
• 销售业绩和佣金是否同步回退？
• 退款结果是否需要同步财务系统？
• 重复提交退款请求时如何保证幂等？

这些问题没有几个是纯编码问题。

它们首先是业务规则和管理决策问题。

如果产品经理、业务负责人和管理者自己都没有形成统一口径，AI只能按照常见做法补全空白。

它生成的代码可能没有语法错误，单元测试也可能通过，但实现的只是一个“看起来合理”的退款流程，不一定是这家企业真正需要的流程。

过去，一个理解错误的模块可能需要三天才能完成。

现在，AI三个小时就能把错误理解写进页面、接口、数据库和测试用例里。

AI没有制造需求错误，只是缩短了错误从想法变成完整功能的时间。

二、能运行的代码，不等于能够长期维护的代码

企业软件返工还有另一层原因：AI擅长完成局部任务，却不一定真正理解整个项目。

例如，项目里已经有统一的日期工具类、返回结果结构和权限校验方法。

当开发者只把当前需求交给AI，没有提供足够的代码库上下文时，AI可能会重新生成一套类似实现。

单独看，每一段代码都能运行。

放到一个持续迭代的项目中，却可能出现：

• 一个项目里存在多套Result返回结构；
• 相同校验逻辑散落在多个Service中；
• 日期、金额和状态使用不同的处理方式；
• 新代码绕过了原有权限组件；
• 公共逻辑被不断复制，而不是复用；
• 需求变化后，需要同时修改多个位置。

GitClear曾分析2020年至2024年间约2.11亿行代码变更，观察到复制代码占比上升，而代码移动、重构和复用相关指标下降。

这类数据不能简单证明“所有重复代码都是AI造成的”，但它至少提醒团队：

当代码生成成本越来越低时，开发者会更容易选择“重新生成一段”，而不是先理解和复用已有实现。

短期看，这是效率。

长期看，可能是维护成本。

三、AI最危险的结果，不是完全错误，而是“几乎正确”

完全错误的代码通常比较容易发现。

真正麻烦的是那些能够编译、能够运行、大部分场景也正常，但在某些边界条件下会出错的代码。

Stack Overflow在2025年的开发者调查中发现，开发者使用AI工具时，最常遇到的困扰不是AI完全不会写，而是生成的答案“几乎正确，但并不完全正确”。

这类代码最容易进入项目。

比如一个AI生成的库存扣减逻辑：

if (stock >= quantity) {
    stock = stock - quantity;
}

在单线程、本地测试和小数据量场景下，这段代码没有明显问题。

但进入真实系统以后，还要考虑：

• 两个订单同时扣减库存怎么办？
• 请求重复提交怎么办？
• 数据库更新失败怎么办？
• 支付成功但扣减库存失败怎么办？
• 多仓库之间如何分配库存？
• 订单取消后如何恢复？
• 是否需要保留库存变化日志？

AI完成了代码表面的功能，却未必自动补齐事务、一致性、并发和补偿机制。

这也是企业软件与普通Demo的区别。

Demo只需要证明正常流程可以跑通。

企业软件需要保证异常发生以后，数据仍然可追溯、可恢复、可解释。

四、代码质量问题，往往在项目扩大后才暴露

Sonar曾使用静态分析工具评估多个大模型完成的4400多项Java编程任务。

研究结果一方面肯定了大模型生成语法正确代码、模板代码和常见算法的能力；另一方面也发现，检测出的绝大多数问题属于代码异味，包括冗余代码、结构混乱、资源处理不当和可维护性不足。

这与实际开发中的体验比较接近。

AI很适合快速生成一个函数，却未必天然知道：

• 当前项目的领域边界是什么；
• 哪些逻辑应该放在领域层；
• 哪些能力应该抽象成公共组件；
• 哪些接口未来需要扩展；
• 哪些旧系统必须兼容；
• 哪些数据涉及安全和合规；
• 一个修改会影响哪些已有模块。

于是，AI生成的第一个版本往往很快。

但随着需求增加，原本堆在一个Service里的逻辑越来越多，状态判断不断嵌套，重复方法逐渐扩散，最终修改一个规则需要同时调整多个模块。

团队经常在这个阶段发现：

AI节省了最初写代码的时间，却没有自动节省理解系统、审查代码和维护架构的时间。

五、真正放大返工的，是需求、代码和测试使用了不同答案

企业项目里还有一个常见问题：

每个环节依据的内容并不一致。

业务人员在会议上调整了退款规则。

产品经理修改了需求文档，却没有更新原型。

开发人员按照原型生成代码。

测试人员又在使用最早版本的验收用例。

所有人都在认真工作，但每个人手里都有一份不同的“正确答案”。

使用多个AI工具后，这种问题可能更明显：

一个工具生成需求文档，一个工具生成原型，一个工具生成代码，另一个工具生成测试用例。

每个环节单独看都更快了。

但前面的需求发生变化后，后面的产物不会天然同步。

最终，团队得到了一批生成速度很快的结果，却没有得到同一个结果。

这也是为什么AI编码提速以后，项目依然可能频繁返工。

项目缺少的不是更多代码，而是一套可以持续传递的统一业务上下文。

六、减少返工，不能只在代码生成后增加Review

代码审查当然重要，但如果需求本身错了，Review只能检查代码是否正确实现了一个错误需求。

更合理的方式，是把控制点向前移动。

1. 先生成问题，再生成代码

拿到需求后，不要马上让AI输出完整模块。

可以先让它列出：

• 涉及哪些角色；
• 核心业务对象有哪些；
• 正常流程是什么；
• 有哪些异常和边界情况；
• 数据会发生哪些变化；
• 哪些规则仍未明确；
• 可能影响哪些已有功能。

先检查问题清单，再决定实现方式。

AI最有价值的用法之一，不是立即给答案，而是帮助团队发现自己还没有回答的问题。

2. 把验收标准写到开发前面

“支持部分退款”不是完整的验收标准。

更具体的描述可以是：

一个订单包含三件商品，客服可以选择其中一件申请退款。主管审批通过后，系统退回对应金额，恢复该商品库存，保留其他商品的发货状态，并记录申请人、审批人、退款原因和处理时间。

当验收场景足够具体时，页面字段、状态流转、接口设计和测试用例都会更清楚。

3. 让AI先理解代码库，而不是每次从零生成

使用AI开发旧项目时，应先提供必要的工程上下文：

• 目录结构；
• 已有公共组件；
• 数据模型；
• 编码规范；
• 异常处理方式；
• 权限框架；
• 相似功能的参考代码；
• 不允许修改的模块。

生成前先搜索可复用代码，生成后检查是否重复造轮子。

否则，AI每次都可能给出一套局部正确、整体不一致的“标准答案”。

4. 把大任务拆成可以独立验证的小任务

不要一次要求AI生成完整订单系统。

可以拆成：

1. 梳理订单状态机；
2. 定义退款单数据结构；
3. 实现退款金额校验；
4. 实现库存恢复；
5. 增加幂等控制；
6. 生成异常场景测试；
7. 检查对财务和业绩数据的影响。

任务越小，越容易检查结果，也越容易发现AI理解偏差。

5. 为AI代码设置明确的准入标准

AI生成的代码不应该因为“能跑”就直接进入主分支。

至少要经过：

• 编译和基础测试；
• 单元测试和关键集成测试；
• 静态代码扫描；
• 重复代码检查；
• 安全检查；
• 人工Review；
• 对现有功能影响范围的确认。

尤其是权限、支付、库存、金额、数据删除和历史系统兼容等模块，必须由熟悉业务和架构的人负责最终判断。

七、不要再用代码量衡量AI开发效率

AI进入开发团队以后，代码提交量通常会快速增加。

但生成了更多代码，不代表完成了更多有效工作。

团队更值得关注的指标是：

• AI生成代码最终保留了多少；
• 提交后短时间内被重写的比例；
• Review平均耗时是否增加；
• 重复代码是否持续上升；
• 需求变化后影响了多少模块；
• 测试阶段发现了多少需求类问题；
• 从需求提出到业务验收到底用了多久。

代码行数是产出数量。

真正需要衡量的是有效交付。

一个团队每天生成十万行代码，却需要不断推翻重写，不一定比每天只提交一千行稳定代码更高效。

八、哪些工作适合交给AI？

AI更适合处理明确、重复、容易验证的工作，例如：

• 基础增删改查；
• 简单页面和接口；
• 单元测试初稿；
• 代码注释；
• 格式整理；
• 数据转换脚本；
• 重复性文档。

以下工作则应该由人主导，AI辅助：

• 业务规则判断；
• 核心架构设计；
• 权限和数据安全；
• 支付、库存和金额逻辑；
• 老系统兼容；
• 高并发和高风险模块；
• 最终代码审查和上线验收。

简单来说：

AI负责把明确的事情快速做出来。

人负责明确哪些事情值得做、应该怎么做，以及生成结果是否真的可以进入生产环境。

写在最后

AI写代码越来越快，企业软件项目仍然频繁返工，并不是一个矛盾。

因为代码生成只是软件交付中的一个环节。

在代码之前，还有需求澄清、业务决策和架构设计；在代码之后，还有Review、联调、测试、上线和长期维护。

如果需求不清楚，AI会更快地生成错误功能。

如果缺少项目上下文，AI会更快地制造重复代码。

如果没有审查和验证，AI会更快地把“几乎正确”的代码送进生产环境。

这也是麦芽AI目前重点关注的问题：不只是让代码生成得更快，而是尽量把需求梳理、产品设计、开发实现和测试验收连接起来，让不同环节基于同一套业务上下文推进。

AI时代真正重要的，不是谁生成的代码更多。

而是谁能够让错误更早暴露，让变化准确传递，让生成出来的代码真正可测试、可交付、也可维护。

别让AI帮助团队加速积累需求债和技术债。

应该让它放大的，是已经被确认过的正确方向。

推荐标签： AI编程、软件工程、技术债、需求分析、企业软件、代码质量、Claude Code、Codex