项目交付方法¶
FDE 项目应该从业务损失和验收标准开始，不从“选哪个模型”开始。
0. 机会筛选¶
优先选择同时满足以下条件的场景：
- 高频或高成本，改善后能算出价值。
- 输入和输出相对清晰，能收集代表性样本。
- 当前有人类流程可对照，而不是凭空定义正确答案。
- 初期可只读或有人复核，错误不会直接造成不可逆损失。
- 关键系统有接口，数据和权限负责人愿意参与。
不要先做：无明确责任人的“万能助手”、无法获得样本的流程、错误代价极高且不能人工复核的自动决策。
1. 发现与定界¶
用一页纸回答：
| 问题 | 必须得到的答案 |
|---|---|
| 谁使用 | 角色、频率、技能水平、当前入口 |
| 为什么做 | 当前成本、风险、延误或收入机会 |
| 输入是什么 | 来源、格式、体量、更新频率、敏感级别 |
| 输出去哪 | 建议、草稿、系统写回、审批还是自动执行 |
| 什么叫正确 | 可观察的通过条件和不可接受错误 |
| 约束是什么 | 网络、合规、地域、预算、时延、集成窗口 |
把目标写成可证伪的形式：
对客服升级工单，在人工批准后生成带引用的建议回复；严重事实错误率低于 1%，P95 小于 8 秒，每单推理成本低于 0.2 元。
2. 建立基线¶
在引入复杂系统前记录：
- 当前人工完成时间与质量分布。
- 一个简单模型或提示词的通过率、时延和成本。
- 不使用 AI 的规则或搜索基线。
- 至少 50 到 200 个代表性样本，覆盖高频、边界和高风险案例。
基线避免团队把任何可运行的 Demo 都误认为改进。
3. 设计最小闭环¶
第一版只保留必要组件：
最小闭环应能收集失败案例。缺少输入快照、模型版本、提示词版本、检索结果、工具调用和最终反馈的 Demo，后续无法调优。
4. 评测驱动迭代¶
每次变更都在固定评测集上比较：
- 先分类错误来源。
- 只修改最可能的层。
- 同时看质量、P95 时延和单位任务成本。
- 对高风险样本做回归测试。
- 记录胜负，不凭个别例子判断。
错误分类建议：需求不清、输入缺失、检索失败、上下文冲突、模型推理失败、工具失败、权限阻断、输出不可用。
5. 试点到生产¶
试点门槛¶
- 有明确用户群和支持渠道。
- 可以回退到原流程。
- 高风险动作需要人工审批。
- 已设置预算、速率、超时和并发上限。
- 关键事件可审计，敏感数据有脱敏和保留策略。
生产门槛¶
- 容量测试达到预估峰值的 1.5 到 2 倍。
- 模型、提示词、索引和工具都有版本与回滚方式。
- 依赖故障时有降级响应，不无限重试。
- 告警有责任人、阈值和处理手册。
- 业务方确认验收指标，并安排上线后复盘。
6. 移交与复用¶
最低移交包：
- 系统架构、数据流和权限图。
- 环境配置、密钥管理方法、部署与回滚步骤。
- 评测集、基准报告和已知限制。
- 监控面板、告警说明和故障手册。
- 成本模型、容量假设和供应商依赖。
- 待办清单及所有权。
把通用部分沉淀为连接器、评测器、网关策略和部署模板。不要把某个客户的字段名、数据或规则直接固化进通用产品。
常见失败¶
| 现象 | 根因 | 修正 |
|---|---|---|
| Demo 很惊艳，上线无人用 | 没进入原工作流 | 从用户入口和责任人重画流程 |
| 一直换模型 | 没有错误分类和固定评测集 | 先建立可复现样本与分层指标 |
| RAG 有引用仍答错 | 检索质量或上下文冲突 | 单独评测检索，再评测生成 |
| Agent 偶尔造成严重后果 | 权限过大、无审批 | 最小权限、幂等工具、人工确认 |
| 成本突然失控 | 上下文、重试或并发无上限 | 配额、截断、缓存、预算告警 |
六周交付样板¶
这不是固定工期，而是一种把不确定性前置的节奏。复杂集成可以延长，但不应跳过证据产物。
| 周次 | 重点 | 演示对象 | 退出条件 |
|---|---|---|---|
| 第 1 周 | 访谈、样本、权限、人工基线 | 真实工作流回放 | 目标和反目标已签字，样本可用 |
| 第 2 周 | 最小技术闭环 | 20 条端到端样本 | 能保存完整 trace，失败可分类 |
| 第 3 周 | 黄金集与第一次选型 | 模型/检索对比报告 | 主方案和备选方案有量化理由 |
| 第 4 周 | 集成、安全、容量 | 预生产环境 | 峰值测试、权限测试、回滚演练通过 |
| 第 5 周 | 小流量试点 | 真实用户和真实任务 | 采用、质量、时延达到试点门槛 |
| 第 6 周 | 扩流与移交 | 生产看板和操作手册 | 所有告警有负责人，接手者可独立操作 |
每周只承诺可验证结果。比如“优化 RAG”不是交付物，“在 120 条黄金集上把关键证据召回率从 72% 提升到 86%，P95 增加不超过 300ms”才是。
责任矩阵¶
项目开始时确认四种角色：执行者 R、最终负责者 A、需协商者 C、需知会者 I。同一事项只能有一个 A。
| 事项 | 业务负责人 | FDE | 平台/IT | 安全/法务 | 运营团队 |
|---|---|---|---|---|---|
| 验收标准 | A | R | C | C | I |
| 技术架构 | C | A/R | C | C | I |
| 数据授权 | A | C | R | C | I |
| 上线批准 | A | R | R | C | C |
| 事故处置 | C | R | A/R | C | R |
| 最终移交 | C | R | A | I | R |
矩阵要替换为真实姓名和联系方式。只有部门名称的责任表，在事故发生时通常无法执行。
发现访谈脚本¶
按实际任务顺序追问，不要从“希望 AI 做什么”开始：
- 请用户现场完成一条真实任务，并说出每一步判断依据。
- 问最近一次失败发生在哪里、如何发现、谁承担后果。
- 记录输入来源、系统切换、复制粘贴、等待与返工时间。
- 找出只能由人批准的动作，以及哪些动作其实可以只读自动化。
- 追问数据缺失时现有流程如何处理，不假设输入永远完整。
- 用三个历史样本让不同专家独立判断，测量“正确答案”是否一致。
范围控制：当利益相关者提出新需求时，先写入变更清单并标注对数据、权限、评测、容量和工期的影响，再决定是替换当前范围还是进入下一阶段。
决策记录模板¶
# ADR-007：生产默认模型与降级模型
- 状态：Accepted
- 日期：2026-09-04
- 背景：峰值 40 并发，P95 < 6s，数据不得出域
- 候选：A / B / C
- 证据：黄金集通过率、TTFT、TPOT、单任务成本、故障注入结果
- 决策：默认 B；超时或容量保护触发时降级到 A
- 代价：复杂推理通过率下降 4.1 个百分点
- 回滚：切换网关别名至上一版本，预计 2 分钟
- 复审条件：数据分布变化 20%，或新模型进入候选池
本章实践¶
拿一个假想场景完成三份一页文档：范围与反目标、50 条样本的采集计划、生产门禁。请另一位同事仅凭这三份文档指出项目在哪些条件下应该停止。无法回答的地方就是尚未暴露的风险。