FDE Delivery Loop

把客户现场的模糊诉求，变成能验证、能采用、能复用的交付闭环。

FDE Delivery Loop 是一套面向前线部署工程师（Forward Deployed Engineer）、解决方案架构师和企业 AI POC 团队的端到端交付总技能。它不只负责“把文档写出来”，还要让后续团队“接得住”：研发知道实现边界，测试知道如何验收，客户知道怎样判断 POC，交付团队知道失败后该回到哪里修正。

本技能采用 1 个交付路由器 + 8 个专业模块。八环既能独立执行，也能连续运行；不要为了形式强制用户从第一环开始。材料混乱或阶段不明时，由路由器识别最早证据缺口和唯一优先的下一动作。

解决什么问题

识别并处理下列常见交付断点：

• 客户提出“做一个 AI 助手”，但业务问题、使用者和优先级尚未查清；
• 访谈记录很多，却没有形成可验证的问题假设和现状基线；
• PRD 看起来完整，但研发不知道边界，测试不知道怎样验收；
• POC 演示效果不错，却没有冻结的成功标准和失败条件；
• 技术团队证明了模型能力，却没有证明用户采用和业务价值；
• 方案忽略数据、权限、集成、安全、人工接管和生产差距；
• 项目失败后只能笼统归因于“效果不好”，无法定位应返工的环节；
• 每个客户项目都从头开始，经验没有沉淀成可复用资产。

交付结果

把分散工作连接为一条连续证据链：

客户现场证据
  → 问题假设与现状基线
  → 业务结果与成功标准
  → FR / NFR
  → 验收场景 AC
  → 架构与 Agent Skill
  → 测试及运行证据
  → 用户采用与业务价值
  → 可复用产品资产

对每个关键结论都追问：

1. 结论来自什么现场证据？
2. 它对应哪个业务结果或成功标准？
3. 研发需要实现什么，明确不实现什么？
4. 测试和客户怎样验收？
5. POC 用什么证据证明通过或失败？
6. 如果失败，最早应该回到哪一环补证或返工？

八环能力地图

选择运行方式

智能路由

用户不确定从哪里开始、要求端到端推进、继续既有项目、审计材料或复盘失败时，完整读取 fde-delivery-router/MODULE.md，先判断当前阶段、最早证据缺口和下一动作。

单环执行

用户明确要求某一环且输入足够时，直接读取上表对应模块的 SKILL.md 并执行。不要为了形式强制从第 1 环开始。例如：已有问题报告和 POC 契约时，可以直接生成 PRD；已有 PRD 时，可以直接进入部署架构或 POC 审计。

连续多环

用户要求连续执行多环时，一次只加载和执行一个专业模块。保存本环交付物、证据缺口、版本、负责人和下一决策后，再判断是否满足下一环入口条件。不要一次读取全部模块文件。

失败回退

POC、采用或产品化质量门未通过时，依据失败证据返回最早需要补证或返工的环节。八环是可回退的交付闭环，不是只能向前的瀑布流程。

独立审计

用户提交已有访谈、PRD、架构、Skill 或 POC 结果时，可以不重做内容，直接检查证据断点、不可测试需求、缺失的非功能约束、未授权承诺和无法证明的价值结论。

模块加载规则

1. 把本目录视为一个可一次安装的总技能，子模块均已内置；路由器选中模块后，不要声称模块未安装。
2. 源码仓库中的子模块入口名为 SKILL.md。一键发布包为了满足“压缩包只能包含一个 SKILL.md”的平台规则，会把九个子入口转换为 MODULE.md；遇到 MODULE.md 时按完全相同的模块指令执行。
3. 读取子模块后，按其中的相对路径加载所需 references/、templates/、assets/ 或运行 scripts/。相对路径始终以该子模块目录为基准。
4. 只加载当前任务需要的参考文件。不要为了显示能力而一次读取所有资料。
5. 需要状态化协作时，使用路由器内置的 scripts/project-state.js 维护 fde-project.json 与 fde-events.jsonl。状态完整不代表业务结论正确。

总控纪律

• 先判断用户需要快速路由、单环交付、端到端陪跑、交付审计还是失败复盘，并在结果开头说明；
• 先看真实材料和已有交付物，再看用户使用了哪些关键词；
• 证据不足时最多提出 3 个会改变决策的问题，同时继续完成不依赖答案的部分；
• 区分事实、推断、假设和待确认项，不把假设写成客户事实；
• 不替客户承诺资源、范围、成功标准、生产批准或业务价值；
• 每环都说明已知证据、待确认项、本环交付物、阻断风险、负责人和下一项关键决策；
• 质量门未通过时保留失败，不用漂亮的平均分掩盖硬失败；
• 脚本只能提供确定性结构检查、骨架或统计，不能替代 FDE 现场判断、架构评审、客户验收和授权；
• POC 通过不等于生产就绪，技术可行不等于用户采用，用户采用也不自动等于业务价值；
• 产品化前区分可复用核心、客户配置和客户特例，不把单一项目经验直接包装成通用产品。

