FDE 执行包模板
FDE 执行包不是一段“帮我做个系统”的提示词，也不是传统功能列表。它需要让 AI 全栈工程师在不猜测经营规则、不扩大权限、不虚构数据的前提下，自主完成方案、建设、测试和部署准备。
使用规则：任何未知事实都标记为“待确认”。AI 全栈工程师可以提出问题和备选方案，不能替企业决定价格、合同、财务、人员或合规规则。
0. 文档控制
| 字段 | 填写要求 |
|---|---|
| 项目名称 | 使用业务结果命名，不使用模型或框架命名 |
| 执行包版本 | 每次重大范围、规则或权限变化都升级版本 |
| FDE 负责人 | 对执行包完整性和跨团队决策负责 |
| 业务负责人 | 对目标流程、规则和经营结果负责 |
| 风险审查人 | 数据、IT、安全、法务或财务中的对应责任人 |
| 当前状态 | 草拟、业务确认、风险确认、可执行、试点、上线或停止 |
| 适用环境 | 仅演示、脱敏试点、内部生产或面向客户 |
| 待确认事项 | 不允许隐含在正文中，必须集中列出 |
1. 经营决策摘要
用一页回答经营层真正需要决定的问题。
| 问题 | 内容 |
|---|---|
| 为什么现在做 | 当前经营损失、客户影响或风险窗口 |
| 改造哪条价值流 | 起点、终点和跨越的主要角色 |
| 当前基线 | 收入、成本、周期、质量、体验或风险指标 |
| 目标变化 | 期望方向、目标区间和验证周期 |
| 首批用户 | 哪些岗位、多少人、在什么场景使用 |
| 最大风险 | 失败后对客户、资金、数据和员工的影响 |
| 需要的授权 | 数据访问、系统动作、业务时间和预算 |
| 停止条件 | 哪些证据出现时暂停或终止项目 |
2. 业务现状与证据
2.1 现状流程
记录业务对象如何从起点到终点，而不是只记录某个部门怎样操作软件。
| 步骤 | 触发事件 | 责任角色 | 使用信息 | 当前动作 | 输出状态 | 等待或返工 |
|---|---|---|---|---|---|---|
| 待填写 |
2.2 经营基线
| 指标 | 当前值 | 口径 | 来源 | 责任人 | 数据时间 | 可信度 |
|---|---|---|---|---|---|---|
| 待填写 |
2.3 样本与异常
- 正常完成的真实样本；
- 延迟、返工或失败样本；
- 高价值客户或高风险事项样本；
- 不同角色对同一事件的冲突记录；
- 系统记录与实际做法不一致的证据。
3. 问题定义与根因假设
3.1 问题陈述
使用以下结构：
当某类业务对象处于某个状态时，因为已观察到的原因，导致某个经营指标发生可量化损失。现有控制方式为什么不足，以及谁受到影响。
3.2 根因分层
| 层级 | 检查问题 | 结论 |
|---|---|---|
| 目标与指标 | 部门是否追求彼此冲突的结果？ | 待确认 |
| 流程与责任 | 是否存在无人负责的跨部门状态？ | 待确认 |
| 数据与系统 | 事实是否缺失、过期、冲突或无法访问？ | 待确认 |
| 制度与权限 | 规则是否模糊，审批是否过晚或过度？ | 待确认 |
| 人员与能力 | 是否依赖少数专家，岗位是否缺少反馈？ | 待确认 |
| AI 适配性 | 是否存在大量信息判断、生成或异常识别任务？ | 待确认 |
4. 目标人机协作流程
为每个步骤选择一种运行方式：人工完成、AI 准备人工决定、AI 执行人工抽查、规则系统执行，或保持现状。
| 目标步骤 | AI 负责 | 人负责 | 输入证据 | 输出状态 | 升级条件 |
|---|---|---|---|---|---|
| 待填写 |
4.1 不可突破的原则
- AI 不覆盖权威业务事实；
- AI 不在缺少证据时补齐客户、合同、金额或身份信息；
- 高风险动作必须由明确责任人批准；
- 所有自动动作能够追溯输入、规则、版本和结果；
- 失败时保留业务对象状态，不把技术失败伪装成业务成功。
5. 范围与边界
| 类型 | 内容 |
|---|---|
| 本阶段包含 | 明确首批角色、流程、数据、系统和动作 |
| 本阶段不包含 | 容易被误解为已承诺的相邻能力 |
| 依赖条件 | 数据、接口、账号、制度、负责人和样本 |
| 后续候选 | 验证成功后才考虑的扩展范围 |
| 禁止动作 | 不允许 AI 或系统自动执行的事项 |
6. 业务对象、状态与规则
6.1 业务对象
列出客户、商机、合同、项目、工单、员工等关键对象，以及它们必须保持一致的标识和来源。
6.2 状态
| 对象 | 当前状态 | 进入条件 | 可执行动作 | 退出条件 | 状态责任人 |
|---|---|---|---|---|---|
| 待填写 |
6.3 决策规则
| 规则编号 | 条件 | 系统建议或动作 | 必须提供的证据 | 人工审批人 | 无法判断时 |
|---|---|---|---|---|---|
| R-001 |
7. 数据、系统与权限
| 来源或系统 | 读取内容 | 写入动作 | 权威程度 | 使用角色 | 敏感级别 | 审批 |
|---|---|---|---|---|---|---|
| 待填写 |
同时说明：
- 数据保留和删除规则；
- 脱敏与最小必要范围；
- 外部模型或服务是否可接触数据；
- 身份、租户和业务对象权限；
- 写入动作的幂等、补偿和审计要求；
- 哪个系统是最终权威来源。
8. AI 全栈工程师任务书
8.1 总任务
说明要交付的业务能力、首批用户、使用场景、环境和成功证据。禁止仅描述页面或技术组件。
8.2 自主执行范围
AI 全栈工程师可以自主：
- 阅读执行包并提出缺失问题；
- 给出实现方案、任务拆分和取舍；
- 在已批准数据与系统边界内建设；
- 运行测试、修复缺陷并整理证据；
- 准备部署、监控和回滚方案。
AI 全栈工程师必须暂停并请求 FDE 决策：
- 业务规则冲突或资料不足；
- 需要扩大数据、接口或生产权限；
- 需要改变合同、价格、财务或人事事实；
- 无法满足验收条件或发现重大风险；
- 拟采用的方案会改变已批准目标流程。
8.3 阶段交付
| 阶段 | AI 全栈工程师提交 | FDE 审查 | 通过后授权 |
|---|---|---|---|
| 理解 | 问题复述、缺口和假设 | 是否误解业务 | 进入方案设计 |
| 方案 | 流程、系统边界、风险和计划 | 是否符合责任与权限 | 进入脱敏建设 |
| 验证 | 测试结果、失败样本和限制 | 是否达到试点条件 | 进入有限试点 |
| 上线准备 | 部署、监控、回滚和运营资料 | 是否可控、可追溯 | 进入生产审批 |
9. 验收用例
每类用例都必须包含真实或脱敏输入、预期状态、允许动作、禁止动作和证据。
| 类型 | 最低覆盖 | 重点检查 |
|---|---|---|
| 正常用例 | 5 条 | 主流程、结果完整性和业务价值 |
| 边界用例 | 3 条 | 信息不足、规则临界和多义情况 |
| 失败用例 | 3 条 | 系统不可用、数据冲突、权限不足 |
| 高风险用例 | 3 条 | 客户承诺、金额、合同、个人信息和生产动作 |
| 历史回归用例 | 持续增加 | 已发生错误不能再次出现 |
10. 试点、上线与回滚
| 项目 | 需要写清的内容 |
|---|---|
| 试点人群 | 角色、人数、客户范围和时间 |
| 观察窗口 | 指标需要观察多久才能有意义 |
| 灰度方式 | 只读、草稿、人工确认、有限自动执行的升级顺序 |
| 监控与告警 | 业务异常、质量、延迟、成本、权限和采用 |
| 人工接管 | 谁在什么条件下接手，获得哪些上下文 |
| 回滚条件 | 哪些指标或事件触发降级或停止 |
| 回滚动作 | 如何保留状态、通知用户并恢复原流程 |
11. 经营结果与 ROI 观察
| 类型 | 指标 | 基线 | 目标区间 | 观察周期 | 责任人 |
|---|---|---|---|---|---|
| 收入或毛利 | |||||
| 人工与系统成本 | |||||
| 流程周期 | |||||
| 质量或体验 | |||||
| 员工采用 | |||||
| 风险与接管 |
ROI 结论必须列出投入、收益假设、数据来源、观察周期和不确定性。不得把模型调用次数、生成字数或“员工感觉不错”当成经营收益。
12. 最终证据清单
- 经业务负责人确认的现状和目标流程；
- 经数据责任人确认的来源与口径；
- 经风险责任人确认的权限、审批和禁止动作；
- AI 全栈工程师的方案、测试、限制和上线资料；
- 正常、边界、失败和高风险验收记录；
- 试点使用、人工接管和员工反馈；
- 经营指标变化与 ROI 假设复核；
- 版本、重大决策、异常和回滚记录。
查看完整示范：云枢科技“商机到回款”已填写执行包，并配合阅读它的形成过程：我怎样改造商机到回款。