FDE 交付操盘系统

交付现场反复出现的四类失败

FDE（Forward Deployed Engineering）项目很少死于模型能力不足。更常见的是：销售带回一个模糊需求，团队直接进入写代码阶段；工作流只按官方文档理解，没人记录现实中的脏活、断点和交接失败；AI 介入点选得太宽，上线后靠英雄主义维持；试点结束被当成上线批准，缺少验收合同与回退路径。

这些问题的共同点是：没有一个可审计的操作回路。@user_ee2f9a3e/fde-os 把交付拆成可判定的阶段，让每一步都有明确的进入证据、必须产出的工件和失败信号。

它如何组织交付

这个技能先做请求路由：先判断你当前处于哪类请求（机会评估、真实工作流采集、试点设计、生产就绪、还是多阶段操盘），再加载最轻量的方法。

它用七个阶段串行推进工作：

• 阶段 1：任务资格判定 — 明确谁负责结果、可观察指标是什么、哪些约束可能导致 no-go
• 阶段 2：运营现实采集 — 重建真实工作流，包括影子流程、脏案例、人工步骤和交接失败
• 阶段 3：系统框架定义 — 划定系统边界，识别当前真正的瓶颈（感知、解读、路由、执行、验证还是治理）
• 阶段 4：状态-动作-证据模型 — 把业务对象转成可运行的控制模型，定义状态迁移、权限与回退规则
• 阶段 5：干预与试点设计 — 选择最小的 AI 介入面，设计评估集、验收标准和回退条件
• 阶段 6：交付架构 — 定义读写集成、遥测、事故响应、隔离边界和运营计划
• 阶段 7：扩展逻辑 — 判断该回路是否值得复用，以及先硬化哪些平台能力

每个阶段都有对应的模板工件（如 mission-brief.md、operational-reality-map.md、poc-acceptance-contract.md），并明确退出闸门。

同时，四条并行控制回路防止局部进展掩盖全局失败：客户价值、系统质量、生产可靠性、产品学习。五个闸门（G0–G4）要求每个决策都显式给出 go、conditional-go 或 no-go，并附带证据要求。

适用边界与注意点

这个技能不是用来替代实现工作的。纯编码任务、厂商对比、无上下文的行业研究会被路由到别处。它的价值在于先判定再设计：如果你连谁是结果负责人都说不清楚，它不会帮你写出一个看起来漂亮的方案。

首次运行时，技能要求选择一个操盘人、一个业务对象、一个触发条件和一个输出，在证据还薄弱时停在交付架构之前。这种保守策略是刻意的——过早进入生产部署是最常见的失败模式。

机器可读的工件与闸门定义在 contracts/artifacts.json 中，可作为团队内部对齐的单一事实来源。