AI 写了 30% 的代码，交付一点没变快：一张需求时间表说清瓶颈

AI 写了 30% 的代码，交付一点没变快：一张需求时间表说清瓶颈

上周写过 《复杂 Harness 不如多想？Surge +「Harness 买 token」对照》，说的是：固定模型时，换脚手架往往买到的是账单，多想和换模型才更像质量杠杆。再往前，《Agent 写基础设施的 4 道验收：OpenAI 用 Codex 10 周重写 Git 后端》 强调验收要卡在真实边界上，而不是「又生成了一批看起来能跑的 diff」。《先看见再省：Thinker 裁上下文 + CodeBurn 拆账单》 则提醒：先把结构和账单看见，再决定拧哪根旋钮。

这一篇换一个更「全流程」的切口。2026 年 11 月 8 日，InfoQ 刊出对阿里云智能集团副总裁、CIO 蒋林泉的专访。据他自述：从 2024 年底，团队已经全员用上 AI 编码工具，生码率很快上到 30% 多；但端到端交付一个需求所消耗的人力，没有变化。后来与业界很多产研团队交流，大家看到同一件事——生码率和代码量持续增长，真实业务项目的端到端耗时几乎没有缩短。

先把结论放在前面：编码只占全流程大约 20%；而这 20% 里，改存量核心系统、与老系统融合、保证上线后稳定安全运行的关键代码，又吃掉 65% 以上的编码时间——恰恰是 AI 帮得最少的部分。 所以，再生更多代码，未必让交付变快。该量的是交付周期，该卡的是联调、测试，以及和老系统的边界。

说明：文中时间分布、生码率、提效上限等数字，均据 InfoQ 专访《Agent 越用越多，企业为何仍不够 AI Native？》（2026-11-08，蒋林泉自述）转述。这是内部复盘口径，本文未实测阿里内部数据，也不把这些比例当成所有团队的通用常数。本站 780、778、781 只作轻对照。

一、一张需求时间表：编码只有约两成

据蒋林泉团队把「一个需求从提出到上线」拆开后的结构：

环节（据蒋林泉自述）	约占全流程
需求设计、评审和修改	约 20%
交互视觉设计、评审和修改	约 10%
技术方案设计和评审	约 15%
编码开发	约 20%
前后端联调和集成	约 15%
测试和 Bugfix	约 20%

真正写代码的时间，只占大约 20%。需求、方案、联调、测试加在一起，才是大头。从 10 年后端的视角看，这张表之所以刺眼，不是因为它公布了一个惊人的新数字，而是它把很多团队「体感提效不明显」写成了可核对的结构：你把最容易加速的那一截加速了，整条链却几乎不动。

再把这 20% 编码拆开，结构更说明问题。据蒋林泉自述：那些要在存量核心系统里修改、要和老系统融合、要保证上线后稳定安全运行的核心代码和关键非功能性代码，代码量不大，却吃掉了 65% 以上的编码时间——而这恰恰是 AI 帮助最有限的部分。反过来，增删改查、前端 UI、测试代码、胶水代码这类常规代码，占据了大部分代码量，却只消耗了不到 35% 的编码时间。

他算了一笔账：20% 乘以 35%，约等于 7%。也就是说，即便 AI 把这部分常规代码的耗时压缩到零、其他环节都不变，端到端能节省的时间上限也只有约 7%——这还只是理论上限。业界交流中，有团队说端到端提效 3%，有的说 5%，做得不错的大约在 5% 左右，与这个推算大致吻合。

结论很清楚：AI 最容易生成的代码，原本就没花多少时间；真正花时间的地方，AI 帮得没那么多。

二、为什么老系统和验收才是瓶颈

用 10 年后端的视角读这张表，刺眼的地方通常不在「CRUD 能不能更快写出来」。成熟系统里，真正耗时的往往是：这段改动会不会踩到未写明的历史约束？和旁边那个用了很久的接口怎么对齐？上线后能不能回滚、可观测、不把邻居服务打穿？这些工作代码量不大，上下文却很深，恰好落在蒋林泉所说「AI 帮助最有限」的那 65% 以上里。

专访里还有一个更值得警惕的现象：有些团队用了 AI 之后，整体效率可能「不升反降」。蒋林泉听到不少 CIO 和产研负责人描述同一种状况：骨干反而成了更大的瓶颈，「像被 DDoS 了一样」。一个人用 AI 很快写出一大堆代码，要上线，就得有人 Review、有人为线上结果负责；真正能负责的往往只是少数「老司机」。这些人被打爆，自己的事情干不了，全链路就卡在他们那里。绕过 Review 直接上线，这些代码又大概率会变成技术负债——而且还很像模像样，比过去更难识别。

