执行驱动交付零为什么先设计后开发AI 项目总是翻车执行驱动交付EDDAI 项目交付方法论 · 系列总论 0/8基于 1 个真实交付项目与内部实战实验实测2026-08 摘要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 熔断四字段loopAgent 在循环中持续执行人在回路介入同构但在「单人交付 资产沉淀」这个细分维度上更深——后面七篇讲的就是深度。全链总览EDD 的完整时间轴EDD 的完整流程一张图看全细节逐篇展开每轮回填约束每轮生成 DSL 的依据TR0 边界卡半天TR1 选型实验执行循环 × N 轮TR3 自验证TR4 验收双面闸TR2 约束真相源活文档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-081 个真实交付项目与内部实战实验。文中数据均来自实测记录方法论部分以「已验证 / 推断待验证」标注边界。应用设计层面的理论四个约束维度、七条定理见同专栏《从踩坑到定理》系列。