当代码近乎免费，瓶颈跑去了需求、集成、验证、对齐

当代码生产近乎免费，软件交付的瓶颈就从”写代码”跑到了别处：定义对的问题、把片段拼成能跑的整体、验证它确实是对的、让组织对齐。 这是约束理论（Theory of Constraints）在软件业的一次重演。制造业 40 年前就趟过这条路：每当一道工序变便宜，瓶颈不会消失，它只是挪到下一道最贵的工序。看懂这一点，你就能解释一个普遍的困惑：AI 编程工具全公司铺开了，写代码明显快了，交付速度却没怎么变。

一位制造业集团的 CIO 给我看他过去半年的数据。IT 团队 80 多人，全面上了 AI 编程工具，单看代码产出，人均提交量和合并速度都涨了三成以上。但业务侧的体感完全不同：一个智能排产的小功能，从立项到上线还是 3 个月起。他原以为工具能带来 2 倍提速，结果只买到了”代码写得快”。他的话很直：”我花了几百万买 license，买到的却是开发更忙、业务更急。”

他假设错了瓶颈的位置。他的真实瓶颈是另一回事：每一个新功能都要穿过 MES、ERP、质检系统、车间终端，外加一套监管报送口径，集成和联调吃掉了大部分工期；而 AI 生成的代码，没有任何一道正式的验收关卡挡在它和生产环境之间。代码写得再快，也只是在错误的瓶颈后面排队。

一、制造业 40 年前就知道：瓶颈会跑

要理解当下，先借制造业一副戴了 40 年的眼镜。

1984 年，物理学家出身的以色列顾问 Eliyahu Goldratt 写了本小说《目标》（The Goal），讲一个濒临破产的厂长怎么救活一座工厂。全书的核心就一句话：任何系统的产出，由它最窄的那个环节（约束，也就是瓶颈）决定。 加宽非瓶颈环节，对总产出毫无帮助；只有加宽瓶颈本身，整体才会变快。而一旦你加宽了瓶颈，瓶颈立刻挪到下一个最窄的地方。这就是约束理论（Theory of Constraints，TOC）。

制造业之后 40 年的自动化史，几乎是一部”瓶颈搬家史”。当数控机床让切削变便宜，瓶颈挪到了换模和质检；当柔性产线让换模变快，瓶颈挪到了排产和供应链协同；当 MES 让排产变准，瓶颈挪到了需求预测和跨厂调度。每自动化掉一段，下一段就浮上来。自动化从不消灭瓶颈，它只给瓶颈换了个位置。

这件事和软件的距离，比你想的近。2013 年，Gene Kim 把 Goldratt 的工厂故事几乎原样搬进了 IT 运维，写出《凤凰项目》（The Phoenix Project）：一个 CIO 怎么用约束理论救活一个快要拖垮整家公司的 IT 部门。所以”用制造业的瓶颈思维看软件”是条已经验证过的路径，不是临时找来的比喻。

二、回到软件：写代码正在变成最便宜的一环

三组数字，把”代码生产成本趋零”说清楚。

Copilot：GitHub 自己的研究测出，在启用 Copilot 的文件里，约 46% 的代码由 Copilot 完成。注意口径，这是”启用文件内”的占比，不是全 GitHub 所有代码的 46%。
Stripe：内部自研的 coding agent “Minions”，每周产出并合并的 PR 超过 1,300 个（早期 1,000，持续上涨）。这里有个关键细节值得记住：每一个 PR 都要经过人工 review 才合并。Stripe 把”写”自动化了，把”验收”留给了人。这一点第四节会用到。
NVIDIA：黄仁勋公开说过，100% 的 NVIDIA 工程师都在用 Cursor 这类 AI 编程工具，”不用 AI 工作”在 NVIDIA 已经不被接受。

把三组数字叠在一起，结论很硬：生产一行代码的单位成本，正在快速逼近零。

尖锐的问题随之而来：既然写代码几乎不要钱了，为什么软件还是这么贵、这么慢、这么难交付？答案正是约束理论给的：你加宽了”写代码”这道工序，瓶颈只是挪走了。它挪去了哪里？

三、瓶颈跑去了四个地方

这一次，瓶颈集中在四道工序上。每一道，都是 AI 短期内碰不到的。