他把这一轮生成式 AI 的悖论概括成：每个人都可以驾驶 AI，快速、规模化地生产无价值的「负债」。风险分两类：价值风险（加速上线低价值的应用和功能，消耗组织和客户稀缺的注意力）；质量风险（加速产出低质量代码，增加系统复杂度和返工，影响稳定性，抬高长期维护成本）。注意力是稀缺的，真正能把控有效性的人也是稀缺的。产出越多，这些稀缺的人就越被逼到极限。

这也和本站 778、780 的验收提醒同向：多生成、多评审 agent，不等于验到了该验的边界。780 开场那个 Zoom 案例里，17 个评审仍没挡住「未付款就发出入场密码」——大家共享了同一个错误假设。老系统融合和联调测试，往往就是这类「假设之外」的坑所在。

需要补一句以免误读：蒋林泉后来也谈到，从 2024 年 12 月到 2026 年 3 月，在组织侧做了测试与观测左移、用 Live Demo 确认需求等变革之后，团队有效代码吞吐和端到端交付效率大致达到原来的 2 到 3 倍。那是组织与流程一起动的结果，不是「生码率到 30%」本身自动换来的。本文关心的，正是生码率先飙升、交付人力却没动的那一段。

三、别只盯生码率：把验收卡在联调、测试和老系统边界

对独立开发者和小团队，这张表不必照抄成制度，但有三条可直接拿走：

1. 别把生码率当成交付指标。 生码率上升，只说明模型在「常规代码」那一截帮了忙。据上述拆分，即便这一截耗时被压到零，理论上限也大约只有 7%。该盯的是一个需求从提出到真正可上线的周期，以及联调、回归、线上返工有没有变少。

2. 给 agent 的验收，应卡在联调、测试，以及和老系统的边界，而不是「又生成了多少行」。 可操作的门闩包括：与现有接口和数据契约是否对齐；关键路径有没有回归；上线后的稳定与安全约束有没有被默默改掉；跨服务的调用时机、权限和失败回滚是否仍成立。778 写过基础设施改动的四道验收，方向是一样的——验的是边界和后果，不是 diff 体积。

3. Harness 是成本杠杆，不是交付杠杆。 780 的实用句仍然成立：固定模型时，换脚手架更常买到账单差异，thinking / 模型更像质量杠杆。781 则提醒先看见上下文和账单结构，再决定拧哪根旋钮。这一篇要补上的是另一根轴：就算 token 更省、代码出得更快，只要你量的仍是生码率，交付周期可以纹丝不动。交付杠杆在验收，在老系统边界，不在「再生更多代码」。

一张极简自检表（自己填，不要求实验室精度）：

你现在量什么	它能说明什么	它说明不了什么
生码率 / 生成行数	常规代码是否写得更快	需求是否更快上线
token / 会话账单（对照 781）	钱花在哪类工作上	联调与回归过不过
从提出到可上线的日历时间和返工次数	端到端有没有真的加快	——
针对老接口、权限、失败路径的验收清单	agent 有没有踩到存量约束	模型「看起来很会写」

如果只能改一个习惯：下周开始，把「这周生码率多少」换成「这个需求从提出到可上线花了几天、卡在哪一环」。卡在需求误解，就用可操作的原型去对需求，而不是再催一轮生成；卡在联调和老系统，就把验收清单写在这些边界上，而不是再给 agent 加一条「请写得更完整」的提示。

四、结尾：瓶颈不在再生更多代码

蒋林泉这张表最有用的地方，是它把一句模糊的体感写成了结构：编码大约只占 20%，AI 最容易接手的又只是其中不到 35%，两端一乘，理论天花板大约 7%。业界交流里 3% 到 5% 的端到端提效，和这个推算对得上。真正花时间的，是存量核心、老系统融合，以及稳定安全这类关键代码；再往后，是联调、测试，以及少数还能为线上结果负责的人。

所以，独立开发者不必追逐下一次「生码率创新高」。780 让你分清成本杠杆和质量杠杆，781 让你先看见再省，778 让你把验收卡在真实边界上。这一篇只补一句：先量交付周期，再谈编码加速；给 agent 的验收，请对准联调、测试和老系统边界，而不是又生成了多少行。

参考

• InfoQ（2026-11-08）：Agent 越用越多，企业为何仍不够 AI Native？（籍云 / 陈姚戈；受访人：阿里云智能集团副总裁、CIO 蒋林泉）
• 轻对照 · 本站 780：https://blog.zhoudw.vip/blog/780
• 轻对照 · 本站 778：https://blog.zhoudw.vip/blog/778
• 轻对照 · 本站 781：https://blog.zhoudw.vip/blog/781

数字均为专访中的内部复盘自报，本文未实测阿里内部数据。