执行驱动交付三执行循环——为什么跑起来再设计比想清楚再做靠谱执行驱动交付EDDAI 项目交付方法论 · 3/8基于 1 个真实交付项目与内部实战实验实测2026-08 摘要EDD 的核心引擎是执行循环——一轮一刀每轮定义一个最小可运行任务MRT跑通、冒烟、修、提炼约束再切下一刀。本文讲刀口标准什么刀值得切、增量集成每轮四步、失败传播失败是业务路径不是意外、介入纪律 ABC报错强制介入/偏离按需介入/正确不介入。本文要解决的核心痛点一个大功能闷头做两周拼装时才发现接口对不上全部返工AI 跑偏了没人管报错了一股脑修改完还是错交付期为了赶进度手工改 AI 输出——这次改对了下次又错经验一点没攒本文讲执行循环一轮一刀 增量集成 介入纪律 ABC——信息只在执行中暴露跑起来才知道往哪走。场景传统开发习惯一个功能拆成模块各做各的最后联调。AI 项目里这个模式死得特别快——因为 AI 的每个环节模型理解、工具调用、知识库召回都是概率性的单块跑通 ≠ 拼起来能跑上下文在链路里丢了、接口字段对不上、顺序依赖没处理。我们踩过的典型翻车意图分类和知识库检索各自调通拼到一起检索环节拿到的是分类节点改写过的问题——字段名对不上检索结果全空。单块验证全绿拼装全红。这类错误如果等全部做完才拼装定位成本最高嫌疑对象是全部模块。执行循环的解法每一轮都切一块、拼一块、冒烟一块——接口错误在拼入的那一轮暴露嫌疑对象只有刚拼的那块定位成本最低每轮结束都有一个能跑的整体随时可以 demo。结论执行循环一轮只切一刀。每轮定义最小可运行任务MRT——范围极小、聚焦、快速闭环。下一刀取决于本轮暴露了什么不预排。跑起来再设计比想清楚再做靠谱。MRT 的定义升级过一版从「能跑」升级到「能拼」——可运行 接口明确 独立验证 语义完整。一刀不只是「跑通一件事」是「跑通一件事且能拼进整体」。推导链为什么信息只在执行中暴露三条机制1. 概率性系统的行为不可预演。模型对这句提示词会怎么理解、这个参数会不会触发工具校验、这 50 条片段召回率多少——全部只在真实执行中暴露。提前预排 MRT2/MRT3 是脑内推演你以为的下一步跑完这一步可能根本不成立。2. 试错成本要摊薄。一刀一轮 每次试错的范围极小错了改的成本最低。一个大刀切下去错了都不知道错在哪块。3. 每轮有可运行整体 受控实验。客户随时能看 demo每一轮的反馈都真实——不是文档评审的「差不多吧」是看到能跑的东西之后的真反应。实践动作执行循环的纪律四条执行循环纪律四条纪律内容① 一轮只切一刀MRT 范围极小、快速闭环下一刀取决于本轮暴露了什么不预排② 介入纪律 ABCA·报错时 → 强制介入纠正评估标准重跑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-081 个真实交付项目与内部实战实验。文中数据均来自实测记录方法论部分以「已验证 / 推断待验证」标注边界。 执行驱动交付（三）：执行循环——为什么跑起来再设计，比想清楚再做靠谱？
执行驱动交付三执行循环——为什么跑起来再设计比想清楚再做靠谱执行驱动交付EDDAI 项目交付方法论 · 3/8基于 1 个真实交付项目与内部实战实验实测2026-08 摘要EDD 的核心引擎是执行循环——一轮一刀每轮定义一个最小可运行任务MRT跑通、冒烟、修、提炼约束再切下一刀。本文讲刀口标准什么刀值得切、增量集成每轮四步、失败传播失败是业务路径不是意外、介入纪律 ABC报错强制介入/偏离按需介入/正确不介入。本文要解决的核心痛点一个大功能闷头做两周拼装时才发现接口对不上全部返工AI 跑偏了没人管报错了一股脑修改完还是错交付期为了赶进度手工改 AI 输出——这次改对了下次又错经验一点没攒本文讲执行循环一轮一刀 增量集成 介入纪律 ABC——信息只在执行中暴露跑起来才知道往哪走。场景传统开发习惯一个功能拆成模块各做各的最后联调。AI 项目里这个模式死得特别快——因为 AI 的每个环节模型理解、工具调用、知识库召回都是概率性的单块跑通 ≠ 拼起来能跑上下文在链路里丢了、接口字段对不上、顺序依赖没处理。我们踩过的典型翻车意图分类和知识库检索各自调通拼到一起检索环节拿到的是分类节点改写过的问题——字段名对不上检索结果全空。单块验证全绿拼装全红。这类错误如果等全部做完才拼装定位成本最高嫌疑对象是全部模块。执行循环的解法每一轮都切一块、拼一块、冒烟一块——接口错误在拼入的那一轮暴露嫌疑对象只有刚拼的那块定位成本最低每轮结束都有一个能跑的整体随时可以 demo。结论执行循环一轮只切一刀。每轮定义最小可运行任务MRT——范围极小、聚焦、快速闭环。下一刀取决于本轮暴露了什么不预排。跑起来再设计比想清楚再做靠谱。MRT 的定义升级过一版从「能跑」升级到「能拼」——可运行 接口明确 独立验证 语义完整。一刀不只是「跑通一件事」是「跑通一件事且能拼进整体」。推导链为什么信息只在执行中暴露三条机制1. 概率性系统的行为不可预演。模型对这句提示词会怎么理解、这个参数会不会触发工具校验、这 50 条片段召回率多少——全部只在真实执行中暴露。提前预排 MRT2/MRT3 是脑内推演你以为的下一步跑完这一步可能根本不成立。2. 试错成本要摊薄。一刀一轮 每次试错的范围极小错了改的成本最低。一个大刀切下去错了都不知道错在哪块。3. 每轮有可运行整体 受控实验。客户随时能看 demo每一轮的反馈都真实——不是文档评审的「差不多吧」是看到能跑的东西之后的真反应。实践动作执行循环的纪律四条执行循环纪律四条纪律内容① 一轮只切一刀MRT 范围极小、快速闭环下一刀取决于本轮暴露了什么不预排② 介入纪律 ABCA·报错时 → 强制介入纠正评估标准重跑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-081 个真实交付项目与内部实战实验。文中数据均来自实测记录方法论部分以「已验证 / 推断待验证」标注边界。