第一道：定义对的问题。 AI 能在几秒内写出”你嘴上说的那个功能”，但它写不出”你真正需要的那个功能”。多数软件项目失败，根子在做出来的东西没人用，一开始就没把要解决什么问题想透。代码生产变便宜之后，”把一个模糊的业务困扰，拆成一个清晰、可解、值得解的规格”（problem formulation）成了最稀缺、也最贵的能力。制造业同行对此不陌生：工艺路线和工程图纸定错了，车间加工得再高效，也是批量生产报废品。

第二道：系统集成。 AI 擅长生成”一段代码””一个函数””一个页面”。可一个能上线的系统，是几百个片段的集成，它们要互通数据、处理边界、保持一致、扛住异常。生成片段便宜，把片段拼成一个可靠的整体昂贵。这道成本，根子在组织和架构对齐上，正是康威定律和团队拓扑关心的事（见本系列前两篇）。回到开篇那位制造业 CIO：他的工期没耗在写代码上，耗在了 MES、ERP、质检、报送这几套系统的联调上。

第三道：验证。 代码量暴涨，可信度参差。谁来拍板”它是对的”？测试、code review、可观测性、灰度发布，这些”验证”工作的分量不降反升。这是最被低估的一道瓶颈，也是制造业镜像最深的一道。第四节单独讲。

第四道：组织对齐。 当团队里多了 AI agent，谁决定做什么、谁审核、谁对结果负责？这又是康威定律和团队拓扑的延伸，组织对齐本身成了瓶颈。系列第 11 篇会专门讲：当组织节点不全是人类，治理怎么变成核心竞争力。

四、最深的一刀：验证，以及丰田”自働化”到底在教什么

四道瓶颈里，最容易被误读的是验证。很多人把它理解成”既然 AI 写得快，那就多测几轮”。这只对了一半。要看懂验证为什么变贵，得先把丰田那套被引用得最烂、也错得最多的概念讲对：自働化（Jidoka）。

先纠正一个广泛流传的误读。自働化不是”用 AI 或机器替代人”，也不是”让人变成机器、像机器一样不停干活”。这两个方向都反了。

自働化的字面就藏着答案。日语里”自動化”是普通的自动化，丰田特意用”自働化”，那个”働”带了人字旁，强调的是”带人字旁的自动化”（automation with a human touch）。它的准确含义是：当机器或产线检测到异常，自动停下来，让人介入、把根因解决掉，再恢复生产。 它有两个机制并行：机器自己装了异常检测，会自己停；产线上任何人发现不对，拉一下安灯绳（andon），整条线立刻停。质量不在末端检，而是嵌在每一道工序里、就地解决。

这里有个反直觉的结论，正是它直接对应软件：自动化越深，质量关卡和人介入的分量只增不减。 自働化把人从”重复操作”里解放出来，重新摆到”发现异常、停线、解根因”这个位置上。丰田给一线工人拉停整条产线的权力，恰恰是因为它清楚：自动化再强，也得有人能在出问题时喊停。这才是”赋予机器人的智慧”那句口号的真正所指：让机器具备停下来呼叫人类的能力。人始终在场，负责解根因。

软件正在重走这条路，而且走得很急。GitClear 对 AI 辅助代码的质量研究已经观察到重复代码块增加、短期 churn 代码上升的迹象：AI 写得快，但也写得”看起来都对”。当大量代码没人逐行写过，传统的”开发心里有数”这种信任机制就失效了。这时候你要的，就是软件版的安灯绳和停线机制：

测试（单元、集成、端到端）从”尽量做”升级为硬门槛，没过不许合并；
Code review 的重点从”检查写法”转向”检查意图和边界”：这段代码到底想解决什么，边界条件覆盖了没；
可观测性（监控、日志、追踪）成标配，因为线上行为比代码本身更能说明问题；
灰度发布 / feature flag 让 AI 生成的东西先在小范围验证，确认没问题再放量。

回头看第二节 Stripe 那 1,300 个 PR：写归 agent 写，合并这道关全留给了人工 review。这就是自働化在软件里的活样板：把生产自动化，把验收留在人手里，并且赋予人”挡住它”的权力。生产变便宜了，质量控制变贵了，这是一条 40 年没变过的规律。

五、”定义问题”的溢价：比 prompt 更值钱的能力

如果说验证是被低估的瓶颈，”定义问题”就是被严重低估的能力。

prompt engineering 火过一阵，不少人以为”会写 prompt”就是核心能力。可 prompt 只是”把问题表达出来”的技巧。真正稀缺的是再往前一步：problem formulation，把一个模糊的业务困扰，拆成一个清晰、可解、值得解的问题。这一步，AI 短期内做不到，因为它得等你先告诉它”问题是什么”。

