FDE 交付检查清单

使用说明

• 每项标注：✅ 已满足 / ⚠️ 部分 / ❌ 未满足 / N/A 不适用
• 原则：任一阶段的"关键项"（标 ★）未满足，不应进入下一阶段
• 后果说明：不满足时的常见结局（红线风险）
• 正文对应：已标注章节，便于查阅细节

---

阶段一：发现（对应第 6 章）

阶段目标：从客户工作流中定位高频、高价值且可验证的问题；先定义基线和成功指标。

关键项（★）

• ★ 问题定义清晰

  • 要素：一句话问题 + 当前基线数据 + 目标指标
  • 正文参考：第 6 章
  • 不满足的后果：
    • 问题定义模糊 → 后续验收永远对不上账
    • 没有基线数据 → 上线后无法证明"比原来好"
    • 没有目标 → 项目永远"做得还不错，再试试"
  • 检查清单：[ ] 一句话清晰定义 [ ] 基线数字有出处 [ ] 目标值与时间窗口已冻结

• ★ 基线已测量

  • 要素：人工流程的耗时/错误率/成本有具体数据（不是估算）
  • 正文参考：第 6 章
  • 不满足的后果：
    • 只有定性评价（"很慢""很多错"）→ 上线对比无法量化
    • 测试样本太小或非代表性 → 数据不可信，客户不认可
    • 测量方法一致性不确保 → 上线前后用不同尺度衡量，数字爆炸
  • 检查清单：[ ] 样本量≥30 [ ] 测量方法有文档 [ ] 至少重复测过一轮

• ★ 用户已尝试过可交互的原型并给出真实反馈

  • 要素：用真实数据、真实用户完成一次端到端交互，收集真实反馈（不只是"点了点头"）
  • 正文参考：第 6 章、第 7 章
  • 不满足的后果：
    • 原型只在演示数据上跑过 → 上线后发现数据分布、格式完全不同
    • 用户点了头但没真实使用 → 需求理解停留在客户的一句话
    • 没有拿到真实反馈（客户怎么用、怎么吐槽） → 第二版设计又是猜测
  • 检查清单：[ ] 用了真实数据（分布、量级都真实） [ ] ≥1位真实一线用户尝试过 [ ] 记录了用户反馈/疑问/困惑

非关键项（可选但推荐）

• 数据可达性清单完成

  • 内容：数据在哪/谁拥有/谁能看/脱敏规则/例外流程
  • 正文参考：第 10 章
  • 早做的好处：发现数据缺失/权限缺失/法律问题趁早补救

• 变更容忍度确认

  • 内容：流程所有者已知、受影响人群已识别、变更会引起的冲击范围已算清
  • 正文参考：第 15 章
  • 早做的好处：避免"上线完美、用户崩溃"

---

阶段二：最小可行部署 MVD（对应第 7、12 章）

阶段目标：用真实数据、真实用户快速验证方案是否可行；用最小范围确保验收成本可控。

关键项（★）

• ★ 真实数据（分布真实，非演示数据）

  • 要素：数据量级、分布、格式都与生产环境一致；不能是"我们选最好的 100 条"
  • 正文参考：第 7 章
  • 不满足的后果：
    • 演示数据分布简单 → PoC 效果 95%，上线效果 65%，被客户投诉"缩水"
    • 演示数据量太小 → PoC 秒级响应，上线百级延迟
    • 演示没有边界情况 → 某类数据一进去系统就崩
  • 检查清单：[ ] 数据量级代表生产环境 [ ] 包含≥5%的边界情况 [ ] 来源可追溯

• ★ 真实用户（至少一个一线用户每周真实使用）

  • 要素：不是"老板看了一眼"，是实际干活的人、每周都用、能给反馈
  • 正文参考：第 7 章
  • 不满足的后果：
    • 只有管理层同意 → 最后执行人不配合，功能设计完全脱离使用场景
    • 用户不是真实干活的人 → 没发现工作流的真实堵点
    • 用户不经常用 → 间断使用发现不了系统稳定性问题
  • 检查清单：[ ] 用户列表有名字/部门 [ ] 用户是实际操作者（不是采购方） [ ] 有周使用记录

• ★ 基准样本准备（代表性例子≥50条，有指定判定人）

  • 要素：收集50条代表一线真实场景的例子（"这个问题应该这样解决"）；明确指定一个人负责判定这些例子是否正确
  • 正文参考：第 12 章
  • 不满足的后果：
    • 样本太少（<20条） → 无法代表真实多样性，评测结果无效
    • 没有判定人 → 样本标注纠纷无法解决，做完了还得返工
    • 样本有偏向 → 只有客户最关心的场景，遗漏了80%的实际问题
  • 检查清单：[ ] 样本数≥50 [ ] 样本覆盖≥3个主要场景 [ ] 指定一个判定人 [ ] 样本与最终评测集的版本管理有记录

