瓶颈不在写代码

原文给的团队内部粗略统计：生码在整个研发链路里只占 20%~30%，甚至更少。

阿姆达尔定律（Amdahl's Law）说的是：系统整体的性能提升，受限于其中无法被优化的那部分。即使把某个环节加速到无限快，整体提升依然有上限。

套进来就是：把占三成的编码环节压缩到接近零，整条链路的提升上限也只有三成。 而且——编码被解决得越彻底，编码之外的部分就越成为新的瓶颈。

继续挤压编码环节的收益已经很小了。 同样的力气花在影响面分析、联调环境、发布编排、灰度验证的工具化上，价值远大于让代码生成再快一倍。

关于"为什么 AI 很强但效率没上来"，常被提到的另外两个原因：

1. 大模型基于公开语料训练，天然缺少我们的业务领域知识 2. benchmark 分数高，不等于在生产环境里能直接把活干好

原文的判断是：这两点都成立，但它们和上面那个案例指向同一个结论——瓶颈不在 coding，而在 coding 之外。

表面的答案是：代码有海量公开语料、公开 issue、公开评测。

更深一层的规律是：AI 总是优先解决那些反馈公开、验证可以规模化的问题。

coding 和数学最先被突破，不是因为它们简单，而是因为它们是少有的"对错机器自己就能判"的领域——编译过不过、测试过不过，跑一下就知道。

而企业级生产环境里恰恰相反：答案藏在内部的各个研发系统里，没有公开反馈，验证一次的成本还很高。

既然 AI 的能力边界是由可验证的反馈划定的，那么该做的就是：主动把内部的研发工作流，改造成"有反馈、可验证"的环境。

Jack Reeves 在 1992 年提出过一个判断：源代码才是软件真正的设计，文档只是设计过程中的摘要，天然会丢信息。

原文给了它一个新读法：生成代码会快到近乎免费，但真正的工作是——把模糊的业务意图变成完整、精确、能跑起来的表达，并且验证它真的符合预期。

所以"让 AI 更会写代码"不再是主战场，主战场在验证与环境。

19 世纪末的工厂围绕蒸汽机设计：一台大型动力机带动贯穿厂房的传动轴，再通过皮带和滑轮连接每台机器。 机器必须沿着传动轴排列——空间布局、作业顺序、管理方式，全都由"如何传递动力"决定。

电动机出现后，大多数工厂没有推倒重建，只是用一台大电机替换了蒸汽机，继续带动原有的传动轴和皮带。这叫"电力轴传动"或"分组驱动"：能源变了，但厂房布局、机器排列和生产流程基本没变。

结果是：旧系统的能量损耗、整片设备联动、局部故障导致大面积停工，问题全都还在。电力只是成了更方便的动力源，还没有成为重构生产系统的基础。

变化发生在企业开始采用单元驱动之后：每台机器配独立电机，机器不再需要围绕传动轴排列，可以按照原材料进入 → 加工 → 装配 → 成品输出的顺序重新布局。

工厂从多层、狭窄、依赖承重传动轴的建筑，转向开阔的单层空间；流水线、连续生产、灵活的材料搬运由此成为可能。

电力带来的最大收益，不是蒸汽机和电动机之间的效率差，而是生产流程、厂房结构、设备组织和管理制度的整体重构。 美国制造业生产率的明显跃升，主要出现在这些互补改造普及的 1920 年代。

换模型、换工具 = 换发电机，容易立项、见效快，也确实能积累手感。但真正的跃升要等到"单元驱动"——让每个工位摆脱中央传动轴，获得独立运转的能力。 原文的主张是：先让 coding 这个工位独立转起来。

目前的主流做法：把 AI 嵌进一套人类设计的固定流程——PRD → 需求澄清 → 技术方案 → 任务拆解 → 生码 → 测试，每个节点调用 AI 做局部提效，节点之间的验收和流转还是按老流程走。

原文认为 SDD、各种 Agent Skills、Superpowers 这类插件，本质上都是同一条路线。而这条路线的天花板在于：它优化的是"人使用 AI 的方式"，而不是"AI 使用环境的方式"。

