4.12 我怎样组装一份完整执行包
到这一篇，我手里已经有很多材料：订单样本、业务任务书、使用状态、数据权限、验收情境、恢复方案、自主授权、交付证据和上线计划。
第一次整理时，我只是把文件放进同一个目录。工程师仍然不知道哪个版本生效，业务负责人也找不到项目目标和验收之间的关系。
材料放在一起，不等于形成执行包。
我先找到贯穿全部材料的同一条主线
我用一句话重新检查整份执行包：
在方案发给客户以前，帮助销售发现客户需求、产品能力和合同承诺之间的差异，把需要决定的例外交给负责人，减少签约后的返工、延期和回款损失。
接着我逐项追问：
- 现状证据是否证明这件事真的发生；
- 目标流程是否改变这个断点；
- 工程任务是否只做范围内的部分；
- 数据和权限是否支持目标流程；
- 验收情境是否覆盖最贵和最危险的错误；
- 上线指标是否能看见经营结果。
任何一部分如果不能回到这条主线，就要删除、改写或单独说明。
执行包按决定顺序组织
我不按“业务文档、技术文档、测试文档”分类，而是按团队作出决定的顺序组织。
1. 为什么改变
经营问题、真实样本、基线、损失和目标结果。读完这一部分，经营层知道为什么值得投入。
2. 现在怎样工作
当前流程、事实来源、交接断点、岗位责任和仍未确认的问题。它防止团队把想象当现状。
3. 未来怎样工作
目标状态、人机分工、触发器、状态、等待、异常和责任迁移。业务人员能够据此复述未来工作。
4. 第一版交付什么
首批用户、范围、不做事项、数据、系统、权限和工程任务。工程师知道可以选择什么实现办法，不能越过什么边界。
5. 什么叫做成
验收情境、质量速度成本、禁止结果、故障恢复和自主级别。团队不会用功能演示代替完成。
6. 怎样上线和继续运行
试点批次、停止条件、支持分工、运行指标、版本、供应商依赖和内部接手。
未决问题必须留在包里
项目进行中一定有不知道的事情。
客户资料能否稳定取得、某类合同由谁最终确认、成本会不会随订单量快速上升，都可能暂时没有答案。
我为未决问题写清当前事实、影响、需要谁决定、下一步证据和最晚复核时间。在答案出来以前，相关范围保持受限。
把问题写成“待确认”不丢人。把问题藏在聊天里，最后让工程师默认处理，才危险。
每个版本都说明为什么变化
执行包不是项目开始时一次写完的需求文档。
试点发现新断点、业务负责人改变规则、数据来源变化、验收失败，都会让内容更新。
每次重大变化记录：
- 改了什么；
- 为什么改；
- 谁确认；
- 影响哪些任务、权限、情境和用户；
- 是否需要重新验收；
- 旧版本怎样保留。
这样三个月后团队仍能解释系统为什么变成现在这样。
我让三种人分别复述
执行包完成前，我安排一次评审。
业务负责人只看执行包，讲清公司为什么做、员工未来怎样工作、什么结果值得继续。AI 全栈工程师讲清第一版建设什么、依赖哪些资料、怎样处理失败和证明完成。风险岗位讲清哪些动作受限、什么情况必须停止。
如果三个人讲的是三个不同项目，文件再完整也不能开工。
复述中出现的差异直接回到对应章节修改，而不是在会议纪要里另写一套解释。
我怎样判断执行包已经可以交付
我使用六个问题：
- 一个没参加诊断的工程师能否复述经营问题；
- 一个没参加设计的业务人员能否走完未来流程；
- 每项重要事实能否找到来源和确认人；
- 资料缺失、冲突、越权和系统失败时是否知道怎样停下；
- 验收能否用真实订单完成；
- 内部团队能否在 FDE 离开后运行、修改和复盘。
只要有一个问题只能靠“到时候再沟通”回答，执行包还没有完成。
执行包也会成为运行手册
交付结束后，经营问题、权限、验收、事故和版本不会消失。
内部团队会继续使用执行包判断新需求是否在范围内、规则变化要重测什么、事故影响哪些结果、供应商替换需要保留什么。
所以我不会在上线后把它归档成项目材料。它会跟着真实运行继续更新。
执行包 1.0 最终装入了什么
| 部分 | 已填写证据 | 下一位使用者据此作什么决定 |
|---|---|---|
| 文档控制 | 版本、授权、当前未决和下一阶段条件 | 团队知道哪一版生效、当前能做到哪里 |
| 经营问题 | 基线、十二笔诊断样本、三个竞争解释 | 经营层判断为何值得投入 |
| 目标工作 | 人机协作、状态、决定规则和恢复 | 业务人员复述未来订单怎样走 |
| 工程任务 | 九名首批用户、包含与禁止、依赖和升级事项 | 工程师选择实现但不越过边界 |
| 数据权限 | 五处来源、权威事实、独立身份和故障表现 | 数据与风险岗位确认用途和最小权限 |
| 完成标准 | 十二类验收、质量等待成本、禁止结果 | 三方决定通过、限制通过或不通过 |
| 试点运行 | 分阶段自主、停止、恢复、采用和支持 | 价值流负责人决定扩大、保持、缩小或停止 |
| 长期掌握 | 版本、事故、可替换资产和内部接手 | 公司以后能修改、重测和更换工具 |
完整填写版本是 云枢科技商机到回款 FDE 执行包，不是空白模板。它保留 YS-24-017 的失败、YS-24-009 的反例、YS-24-028 的过度归因边界，也把 YS-P-001 的主体冲突、特殊折扣、资料缺失和故障分支映射到验收与恢复。
当前结论仍是“适用于脱敏历史验证和有限只读试点”。正式写入、对客发送和财务动作没有因为执行包完成而自动获得授权；三项未决问题也继续留在首页。
第 4 卷到这里把一张目标蓝图翻译成了可建设、可验收、可停止的交付契约。下一卷不重复做十一份执行包，而是沿不同价值流各选一笔典型事件，判断哪些能力可以复用、哪些商业逻辑必须重新设计：端到端价值流改造。