PR 多了 98%，评审时间也多了 91%：AI 编程的瓶颈，已经不在写代码

一个做研发效能的朋友最近吐槽：团队上了 AI 编程工具之后，PR 数量肉眼可见地涨，评审队列也跟着涨，版本发布却没快多少。“写得是快了，可卡在评审和联调上。”这不是个别现象。Faros AI 分析了超过 1 万名开发者、1255 个软件工程团队的工作流数据，结论很直接：AI 采用率与企业关键交付指标之间，没有显著相关性；PR 合并数量增加了 98%，代码审查时间却增加了 91%。

一分钟速览

• Faros AI 分析 1 万多名开发者、1255 个团队：AI 采用率与交付效能无显著相关性。
• PR 合并数量增加 98%，代码审查时间增加 91%，瓶颈从“写”转移到“审”。
• 网易智企发布 CodeWave SDD“AI 软件交付团队”，用多 Agent 覆盖需求、设计、开发、测试、部署。
• 官方称经 100 多家企业验证，产能提升约 3 至 5 倍。
• 产品约 70% 研发投入用于企业级 Harness 运行环境，30% 用于多 Agent 协作。

提效 30%，为什么项目没有提前 30% 完成

软件交付不是一条流水线，而是一张网。需求分析、产品设计、架构规划、测试验证、部署发布、后续维护，每一环都可能成为瓶颈。即使编码环节快了三成，只要评审、测试、集成没跟上，整体交付时间几乎不变。

Faros AI 的数据把这件事量化了：代码生成加速之后，PR 数量暴涨，评审工作量跟着暴涨。原来一个评审者一天看五个 PR，现在要看十个，质量风险反而上升。AI 解决的是“写”的产能，却把压力转移到了“判断”的环节。

网易智企副总经理、CodeWave 业务负责人王桐的说法更直白：“我们现在跟企业聊，就不聊开发提效了，直接聊扩产能。”这句话背后是一个判断：单点提效的天花板已经到了，接下来要动的是组织方式。

让 Agent 去用 AI Coding 工具

10 月 26 日发布的 CodeWave SDD，核心思路是“下一代的用法，不是人用 AI Coding 工具，而是让 Agent 员工去用 AI Coding 工具”。具体做法是把交付流程拆成角色：需求分析师 Agent 读需求文档，识别文本、表格、流程图、原型图；遇到不明确的地方主动向人提问；澄清后用 EARS 等结构化方法生成规格文档；设计师 Agent 出原型，架构师 Agent 拆任务，前后端开发 Agent 写代码，测试 Agent 依据规格生成用例并执行验证。

这套流程叫规格驱动开发（Spec-Driven Development）。它要解决的是一个老问题：需求文档往往不完整甚至自相矛盾，人类工程师可以靠会议和经验补齐，AI 直接照着模糊需求写代码，只会把偏差放大。先把规格钉死，再让模型执行，是这家公司的答案。

王桐反复强调一句话：“严肃的任务，我们是不希望模型做发挥的。”金融、政企系统的权限控制、数据结构、操作逻辑必须符合明确要求，任何未经确认的功能增减都可能引入业务风险。所以系统会把大需求拆成大量细颗粒度任务，分批执行，并持续检查规格一致性。

70% 的功夫花在“环境”上

多 Agent 协作听起来很酷，真正难的是让它们稳定跑几十个小时。网易为这套产品投入接近 100 人的研发团队，打磨了大半年，其中约 70% 的资源和时间用于构建企业级 Harness 环境，30% 用于多 Agent 协作本身。

Harness 干的是脏活累活：检查 Agent 是否正常工作、任务是否超时、Agent 之间的通信是否中断、每个阶段的交付物是否符合规格。任何一项不通过，任务就被拦住，进入修复流程。这和运行在个人电脑上的编程助手是两种东西——后者崩了重开就行，前者崩了，可能意味着一个企业项目停摆。

存量系统改造也有专门设计。面对老系统，平台先读历史代码，用 AST 语法树和 LSP 语义服务建立代码地图，梳理程序结构与依赖关系，再按新需求迭代。这个能力针对的是企业开发的常态：大多数任务不是从零建新系统，而是在文档不全的老系统上动刀。

数据支撑

• 98% / 91%：PR 合并数量与代码审查时间的增幅（Faros AI）。
• 1 万+ / 1255：分析覆盖的开发者与团队数量。
• 3 至 5 倍：官方披露的产能提升区间。
• 100+ / 80%：参与验证的企业数量，其中约八成是软件开发服务商。
• 90% / 80%：P0 级与 P1、P2 级测试用例的一次通过率。
• 200 多份：某省级担保公司案例中，需求分析与架构设计 Agent 生成的规范文档数量。

案例与边界

网易智企选了一个省级担保公司的核心业务系统做对比：需求文档超过 100 页，涉及业务台账、数据分析、复杂检索等模块。在相同需求与模型条件下，CodeWave SDD 基本还原了功能模块，而参与对比的一款 IDE 类工具遗漏了部分子菜单、检索能力与页面交互。

但单个项目的展示，不足以证明工具在所有任务上的差异。项目复杂度、提示方式、任务拆解机制、验证标准，都会影响结果。更值得关注的是后续维护：AI 生成的代码由谁负责？出问题谁修？平台的做法是保留需求文档、架构设计、源代码、测试用例与报告等交付资产，让后续接手的人有据可查。

组织结构会被怎么改

王桐提出的思路是：原来一名产品经理配十名开发人员，未来可能变成五名产品人员配五名开发人员，Agent 承担更多执行工作。这个比例不一定适用于所有项目，但方向很清楚——需求理解、方案评审、质量验收的重要性上升，纯执行岗位被压缩。

他还提到 FDE（前沿部署工程师）的价值：核心不只是会用 Agent 工具，而是能理解客户业务，把模糊诉求翻译成明确需求，并对交付结果负责。AI 越深入，人的判断越值钱，这句话在软件行业正在变成现实。

趋势洞察

第一，AI Coding 的竞争从“补全速度”转向“交付闭环”。谁能把需求、规格、开发、测试、部署串起来，谁就能吃到企业预算，而不是只卖订阅席位。

第二，工程规范重新变得重要。模型不怕写不出代码，怕的是写出“看起来对、实际不符合业务规则”的代码。规格驱动、形式化约束、过程校验，这些“老派”做法正在回归。

第三，组织调整会慢于工具落地。工具可以一个季度上线，岗位分工、考核方式、责任边界却要以年为单位磨合。真正的瓶颈，可能不是模型能力，而是谁来为 AI 写的代码签字。

结语

“AI 让开发更快”这句话只说对了一半。它确实让代码产出变快，但也让评审、测试、集成变得更拥挤。CodeWave SDD 这类产品的价值，不在于证明 Agent 能写代码，而在于尝试回答一个更硬的问题：当代码不再稀缺，软件交付的瓶颈该由谁来拆。

参考链接：InfoQ 报道