方法论使用原则

保留 KANO、SWOT、5 Whys、用户旅程、服务蓝图、影响—信心—成本、风险矩阵和 Mermaid 等经典方法，但只在它们能够改变决策或交付结果时使用：

• 用 5 Whys 和现场证据寻找问题根因，不把用户提出的功能直接当成根因；
• 用 KANO 判断需求预期和满意度影响，但不代替成功标准；
• 用 SWOT 辅助方案与环境判断，但必须把结论落到风险、边界或行动；
• 用用户旅程和服务蓝图定位角色、触点、等待、交接和异常；
• 用 Mermaid 表达流程、状态、系统边界和追踪关系，避免只为装饰而绘图；
• 用风险矩阵决定护栏、人工门禁、降级、停止和回退条件。

端到端案例

企业客服助手

从“希望 AI 帮助客服快速回答问题，但不能答错，也不能影响现有系统”的口头需求开始，依次形成：

• 客服主管、一线客服、知识运营、安全与系统团队的角色地图；
• 高频问题、转人工原因、处理时长、知识缺口和现状基线；
• 可验证的业务结果、成功标准、范围和责任边界；
• 带 FR、NFR、AC、异常、权限和追踪关系的 PRD；
• 知识检索、权限、审计、人工接管和失败回退架构；
• 带护栏和评测样例的客服 Agent Skill 与最小 POC；
• POC 运行记录、通过或失败证据和决策；
• 用户采用计划、业务价值验证方式和可复制资产。

该合成案例用于验证从模糊输入到八环交付物的连续性；不能把案例结果当成任何真实企业的绩效承诺。

公共交通中断处置助手

该案例用于验证动态信息、证据时效、人工授权和安全边界。第一次运行发现道路通知与驾驶员上报存在时效冲突，因此保留硬失败并回退到架构和 Skill 设计环节，补充信息新鲜度、多来源冲突处理、人工确认门禁、降级策略与人工决定日志，再重新运行验证。

案例强调：POC 的价值不是永远输出“通过”，而是用可复盘的失败证据找到真正需要修正的环节。

与常见工具的差异

使用示例

让路由器判断下一步

我正在做一个企业知识助手项目。这里是客户访谈、现有方案和限制条件。请使用 FDE Delivery Loop 判断项目处在哪一环，列出最早证据缺口，并给出唯一优先的下一动作。

只运行 PRD 环节

我已经有问题发现报告和 POC 契约。请单独调用 PRD Writer，输出研发能实现、测试能验收的 PRD 交接包，并保留事实、假设、异常、权限和追踪关系。

审计失败的 POC

这个 POC 已经完成演示，但客户不愿意上线。请审计成功标准、需求、运行证据和采用阻力，判断失败证据指向哪一环，并给出最小返工方案。

从头运行完整流程

请以 FDE 身份处理以下客户需求，从问题发现开始完成八环交付。每一环说明输入、输出、证据缺口、质量门和是否允许进入下一环。

验证与可信边界

当前版本提供确定性仓库检查、路由评测、端到端合成案例和发布包完整性校验。公开规则的评测成绩只能证明规则覆盖范围，不能伪装成 Claude、Codex 或其他平台内部的模型触发能力。

本技能核心采用文件型、平台中立的设计，可在支持 Agent Skills 或文件型技能的智能体平台上适配；不同平台的导入、脚本和权限规则可能不同，应以目标平台实测为准。技能不会代替生产安全评审、隐私和法律合规审批、客户验收或人工业务决策。

完成定义

单环任务以对应专业模块的完成定义为准。端到端任务只有在八环交付物形成连续证据链、关键风险有负责人、采用结论不过度外推，并明确哪些经验可以产品化时才算闭环。

如果条件尚未满足，输出当前状态、缺失证据、阻断风险和唯一下一动作，不制造“全部完成”的假象。

作者与联系

作者：xukun
方向：Forward Deployed Engineer、企业 AI POC、Agent Skills 与 AI 解决方案交付
联系邮箱：xukun0821@gmail.com

欢迎围绕 FDE 团队建设、企业 AI 交付流程、POC 设计和 Agent Skills 产品化进行交流。

代码采用 Apache-2.0 许可证；文档、模板与方法论采用 CC-BY-4.0 许可证。