执行驱动交付（零）：为什么先设计后开发，AI 项目总是翻车？
执行驱动交付（EDD）：AI 项目交付方法论 · 系列总论 0/8
📖 摘要：AI 项目不能照搬传统软件的「先设计后开发」——需求是流动的、文档是脑内推演、经验不沉淀。本文提出执行驱动交付（EDD）：拿客户需求做受控实验，每单同时产出客户要的成果和我们可复用的资产；开工前只写两样东西，其余文档全部从执行里长出来。
📌 本文要解决的核心痛点
- 需求访谈做了两周，流程图画了十几张，上线第一天被一句口语化提问击穿？
- 文档写了一堆，开发时没人看，验收时对不上？
- 项目做完就完，做下一单还是从零开始，经验一点没攒下？
- 本文用「执行驱动交付（EDD）」重新定义 AI 项目的交付流程——先跑起来，用执行结果驱动下一轮设计。
场景
接一个「企业知识库问答助手」的需求。客户说：把你们的产品手册喂给 AI，让值班的人直接问。
按传统软件的做法，第一步是需求调研：访谈、写需求规格书、画流程图、评审、冻结需求。两周后拿着四十页文档跟客户对，客户说「差不多吧」，然后开发。上线第一天，值班的人问了一句：「昨天那个告警，现在还能看吗？」——系统答非所问。翻回需求文档，里面确实没写「时间相关的追问」——但客户觉得这不用写，这是常识。
问题不在文档漏了这条。问题在：AI 项目的需求，根本不可能在开工前被穷举完。传统软件是确定性系统，需求可预先枚举；AI 是概率性系统——模型理解、工具调用、知识库召回，只在真实执行中暴露。前期花两周画出的完美流程图，可能上线第一天被一句口语化提问击穿。
结论
AI 项目交付不能用「先设计后开发」，要用执行驱动交付（EDD）——拿客户需求做受控实验，每次交付同时产出两样东西：客户要的成果，和我们可复用的资产。
EDD 的英文是 Execution-Driven Delivery，核心就一句话：先跑起来，用执行结果驱动下一轮设计。它有三个支柱：
文档后置——开工前只写两样（一页边界卡 + 一张字段表骨架），其余全部文档从执行产物里长出来
受控实验——每一轮都是一个小实验，范围极小、快速闭环；实验发生在不损害客户利益的范围内
资产复利——每一单结束，客户拿走应用，我们拿走复用资产；每一单都在让下一单更便宜
这套方法不是「敏捷开发的变体」。敏捷仍然是「先有完整设计、再增量实现」；EDD 是承认「AI 项目的设计在开工时根本写不出来」——设计不是前置的输入，是执行的回填。
EDD 这个名字：一次缩写说明
先消除一个可能的误会：EDD 在本文指 Execution-Driven Delivery（执行驱动交付）——拿客户需求做受控实验，从执行里长文档、长约束、长资产。
业界（尤其是 Agent 工程社区）近年常用 EDD 指 Evaluation-Driven Development（评测驱动开发）——用评测集作为 Agent 的可执行行为规格，通过持续收集 badcase、自动诊断、回归验证，推动 Agent 在受控边界内演进。两个 EDD 不冲突，是互补的两层：
评测驱动管的是「用评测集驱动 Agent 行为迭代」——这是 Agent 内部的质量循环
执行驱动管的是「拿客户需求做受控实验、从执行里长文档」——这是项目交付的顶层哲学
本体系把评测驱动作为 TR3 自验证的核心机制吸收进来（第四篇展开）：评测集从执行循环的错误清单里「长出来」，硬断言（Tests）与软断言（Evaluations）分层，黄金集作为跨客户复用的回归基线。
如果你熟悉业界常见的 Agent 交付框架 spec → harness → loop（人定规格 → 构建约束与验证封装 → Agent 在循环中持续执行），本体系的对应关系是：
| 本体系 | 业界坐标（spec→harness→loop） | 对应内容 |
|---|---|---|
| TR0 边界卡 + 可断言成功标准 + 终态画面 | spec | 人定规格：意图、边界、验收标准 |
| TR2 约束真相源 + TR3 评测集 + 黄金集 + 错误清单 | harness | 约束与验证的封装：测试套件、断言、回归门禁 |
| 执行循环 + 介入纪律 ABC + 熔断四字段 | loop | Agent 在循环中持续执行，人在回路介入 |
同构，但在「单人交付 + 资产沉淀」这个细分维度上更深——后面七篇讲的就是深度。
全链总览：EDD 的完整时间轴
EDD 的完整流程，一张图看全（细节逐篇展开）：
TR0/TR1 是一次性的门；中间是迭代段（执行循环 + TR2 活文档交织）；TR3/TR4 是收尾的两个正式关卡。闭环一句话：经验 → TR → DSL → 执行 → 经验。
推导链：为什么前期大设计在 AI 项目上失效
三个机制，逐层推：
1. 需求是流动的，不是冻结的。 客户回答不了「你要什么功能」这种开放问题——他脑内没有完整画面，问出来的需求是零散的碎片；但客户对「某个具体画面」一定有反应：同意、否定、修正。需求不是被问出来的，是被样板激发出来的。所以需求不用穷举（客户说不清），痛点要穷举（客户说得清），边界要穷举（防越界）。
2. 文档是脑内推演，不是事实。 开工前写完四十页设计文档，每一页都是「我猜客户会这样用」。同样篇幅的文档，从脑子里长出来的（推演）和从执行里长出来的（固化），准确率和复用价值差一个量级。AI 项目的坑（模型抽风、召回失败、工具调用错参数）全部在真实执行中暴露，不写代码不跑通就永远猜不到。
3. 经验不沉淀，做 100 单和做 1 单一样。 传统交付项目结束就结束了——客户拿走代码，团队拿走的只有一笔钱。下一单遇到同类需求，还是从零开始。变强的不是模型（LLM 权重是固定的），是资产库：skill、黄金集、知识库、执行器、配重表。沉淀率是 0%，做 100 个项目就和做 1 个一样——项目是本金，沉淀是利率。
正例实证：从「先跑起来」开始的交付
我们交付一个网络设备故障诊断助手（产品手册 4277 页 → 企微机器人），没有走「先设计后开发」。第一天只做了一件事：切第一刀——把「手册能不能被检索到」跑通。用 50 条手册片段建了个小知识库，拿三个客户真实问题测召回：命中，继续；不命中，先不往下做。
第一刀跑通后，才定义第二刀：意图分类——「问故障」和「问配置」分开走。第三刀：回答链路。每一刀都在上一刀跑通的基础上切，每一轮结束都有一个能跑的整体（随时可以 demo 给客户看）。最终三库三分流、检索调优、回答分流，全部是从执行里长出来的——没有一个设计是开工前拍脑袋定的。
这个项目最值钱的产出不是应用本身，而是过程中沉淀的：检索调优的实测结论（top_k 从 4 调到 8 显著提升带图段命中率）、意图分类的兜底模式、企微接入的部署包——这些直接让下一单的成本下降了一个台阶。
反例实证：四十页文档的翻车现场
同一个需求，我们见过另一种走法（也踩过）：两周需求调研 + 四十页规格书 + 评审通过，开工。规格书里定义了二十多个功能点，第一版做出来，客户验收时发现——「这个按钮我不需要」「这个报表格式不对」「我没说要按部门分」。
四十页文档没有一个字是错的，但它是脑内推演的结果：客户说「要报表」，文档写了「按部门分组报表」，客户当时没反对，因为他也想象不出报表长什么样。真做出来才反应过来。需求规格书越厚，冻结的脑补越多——这不是文档质量问题，是方法问题。
EDD 的解法：不写功能清单，写痛点地图和边界清单。「烦什么」客户说得清，「要什么功能」客户说不清——从痛点反推方案，方案由执行验证，不验证的脑补不允许进文档。
实践动作：开工前只写两样
开工前只写两样（其余全部从执行里长出来）：
| 类别 | 管什么 | 内容 |
|---|---|---|
| 边界卡（半页~一页） | 不能做什么 | 痛点清单（带下刀点）/ 边界清单（带来源）/ 成功标准（可断言）/ 第一刀 MRT1 / 档位 |
| 真相源骨架（一张字段表） | 生成时用什么 | 变量名 / 字段名 / Mock Schema |
| 从执行里长出来的（不前置写） | — | TR2 约束内容 / TR3 用例 / TR4 报告 |
一句话判断标准：开工前要写的文档，只有「第一轮执行必须用到的东西」——边界卡定方向，字段表定数据形状。写不出来的，跑出来再写。
边界与版本
EDD 适用的边界，诚实划一下：
适合：AI 应用交付（知识库问答/智能体/自动化流程）、一人公司或小团队、需求边界模糊的项目
不完全适合：传统确定性软件（需求可穷举时，先设计后开发的效率更高）；合规要求强制前置设计文档的场景（流程照走，但设计内容仍建议从原型实验里长出来）
需要客户配合：EDD 要求客户参与「边界拍板」和「成功标准确认」——客户完全甩手（「你看着办」）的项目，EDD 会退化成自由发挥，建议换成更小的第一刀
本文方法论的验证记录：1 个真实交付项目 + 内部实战实验；部分推论（如配重校准、资产账本）标注「待验证」——方法骨架跨平台成立，具体参数以你的项目为准
收尾
传统交付问「需求是什么」，EDD 问「痛点是什么、第一刀切哪」。前者把项目当文档问题，后者把项目当实验问题——AI 项目是后者。
下一篇，从杠杆最高的环节开始：TR0 边界卡——为什么开工前只花半天、只写一页纸，比两周需求调研更可靠。
💬 讨论区：你经历过「先设计后开发」在 AI 项目上翻车吗？最痛的一次是什么——需求冻结后改不动，还是文档写完没人看？评论区聊聊你的交付现场。
本文基于真实项目交付经验撰写（2026-08，1 个真实交付项目与内部实战实验）。文中数据均来自实测记录，方法论部分以「已验证 / 推断待验证」标注边界。应用设计层面的理论（四个约束维度、七条定理）见同专栏《从踩坑到定理》系列。
