执行驱动交付四活文档——为什么 TR 文档从执行里长出来比开工前写完准执行驱动交付EDDAI 项目交付方法论 · 4/8基于 1 个真实交付项目与内部实战实验实测2026-08 摘要EDD 把 TR 文档从「评审关卡」改成「活文档 执行产物固化」——四个活文档贯穿全程边界卡不能做什么、TR2 约束真相源生成时用什么、跑通记录执行时的账、TR3 用例集执行后的账。核心机制骨架前置 内容后置——字段表开工前建好生成要用约束内容从执行里长出来推演写不准。本文要解决的核心痛点开工前写完的设计文档开发时没人看验收时对不上字段名每轮生成都改一遍DSL 导入一次错一次用例集基线化前没确认验收时测试漂移谁改的都不知道本文讲四个活文档 TR2 真相源 TR3 自验证闭环——文档从执行里长出来而不是开工前拍脑袋。场景传统项目的文档是「评审关卡」开工前写设计文档评审通过开发照做。AI 项目里这套有两个死穴第一开工前写不完。字段名、接口形状、约束规则——这些只有跑起来才知道。开工前写完的「详细设计」一半是脑内推演写的时候信誓旦旦跑起来全对不上。第二评审通过 ≠ 文档有效。评审时看的是「文档写得好不好」不是「文档和现实对不对得上」。AI 项目的现实在变模型行为、平台行为、客户反馈静态文档跟不上的速度。我们踩过的典型TR2 字段表里写了item_count执行循环生成 DSL 时用的却是total_count——字段漂移。DSL 导入一次错一次查半天才发现是文档和代码各说各话。文档不是写出来的是养出来的。结论TR 文档从执行里长出来不是开工前写出来——四个活文档贯穿全程边界卡管「不能做什么」TR2 约束真相源管「生成时用什么」跑通记录管「执行时的账」TR3 用例集管「执行后的账」。骨架前置内容后置。活文档作用更新规则边界卡管「不能做什么」TR0 初始定稿执行中增量追加走证据门槛TR2 约束真相源管「生成时用什么」骨架前置固定内容随执行固化变更走机制跑通记录执行时的账每轮执行累积TR3 用例集执行后的账随错误清单累积基线化后严格执行推导链为什么「骨架前置 内容后置」是唯一正确的分工骨架必须前置——因为第一轮执行就要用。字段表变量名/字段名/Mock Schema是第一轮生成 DSL 的输入不可能等执行完再补。骨架建好即固定防字段漂移。内容必须后置——因为内容写不准。TR2 的约束规则「这个场景这个客户」的约束只有执行循环每轮回填才准——跑通记录里「留下了什么约束」是内容主源。经验再好也给不出「这个客户这个场景」的约束。TR2 的内容来源三分骨架字段表——经验定TR1 选型 平台层经验 边界卡。经验决定骨架长什么样内容约束规则——执行定执行循环每轮回填带来源标注客户/实测/推测待验证。凭经验写 脑内推演 文档后置要戒掉的动作字段准确值——实测定平台字段名/参数名以实测为准查源码优先经验给方向实测定准确值一句话TR2 经验开个头骨架 执行喂大内容 实测校准字段。正例实证字段表前置一次生成通过网络设备故障诊断助手第一轮执行前 TR2 骨架就建好了意图分类的输出字段intent 枚举值、检索节点的入参query/top_k/score_threshold、回答链路的出参answer/source_chapter。骨架固定后每一轮生成 DSL 都用同一份字段表——字段漂移一次没发生过。内容怎么长的执行循环里发现「口语问法『认证』命中不了『验证』」——这条约束回填 TR2检索词需要归一化处理带来源标注「实测」。这个约束是开工前不可能写出来的它是执行暴露的。反例实证字段漂移与脑内推演文档反例 1字段漂移。内部实验项目TR2 骨架没在建好时固定——执行中想改就改。三轮之后文档里的字段名和已生成的 DSL 对不上了第四轮生成直接导入失败排查花了半天。修复TR2 加变更记录改字段 记录原因 影响范围 是否影响已生成 DSL版本可逆谁改的、为什么改、影响哪全链条可查。反例 2脑内推演的 TR2。另一个实验TR2 内容不是从跑通记录提炼的是开工前「参考别的项目」写的。跑起来发现客户的实际字段格式和 TR2 写的不一样——文档是抄来的约束是猜的。废掉重写从跑通记录重新提炼。参考别的项目 内容搬移跑通记录提炼 约束固化。前者是脑内推演后者才是真相源。实践动作TR3 自验证闭环用例从错误清单长出来TR3 是开发阶段的自验证不是验收验收是 TR4。用例三个来源通道用例来源三通道 ① 错误清单 → 回归用例修过几个错就有几条 ② 成功标准 → 端到端用例每条成功标准至少一条 ③ 边界禁区 → 负向用例测 AI 不会越界三个通道汇成一条自验证闭环是否执行中出错的 badcase写入错误清单生成回归用例修过几个错就有几条跑用例回归验证通过进入黄金集回归基线修复后重跑后续每轮变更后回归TR3 与业界评测驱动开发Evaluation-Driven Development同源——评测集Eval dataset本质是 Agent 的可执行行为规格持续收集 badcase、自动诊断、回归验证推动 Agent 在受控边界内演进。本体系的对应关系是硬断言 Tests确定性断言pass/fail字段一致性、禁区触发、工具调用顺序软断言 Evaluations概率性评估score over dataset语义相似度、关键信息覆盖率黄金集 Eval dataset带 Source 标注的回归基线跨客户复用前跑回归100% 通过才交付差异化在于评测集从执行循环的错误清单里「长出来」不是开工前预设——修过几个错就有几条回归用例评测集随项目生长天然覆盖真实踩坑。硬断言 / 软断言分层硬断言规则校验机器可执行字段名与 TR2 一致性、禁区触发、工具调用顺序。示例contains_key(order_id)/len(tool_calls)3/text!——通过率不达标不进 TR4软断言语义质量语义相似度 0.9、关键信息覆盖率 100%风险优先级用例不平均用力先覆盖会造成损失的场景越权/错数据/重复扣费/错误发送/错误删除/错误审批归因三分TR3 发现问题先归因再动手应用缺陷 → 修应用改工作流/提示词不反馈 TR2约束缺陷 → 反馈 TR2 更新约束 → 重新生成 DSL → 重跑边界缺陷 → 更新边界卡 → 可能联动 TR2 → 重跑用例缺陷 → 只修用例标识不修改应用基线后环境问题 → 排除后重跑。基线化纪律用例集全部输出 → 人确认基线化 → 严格执行中途不改用例防测试漂移。基线后用例缺陷只标识不修改应用——把用例缺陷当应用缺陷修是验收里最常见的自欺应用本来是对的因为用例断言错了报 FAIL然后团队去「修应用」越修越错。边界与版本冒烟 vs TR3冒烟是每轮的小测验这轮算没算完成TR3 是收敛后的期末大考正式验证——生成/导入/冒烟属于执行循环TR3 验证的是导入后的应用档位差异一档 TR2 极简一页字段表可和跑通记录合一、TR3 10-20 条用例三档完整13 节 变更记录 边界对照表 全量双层用例黄金集从 TR3 用例挑 10-20 条核心集带 Source 标注作跨客户复用前的回归门槛100% 通过才交付新客户——第七篇展开TR2 是纯文档环节零执行动作不依赖环境它的消费方是执行循环的 DSL 生成收尾活文档的实质文档的职责从「评审关卡」变成「执行产物的固化」。评审关卡问「文档写得好不好」活文档问「文档和现实对不对得上」——后者才是 AI 项目里文档唯一有用的形态。骨架前置保证能用内容后置保证准变更机制保证可追溯。下一篇执行驱动交付五错误放大坑——为什么一条推测会变成毒资产 更多实战记录见我的博客鱼日先生讨论区你遇到过字段漂移吗文档和代码各说各话排查半天才发现你的项目里文档是「评审关卡」还是「活文档」评论区聊聊。如果觉得有收获欢迎点赞 收藏 关注这是激励我更新这个系列的最大动力。本文基于真实项目交付经验撰写2026-081 个真实交付项目与内部实战实验。文中数据均来自实测记录方法论部分以「已验证 / 推断待验证」标注边界。