制造业老法师对这一步的分量最有体感。一张工程图纸、一条工艺路线定错了，下游加工和装配再高效，也是批量生产错误。软件同理：需求规格定错了，AI 帮你以十倍速度造出一堆没人要的东西。

判断一条很直接：别再卷”写代码的速度”，去练”拆问题的清晰度”。 在组织里，这意味着把”需求定义”和”验证验收”摆成正式岗位，别再让开发顺手做。AI 把实现变便宜之后，这两个岗位的回报上升最快。

六、四个行业的真实瓶颈长什么样

把”瓶颈转移”套到四个行业，每个行业的瓶颈都不在写代码上。

制造业。主线就是开篇那位 CIO。智能排产、质量追溯、能耗优化这些功能，技术上都不难，模型不少是现成的。瓶颈卡在 MES / ERP / 质检 / 报送几套系统的集成联调，以及车间终端的实地验证上。这类项目的代码往往写得很快，可 MES/ERP 几套系统的联调要吃掉数倍于写代码的时间；只有把验收岗摆到车间终端和集成环节，缺陷才能就地拦下来，而不是流到投产才暴露。

电信 / 运营商。一个套餐变更或政企专线的开通流程，要穿过渠道、计费、CRM、网络开通、装维排程好几个域。AI 让各域的开发都快了，可跨域的端到端联调和一致性验证才是工期大头。运营商还有一个独特瓶颈：合规与对账。计费差一分钱都是事故，验证的分量比任何行业都重。以政企专线开通为例，AI 把各域开发都加快了，端到端联调加上计费对账，往往仍要占去工期的大半。

金融。一个信贷风控或反洗钱规则的调整，跨 App、核心系统、风控引擎、数据中台、监管报送。这里验证的权重极高，因为错一笔就是合规事故。瓶颈在可解释、可审计、可回溯：AI 写的规则再准，过不了监管那一句”为什么这么判”，照样上不了线。反洗钱规则迭代就是典型：AI 加快了规则编写，可模型的可解释性审核和监管报送对齐加在一起，常常吃掉整个周期的一大半。

电商。一个促销或大促功能，跨商品、交易、营销、仓储、客服。AI 让页面和接口写得飞快，瓶颈挪到了压测、库存一致性、风控防薅羊毛、对账上。大促当晚挂的，从来不是写得不快的代码，是没验证到的边界。大促准备就是个缩影：促销页 AI 很快就能生成，可端到端压测和库存一致性验证，常常要占去备战的大半工时。

四个行业的共性很清楚：AI 加速的是”写”，卡住的是”拼、验、对齐”。 把省下来的开发产能投到这三件事上，才是真提效。

七、判断错了会怎样：三种最常见的错配

第一种：把”代码写得快”当成”交付变快”。 这是最普遍的错觉。代码只是交付链上的一环，加宽它不会让整条链变快，只会让瓶颈后面堆更多半成品。约束理论管这叫库存，软件里叫未验收的 PR 和没联调的分支。结果就是开发更忙、业务更急、产出没变，正是开篇那位 CIO 的处境。

第二种：生产提速的同时，拆掉了质量关卡。 这是违反自働化的典型错误。有人觉得”AI 写得又快又好，code review 可以简化、测试可以砍”。恰恰相反，生产越快，安灯绳越要紧。砍掉验收关卡，等于让没人在场的流水线全速空转，缺陷会以更快的速度涌向生产环境。

第三种：在非瓶颈上砸钱。 集成是瓶颈，你却去买更多 AI 编程 license；验证是瓶颈，你却去招更多开发。约束理论早就讲透：在非瓶颈上加投入，对总产出零贡献，只会让账面更难看。正确的顺序是先定位瓶颈，再把资源压到瓶颈上。

八、对决策者的启示

启示一：买工具之前，先画一张瓶颈图。 把你最近三次卡住的交付拆开看，时间到底花在哪。是写不出代码，还是拼不起来、没人验、需求没想清？标不出来的，就是在按技术层瞎猜。瓶颈图比任何工具采购清单都值钱，它能挡掉大企业至少一半的无效 IT 投资。

启示二：把省下的产能，投到需求和验证上。 AI 让开发变快，意味着你能匀出人手。把这些人正式编进”需求定义”和”验证验收”两个岗位，别让他们继续埋头写更多代码。这两个岗位的回报，在 AI 时代上升最快。

