最近不少开发团队都有一种很矛盾的感受代码确实写得越来越快项目却不一定交付得更快。以前需要一两天完成的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生成完整订单系统。可以拆成梳理订单状态机定义退款单数据结构实现退款金额校验实现库存恢复增加幂等控制生成异常场景测试检查对财务和业绩数据的影响。任务越小越容易检查结果也越容易发现AI理解偏差。5. 为AI代码设置明确的准入标准AI生成的代码不应该因为“能跑”就直接进入主分支。至少要经过编译和基础测试单元测试和关键集成测试静态代码扫描重复代码检查安全检查人工Review对现有功能影响范围的确认。尤其是权限、支付、库存、金额、数据删除和历史系统兼容等模块必须由熟悉业务和架构的人负责最终判断。七、不要再用代码量衡量AI开发效率AI进入开发团队以后代码提交量通常会快速增加。但生成了更多代码不代表完成了更多有效工作。团队更值得关注的指标是AI生成代码最终保留了多少提交后短时间内被重写的比例Review平均耗时是否增加重复代码是否持续上升需求变化后影响了多少模块测试阶段发现了多少需求类问题从需求提出到业务验收到底用了多久。代码行数是产出数量。真正需要衡量的是有效交付。一个团队每天生成十万行代码却需要不断推翻重写不一定比每天只提交一千行稳定代码更高效。八、哪些工作适合交给AIAI更适合处理明确、重复、容易验证的工作例如基础增删改查简单页面和接口单元测试初稿代码注释格式整理数据转换脚本重复性文档。以下工作则应该由人主导AI辅助业务规则判断核心架构设计权限和数据安全支付、库存和金额逻辑老系统兼容高并发和高风险模块最终代码审查和上线验收。简单来说AI负责把明确的事情快速做出来。人负责明确哪些事情值得做、应该怎么做以及生成结果是否真的可以进入生产环境。写在最后AI写代码越来越快企业软件项目仍然频繁返工并不是一个矛盾。因为代码生成只是软件交付中的一个环节。在代码之前还有需求澄清、业务决策和架构设计在代码之后还有Review、联调、测试、上线和长期维护。如果需求不清楚AI会更快地生成错误功能。如果缺少项目上下文AI会更快地制造重复代码。如果没有审查和验证AI会更快地把“几乎正确”的代码送进生产环境。这也是麦芽AI目前重点关注的问题不只是让代码生成得更快而是尽量把需求梳理、产品设计、开发实现和测试验收连接起来让不同环节基于同一套业务上下文推进。AI时代真正重要的不是谁生成的代码更多。而是谁能够让错误更早暴露让变化准确传递让生成出来的代码真正可测试、可交付、也可维护。别让AI帮助团队加速积累需求债和技术债。应该让它放大的是已经被确认过的正确方向。推荐标签AI编程、软件工程、技术债、需求分析、企业软件、代码质量、Claude Code、Codex