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

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

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

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

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

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

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

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

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

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

自动化的瓶颈之旅

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

这条规律不是制造业的专利。2026 年 7 月，a16z 播客《Software in the Age of Agents》里，前微软 Windows 总裁 Steven Sinofsky 用企业软件的例子，独立得出了同一条结论。他的原话是：

“The long tail got no shorter. It just got longer in a different way.”（长尾一点没变短，只是换了个方式变得更长。）

他举了 Amazon 客服：砍掉电话、让 chatbot 直接补发商品，看似省了人力，可后端立刻冒出”怎么防止同类问题再发生”的根因分析需求，比接电话更复杂。报销流程也一样：OCR 自动入账之后，财务要做的变成了差旅绩效优化、动态比价——工作没消失，只是从”录入”上移到了”分析决策”。一位微软老兵、a16z 合伙人，没用 Goldratt 的理论，却得出了和制造业 40 年前一样的判断。一个来自车间，一个来自企业软件，两条独立路径指向同一条规律。

不过要给这条规律补一个限定，免得被读成绝对真理。确实有瓶颈是被永久消灭的：打字员、电话接线员、铅字排版工——这些工种没有”上移”，是真切消失了。判断一种工作会被搬家还是被消灭，关键看自动化释放的产能是催生了新需求（经济学叫杰文斯悖论），还是单纯让这块需求萎缩。企业核心系统周围的多数工作属于前者：账算得越快，老板想看的分析就越多越细。所以这里的结论不是”自动化能裁掉多少活”，而是”把人和预算，从被自动化的那层，搬到新冒出来的那层”。（企业软件视角的长尾搬家，番外篇《企业软件粘性》有完整展开。）

L’IT et la manufacture : une histoire de coûts

L’histoire que vous allez entendre est plus proche de l’informatique que vous ne le pensez. En 2013, Gene Kim a repris presque mot pour mot l’histoire de la manufacture de Goldratt et l’a appliquée à l’IT, en écrivant “The Phoenix Project” : comment un CIO a sauvé son département IT en voie de faillite en utilisant la théorie des contraintes. Ainsi, “regarder l’informatique à travers les lunettes de la manufacture” est une approche qui a déjà été testée et qui n’est pas une métaphore temporaire.

Industrie manufacturière : le bouchon se déplace : élargir une étape, la suivante sera bloquée Première étape : l'usinage est le bouchon Usinage / Taille Soudure Peinture Montage final Contrôle Stockage de demi-produits Production continue = production de l'étape d'usinage (la plus étroite) Introduction de machines numériques : l'usinage est élargi ↓ Deuxième étape : le bouchon se déplace vers le montage final / le contrôle Usinage (déjà accéléré) Soudure Peinture Montage final Contrôle Stockage de demi-produits Théorie des contraintes (Goldratt, 1984) : la production est déterminée par la section la plus étroite ; élargir celle-ci, le bouchon se déplace L'industrie logicielle répète l'expérience : la tâche de codage devient moins chère, le bouchon se déplace vers la demande, l'intégration, la validation, l'alignement

II、Retour à l’informatique : la programmation devient la tâche la moins chère

Trois chiffres pour expliquer clairement que “le coût de production du code tend vers zéro”.

AI 技术博客：写代码的成本正在快速逼近零

Copilot：GitHub 的研究结果

GitHub 自己的研究测出，在启用 Copilot 的文件里，约 46% 的代码由 Copilot 完成。注意口径，这是”启用文件内”的占比，不是全 GitHub 所有代码的 46%。

Stripe：内部自研的 coding agent “Minions”

内部自研的 coding agent “Minions”，每周产出并合并的 PR 超过 1,300 个（早期 1,000，持续上涨）。这里有个关键细节值得记住：每一个 PR 都要经过人工 review 才合并。Stripe 把”写”自动化了，把”验收”留给了人。这一点第四节会用到。

NVIDIA：100% 的工程师都在用 AI 编程工具

黄仁勋公开说过，100% 的 NVIDIA 工程师都在用 Cursor 这类 AI 编程工具，”不用 AI 工作”在 NVIDIA 已经不被接受。

结论：写代码的成本正在快速逼近零

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

尖锐的问题：为什么软件还是这么贵、这么慢、这么难交付？

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

三、瓶颈跑去了四个地方

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

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

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

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

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

Où est passé le délai de livraison ? : la tâche de codage est réduite à une étape, les quatre étapes sont élargies Avant l'AI Après que le codage devient presque gratuit Codage Prend la moitié du temps de livraison Demande Intégration Validation Alignement Codage ↓ réduit à une étape Demande ↑ Intégration ↑ Validation ↑ (augmente le plus) Alignement ↑ Proportionnalité indicative (expérience industrielle globale), non des chiffres précis issus d'une seule étude

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

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

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

