夜雨聆风AI 能力在跃迁，软件交付为什么没有？
代码生成变快之后，工程瓶颈去了哪里
几乎每隔一段时间，AI 都会展示出新的能力。
它可以理解更大的代码库，完成更长的任务，生成更完整的系统。过去需要经验丰富的工程师投入几天才能完成的工作，现在可能几个小时就能看到结果。
从个人使用感受看，变化已经非常明显。
写代码变快了，分析问题变快了，制作原型、补充文档、生成测试也变快了。很多工作不只是百分之十、百分之二十的改善，而是成倍提速。
但从软件交付的整体过程看，另一种感受同样真实。
需求仍然需要反复确认，方案仍然需要讨论，跨系统集成仍然困难，发布周期没有同比例缩短，原来的流程也没有发生颠覆性变化。很多团队已经广泛使用 AI，却仍然沿用原来的协作、评审和决策方式。
一边是迅速增强的 AI，一边是变化缓慢的软件交付系统。
这两种感受为什么会同时成立？
最近，Thoughtworks 在欧洲举办了一场关于未来软件工程的闭门研讨。来自工程、研究和商业领域的参与者提出了八个判断，包括代码生成不再是主要瓶颈、验证变得更加重要、Harness Engineering 正在成为独立学科，以及工程瓶颈正在向决策迁移。
这不是一份严格的行业统计报告，而是一次研讨活动形成的现场共识。但它最打动我的地方，恰恰不是预测了多么遥远的未来，而是准确描述了很多人正在经历的割裂。
问题可能不在于 AI 能力被高估，而在于我们把“更快完成一项工程任务”和“更快完成一次软件交付”当成了同一件事。
图 1｜AI 首先加速局部执行；交付瓶颈随后迁移到验证、流程与决策。
AI 的进步不是错觉，只是发生在不同层级
讨论 AI 效率时，我们经常把三件不同的事情混在一起。
第一种是任务效率。
例如，编写一个接口、分析一段代码、生成测试用例、补充技术文档。任务边界明确，输入输出相对清楚，AI 在这些场景中的优势已经非常明显。
第二种是流程效率。
一个需求需要经过分析、设计、开发、集成、验证和发布。每个环节不只是完成自己的任务，还要与上下游交换信息、处理依赖、发现问题并进行返工。
第三种是交付效率。
它衡量的不是某个环节完成得有多快，而是从问题提出，到系统稳定运行并产生业务结果，整个过程需要多长时间。
AI 在第一个层级已经产生了显著变化，在第二个层级开始产生影响，但在第三个层级还没有普遍形成质变。
图 2｜局部生产率、流程吞吐量和业务结果，是三个不同层级的指标。
这也解释了为什么管理者和工程师会对 AI 形成不同的感受。
管理者看到 AI 可以完成越来越复杂的任务，一个人能够同时推进更多工作，于是自然期待团队整体产能快速提升。
工程师看到的则是另一面：AI 生成的代码仍然需要理解和验证，系统之间的依赖不会自动消失，架构约束不会因为实现速度加快而放宽，高风险变更仍然需要有人判断并承担后果。
两种观察都是真的，只是观察的层级不同。
一个功能过去需要三天编码，现在可能半天就能完成。这是任务效率的显著提高。
但如果需求确认需要两天，方案决策需要三天，环境准备需要一天，集成和发布还需要一周，那么编码环节节省的两天半，不会自动变成整个交付周期的同比例缩短。
软件交付是一条完整链路。最终吞吐量并不由最快的环节决定，而是受到整条链路中最强约束的限制。
AI 提高了局部生产率，但局部生产率不等于系统吞吐量。
当生成不再稀缺，候选结果开始过剩
过去，代码和方案的生产成本很高。
工程师需要投入大量时间理解需求、编写代码和调试程序。受限于人的时间，一个团队通常只能认真推进少量方案。
生成能力本身限制了需要评审、验证和决策的工作数量。
AI 改变了这一点。
对于同一个问题，它可以迅速生成多个技术方案；对于同一个需求，它可以同时给出不同实现；如果允许 Agent 并行工作，一次任务甚至可以产生多组代码、文档和测试结果。
但候选结果增加，并不意味着有效结果同比增加。
每一个候选结果仍然需要回答：
它是否理解了真正的需求？ 是否满足已有架构和非功能约束？ 是否覆盖了失败路径？ 是否能与现有系统正确集成？ 是否引入了新的安全和运维风险？ 是否值得承担后续迁移和维护成本？ 谁愿意接受最终风险？
这些问题不会因为代码生成得更快就自动消失。
相反，当生成速度超过验证和决策速度，等待评审的代码、等待选择的方案、等待验证的产物会迅速增加。
AI 解决了“有没有答案”的问题，却把新的压力推给了“哪个答案是可信的”。
图 3｜当生成速度超过验证和决策速度，更多输出只会形成更长的交付队列。
我此前做过一次很小的实验。
我把同一个 PDF Skill 交给三个不同的 AI 工具运行。它的任务并不复杂：读取 JSON 数据，将内容填入 PDF，渲染出 PNG，最后生成一份结果文件。
为了判断任务是否真的完成，我设计了多项检查：执行状态、命令轨迹、PDF 内容、PNG 文件签名、唯一运行编号和产物哈希必须相互一致。
结果出现了一个很典型的冲突：在某个失败场景中，模型告诉我“没有产生任何输出”，但文件系统里已经多出了一个半成品。
模型的解释与外部状态不一致。
如果只看对话框里的回答，这次执行似乎安全失败了；如果检查文件系统，就会发现任务已经修改了外部状态。如果下游流程继续把这个半成品当成有效输入，问题还会进一步扩大。
这次实验让我更加确信：
模型说“完成了”，不等于工程任务真的完成；模型说“什么都没有发生”，也不能证明外部状态没有被改变。
AI 生成的是候选答案。只有经过验证、集成和确认，它才能成为工程结果。
这也是为什么代码生成能力越强，验证反而越重要。
这个规律并不只存在于软件工程。白宫科技政策办公室发布的《Science: A New Golden Age》在讨论 AI for Science 时，同样把低成本、持续性验证视为承接大规模发现能力的重要基础。报告以形式化数学为例指出，在“检查答案比发现答案更容易”的领域，验证能力会直接决定 AI 能否重组原有生产方式。
过去，验证主要处理人类工程师有限数量的产出。现在，AI 可以持续、大量、并行地制造新产物，而人的理解、评审和风险判断速度并没有同比例提高。
生成能力越来越像一种充足供给，可信结果才成为新的稀缺资源。
我们把 AI 接入了旧流程，却没有重构交付系统
如果 AI 能够显著提高任务效率，为什么软件交付流程没有随之改变？
一个直接原因是，多数团队只是把 AI 接进了原有流程。
在原来的开发阶段加入 AI Coding，在原来的评审之前增加 AI 生成，在原来的测试流程中增加用例生成，在原来的审批体系里增加 AI 产物。
工具变了，但流程的阶段划分、信息传递、责任边界和验收标准基本没有变化。
我们给旧流水线换了一台更快的发动机，却没有重新设计传动、制动和控制系统。
于是，AI 节省出来的时间，很快在其他地方重新消耗掉：
生成的内容变多，评审队列变长。 可以尝试的方案变多，选择成本上升。 并行任务变多，系统依赖和冲突增加。 实现速度变快，需求模糊造成的返工更早出现。 单点效率提高，团队开始承接更多任务，节省的产能又被新增范围吸收。
真正的问题不是 AI 不够强，而是交付系统还没有准备好承接这种新的生成能力。
这也是 Harness Engineering 开始受到关注的原因。
Harness 不只是给模型写一段更详细的提示词，而是围绕 Agent 建立一套完整的运行和控制环境：
给它提供正确、完整的上下文。 明确它可以执行哪些动作。 把架构约束和业务边界放进执行过程。 观察任务的中间状态。 在关键节点触发确定性检查。 失败后能够安全停止和恢复。 用独立证据证明最终结果。
图 4｜Harness 用前馈约束、确定性执行、独立验证和反馈控制构成工程闭环。
在前面的 PDF Skill 实验中，第一版程序会先写入正式文件，再检查外部渲染器是否存在。一旦渲染器缺失，任务虽然失败，半成品却已经留下。
改造后的版本先检查依赖和权限，在临时目录完成填充、渲染和验证，只有全部通过后，才将产物提交到正式位置。
模型并没有因此变得更聪明，但失败不再污染已有结果，完成状态也有了可以独立检查的证据。
这套分工可以概括为：
模型负责判断，确定性工具负责执行，独立验证器负责证明结果。
它解决的不只是某个 Skill 的可靠性问题，也是软件交付系统下一步需要补上的能力。
需求不能只存在于会议和人的记忆中，而要转化为可以检查的结果定义；架构原则不能只写在文档里，而要尽可能转化为规则和门禁；发布不能只依赖某个人的经验判断，而要能够提供风险、行为和运行状态的证据。
当这些能力仍然依靠人临场补足时，AI 只能提高某个工程师的个人效率。
只有当上下文、约束、执行和验证被沉淀为团队共同使用的工程系统，模型能力才可能稳定地转化为交付能力。
我们真正需要重构的，不是“怎样让 AI 多写一些代码”，而是“怎样让更多代码更快地变成可信的软件变化”。
存量系统规模化迁移，为什么能够率先提效？
如果说 AI 只能改善局部任务效率，可能低估了它的价值。
在一些边界清晰、环境可控的场景中，AI 已经可以显著提高端到端交付效率。存量系统的规模化迁移，就是一个很好的例子。
这里我更愿意使用“存量系统”，而不是“遗留系统”。
这些系统未必落后。很多系统已经稳定运行多年，承载着真实业务、历史数据、上下游依赖和大量没有被完整记录的规则。它们只是形成得更早，技术栈、架构或运行环境需要升级。
在可控环境中，AI 很适合处理这类规模化工作：
框架和语言版本升级 标准化接口迁移 配置与依赖改造 重复性代码转换 兼容层与适配层生成 测试和文档补齐 多个系统的批量分析与修改
这些工作的共同点，不只是“可以生成代码”。
更关键的是，它们通常同时具备几个条件：
第一，目标状态明确。团队知道要迁移到哪个版本、规范或者平台。
第二，迁移规则相对稳定。同一类修改可以在多个模块和系统之间重复应用。
第三，环境受到控制。依赖、权限、执行路径和目标平台相对清楚。
第四，结果能够验证。编译、测试、行为对照、数据校验和安全扫描可以证明迁移是否成功。
第五，失败可以定位和回滚。一次修改没有通过验证，不会直接污染所有正式结果。
图 5｜目标明确、规则稳定、环境可控、结果可验证，是规模化迁移提效的前提。
在这样的系统中，AI 可以快速分析代码、生成修改、补充验证，并在 Harness 的约束下反复执行。
它提高的不再只是某个工程师敲代码的速度，而是整个迁移流水线的吞吐能力。
这不是对“局部效率不等于系统效率”的反驳，恰恰是它的正向证明：
当目标、规则、环境和验证都被工程化，AI 的局部能力就能够转化为端到端交付效率。
真正决定 AI 能否规模化创造价值的，不只是模型会不会完成任务，而是任务之外的约束是否足够清晰，结果是否足够容易验证。
越接近这种条件的场景，越可能率先发生真正的流程变化。
越依赖模糊需求、复杂协作和高风险判断的场景，AI 能力与交付效率之间的距离就越远。
当交付系统真正变快，瓶颈会继续向上迁移
假设 Harness、自动化验证和工程流程逐渐成熟，更多任务开始像存量系统迁移一样被稳定、并行地执行，会发生什么？
软件交付当然会变快。
但新的问题也会随之出现。
当工程师和 Agent 能够同时推进更多任务，组织面对的就不只是更多代码，而是：
更多等待选择的方案 更多需要判断的风险 更多同时推进的项目 更多跨系统依赖 更多资源和优先级冲突 更多需要承担责任的决策
执行能力可以通过模型和 Agent 横向扩展，组织的决策能力却无法用同样的方式复制。
图 6｜执行能力可以横向扩展，人的注意力和判断力不能线性扩张。
LeadDev 最近的一篇文章把这种问题描述为“上下文负荷”：真正限制管理者的，不只是管理多少人，而是同时需要理解多少对话、决策和风险。AI 可以帮助团队更快地产生工作，也会带来更多方案、规格和半成品，瓶颈因此从生产工作迁移到判断哪些工作是连贯的、值得做的。
这会形成软件交付中的下一个不对称：
执行端正在快速并行化，决策端仍然高度串行化。
这不是因为管理者不够努力，也不一定是管理能力不足。
问题在于，很多组织仍然要求少数管理者参加大量评审、理解所有重要上下文、确认关键方案，并为跨团队风险兜底。过去，执行速度限制了同时涌来的决策数量，这套方式还能勉强运行。
AI 提高执行速度后，原来被生产能力掩盖的决策约束会迅速暴露。
如果每一个 Agent 产生的方案都需要同一个人确认，如果每一个并行项目都需要同一个人协调，那么 AI 生成得越快，决策队列就会越长。
到了这个阶段，企业需要重新设计的就不只是软件交付流程，还有组织的决策系统：
哪些决策必须由管理者完成？ 哪些判断可以下放给更接近上下文的人？ 哪些重复判断可以变成规则和系统门禁？ 哪些风险才值得消耗稀缺的管理注意力？ 如何让团队提交的是已经收敛的决策选项，而不是大量原始材料？
这是另一个值得单独讨论的问题。
但它至少说明了一点：AI 不会消灭软件工程的瓶颈，它会不断推动瓶颈迁移。
写在最后
AI 能力在跃迁，软件交付却没有同步发生颠覆。
这两种感受并不矛盾。
AI 首先改变的是任务层面的生产效率，软件交付衡量的却是一个包含需求、设计、实现、集成、验证、发布和决策的完整系统。
当代码生成不再稀缺，验证开始成为瓶颈；当验证和执行逐渐被工程化，流程与决策又会成为新的约束。
存量系统规模化迁移已经说明，只要目标、环境和验证机制足够清晰，AI 的能力完全可以转化为显著的交付效率。
所以，真正的问题已经不是：
AI 还能不能生成更好的代码？
而是：
我们能不能围绕这种新的生成能力，重新设计软件交付系统？
如果不能，AI 的进步会继续停留在个人和任务层面。
如果能够，软件交付效率确实可能迎来一次真正的跃迁。但到那时，我们还会面对下一个更难复制的稀缺资源：人的注意力、判断力，以及组织形成高质量决策的能力。
真正限制未来软件交付效率的，可能不再是我们能够生产多少代码，而是我们能够多快地把大量可能性，收敛成一个值得交付、可以负责的结果。
参考资料
Thoughtworks，《The Future of Software Development Retreat Europe 2026》
The White House, Office of Science and Technology Policy，《Science: A New Golden Age》
Diego Quiroga，《Engineering managers are paying the price of rising expectations》，LeadDev