开始折腾
我没有先去找一个更好的生码Prompt，而是从一份跨多个业务域的内部脱敏需求复盘开始拆。
材料把传统方式的估算设为 100%。用了AI辅助研发以后，实际投入降到原来的 41.7%，相对减少 58.3%。这是一个足够漂亮的AI Coding案例。
但我继续把AI辅助后的投入设为 100% 再拆开，情况变得有意思：
- 需求澄清占 40%；
- 编码占 30%；
- 上下游对接、自测和Code Review占 20%；
- 发布后的观察与风险排查占 10%。
代码只占 30%。剩下 70%，都发生在代码之外。
图解：AI辅助后的剩余投入中，编码只占30%，另外70%发生在代码之外。
如果继续只优化写代码，我们当然还能更快一点。即使把 30% 的编码投入继续压缩一半，其他环节仍占剩余工作的主体。即使编码投入降到 0%，这个需求也不会瞬间交付。
它仍然需要回答：需求到底要解决什么，改动边界在哪里，上下游契约是否一致，测试证明了什么，发布有没有生效，风险能不能接受。
我的判断是：AI Coding提高的是代码生产速度。AI Delivery要提高的是一项改变从意图出发，穿过研发系统，最终被用户或业务验收的速度与可靠性。
这两个速度不会自动相等。
沿着这组比例，我接下来关心三件事：
- 为什么代码生产提速以后，端到端交付没有同步提速；
- 怎样用状态、证据、harness和反馈回路，把候选代码推到真实结果；
- 当Agent接住越来越多中间执行，人应该站在哪里，又该用什么指标判断系统是否变好。
如果AI Coding解决的是“代码怎么更快地产生”，AI Delivery要回答的是“改变怎样安全、稳定地到达用户”。
01 代码变快以后，瓶颈会迁移
软件交付是一条有前后依赖的链路。
需求要先被理解，方案要和现有系统对齐，代码要进入仓库，测试要在有效环境中运行，变更要经过发布，线上结果还要被观察。任何一段处理能力不足，工作就会在那里排队。
AI Coding改变了其中一段，而且通常是改变最剧烈的一段。
过去，编码本身可能是主要耗时。现在，Agent可以并行读代码、改多个文件、补测试、修静态扫描。代码供给突然增加，Review、环境、联调和发布没有同步扩容，于是等待从编码前后向其他环节转移。
这和工厂里只加速一台机器没有本质区别。上游产出加快，下游没有变化，系统不会自动获得同比例吞吐，只会先获得更多库存。
代码成了新的在制品。
它生成得越便宜，团队越容易一次改更多文件、同时开更多分支、把更大的需求塞进一个变更。等待没有消失，只是换了位置。DORA在 2025 年的研究中把AI描述为组织能力的放大器：它会放大团队已有的能力与问题；更高的AI采用率同时与更高吞吐和更高不稳定性相关。DORA在 2026 年的后续说明中也提到，生成节省下来的时间，常常被重新花在审计和验证上。
即使只看Coding，研究结果也并不整齐。GitHub的受控实验中，参与者完成一个边界清楚的JavaScript HTTP server任务时平均快了 55%；METR在 2025 年让资深开发者处理自己长期维护的成熟开源仓库，测到的却是平均慢 19%。METR后来使用更晚的工具观察到了加速信号，但选择偏差让幅度难以确定。
这些结果不必互相推翻。它们测量的任务、代码库、工具能力和完成边界不同。越接近真实交付，历史上下文、质量要求和环境依赖越难被排除。把任何一组Coding数据直接外推成组织提效，都会跨过太多没有被测量的环节。
所以，看到AI代码占比提升时，我不会先问“还能不能再高一点”。我会问另外几个问题：
- Change从提出到上线，P50 和P90 用了多久？
- 等待主要发生在哪一段？
- 变更批次是不是变大了？
- Review、返工和故障有没有同步增加？
- 用户拿到的结果有没有变快？
AI Coding是局部能力。只有这些问题一起改善，局部能力才变成了系统能力。
02 “代码完成”不是一种状态
沿着交付链往下看，我觉得最容易踩的坑，是所有系统都在说“完成”，说的却不是同一件事。
Agent说代码完成了，开发说自测完成了，流水线显示构建完成了，发布平台显示任务完成了。它们都可能是真的，但说的不是同一件事。
一项变更至少会经过这些状态：
代码已生成，只能证明工作区里出现了一份候选修改。
测试通过，证明的是指定测试在指定环境和输入下通过。它不自动证明需求被正确实现，也不证明没有遗漏重要场景。
MR合并，说明变更进入了目标分支。它不代表目标环境已经加载这份代码。
部署成功，说明发布系统完成了自己的动作。它不代表流量已经命中新版本，也不代表依赖、配置和数据都处在预期状态。
线上验证通过，仍然只是技术结果。最终还要回到需求原本想改变的业务Outcome。
代码完成、本地完成、协作完成、部署完成和业务完成是五件事。AI Delivery的第一步，是停止用同一个“done”覆盖它们。
图解：每一种“完成”都只能由对应证据推进，不能用同一个Done替代。
这要求交付链路里的每一次责任转移，都携带最小但完整的契约：
| 字段 | 它回答的问题 |
|---|---|
| Objective | 为什么要做，准备改变什么结果 |
| Scope | 这次改到哪里，在哪里停止 |
| Evidence | 当前判断基于什么事实 |
| Acceptance | 什么证据出现以后才算完成 |
| Constraints | 哪些权限、风险和兼容性边界不能越过 |
| Return | 结果、限制和未完成项要回到哪里 |
这不意味着每个小需求都要先写一份厚文档。很多时候，六个字段加起来只有几百字。关键是让下一个人或Agent接到一段可以执行、可以质疑、可以验收的责任，而不只是一句“帮我改一下”。
03 Prompt决定一次回答，harness决定长期交付
当AI Coding刚开始普及时，很多注意力放在Prompt上。
这很合理。模型不知道你的意图，第一步当然要学会怎样表达任务。但我对照真实仓库里的执行链后，更在意Prompt之外的东西：随着Agent开始处理真实环境，Prompt很快不再是最大的变量。
一个写得很好的Prompt，无法补上过期的业务规则；无法替Agent获得正确的仓库、日志和发布工具；无法证明测试环境与生产一致；也无法在发布出错时提供幂等、回滚和审计。
这些东西共同组成harness。
Context：让Agent面对当前世界
Agent需要的不是尽可能多的资料，而是这次任务真正相关、仍然有效的上下文：当前业务规则、系统边界、接口契约、历史决策、代码规范、环境差异和已知风险。
上下文过少，Agent会猜。上下文过多，它会被旧事实和无关材料淹没。
Context Engineering要让知识有来源、有时效、有作用域，并能按任务逐步展开。把Wiki全塞进窗口解决不了这个问题。
Tools：让Agent接触真实系统
只会生成文本的Agent，最多交付一个建议或补丁。
进入Delivery，它必须能在受控范围内读取代码、查询依赖、运行测试、查看CI、检查环境、创建变更、观察发布结果。不同工具的返回还要有稳定语义，不能把“请求已受理”“执行成功”“用户已看到”混成一个状态。
Validation：让“看起来对”变成“有证据”
AI生成代码的边际成本下降以后，验证会成为更稀缺的能力。
单测、静态扫描、契约测试、回归用例、真实环境探针和业务验收要形成层次。自动化不是为了给每一段代码盖章，而是尽快找到能够推翻错误假设的证据。
Runtime：让Agent可以行动，也可以被阻止
真实交付包含权限、并发、重试、超时、幂等、灰度、回滚和可观测性。
一个Agent能调用发布工具，不等于它获得了发布授权；一个任务返回成功，不等于生产已经生效；一个进程还活着，也不等于它加载的是刚才那次变更。
这些边界如果只写在Prompt里，就仍然依赖模型每次“记得遵守”。高风险动作需要代码级guard，需要最小权限，需要留下可复核的记录。
Prompt可以让一次回答更像专家。Harness才能让一段工作反复、稳定地穿过真实世界。
图解：Prompt决定一次回答；Context、Tools、Validation和Runtime共同决定交付能否稳定重复。
04 Agent不该沿着流程跑，它要围绕结果闭环
很多所谓端到端Agent，本质上是把原来的研发流程串成一条更长的Workflow：先生成需求，再生成方案，再生成代码，再跑测试，最后触发发布。
这当然有用。但把节点换成Agent，并不自动得到AI Delivery。这里的坑是把“流程跑完”误当成“结果成立”。
真实工作不会严格沿着一条直线向前。
需求澄清时可能发现现有产品已经支持；写方案时可能发现接口假设错误；跑测试时可能暴露数据问题；发布验证时可能证明代码没问题，配置却没有生效。每一次环境返回，都可能改变下一步。
因此，Agent的核心结构不是更长的流程图，而是一条反馈回路。
这条回路里有几个很容易被忽略的边界。
Evidence要来自环境，不来自Agent对自己工作的描述。测试报告、diff、CI结果、发布版本、线上Trace和业务指标，强度都高于一句“已经处理完成”。
Validation必须能失败。一个永远给出通过结论的Reviewer，只是另一个生成器。好的验证会在证据不足时停住，会指出哪条Acceptance尚未满足，会把未知保留为未知。
Learning也不能等同于把本次对话写进Memory。一次成功可能是偶然，一次失败也可能来自环境。经验先成为candidate，经过回归、对照和灰度以后，才有资格改变Skill、规则或默认行为。
这也是AI Coding与AI Delivery的一个深层差别。
AI Coding关注模型能否完成眼前的修改。AI Delivery还要保证系统不会因为一次看似成功的运行，学会一个长期错误。
图解：只有来自环境的证据、可以失败的验证和经评测的学习，才能把流程闭成结果。
05 Human不再串联每一步，但要回到两端
当Agent能读代码、调用工具并完成多步任务以后，人最先让出的，通常是中间执行。
过去，工程师自己搜索代码、改文件、跑测试、看报错、再改一轮。现在，这些步骤可以在一个长任务里连续发生。
但人的工作没有消失，只是向两端移动。
在交付链路前端，人要定义问题。
这个需求是否值得做？真正的业务对象是什么？哪些是事实，哪些只是提出者的猜测？如果现有配置已经能解决，是否还需要写代码？这部分工作越模糊，Agent越容易用高质量实现交付一个错误问题。
在交付链路后端，人要判断结果。
Acceptance是否真的满足？局部测试能不能支撑整体结论？风险是否可接受？这次变更应不应该灰度、暂停或回滚？当系统要影响用户、资金、数据和外部承诺时，谁拥有最终授权？
中间仍然有一块混乱地带。
跨领域的责任冲突、组织内没有写下来的默契、临时变化的环境、无法自动判断的业务取舍，都不会因为模型更强就立即消失。Agent可以帮助取证、提出选项、缩小未知，但不能把缺少授权解释成默认同意，也不能把不确定性藏在流畅的答案里。
所以，AI时代的工程师不会只剩下“审代码”。
更准确的角色是Delivery Owner：定义目标，组织上下文，分配责任，设计验收，在关键边界作决定。
这也是我理解的Orchestrator。他不再站在一群Agent中间搬运消息，而是让系统自己完成可验证的执行，把人的注意力留给方向和后果。
06 从使用率指标，转向交付指标
一个团队开始使用AI时，最容易采集的是活动数据：调用次数、活跃人数、AI代码占比、采纳率、生成Token。
这些数据有用。它们可以告诉我们工具有没有进入日常工作，也能帮助排查某个团队为什么没有使用。但它们不能回答“交付是否变好了”。
代码生成得多，不代表上线更快；Agent调用得多，也可能是在反复返工。
所以，如果让我判断AI是否真的进入Delivery，我不会只看使用率，而会把指标沿着结果链分层。
第一层是Activity：谁在用，在哪些环节用，生成了多少代码。这一层回答采用情况。
第二层是Flow：变更前置时间、部署频率、在制品数量、各阶段等待时间。这一层回答工作是否更顺畅。
第三层是Quality：变更失败率、部署返工率、恢复时间、缺陷逃逸和验收一次通过率。这一层回答速度是否以质量为代价。
第四层才是Outcome：用户是否获得能力，业务指标是否发生预期变化，释放出来的时间是否被用于更有价值的工作。
DORA当前使用五个软件交付指标：Change lead time、Deployment frequency、Failed deployment recovery time、Change fail rate和Deployment rework rate，并把它们归为Throughput与Instability两组。它们比代码量更接近Delivery，但仍然不是业务价值本身。
团队最终还要为自己的产品定义Outcome。客服Agent看解决率和转人工，诊断Agent看MTTR与一次解决率，研发Agent看质量调整后的需求吞吐、端到端周期和人类注意力投入。
AI代码占比可以证明AI参与过生产，不能证明团队交付了更多价值。活动指标应该留在诊断页，结果指标才有资格进入目标页。
图解：Activity适合诊断，Flow和Quality衡量系统，Outcome才回答用户是否拿到价值。
07 AI Delivery到底是什么
现在可以回到最初的问题。
当代码不再是交付里最慢的一环，接下来应该优化什么？
不是再造一个更会写代码的Agent，也不是先把需求、开发、测试、发布各放一个Agent，然后宣布端到端已经成立。
需要改变的是整条责任链。
需求要从一句自然语言变成范围清楚、可验收的Objective；上下文要从散落在人脑和文档里的背景，变成Agent能按需消费、可以核验时效的资产；工具要连接真实系统，也要守住权限与副作用；每个阶段要返回证据，而不是只返回状态；运行结果要进入评测和反馈，经过验证后才能改变下一轮能力。
人也会换一个位置。
他不再亲手串联每一步，但仍然拥有方向、重要事实、风险选择和现实授权。Agent接住中间大量执行，harness保证这些执行可观察、可停止、可验证、可恢复。
所以，我理解的AI Delivery是：
一套由Objective驱动、由harness支撑、能够让Agent在真实环境中持续行动，并用Evidence与Acceptance对结果负责的软件交付能力。
它不以“生成了代码”为终点，也不以“流水线显示成功”为终点。
它的终点，是一项改变安全地到达用户，并且我们能证明这件事发生了。
如果是我来推进一个团队的AI Delivery，我不会先扩Agent数量。我会先选一个真实需求，把Objective和Acceptance写清，让每一种“完成”都绑定证据，再同时观察Flow、Quality与Outcome。高风险动作继续保留明确的人类授权；小闭环跑通以后，再扩大自动化范围。
AI Coding让代码变得便宜。
AI Delivery要解决的是：当实现不再稀缺，怎样让正确的问题、可靠的证据和可控的行动跟上来。
我会从下一次真实需求开始，把“完成”改成可验收的证据：用户没有拿到结果，就不算交付。