执行驱动交付（三）：执行循环——为什么跑起来再设计，比想清楚再做靠谱？
执行驱动交付（EDD）：AI 项目交付方法论 · 3/8
📖 摘要：EDD 的核心引擎是执行循环——一轮一刀：每轮定义一个最小可运行任务（MRT），跑通、冒烟、修、提炼约束，再切下一刀。本文讲刀口标准（什么刀值得切）、增量集成（每轮四步）、失败传播（失败是业务路径不是意外）、介入纪律 ABC（报错强制介入/偏离按需介入/正确不介入）。
📌 本文要解决的核心痛点
- 一个大功能闷头做两周，拼装时才发现接口对不上，全部返工？
- AI 跑偏了没人管，报错了一股脑修，改完还是错？
- 交付期为了赶进度，手工改 AI 输出——这次改对了，下次又错，经验一点没攒？
- 本文讲执行循环：一轮一刀 + 增量集成 + 介入纪律 ABC——信息只在执行中暴露，跑起来才知道往哪走。
场景
传统开发习惯：一个功能拆成模块，各做各的，最后联调。AI 项目里这个模式死得特别快——因为 AI 的每个环节（模型理解、工具调用、知识库召回）都是概率性的，单块跑通 ≠ 拼起来能跑：上下文在链路里丢了、接口字段对不上、顺序依赖没处理。
我们踩过的典型翻车：意图分类和知识库检索各自调通，拼到一起，检索环节拿到的是分类节点改写过的问题——字段名对不上，检索结果全空。单块验证全绿，拼装全红。这类错误如果等全部做完才拼装，定位成本最高：嫌疑对象是全部模块。
执行循环的解法：每一轮都切一块、拼一块、冒烟一块——接口错误在拼入的那一轮暴露，嫌疑对象只有刚拼的那块，定位成本最低；每轮结束都有一个能跑的整体，随时可以 demo。
结论
执行循环：一轮只切一刀。每轮定义最小可运行任务（MRT）——范围极小、聚焦、快速闭环。下一刀取决于本轮暴露了什么，不预排。跑起来再设计，比想清楚再做靠谱。
MRT 的定义升级过一版：从「能跑」升级到「能拼」——可运行 + 接口明确 + 独立验证 + 语义完整。一刀不只是「跑通一件事」，是「跑通一件事且能拼进整体」。
推导链：为什么信息只在执行中暴露
三条机制：
1. 概率性系统的行为不可预演。 模型对这句提示词会怎么理解、这个参数会不会触发工具校验、这 50 条片段召回率多少——全部只在真实执行中暴露。提前预排 MRT2/MRT3 是脑内推演：你以为的下一步，跑完这一步可能根本不成立。
2. 试错成本要摊薄。 一刀一轮 = 每次试错的范围极小，错了改的成本最低。一个大刀切下去，错了都不知道错在哪块。
3. 每轮有可运行整体 = 受控实验。 客户随时能看 demo，每一轮的反馈都真实——不是文档评审的「差不多吧」，是看到能跑的东西之后的真反应。
实践动作：执行循环的纪律（四条）
执行循环纪律四条：
| 纪律 | 内容 |
|---|---|
| ① 一轮只切一刀 | MRT 范围极小、快速闭环；下一刀取决于本轮暴露了什么（不预排） |
| ② 介入纪律 ABC | A·报错时 → 强制介入，纠正评估标准重跑；B·偏离时 → 按需介入（不满足成功标准断言），调边界卡或 TR2 后重新生成；C·正确时 → 不介入，只标记「已验证」（进入固化层的前置条件） |
| ③ 熔断四字段（写进每个 MRT 定义） | max_steps / token_budget / forbidden_actions / escalate_to_human |
| ④ 自断后路 | 不手工改 AI 输出，错了改工作流/提示词/加断言直到自动跑通 |
介入纪律 ABC 是执行循环的灵魂——它定义了人和 AI 的协作边界：A 报错时（API 异常/工具调用失败/格式不对）必须介入，纠正评估标准让 AI 重跑；B 行为偏离时（没报错但输出不符合成功标准）按需介入，调整约束后重新生成；C 行为正确时不介入，唯一动作是标记「已验证」——这个标记是 TR3 用例素材和参考基线的来源。
自断后路铁律：交付期坚决不手工改 AI 输出，错了必须改系统（工作流/提示词/断言）直到自动跑通。为什么这么绝？手工改输出 = 绕过循环 = 错误不进错误清单 = 资产不沉淀——这次你手改了，下次它还会错，而且你没有留下任何修对的记录。
刀口标准：什么刀值得切（五条判定）
一刀成为拼图块，五条判定，缺一不可：
业务语义完整——一句话说清这刀干什么（业务语言）；「调用 LLM」「写文件」这种技术步骤不算（子工作流是编排单元不是函数）
接口明确——入参出参清晰：完整（刀内所需都从入参进）/ 最小（不拖无关数据）/ 稳定（接口第一轮前固定）
独立可验证——给入参能跑、跑了能判对错；没有独立验证能力的刀是「依赖刀」，并进别的刀
内部无独立子动作——刀内不再有多个可独立验证的业务动作（有 = 刀切大了）
有复用可能（第二层判据）——同类项目大概率重现
两类刀：拼图刀（做业务的、满足五条，一律封成子工作流）；胶水刀（连接业务的：路由/映射/转换/编排，留主工作流）。总量约束：一个项目 5-8 块健康区间，切刀时以「最终 5-8 块」反推刀口，防碎片化。
增量集成：每轮四步 + 收官轮
每轮节奏四步：
① 切拼图刀 → 建子工作流
② 子工作流独立冒烟（正常路径用例 + 错误清单扩充的异常路径）
③ 拼入主工作流（骨架先行：第一轮前建好只有胶水的主工作流）
④ 主工作流整体冒烟（已拼部分主路径跑通）
收官轮（拼装刀）：完整主工作流全量验证四件事——全链路协作跑通 / 接口契约全量核对 / 端到端业务场景 / 性能边界。收官跑通 = 收敛 = 进 TR3。
失败传播：失败是业务路径的一部分，不是意外
三条原则：
失败后行为必须设计出来——每个调用节点有明确失败分支，不允许「失败就报错」了事
失败分级，不同策略：瞬时错误（超时/限流）→ 重试；业务异常 → 不重试走降级（另一块拼图接管/兜底分支/引导用户）；契约错误（接口不匹配）→ 不重试快速失败，反馈给开发而不是丢给用户
失败向上冒泡但语义化——主工作流知道哪块失败、为什么、影响什么；原始报错不直接丢用户
配套一个强制约定——失败契约：每个子工作流的输出变量必须显式声明结构化错误对象
{error_code, error_message, retryable}，error_code
结构化（主工作流路由可判断）、error_message 人可读、retryable
标记是否可恢复。没有这个契约，错误和成功在输出里无法区分，主工作流会把失败当成功继续跑——这是反模式「失败吞噬」，TR3
要用「模拟失败→断言走了错误路径」的用例专门抓。
反例实证：手工改输出，改了七次
一个表单提取项目（内部实验），交付期 LLM 提取的日期格式总错。赶进度，手工改了三次输出——每次都对，客户也验收了。但第四天换了一批数据，又错。因为手工改的是「这一次的输出」，不是「为什么会错」——系统层面的根因（日期格式没进形状断言）一直没修。
后来按自断后路铁律重做：加形状断言 + 修正提示词，让系统自动跑通。从那以后这个错误再没出现过，而且「日期格式必须断言」进了错误清单，成了 TR3 的回归用例——手工改输出，改的是结果；改系统，改的是原因。 前者让错误反复出现，后者让错误一次性消失并变成资产。
边界与版本
冒烟 ≠ TR3：冒烟是每轮的小测验（这轮 MRT 目标场景能不能跑，几分钟）；TR3 是收敛后的期末大考（正式验证）。别把冒烟当验证，也别等 TR3 才冒烟
收敛条件（进 TR3 的前提）：MRT 目标达成 + 应用形态基本稳定（不再大幅重构）+ 错误清单饱和（新错误不再频繁出现）
每轮动作：用 TR2 当前版本生成 DSL → 导入 → 冒烟 → 修 → 提炼约束写跑通记录（约束回填 TR2、错误进错误清单）——生成/导入/冒烟是执行循环的固定动作，不属于 TR2 也不属于 TR3
平台实现细节（子工作流变量隔离等）基于 Dify 1.16.x 实测，其他平台按「接口明确 + 独立验证」原则适配
收尾
执行循环回答了一个反直觉的问题：为什么跑起来再设计，比想清楚再做靠谱？ 因为 AI 项目的设计信息不在脑子里，在执行里。一刀一轮不是「边做边想」的偷懒，是「让执行告诉你下一步」的机制——每轮结束，你手里的不是半成品，是「一个能跑的版本 + 一组新约束 + 一条错误清单」。
下一篇：活文档——TR 文档从执行里长出来，为什么比开工前写完准？
💬 讨论区：你手工改过 AI 的输出吗？改了第几次才意识到「改结果不如改原因」？评论区聊聊你的自断后路故事。
本文基于真实项目交付经验撰写（2026-08，1 个真实交付项目与内部实战实验）。文中数据均来自实测记录，方法论部分以「已验证 / 推断待验证」标注边界。