非关键项（可选）

• 范围界限明确
  • 内容：清晰划定边界——只做1条流程、1个用户群、Agent只做可测段
  • 正文参考：第 7 章
  • 推荐早做：避免最小可行部署变成"试试所有功能"

---

阶段三：生产化（对应第 8-14 章）

阶段目标：把 PoC 补齐成能在真实企业环境中独立运行的系统。对应第9章的"八堵墙"逐堵拆除。

关键项（★）— 必须拆的墙

地基性（不通则什么都别谈）

• ★ 第一堵墙：数据与权限 → 数据契约签署

  • 内容：范围/可见性/留存/审计 四项一张表
  • 要素：哪些表能读、结果谁能看、脱敏规则怎么做、异常权限走什么流程
  • 正文参考：第 9 章、第 10 章
  • 不满足的后果：
    • 上线后才发现某表无权读 → 流程卡住
    • 没有脱敏约定 → 客户投诉泄露敏感信息
    • 结果可见范围没定 → 有人看不到，项目失败
  • 检查清单：[ ] 一张表列出所有要读的数据源 [ ] 每个源标注权限方 [ ] 脱敏规则附表 [ ] 审计日志方案确认

• ★ 第二堵墙：系统集成 → 打通新旧系统的集成路径

  • 内容：Agent 要写回的那个系统怎么接（API/数据库/RPA/其他）
  • 要素：接口协议确认、数据格式映射、失败重试策略、幂等性保证
  • 正文参考：第 9 章、第 10 章
  • 不满足的后果：
    • 没事先验证 API 可用性 → 上线后发现接口从未真正能用
    • 没做失败重试 → 偶发网络抖动导致数据丢失
    • 没做幂等性检查 → 重试后客户数据被重复处理
  • 检查清单：[ ] 集成方案已做 PoC（真实连接过一次） [ ] 网络异常、timeout、返回格式错误都测过 [ ] 幂等性设计文档 [ ] 失败回滚方案明确

风险性（能跑但随时出事）

• ★ 第三堵墙：工具边界 → 工具契约

  • 内容：Agent 能调什么工具、参数谁校验、什么情况下拒绝调用
  • 要素：工具清单/参数校验规则/高风险工具的防护（如发邮件、修改数据）
  • 正文参考：第 9 章、第 11 章
  • 不满足的后果：
    • 没有参数校验 → Agent 生成错误的邮件、删除错误的记录
    • 没有工具白名单 → Agent 调用不该有权限的工具
    • 没有速率限制 → Agent 给外部 API 发起 DDoS 级的请求
  • 检查清单：[ ] 工具清单白名单化 [ ] 每个工具的参数校验规则写进代码 [ ] 高风险工具（写操作、外发）有审批工单 [ ] 调用速率/并发限制确认

• ★ 第四堵墙：运行可控 → 运行状态机 + 检查点与恢复

  • 内容：任务失败怎么办、卡在人工审批能否续跑、中途宕机能否断点续传
  • 要素：状态流转图/检查点/恢复策略
  • 正文参考：第 9 章、第 11 章
  • 不满足的后果：
    • 没有检查点 → 任务失败只能全部重跑，客户数据被重复处理
    • 没有人工审批挂起点 → 需要人工确认的事卡住了，整条链路堵死
    • 没有降级路径 → 系统故障就是业务故障，没有人工兜底
  • 检查清单：[ ] 状态流转图已画 [ ] 至少 3 个关键检查点已实现 [ ] 人工审批节点能挂起并续跑 [ ] 降级到人工/Excel 的路径演练过

信任性（不通则永远停在试用）

• ★ 第五堵墙：效果可证 → 评测集 + 变更门禁

  • 内容：改了提示词/模型/工具后，效果是升是降有数据说话
  • 要素：回归集/对标版本/变更前后对比
  • 正文参考：第 9 章、第 12 章
  • 不满足的后果：
    • 没有回归集 → 每次改动都是赌博，一周改崩系统
    • 没有对标版本 → 改进还是倒退看不出来
    • 没有变更门禁 → 谁都能改，出了事无法追责
  • 检查清单：[ ] 回归集≥200条 [ ] 基线版本冻结并记录 [ ] 变更前后有自动对比 [ ] 变更日志可追溯

• ★ 第六堵墙：结果可信 → 证据链

  • 内容：客户问"这个数字哪来的""这个结论为什么信"能拿出证据
  • 要素：调用执行记录/原始输入/中间推理步骤/最终决策依据
  • 正文参考：第 9 章、第 13 章
  • 不满足的后果：
    • 没有执行记录 → 客户质疑结果只能重跑，无法溯源
    • 执行记录不完整 → 客户看到结果但看不到推理过程
    • 没有原始数据存档 → 数据变了，无法做事后复盘
  • 检查清单：[ ] 每次调用记录了输入 [ ] 中间步骤（检索结果、模型输出）可查 [ ] 最终决策依据可展示给客户 [ ] 日志存储周期明确