自働化的字面就藏着答案

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

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

AI 技术博客

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

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

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

Boucle de robotisation : ligne de production Toyota ↔ CI/CD logiciel Ligne de production Toyota (robotisation, avec un personnage automatique) Machines en fonctionnement automatiqueProduction automatisée Détection d'anomalieArrêt automatique de la machine / signalisation d'arrêt Intervention humaine, résolution de la causeRésolution sur place, sans attendre la fin de la production Rétablissement de la productionL'homme a le droit de faire cesser la production → → → ↓ Même logique, appliquée au logiciel CI/CD logiciel (porte de qualité de l'ère de l'AI) Génération de code par l'AIÉcriture, automatisation Tests / Revue de code bloquésMais pas de fusion Vérification humaine + résolution de la causeVérification des limites, explicabilité Fusion / Augmentation de la quantité de "gris"Vérification sur une zone restreinte → → → Production automatisée, vérification laissée à l'homme "droit d'arrêt", automatisation plus profonde, porte de qualité plus importante Stripe Minions : 1 300+ PR par semaine écrits par un agent, tous les révisions humaines après, puis fusion Robotisation ≠ Remplacement de l'homme par l'AI ; robotisation ≠ Transformation de l'homme en machine = Arrêt d'exception + intervention humaine (robotisation avec une touche humaine)

五、”定义问题”的溢价：比 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 时代软件工程变革系列

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

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

关于本系列

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

La révolution de l’ingénierie logicielle à l’ère de l’IA est une série d’études approfondies destinée aux CIO/CDO/CTO et responsables de la transformation numérique des secteurs des télécoms, de la finance, de la fabrication et du commerce électronique, composée de 15 articles. Basée sur plus de 200 articles académiques et rapports industriels, elle fournit des références décisionnelles annotées selon des niveaux de preuve.
Je suis ancien ingénieur IBM et coach certifié ICF, ayant mené la mise en œuvre de projets IA et de transformation numérique pour des opérateurs et de grandes entreprises. Ce que j’écris ici repose sur des jugements pratiques tirés de l’accompagnement d’entreprises à travers leurs échecs et leurs apprentissages.

Sources de référence (tous vérifiés)

  • a16z (2026). Software in the Age of Agents. The a16z Podcast. (Citation emblématique de Steven Sinofsky, ancien PDG de Windows chez Microsoft : « The long tail got no shorter, it just got longer in a different way » — une validation indépendante du principe du déplacement du goulot d’étranglement TOC, du point de vue des logiciels d’entreprise ; source primaire — enregistrement original du podcast. Positionnement : Partenaire a16z / ancien cadre Microsoft, position VC. Invités vérifiés : Seema Amble, partenaire de l’équipe entreprise a16z ; Steven Sinofsky, board partner ; Elena Burger, rédactrice a16z ; diffusion en juillet 2026.)

  • Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. (Source originale de la Theory of Constraints (TOC) ; source primaire ; roman se déroulant dans une usine manufacturière.)

  • Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press. (Transposition directe de la TOC de Goldratt dans l’IT et l’exploitation logicielle — le pont entre fabrication et logiciel ; source primaire.)

  • Toyota. Toyota Production System — Jidoka (自働化). toyota-global.com (Jidoka = automatisation avec un caractère humain ; arrêt automatique en cas d’anomalie + intervention humaine pour résoudre la cause racine ; système Andon ; source primaire.)

  • GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle. (Copilot active environ 46 % des complétions de code au sein du fichier — mesure basée sur « file-level enabled » ; source primaire.)

  • Stripe (2025/2026). Minions: Stripe’s one-shot, end-to-end coding agents. stripe.dev/blog ; InfoQ rapporte plus de 1 300 PR par semaine, tous revus manuellement (source primaire + secondaire.)

  • NVIDIA / Jensen Huang. Déclaration publique selon laquelle 100 % des ingénieurs utilisent des outils de programmation IA comme Cursor (propos direct.)

  • GitClear (2025). AI-Assisted Code Quality Research. (Observation d’une augmentation des codes répétitifs et du churn à court terme sous assistance IA — soutient l’idée que « la validation devient plus coûteuse » ; source secondaire.)

  • Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press. (Les performances de livraison sont déterminées par la culture, la vitesse de flux et les retours, et non par la vitesse de codage individuelle ; source primaire.)