漫谈企业软件工程的“时差”:AI 编程越来越快,交付为什么还没跟上?

点击上方蓝字加入我们

最近和一位做 ToB 软件的朋友聊起 AI。他说，现在代码确实快，但交付提速远没有传说中那么明显，团队似乎还更忙了。那么，AI 编程节省的时间，去了哪里？

我想这里面除了企业软件的客观特点 — 领域知识复杂、非标定制、交付要求高之外，一个更大的可能原因是：

这就像一个工厂，生产线再先进，供应链管理、排产、质检甚至物流跟不上，订单也很难按时交付到客户手里。

本篇就来结合笔者的一些亲身实践，谈谈这个问题。

01局部快了，整体未必跟着快

这是一笔很容易算清的账。

假设一个项目或需求从开始到上线需要 10 天，其中沿关键路径的编码占 3 天，其他工作与等待占 7 天。

现在 AI 把编码速度提高到原来的 5 倍（虽然这也并不容易），编码只用 0.6 天，总周期却仍要 7.6 天，相对原来总周期也只缩短了 24%。

而如果采用 AI 编程后还多出 1.4 天的人工审查和返工，那么周期就是 9 天。

你看到代码快 5 倍，项目周期只缩短了 10%。两件事完全可能同时发生，并不矛盾。

大型的企业应用中，这里的“其他时间“都有具体去处：

从原始需求、方案评审，到联调、回归、业务验收，以及各个环节间的等待 — 来自这类项目中不同模块、层次、甚至不同的代码仓之间的复杂依赖关系。

比如，一个看似简单的“部分退款”需求，可以牵涉到订单、支付、发票等多个子系统。当前模块写完了，别的接口和环境可能还未就绪。

当你可以每天提 10 个PR，但人工审查和验证只能完成 3 个，就会出现积压并拉长交付周期。

更何况，如果 AI 还是在一个十年以上的屎山代码上“雕花”，各种隐性的业务规则、依赖关系，还会增加理解与返工的成本。

一篇近期的研究论文（Artificial Intelligence in the Firm: Bottlenecks in Software Production）调查了约 700 多家企业、约 3 亿条工作事件：在AI 编程的采用样本中，代码产出明显增加，但 PR 从提交到合并的平均时长也增加约 49%：

我们从一些关键环节来做深入探讨。

02需求分析：让 AI 减少猜测和误解

业务需求是一切的起点。这里面的最大缺口是：

原来的需求是给人看的，现在的需求则更多要给 AI 看。

以“订单需要支持部分退款”这个需求为例，人类可以边做边沟通。

但如果直接丢给 AI 开发，AI 会按照自己的理解脑补一套：优惠怎么分摊？已开的发票怎么办？重复请求如何处理？

AI 可能会编造业务规则，也可能会过度设计，这取决于模型。但这些问题却可能会直到联调、测试验收、甚至上线后才暴露。

因此 AI 参与后，更需要把过去依赖口头沟通和个人经验的分析写出来。如果你用了 SDD（规格驱动开发），Spec 也需要经过确认的业务事实做基础。

这应该是一个更标准化的动作与方法：

最终能够从几个方面，把需求整理成可执行、可验证的开发输入。

以上面的“订单部分退款”需求为例：

真实应用中，分析人员可以借助 AI 工具/Skill 辅助追问、找矛盾、补场景，再用需求模板与检查清单核对。关键规则没确定，就先缩小范围或继续澄清；确认后再同步更新Spec 与验收条件。最后：

03上下文工程：把知识和经验传授给 AI

AI 很能干，但也没你想象的那么能干。

对于通用的标准型小工具，直接 Vibe Coding 让 AI 边理解边做就行；

当面对一个几万行代码的小型应用时，借助开源工具，管理如 AGENTS.md，CONTEXT.md 文件作为上下文，或许也够用；

但当你的代码库有几百万甚至千万行代码、背着多年的技术债、文档不全、命名随意、工程师离职... AI 就没那么能干 — 可怕的是它会装作很能干。

这时候，简单的一份项目“说明书”就无法承载。完善的知识工程，就必不可少。

这需要贯穿知识的三个阶段：知识的组织、使用、和持续治理。

知识的组织

大型企业应用需要的知识散落在不同的地方：各类原始需求和设计文档、代码与配置、还有工程师的脑袋里。

汇集这些原始出处，再让 AI 辅助整理，并由熟悉业务的人审核确认。

大量的知识通常无法用单一文档来承载。一个思路是参考 LLM-Wiki 的方法：让 AI 帮你生成不同主题、相互链接、分层索引的知识页：

代码知识是另一个重要的上下文，借助如 GitNexus、CodeGraph 这样的 AST 分析工具生成代码图谱（无须 token），与文档知识结合，构成一个更立体的知识空间。

知识的使用

当然，你不能每次把所有知识一股脑塞给 AI。

一是装不下，二是太多知识可能会让重要约束被“淹没”。

在笔者参与的一个项目中，我们把分层加载与定向检索结合起来：

先让 AI 读取项目概览和必要约束，再沿索引进入相关业务、技术页面；遇到具体 API 或表结构问题，再定向查找，同时用代码图谱辅助影响分析。

这样既避免把所有知识都塞进上下文，也减少传统 RAG 或图谱方案只检索到零散片段、遗漏上下文的问题。

新知识回流

每一次需求的开发过程，都可能产生新的业务与技术知识。因此你需要在某些时机（如需求澄清、缺陷修复、代码提交），借助 AI 进行新知识的回流与更新。

但知识的回流必须是严谨的，否则会产生大量的“垃圾”上下文。

AI 可以起草更新，但要经过确认再回写；重要的知识要有来源、适用说明、维护责任等；团队作业时，要像代码一样管理知识的版本和合并；要及时检查是否导致冲突、冗余，索引是否更新等。