更尖锐的一句判断：这等于在 AI 时代重新引入瀑布模型。 因为它假设需求澄清后就是对的、方案评审后就是可行的、实现阶段只需忠实执行。

而真实开发里，一次测试失败可能来自实现、环境、数据、架构假设或需求理解中的任何一层。 任何失败都回退到"重新出方案再生码"，只会把已经做对的判断一起推倒。

agentic 的本质，是 AI 能否自主获取验证信号——不用每一步都等人来判断对不对。

在这条路线里 workflow 并不消失，它退回到自己该待的位置：调度、权限控制、状态保存、审计、高风险检查。

原文给了一个可以直接拿来做决策的问题：

「下一代 SOTA 模型发布时，我正在做的这件事，是获益，还是作废？」

贬值区：围绕"生成能力"的投入

微调模型提升生码质量、囤积提示词技巧、精细编排生码流程。昨天的脚手架，变成今天模型的内置能力——在这条线上投入，等于和模型厂商打军备竞赛。

增值区：围绕"环境与验证"的投入

把企业内部的构建、部署、测试、数据、接口、日志、监控、发布链路，做成 AI 可调用的工具。没有任何厂商能替你做，而且模型越强，这些资产越值钱。

企业从 AI 拿到的红利，约等于模型能力与环境能力的乘积。

模型是租来的因子，跟着厂商的节奏自己往上涨；环境是自有的因子，只能自己建，而且只涨不跌。

乘法的意思有两层：

1. 任何一端是零，结果就是零——再强的模型，进不了你的环境，生产力就是零 2. 模型每强一代，都会把同一套环境的价值重新放大一遍

所以 workflow 化的收益是线性的（只是给现有环节加了个常数），环境投入的收益是复利的（它在乘法里占住了一个因子）。

不做"如何让 AI 生码更强"的军备竞赛，只做企业内部环境的工具化。 这不是说模型相关的事一概不碰——模型选型、评测、上下文接入当然要做，划界标准就是上面那个问题。

阿姆达尔定律的前提是各环节相互独立、串行叠加。但实测数据显示，编码加速不是中性的。

Google 的 DORA《2025 State of AI-assisted Software Development》报告发现：AI 采用度与交付吞吐量正相关的同时，也与交付不稳定性正相关——变更失败更多、返工更多、问题解决周期更长。原因是变更量上去了，而下游的测试、评审、质量保障接不住。

所以准确的说法不是"提升上限只有三成"，而是：那三成里还有一部分会被下游多出来的返工吃掉。 生码从 1 小时压到 10 分钟，如果因此多提了几个 PR、多引入一次线上问题，链路总时长可能不降反升。

这处修正是往同一个方向加强的：不先建验证与环境就压缩 coding，收益不只是"有限"，而是可能为负。

那 3 周里，618 封网不是效率瓶颈，而是故意设置的风险门禁——它的存在本身就是目的，用发布自由度换稳定性。把它和"联调环境难搭""影响面分析靠人肉"放进同一个待优化的 3 周，会导向错误的投入方向。

我认为应该拆开：

- 可工具化的等待（影响面分析、联调环境准备、发布编排、灰度指标读取）——该工具化，收益是真的 - 故意的门禁（封网期、灰度观察期、多人审批）——不该被"优化掉"

对第二类，要优化的不是让它变快，而是让门禁的判断依据自动化：封网期要不要放行，现在靠人判断风险；如果影响面分析、回滚验证、灰度指标都变成机器可读的，决策会快，但门禁本身应该保留。

混为一谈很容易做出"用工具绕过管控"的东西——那是在借将来要还的债。

原文说 agentic 的本质是"AI 能否自主获取验证信号"。但自主循环真正的前提，是信号本身有鉴别力。

假信号比没信号更危险。 没有信号时，Agent 会停下来问人；假信号会让它自信地跑完整个错误的循环，而且沿途每一步都显示"验证通过"。

环境建设的第一步不是"让 AI 能调用"，而是"让信号有鉴别力"。 顺序反了的话，你建的是一套能高速运转、但会自信地跑错方向的机器。