• ★ 第七堵墙：成本与稳定 → 成本归因 + 预算熔断

  • 内容：账单怎么算、超了怎么办、系统怎么保证服务水平目标 SLO
  • 要素：每次调用的成本分摊/成本预警/超预算自动降级
  • 正文参考：第 9 章、第 14 章
  • 不满足的后果：
    • 没有成本分摊 → 月底账单爆炸，客户怨声载道
    • 没有预警 → 等发现的时候已经超预算数倍
    • 没有自动降级 → 成本高时还在跑高耗能的调用，恶性循环
  • 检查清单：[ ] 成本模型文档 [ ] 每 1000 调用的平均成本已测 [ ] 预算预警阈值设定 [ ] 超预算时自动降级策略已实现

• ★ 第八堵墙：责任可移交 → 责任交接表 + 运行手册

  • 内容：出了事谁负责、撤场后系统交给谁
  • 要素：事故分类/第一责任人/升级路径/运行文档
  • 正文参考：第 8 章、第 17 章
  • 不满足的后果：
    • 没有责任表 → 出事时指责无门，关系破裂
    • 运行手册只在乙方 → 客户接手不了
    • 没有升级路径 → 半夜告警，找不到人
  • 检查清单：[ ] 责任矩阵（事故类型×责任人）已列 [ ] 升级时间与升级对象明确 [ ] 运行手册客户已评审过 [ ] 故障演练至少做过一次

非关键项（检查但可分阶段）

• 高风险动作审批工单

  • 内容：写操作前要有人批、记录 run_id/approver_id/操作详情
  • 正文参考：第 11 章

• 服务水平目标 SLO 三维承诺（可用性/延迟/质量）+ 降级路径

  • 内容：服务水平协议 SLA 合同里写的指标，要用三维来定
  • 正文参考：第 14 章

• 风险分级表（只读/可逆/不可逆/外发）

  • 内容：把所有操作按风险等级分类
  • 正文参考：第 11 章

---

阶段四：上线与采用（对应第 8、15、16 章）

阶段目标：效果已证、系统已稳，从试用到生产的最后一关：客户要敢接、员工要想用。

关键项（★）

• ★ 效果验收单（指标+基线+窗口+分母口径+判定人，事前冻结）

  • 内容：五要素齐全，打印一张贴在评审室
  • 要素：
    • 基线值（第6章测出的人工流程水平）
    • 目标值（要达到的水平）
    • 测量窗口（按周/按月）
    • 分母口径（算谁、不算谁）
    • 判定人（一个人的名字，不是"业务方"）
  • 正文参考：第 8 章
  • 不满足的后果：
    • 指标事前没冻结 → 上线后因"这月数据特殊"改指标，扯皮无解
    • 分母口径模糊 → 客户说"没达标"，乙方说"你算错了"
    • 判定人不明确 → 最后谁也说不通，项目悬而未决
  • 检查清单：[ ] 五要素全部写进合同 [ ] 判定人签字 [ ] 灰度阶段的各级回滚线已量化

• ★ 运行就绪清单（告警有人看/降级可用/手册有人读过）

  • 内容：四项核查，一项都不能缺
  • 要素：
    • 告警有人看：告警响起时有值班表对得上
    • 降级路径可用：包括退回 Excel 和人工，已演练过
    • 运行手册：客户有一份、读过一遍
    • 值守排期：上线后第一周谁值守、响应时间承诺白纸黑字
  • 正文参考：第 8 章
  • 不满足的后果：
    • 告警响了没人看 → 系统故障客户先知道
    • 没有降级路径 → 系统一坏就是业务停机
    • 手册只在乙方 → 客户半夜故障无人接
    • 值守表空白 → 谁来处理第一个告警？
  • 检查清单：[ ] 值班表有覆盖 [ ] 降级流程演练过一次 [ ] 客户确认收到并读过手册 [ ] 值守承诺服务水平协议 SLA（响应时间）已签

• ★ 责任交接表（每个事故场景的第一责任人）

  • 内容：把系统可能的死法逐一列出，每种写明第一责任人和升级路径
  • 示例：

    出了什么事	第一责任人	升级路径
    模型输出错误，造成业务损失	谁判定、谁拦截、谁赔付	1小时内到双方负责人
    数据源故障/上游宕机	数据方接口人	4小时内到供应商值守
    用户误操作引发故障	客户侧系统管理员	当日到联合复盘
    成本超预算	平台方	周报到项目负责人

  • 正文参考：第 8 章
  • 不满足的后果：
    • 没有责任表 → 出事时"这不是我们的问题"←→"这怎么会是我们的问题"，关系破裂
    • 没有升级路径 → 半夜故障无人接，问题升级成客户投诉
    • 只写了法律责任不写处置流程 → 纸上有名字，现实中没人接
  • 检查清单：[ ] 列出至少 5 种可能的故障场景 [ ] 每种标注第一责任人（用人名，不用部门名） [ ] 升级时间与升级对象明确 [ ] 双方签署

