THESIS / 核心主张
代码合并只是中间状态；真正完成需要让下一位工程师和未来的 AI 都能理解、验证和安全修改。
OPERATING STEPS / 执行动作
把原则变成可以检查的动作。
- 列出必须交付的系统、文档与证据
- 链接规格、代码、测试和运行结果
- 明确已完成、限制和下一步
- 复盘后更新规则、模板和缺陷库
OUTPUTS / 交付物
每个阶段都要留下可复用的产物。
APPLIED CASE / 项目映射
这条方法如何落到真实项目？
GMV 交付包至少应包含历史链路地图、九平台实现、统一入口说明、测试、同范围对账和规则治理手册。
FULL CHAPTER / 完整正文
从结论摘要，继续读到判断依据和执行细节。
正文保留 site-v3 的完整论证结构，并将贯穿示例改写为生态店铺 GMV 清洗迁移；原作者身份、原演示案例和未经证实的个人成果不进入本站。
交付物标准：一次合格的交付包含什么
"完成"必须被定义成一张可逐项验收的清单，否则它就是一句自我感觉。这张清单也是整套方法论"可复刻"的最终形态——照单交付，就是在执行这套方法。
一、由果倒推："交付完成"意味着三件事成立
一个用 AI 交付的系统，什么状态才算"真正交付"？倒推三个必须成立的性质：
- 能运行——安全、可靠、可用：行为符合规格、边界未被穿透、故障可恢复；
- 能迭代——下一个需求进来，规则、规格、缺陷库这些资产让它比上一个更快、更稳，而不是从零再猜一遍；
- 能自答——业务问"能不能做"、运维查"哪里坏了"，不依赖翻代码和特定的人（见运行与解答）。
传统 DoD（Definition of Done）只覆盖第一条。AI 时代恰恰相反：第一条是 AI 最擅长的，后两条才是拉开差距的地方——它们决定了交付速度是一次性的，还是复利的。
二、交付物清单
三组交付物，分别支撑上面三个性质。每项标注格式、消费者和验收标准：
A · 运行组（支撑"能运行"）
| 交付物 | 格式 | 消费者 | 验收标准 |
|---|---|---|---|
| 代码 | 按项目规范 | 人 + CI | 四道验证闸门通过（验证闭环） |
| 测试 | 与实现分单产出 | CI | 逐条对应 EARS 规则；失败路径先红后绿；关键路径变异抽查 |
| 迁移脚本 | 版本化 SQL/脚本 | CI + DBA | 可正向执行、有回滚方案 |
| 监控与告警配置 | 代码化配置 | 运维 + 排障 Agent | 关键指标可查（吞吐/延迟/失败数/业务键）；告警有 runbook 指向 |
B · 知识组（支撑"能自答"）
| 交付物 | 格式 | 消费者 | 验收标准 |
|---|---|---|---|
| 行为规格 | EARS 规则文件 | 人 + AI + 测试 | 与实现一致（契约测试对齐） |
| 接口目录 | 结构化条目：参数/错误码/权限/幂等语义 | 业务 + AI | AI 仅凭目录能正确回答接口咨询 |
| 流程图 | Mermaid，与代码同库 | 人 + AI | 覆盖本次变更的核心链路；与代码无漂移 |
| ADR | 决策 + 理由 + 被否方案 | 人 + AI | 本次全部结构决策有记录 |
| 数据字典 | 表/字段/约束/敏感级别 | 人 + AI | 与迁移脚本同步更新 |
| 变更说明 | 面向下游的影响面描述 | 下游团队 | 基于调用链分析，非人肉记忆 |
C · 资产组（支撑"能迭代"）
| 交付物 | 格式 | 消费者 | 验收标准 |
|---|---|---|---|
| 规则文件更新 | CLAUDE.md / rules diff | 下次任务的 AI | 本次暴露的新约束已沉淀 |
| 缺陷库条目 | 模式 + 根源 + 验证方式 | 体检/工作单/review | 本次逃逸到验证层的缺陷已归纳（入库门槛） |
| 工作单归档 | 任务卡 + 汇报 | 复盘 + 审计 | 「需要人工确认」事项全部闭环 |
| 复盘记录 | 如果重来会改什么 | 团队 | 至少一条流程改进落到规则或模板 |
C 组是最容易被省略、也最能区分两类工程师的一组：A、B 组交付这个系统，C 组让下一个系统更快——这正是认知篇里"组织资产"分水岭的落地形态。
三、为什么这张清单是行业无关的
注意：上面三张表里没有出现任何领域词汇。拿两个截然不同的系统对照：
| 交付物 | 数据同步平台 | 智能仓储 WMS 调度 |
|---|---|---|
| 行为规格 | 五条同步语义不变量（可恢复/幂等/…） | 排波规则、库存扣减语义、波次状态机 |
| 接口目录 | 任务创建/启停/位点查询接口 | 波次创建/拣选任务分配/回传接口 |
| 流程图 | CDC 事件流转链路 | 订单 → 波次 → 拣选 → 复核 → 发运链路 |
| ADR | 至少一次 + 目标端幂等的取舍 | 排波策略可插拔、库存预占的取舍 |
| 缺陷库 | 位点提交顺序、重复消费模式 | 超卖、重复分配、状态机跳转模式 |
结构完全相同，内容完全不同。 方法论规定结构，领域知识填充内容——这就是"换一个行业照样复用"的机制保证。清单本身可以直接抄走用在任何系统上，这也是本站总规程可以直接喂给 AI 的原因。
四、按任务分级裁剪
全量清单对应 L 级任务。照搬到改文案上是形式主义，按任务分级裁剪：
| 级别 | 运行组 | 知识组 | 资产组 |
|---|---|---|---|
| S | 代码 + 回归 | 无 | 无 |
| M | 代码 + 测试 | 受影响的接口目录/规格条目更新 | 有新模式则入缺陷库 |
| L | 全量 | 全量 | 全量 |
判据不变：交付物的完整度和缺陷逃逸代价成正比。
五、怎么验收
- 能自动的进 CI：契约测试（接口目录对齐）、ArchUnit（边界）、迁移可执行性、测试门禁——机器拦截，不看自觉；
- 不能自动的进交付评审：对着清单逐项过，缺项要么补齐、要么显式记录"本次豁免及理由"——允许豁免，不允许沉默跳过；
- 清单本身进入 Agent 工作单的【输出要求】，让 AI 在交付时就按此结构汇报，而不是人在验收时倒推。
六、本章小结
- "完成" = 能运行 + 能迭代 + 能自答；传统 DoD 只覆盖第一条，而后两条才是 AI 时代交付速度从一次性变成复利的关键。
- 三组交付物：运行组（代码/测试/迁移/监控）、知识组（规格/接口目录/流程图/ADR/数据字典/变更说明）、资产组（规则/缺陷库/归档/复盘）。
- 清单不含领域词：结构行业无关，内容由领域填充——这是方法论可复用的机制保证。
- 按 S/M/L 裁剪；能自动的进 CI，不能自动的进评审；允许豁免，不允许沉默跳过。
下一章 实证案例，看这套标准在真实系统交付中的完整运转。