启示三：给软件装一道安灯绳。 自働化最直接的落地，是在你的 CI/CD 里设硬门槛：测试不过不许合并、review 必须查意图和边界、灰度先小范围放量、可观测性成标配。生产越自动化，这道关越要牢。这是在防止”代码免费”变成”事故免费”。

启示四：重新摆人的位置，别把人撤掉。 自働化指向同一个结论：自动化越深，人越要被摆到”判断、验收、解根因”的位置上。把人从重复操作里解放出来，重新部署到验证和对齐上，这是 AI 时代组织设计的核心动作，也是本系列后面几篇要展开的内容。

九、你可能想问

“我们只是局部试点 AI，没必要画全公司瓶颈图吧？” 试点也得先看清：试点的这个环节，到底是不是真正的瓶颈？如果卡点其实在集成或验证上，那在”写代码”这个环节试点 AI，就是在非瓶颈上砸钱，正好踩中第七节讲的第三种错配。先做一次小范围的瓶颈诊断，工具的钱才花得值。

“验证关卡会不会拖慢交付？” 短期会有摩擦，长期是加速。没有验收关卡的”快”，是把缺陷推向生产环境的快，返工成本十倍起。自働化的经验是：就地解决一个缺陷的成本，是让它流到下游再解决的零头。

“这和我们正在搞的 AI 转型什么关系？” 关系很直接。AI 转型最常踩的坑，就是假设瓶颈在”写代码 / 产能”上，然后买一堆工具去加宽这一环。先做瓶颈诊断，再决定钱花在哪。这也是我把”能力评估”和”价值场景识别”放在《AI 转型 7 步教练框架》靠前位置的原因：先看瓶颈在哪，再谈工具。

反向自检（回答时别美化）：你最近一次卡住的交付，时间到底花在写代码上，还是花在拼起来、验过去、对齐上？你的 AI 工具产出一堆代码，能稳定上线、用户真在用的有多少？你的 CI/CD 里，有没有一道”测试不过不许合并”的硬关卡？三条里有一条答得心虚，那就先别急着买更多 AI 工具，先找到你的瓶颈在哪。

下一步

这是”AI 时代软件工程变革”系列 15 篇的第三篇。从康威（组织决定架构）、团队拓扑（怎么设计组织），走到了瓶颈转移（当代码近乎免费，瓶颈去了哪里）。下一篇（第 4 篇）换一个更实操的视角：主流 AI 编程工具怎么选。 但结论可能反直觉：选型说到底是一次组织决策，要按你的成熟度和治理水平来挑，别按”谁写的代码最炫”去选。

系列说明：本系列会持续追踪AI编程工具、组织架构和软件工程范式的最新演进，如2026年康威定律在AI代理时代的新变化、最新工具生态的成熟度等。关注本系列，获取持续更新的洞察。

关于本系列

“AI 时代软件工程变革”是写给电信、金融、制造、电商等行业 CIO/CDO/CTO 与数字化负责人的深度研究系列，共 15 篇。基于 200+ 篇学术论文与行业报告，提供有证据层级标注的决策参考。

我是前 IBM 工程师、ICF 认证教练，做过运营商和大型企业的 AI / 数字化项目落地。这里写的都是陪企业蹚过坑的实战判断。

参考来源（均已核实）

Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement.（约束理论 TOC 的原始出处，一级来源；以制造业工厂为场景的小说）
Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press.（把 Goldratt 的 TOC 原样搬进 IT 运维，制造业→软件的桥，一级）
Toyota. Toyota Production System — Jidoka（自働化）. toyota-global.com（自働化 = 带人字旁的自动化，异常停线 + 人介入解根因；安灯系统；一级来源）
GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle.（Copilot 在启用文件内完成约 46% 代码，口径为”启用文件内”，一级）
Stripe (2025/2026). Minions: Stripe’s one-shot, end-to-end coding agents. stripe.dev/blog；InfoQ 报道每周 1,300+ PR，全量人工 review（一级 + 二级）
NVIDIA / 黄仁勋. 100% 工程师使用 Cursor 等 AI 编程工具的公开表态（一手言论）
GitClear (2025). AI-Assisted Code Quality Research.（观察到 AI 辅助下重复代码 / 短期 churn 上升，支撑”验证变贵”，二级）
Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press.（交付绩效由文化、流速、反馈决定，非个人编码速度，一级）