2025 年 DORA 调查中，90% 的受访技术人员已经在工作中使用 AI，超过 80% 认为自己更高效。但这是自陈调查，不是生产率的因果测量。同一研究还观察到另一组关系：AI 采用越多，软件交付吞吐越高，交付稳定性却越低。这同样只是组织层面的关联，不能证明 AI 单独制造了事故。两项材料都来自 Google/DORA。它们共同摆出的矛盾是：人们感到更快，组织也交付得更多，但总价值和稳定性没有自动随之提高。
常见解释会把问题归到模型质量。模型再准一点，生成的代码再好一点，稳定性迟早也会追上来。这个解释漏掉了更难的一段：AI Coding 降低的是让项目出生的成本，需求选择、审查、集成、维护和叫停仍然消耗人的注意力。第一笔下注变便宜了，项目总成本却未必按同样比例下降。这是本文对现有证据的综合判断，目前还没有研究直接测量 AI 项目组合的全周期总成本。
这也意味着，项目变多本身不是坏消息。便宜原型可以帮团队更早证伪一个需求。真正需要追踪的变量是：原型失败以后会不会被关掉；它进入生产以前，有没有重新支付维护、治理和责任成本。
六十年前，软件成本就已经不只发生在编码阶段
1968 年，NATO 软件工程会议讨论的“软件危机”并不是程序员不会写代码。系统规模扩大以后，需求收集、计划、集成、验收、文档和维护一起超过了当时的组织能力。会议原始报告甚至写道，维护成本经常超过最初开发成本。
这次转折改变了责任边界。软件不再只是一个人把程序写出来，还要有人定义它该做什么、证明它能工作、处理变更，并在交付以后继续负责。代码只是生命周期里最容易看见的一段。这份历史材料解释的是软件工程机制，并不直接测量今天的 AI Coding。
1986 年，Fred Brooks 在 No Silver Bullet 里区分了偶然复杂度（accidental complexity）和本质复杂度（essential complexity）。高级语言大幅降低了机器表达的偶然复杂度，开发者不必再把大部分精力花在寄存器、分支和设备细节上。可需求、接口、状态空间和团队沟通构成的本质复杂度还在。他把最难的工作概括成一句话：精确定义到底要做什么。
Brooks 并不反对快速原型。他恰恰主张用原型澄清客户自己也说不清的需求。因此，这段历史留下的结论并非“工具提效没有用”。它更适合被当作一种历史参照：表达成本下降以后，需求判断、系统集成和持续责任仍可能留下来；它不能证明所有新工具都会重复同一条路径。
AI Coding 把表达成本再往下压了一层。本文据此提出一个尚未被直接测量的机制假设：当第一笔实现预算降低，预算原有的项目筛选作用也可能减弱，“能跑起来”因而更容易被误当成继续投入的理由。
速度收益发生在哪里，决定了成本被推到哪里
AI Coding 的生产力证据看起来互相矛盾，其实测的是不同工作。
GitHub Copilot 的一项厂商关联预印本控制实验让参与者完成一个边界清楚的 JavaScript HTTP server 任务，处理组平均快了 55.8%，95% 置信区间为 21% 到 89%。结果只适用于这一单一新建任务，不能外推为普遍生产率。
METR 2025让 16 名资深开源维护者在自己熟悉的大型仓库处理 246 个真实 issue，使用当时的 AI 工具后反而慢了 19%。到了2026 年更新，研究者认为工具很可能已经更有帮助，却也承认开发者不愿接受无 AI 条件等选择效应，让精确提速幅度变得不可靠。
55.8% 加速和 19% 减速没有互相推翻。边界清楚的新建任务，瓶颈可能更接近代码生成；成熟系统里的真实修改，理解上下文、校验、集成和失败责任可能占得更重。两项研究的工具、任务和样本不同，不能据此推出普遍因果，但它们共同说明：AI 的收益取决于它压缩的是哪一段工作。
DORA 的平台工程材料把这种成本转移描述得更直接：AI 节省的生成时间会转向审计、验证和生产集成。它认为强平台与快速反馈更能吸收增加的变化量，测试、安全审查和部署流程薄弱时，编码速度会被下游瓶颈吞掉。这是 Google/DORA 的组织能力分析，不是采用某种平台以后必然改善结果的因果实验。AI 更像放大器，而不是一台单独决定结果的发动机。
真实仓库里的新研究给出了另一个信号。一篇 2026 年预印本追踪 6,299 个公开仓库中的 302,600 个 AI commit，识别出 484,366 个静态分析问题。在能够继续追踪的问题中，22.7% 留在 HEAD，也就是仓库最新版本。这些问题不等于用户可见的 bug，AI commit 归因和公开仓库样本也可能有偏。它能支持的判断是：至少一部分可追踪问题不会自动随时间消失，merge 后仍留待后续处理；不能据此把它们全部等同于已经发生的维护债务。
另一项已被 MSR 2026 接收的研究分析 5 个 coding agent 在公开项目提交的 33,000 多个 PR。失败不只来自测试和 CI，也包括重复 PR、不需要的功能，以及维护者放弃审查。在这组公开项目和特定 agent 样本中，任务选择、scope 和 review 已经成为变更能否被接纳的重要条件，但不能据此外推全部 AI Coding 项目。
Jevons 给出的只是警告，不是判决
这很像能源效率里的反弹效应（rebound effect）：单位服务成本下降以后，人们可能使用更多，预期节省会被新增需求吃掉一部分。最极端的情况通常被称作 Jevons Paradox。
能源研究并没有得出“效率一定增加总消耗”的简单结论。Gillingham、Rapson 与 Wagner 的综述认为，较可靠的家庭交通与用电直接反弹研究大多落在 5% 到 25%，并不支持节省普遍被完全逆转。经济全局模型往往估得更高；Brockway 等人的叙述性综述汇集的 CGE 等模型中，敏感性结果从约 12% 到超过 200%。这些估算高度依赖模型边界、替代弹性和反事实基线，不能给出 strict backfire 的统一结论。
把它映射到 AI Coding，单位编码成本下降，组织可能启动更多项目。项目发起人先拿到便宜供给，review 注意力、维护容量、安全和数据治理却可能承担尾部成本。如果新增需求把全部提效吃掉，团队得到的只是更多待维护系统。
类比到这里就该停。能源是可以加总的同质流量，软件项目是异质、离散、可以删除却会积累依赖的资产。我们甚至还没有统一的“软件总消耗”单位。只看到项目数增加，不能证明 AI Coding 已经发生严格的 Jevons backfire。
便宜的错误实验，也可能是最值钱的实验
反方最强的证据不在模型 benchmark，而在试验本身。
一项软件原型的 mapping study 和多案例研究发现，原型能帮助团队探索问题和解法，验证市场、技术和可用性，在完整开发之前获得真实反馈。同一研究也划出了边界：如果利益相关者把原型误判为成熟产品，扩展性、安全和稳健性风险可能随之进入生产。这项研究并不直接测量 AI 项目。
创业公司采用 A/B testing 的研究也观察到一个看似矛盾的结果：使用一年后的表现与 30% 到 100% 改善相关，公司扩张得更快，失败得也更快。这不是随机分配，指标也不等于利润或长期维护质量。它至多提示：如果负面信号能够触发停止，更快失败可能减少后续投入。
所以，项目启动数不是维护负担的好指标。一个便宜原型只有在后续投入仍需重新决策时才是一张期权。它要回答一个明确问题，有期限，有成功和失败条件，也允许答案不好时直接丢弃。没有这些条件，“先试一下”会变成默认续费。
真正的门，应该设在项目获得生产身份的时候
低代码提供过一组相似的观察。一项 2024 年研究在两家公司开展了 30 次对技术专家和 citizen developers 的访谈。业务人员用低代码快速完成小型应用和 POC，缩短了需求验证；治理缺席时，也出现了应用无人维护、重复建设、shadow IT 和 technical debt。样本只有两家公司，只能提示开发权下放、资产盘点和生命周期责任之间可能存在的机制，不能推算行业比例，也不能外推全部企业。
应用组合治理可以提供一个参照。美国联邦 CIO 的 Application Rationalization Playbook要求盘点真实使用、依赖、维护成本和技术适配，再决定保留、替换、退休或合并。它控制的是生产资产，不是脑暴；但这是一份政府实践指南，不能直接证明企业或 AI 项目采用同样做法后的效果。
AI Coding 也需要这条两状态边界。这里的划分是本文提出的操作性定义，并不是论文或行业已经采用的统一标准。
实验状态允许廉价、短命、可丢弃。它的目标是获取信息、降低不确定性，因此只需要限定数据范围、明确问题、期限和停止条件。
生产资产状态意味着持久承诺：代码进入持续维护分支，接入真实数据或内部系统，真实用户开始依赖，其他服务形成依赖，团队承诺 owner、变更流程、SLO 或 on-call。跨过这条线时，项目需要重新提交用户证据、依赖清单、维护预算、负责人和退出条件。Google SRE把生产接管写成责任与 ownership 的转移，为这条边界提供了实践参照，但并不等于给出了统一定义。
这道门不必阻止原型继续出现。区别在于，做出来不再自动等于应该留下。
接下来六到十二个月，三个数字会改变判断
以下是本文提出的观察指标，尚无统一行业基准，只用于更新判断，不构成因果检验。
第一，看新项目启动数与 30 天、90 天内关闭或归档数的比值。如果试验变多，负面信号也能稳定触发停止，便宜项目买到的是信息。
第二，看每个活跃系统的人均维护工时、事故和依赖存量。如果生产资产增加，这三项却下降，将支持平台和控制系统可能吸收了新增变化量的判断。
第三，看原型进入生产前，具备明确 owner、真实用户证据、维护预算和退出条件的比例。如果这道门没有形成，会增加编码节省正在转化为未来责任的担忧。
回到开头，DORA 看到的吞吐增加和稳定性下降并不矛盾。本文的编辑判断是：现有证据尚不能证明组织已经普遍建立了为长期承诺重新定价的机制。项目可以更容易出生，但它不该因此自动获得活下去的权利。