04验证与测试：如何为 AI 做分层的质量把关

相信很多朋友已经好久没有认真审查过代码了。

在企业应用中，这其实蕴含了很大的风险 — 因为 AI 永远都有犯错的概率。

AI 代码写得越快，越需要完备的验证手段，把犯错的可能性降到最低。否则，编码节约的时间，容易变成后面的返工甚至生产事故。

但另一方面，大型的分布式应用受到错综复杂的安全、依赖、资源、数据等因素的制约，很难像本机小应用那样，靠几轮生成和 AI 自测就完成验证。

AI 自动审查

大白话说，就是让 AI 自己查自己，就像考试时的答卷复查。

具体而言，AI 每完成一轮实现，都可以触发一次静态的审查；特别对于较弱的模型，这也是一种提高代码完成度的简单方法。

在检查维度上，可以有两个层面：

• * Spec 符合性：也就是看功能、边界和异常场景有没有遗漏。比如 10 个功能点是不是只完成了 8 个；是不是只做了后端忘了前端，等等。
• * 工程质量：基于定义的 Checklist 做核查。比如有没有编造接口、有没有绕过权限检查、异常处理、兼容性是否符合规定等。

前者侧重“有没有完成任务”，后者则是“任务完成的质量如何”。

在模型层面，一种方法是写代码的模型自检；但更推荐的是交给另一个不同模型的 独立审查 Agent — 给它规则、代码和必要的上下文。

此外，能够做确定性检查的规则，尽量交给 Lint、脚本、工具来完成；而需要结合上下文理解的部分，再交给模型完成。

注意在这里不执行测试用例，检查通过不代表业务功能正确。

分层的测试反馈闭环

这是最关键、也是最复杂的部分。

大型企业应用测试有一些不同于传统软件的特点：

• * 业务代码很多以转给 DAO 的数据操作为主，基于 Mock 的单元测试价值低
• * 测试的预期结果应以需求阶段确认的规则和验收条件为主
• * 对环境与资源要求较高，本机很难具备完整的端到端测试条件
• * 依赖关系复杂，很容易牵一发而动全身

因此我们根据反馈周期和依赖范围，把测试组织成四层：

在大型系统中，测试环境与测试数据是另一个“大麻烦”。

可以把环境与测试数据当作工程资产：可重复初始化的数据、可复用的部署脚本、组装好的测试容器、外部系统的模拟 Server 等。

在以上介绍的测试层次中，除了开发内循环，其余的需要结合 Git/CI/CD 环境来实现触发：准备环境、运行测试、搜集结果与证据，并交回开发。

05CI/CD：构建 AI 编程的测试反馈闭环

现有的CI/CD流水线，已经会构建、测试、部署，也会报告失败。

但我们可以做进一步增强：利用 Agent 来辅助复现、诊断与补测，并把结果交回 Coding Agent，真正形成“提交-验证-反馈-修复-再验证”的大闭环。

最终形成大致的分工：

Git 平台及工作流负责编排和门禁；CI Runner 执行作业；Test Agent 辅助测试分析；Coding Agent 修复代码。

形成的方案如下（多个 Runner 可以运行在不同的环境中）：

1. AI 完成编程任务与单元/组件测试后，经过必要的审查后提交 PR/MR
2. Git 平台经过基本的质量门禁后触发 CI 工作流，派发 Job 给 CI Runner
3. Runner A 完成验证测试（静态检查、编译构建、基本测试），通过后生成制品
4. Runner B 通过制品库获得构建包或镜像，在集成测试环境部署并做集成验证
5. 在验证过程中，可以借助 Agent（需具备模型条件）辅助复现、补测，分析问题是代码缺陷还是环境问题、搜集必要的反馈数据与日志
6. 测试中如果发现问题，需要将失败的用例、测试报告、制品 ID、环境与日志等信息，关联到任务和PR；然后将这些证据回传 Git 平台
7. Coding Agent 可通过Git API、CLI 或 MCP 读取这些证据，在对应版本上定位问题、尝试修复，审核后提交新版本接受复验

整个过程需要项目团队对其中的触发、关联和回传关系等做显式配置，特别是整个过程中的工程对象与证据的关联。常见的细节包括：

• 跨仓库、多项目的一次集成验证要记录版本的组合
• 测试反馈到 Coding Agent，如何把测试结果和代码版本对应
• 验证失败不必然是代码问题，也可能是环境故障，需要区分，必要时人工介入
• 最大允许的 CI 集成测试失败并回退到开发的次数是多少（一般不超过3次）
• 测试数据准备与复位：测试后如何清理与恢复，保证可重复验证

最后是 CD 环节。代码快了，变更多了，当然部署与发布也要跟上。如果仍需要太多时间核对环境和依赖，再集中上线，也会降低整体交付速度。

因此，也需要在部署环境的准备与核对、小批量快速发布、以及发布后异常的反向追溯等环节做增强，以实现全流程的提速。

06总结：让每一环都接住 AI 编程的提速

回头来总结如何从端到端工程的维度接住 AI 编程的速度 — 绝不仅仅是开发阶段，我们还需要做的更多：

最后，是在整个环节中不能遗漏的重要一环 ：人始终要在这条链路中发挥关键作用。

• 确认需求、上下文知识、Spec 与设计，明确边界并完成审查。
• 按需复核编程实现中及合并前的关键变更。
• 出现疑点时，要能随时接手。如测试结果与预期矛盾、修复超过重试上限等，都需要人类介入判断，并在确认后更新任务、规则与相关脚本等。
• 端到端的业务验收很大程度上仍然需要人类来补足判断；发布阶段的风险审查与授权也需要人类完成。