非关键项（推荐但可分阶段）

• 灰度计划（分级放量 + 每级回滚线）

  • 内容：第一批 10% 用户→20%→50%→100%，每级有明确的回滚条件
  • 正文参考：第 8 章

• ★ 激励三问已回答（字典：考核变了吗/省的时间归谁/出错算谁的）

  • 内容：用户为什么要用这个系统
  • 正文参考：第 15 章

• 支持者网络（每团队一个 champion）

  • 内容：每个受影响的部门里，有一个人懂系统、能回答同事的问题
  • 正文参考：第 15 章

• 激活度量口径（激活率/分流率，分母与窗口明确）

  • 内容：怎么算用户真正在用系统
  • 正文参考：第 15 章

---

阶段五：移交与回流（对应第 16、17、21、22 章）

阶段目标：从 FDE 拉手交给客户；把这一次交付的经验和工具沉淀成可复用的产品能力。

关键项（★）

• ★ 三资产移交

  • 内容：三个东西客户必须接住（缺一个就还不算"移交成功"）
  • 第一项：运行手册
    • 包括：故障排查树、常见问题 Q&A、值守流程、人工回退步骤
    • 客户验收标准：至少一个人能按手册处理一次实际故障
    • 正文参考：第 17 章
  • 第二项：评测集 + 维护责任
    • 包括：评测集（用于后续验证）+ 定期补充的计划（谁负责）
    • 客户验收标准：能自己跑评测，明白怎么加新样本
    • 正文参考：第 17 章
  • 第三项：故障应对指南
    • 包括：常见故障的诊断与处置步骤，每条配例子
    • 客户验收标准：见过指南里的场景，知道怎么处理
    • 正文参考：第 17 章
  • 不满足的后果：
    • 手册没演练过 → 真出事时还是要回头找 FDE
    • 客户不懂评测集怎么维护 → 系统漂移无人感知
    • 没有故障应对指南 → 每次故障都是紧急求救
  • 检查清单：[ ] 三份文档客户都收到并评审过 [ ] 各项都演练过一次（不是"看过"，是"做过"） [ ] 客户能独立完成最常见的 3 种故障处理

• ★ 定制请求打标（一次性/行业共性/通用）

  • 内容：这次项目的需求，哪些只是这个客户的、哪些是行业通性、哪些能沉淀成产品
  • 正文参考：第 21 章、第 22 章
  • 不满足的后果：
    • 全当"一次性需求"处理 → 下一个客户还是从零开始
    • 全当"行业共性"承诺 → 承诺太重，后续项目成本爆炸
    • 没有打标 → 回流评审时不知道该沉淀什么
  • 检查清单：[ ] 给全部定制需求标注了分类 [ ] 一次性需求有明确的退出日期 [ ] 通用能力的初版代码已提交

非关键项（推荐）

• 移交阶梯执行（陪伴→影子→撤出，各级有时间与退出条件）

  • 内容：第一阶段 FDE 陪伴，第二阶段 FDE 影子跟着，第三阶段客户自己干
  • 正文参考：第 17 章

• 客户方操作者通过考核（不只发文档）

  • 内容：客户的对接人要实际操作过、出过问题、自己解决过
  • 正文参考：第 17 章

• 回流评审至少一次（交付+产品双席）

  • 内容：项目结束后，交付侧和产品侧坐下来，梳理这次有什么能力值得沉淀
  • 正文参考：第 22 章

• 定制量趋势记录（第 N 客户 vs 第 1 客户）

  • 内容：定制量是上升还是下降，是产品-市场匹配的指标
  • 正文参考：第 21 章

---

使用建议

对 FDE 团队

• 阶段1-3：项目启动时就对照清单评估，逐项标注 ✅/⚠️/❌
• 阶段4-5：上线前两周拉上客户，逐项过堂，落实 ★ 标记的必须项
• 持续维护：每个项目后做一次回顾，补充这份项目特有的坑

对客户采购方

• 把这份清单的"关键项"部分写进采购需求书
• 把第8章的"甲方自检清单"和这份清单的"关键项"对应，评估你们的采购流程是否天然制造"只许看、不给碰"的困境

对项目经理

• 前期评估：用这份清单快速评估一个"PoC 已完成"的项目离生产还有多远
• 风险管理：把这份清单转成甘特图，八堵墙的各项工程量和依赖关系清晰可见

---