附录 B · 模板工具箱
模板不是答案，是让讨论有形状的工具。这 12 份覆盖一次小型 AI 部署从发现到复盘的完整链路，每份都能直接复制到飞书、Notion、GitHub Issue 或 Word 里用。示例均为合成场景，数字只用于演示格式，不代表真实客户。
使用约定
- 先填事实，再填判断：拿不准的写「待验证」，不要写成结论。
- 每个数字带口径：来源、时间范围、统计对象，三者缺一不可。
- 一页原则：能一页说清就不要两页；超过一页说明还没想清楚。
- 版本化：文件名带日期和版本，例如
roi-v0.2-2026-03-01。
| # | 模板 | 用在哪 | 主要产出 |
|---|---|---|---|
| 1 | 发现访谈提纲 | Discover | 一页访谈摘要 + 问题清单 |
| 2 | 干系人地图 | Discover / Define | 权力—态度表与接触计划 |
| 3 | 流程地图 | Discover / Define | 泳道流程与例外清单 |
| 4 | 数据接入清单 | Define / Prototype | 数据可用性与接入方案 |
| 5 | 价值模型 / ROI | Define / Pilot | 收益、成本与回收期 |
| 6 | 项目章程 | Define | 一页纸共识与签字 |
| 7 | 试点计划 | Pilot | 范围、指标与 Go/No-Go |
| 8 | 评测计划 | Prototype / Pilot | 评测集与门槛 |
| 9 | 上线就绪检查 | Production | 放行或延期的证据 |
| 10 | Runbook | Production | 值班与故障处置手册 |
| 11 | 交接清单 | Handover | 可验收的移交包 |
| 12 | 事故复盘 | 全程 | 无责复盘与行动项 |
模板 1 · 发现访谈提纲
用途：Discovery 阶段对 3-8 位一线用户、主管和支持团队做半结构化访谈，把「我要一个 AI 助手」还原成可验证的现状事实。
填写说明
- 45-60 分钟、1 对 1；管理者与一线分开谈，避免下属看眼色。
- 只问「最近一次」的具体事实，不问「你觉得 AI 能做什么」。
- 记录原话与数字，不当场承诺方案；24 小时内整理成一页摘要。
模板正文
| 环节 | 主问题 | 追问 | 危险信号 |
|---|---|---|---|
| 开场 | 说明目的、时长、录音与匿名规则 | 你希望这次访谈帮你解决什么？ | 以为你是来卖软件的 |
| 现状 | 最近一次遇到这个问题，把过程讲一遍 | 先后做了什么？用了哪些系统？ | 只有观点，没有具体案例 |
| 频率与代价 | 一周几次？每次多久？谁受影响？ | 出错一次损失多少时间或钱？ | 「经常」但给不出量级 |
| 现有解法 | 现在怎么解决？为什么不够好？ | 试过别的办法吗？为什么放弃？ | 把「没人做」当成「做不了」 |
| 决策与预算 | 如果改进，谁批准？钱从哪来？ | 类似项目过去谁买单？ | 找不到经济买家 |
| 成功标准 | 半年后什么变化算成功？怎么量？ | 这个指标现在是多少？ | 只能说「更智能」 |
| 数据与权限 | 数据在哪？谁有权限？能取脱敏样本吗？ | 更新频率？有唯一编号吗？ | 「数据都有」但没人拿得到 |
| 收尾 | 还有谁该聊？能旁观一次实际操作吗？ | 下周能给我什么材料？ | 不愿安排影子跟岗 |
示例片段（合成场景）
用户：「退换货工单每天早上堆两百多张，三个人分，分错的和紧急的混在一起。」 追问得到：每天约 220 张、分拣 3 人 × 2 小时、错分率没统计、系统是自研工单平台且可导出。下一步先要 3 个月导出数据算基线，而不是先选模型。
常见错误
- 只访管理者，拿到的是一份愿望清单。
- 问「你想让 AI 做什么」，把访谈变成需求点名。
- 听完痛点就现场答应「这个能做」，后面收不了口。
模板 2 · 干系人地图
用途：在立项前看清「谁会支持、谁能否决、谁必须被说服」，尤其别漏掉 IT、安全、法务和采购。
填写说明
- 每个角色写真实岗位，不写「业务方」这种模糊称呼；一个人一行。
- 态度按当下事实填，不按你希望的态度填。
- 每周更新一次，态度变化就是项目风险信号。
模板正文
| 姓名 / 岗位 | 组织 | 角色 | 关注点 | 影响力 | 态度 | 接触策略 | 上次接触 |
|---|---|---|---|---|---|---|---|
| 经济买家 / 用户 / IT / 安全 / 法务 / 采购 / 赞助人 | 高 / 中 / 低 | 支持 / 中立 / 反对 |
补充三条
- 经济买家：谁有权批预算、签合同？写下他的名字和审批额度。
- 隐形否决者：谁能在最后一刻说「不」？安全、法务、运维最常担任这个角色。
- 你的内线：谁愿意私下告诉你真实进展？每周至少联系一次。
示例片段（合成场景）
| 姓名 / 岗位 | 组织 | 角色 | 关注点 | 影响力 | 态度 | 接触策略 | 上次接触 |
|---|---|---|---|---|---|---|---|
| 张敏 / 客服总监 | 客服中心 | 经济买家 | 降低错分与超时 | 高 | 支持 | 每周一 30 分钟对齐指标 | 2026-03-02 |
| 李工 / 信息安全 | IT | 隐形否决者 | 数据不出域、权限可审计 | 高 | 中立 | 提前提交数据流图与脱敏方案 | 2026-03-03 |
常见错误
- 只画组织架构图，不写关注点和态度。
- 把「赞助人」当经济买家：他支持，但签字的不一定是他。
- 地图画完就锁进抽屉，不做每周更新。
模板 3 · 流程地图
用途：把「现在到底怎么干活」画出来，找到耗时、出错和例外最集中的环节，作为场景选择的依据。
填写说明
- 用影子跟岗或流程走查获取，不靠会议室回忆。
- 至少标注一个「例外路径」；例外往往才是痛点所在。
- 每个环节都写系统和输入输出，方便后面判断数据在哪。
模板正文
【泳道流程 · 以客服退换货为例】
客户 提交申请 ──────────────┐
▼
客服(一线) 收单 ──▶ 判断类型 ──▶ 转交对应组 ──▶ 回复客户
│ │
│ └─▶ 分类不清？→ 转主管人工判断（例外）
▼
系统/工单平台 建单 打标签 状态流转 关闭
每步记录：执行角色 | 使用系统 | 输入 | 输出 | 例外 | 单次耗时 | 出错率| 步骤 | 执行角色 | 系统 | 输入 | 输出 | 例外 | 单次耗时 | 出错率 |
|---|---|---|---|---|---|---|---|
| 1 | |||||||
| 2 |
示例片段（合成场景）
步骤 2「判断类型」由一线客服执行，依靠个人经验，单次约 3 分钟；例外是「促销期退换」需要主管确认，平均多等 40 分钟。结论：优先做「分类辅助」而不是「自动回复」。
常见错误
- 把流程画成 IT 系统架构图，看不到人的动作。
- 只画 happy path，不画例外和返工。
- 耗时凭印象填，没有抽查样本支撑。
模板 4 · 数据接入清单
用途：在动手写代码前，确认「数据到底能不能用、怎么接、谁批准」，把数据风险提前暴露。
填写说明
- 一个数据集一行；拿不到的数据也要写，标「阻塞」。
- 权限一栏写清是「可导出」「可查询」还是「只能看报表」。
- 就绪度用红黄绿：绿=已拿到样本，黄=有承诺未交付，红=没有路径。
模板正文
表 A · 业务与权限
| 数据集 | 源系统 | 负责人 | 用途 | 关键字段 | 唯一编号 | 更新频率 | 权限方式 |
|---|---|---|---|---|---|---|---|
| 可导出 / 可查询 / 仅报表 |
表 B · 接入与质量
| 数据集 | 接入方式 | 数据量 | 质量评分 | 脱敏 | 含 PII | 就绪度 | 备注 |
|---|---|---|---|---|---|---|---|
| 一次性导出 / 定时同步 / 实时接口 | 1-5 分 | 是 / 否 | 是 / 否 | 绿 / 黄 / 红 |
接入前五步
- 拿到 100-500 行脱敏样本，确认字段与业务口径。
- 确认权限审批人、审批周期、生产访问方式。
- 确认更新机制：一次性导出、定时同步，还是实时接口。
- 确认 PII 字段与脱敏规则，写进合规检查。
- 用小样本跑通端到端管道，再申请全量。
示例片段（合成场景）
表 A：工单历史 | 工单平台 | 客服运营李娜 | 训练分类器与评测 | ticket_id、content、category、created_at | ticket_id | 每日 | 只读账号 + 导出审批。
表 B：工单历史 | 每日凌晨导出 CSV | 约 42 万条 | 3.5 / 5 | 手机号已掩码 | 是 | 黄（审批中） | 审批预计 3 个工作日。
常见错误
- 把「数据库里有」当成「我能用」。
- 只问 IT 不问数据 owner，字段口径全错。
- 忽略更新频率，上线后数据停在昨天。
模板 5 · 价值模型 / ROI
用途：把「这个项目值不值」拆成可核对的收益与成本，用于立项、试点复盘和续约谈判。
填写说明
- 先写基线，再写目标；没有基线的收益一律不写。
- 收益分四类：时间、人力、收入、风险；每类都要有证据来源。
- 成本至少算建设、运行、变更管理三项，别只算模型调用费。
模板正文
ROI =（年化收益 − 年化总成本）÷ 年化总成本 × 100%
回收期（月）= 一次性投入 ÷（月均收益 − 月均运行成本）| 收益类别 | 指标 | 现状基线 | 目标 | 年化价值 | 证据来源 | 备注 |
|---|---|---|---|---|---|---|
| 时间 | 平均处理时长 | |||||
| 人力 | 每人每周节省小时 | |||||
| 收入 | 转化率 / 续约率 | |||||
| 风险 | 错误率 / 合规损失 |
| 成本项 | 一次性 | 每月 | 说明 |
|---|---|---|---|
| 建设（人天 + 外部费用） | |||
| 运行（模型调用、存储、运维） | |||
| 变更管理（培训、流程改造） |
示例片段（合成场景，仅演示格式）
基线：每人每天分拣 2 小时、3 人、250 个工作日 ≈ 1,500 小时/年。目标节省 40% ≈ 600 小时；按内部综合成本 80 元/小时计，年化收益约 4.8 万元。年化成本约 2 万元，ROI 约 140%，回收期约 3 个月（按一次性投入 0.8 万元测算）。数字为演示，不构成承诺。
常见错误
- 只列收益不列成本，ROI 高得离谱。
- 把「效率提升」直接等价成「裁员」，引发用户抵触。
- 基线是访谈拍出来的，没有系统数据支撑。
模板 6 · 项目章程
用途：立项时用一页纸让所有关键人确认「做什么、不做什么、怎么算成功」，防止后期扯皮。
填写说明
- 一页写完；写不完说明范围还没收敛。
- 「不做」清单和「做」清单一样重要，必须双方确认。
- 退出标准和批准人必须写名字，不写部门。
模板正文
| 字段 | 内容 |
|---|---|
| 项目名 | |
| 一句话问题 | 谁，在什么场景，因为什么，损失了什么 |
| 背景与证据 | 3 条以内的数据或访谈证据 |
| 目标与指标 | 主指标 + 护栏指标，含基线与目标值 |
| 范围（做） | |
| 范围（不做） | |
| 里程碑 | 发现 / 定义 / 原型 / 试点 / 上线 的日期与交付物 |
| 角色与决策权 | 经济买家、产品负责人、技术负责人、用户代表 |
| 预算与资源 | 人、钱、数据、环境 |
| 依赖与风险 | 前 3 个风险及应对 |
| 退出标准 | 什么情况下停止或延期 |
| 批准 | 姓名 / 日期 |
示例片段（合成场景）
一句话问题：客服中心每天约 220 张退换货工单靠人工分类，错分导致平均处理时长多 40 分钟。范围（做）：只做工单分类辅助与人工复核；范围（不做）：不做自动回复、不改工单系统。退出标准：试点 4 周内分类准确率低于 85% 则停止。
常见错误
- 目标写成「提升效率」，没有指标和基线。
- 不写「不做」，范围在试点期无限膨胀。
- 章程只有你一个人签字，客户方没人认。
模板 7 · 试点计划
用途：用 4-8 周在真实用户、真实数据上验证价值，并给 Go/No-Go 提供可核查的证据。
填写说明
- 试点范围要小到能管住：一个团队、一个地区、一类工单。
- 主指标之外必须有护栏指标，防止为了指标牺牲安全。
- Go/No-Go 条件在开始前定好，不能等结果出来再商量。
模板正文
| 项目 | 内容 |
|---|---|
| 试点对象 | 部门 / 用户数 / 地区 / 场景 |
| 入选标准 | 什么条件的人和数据进入试点 |
| 对照与基线 | 对照组或历史基线，取数口径 |
| 主指标 | 例如分类准确率、解决率、处理时长 |
| 护栏指标 | 错误率、投诉率、时延、成本、安全事件 |
| 周期与节点 | 第 1 周上线，第 4 周中期复盘，第 8 周终评 |
| 治理节奏 | 周会、日报、问题升级路径 |
| Go 条件 | 例如主指标 ≥ 目标且护栏指标不劣化 10% |
| No-Go 条件 | 例如连续两周不达标或出现 P0 安全事件 |
| 沟通与培训 | 用户培训、FAQ、反馈渠道 |
| 回滚方案 | 谁决策、多久回滚、回到什么状态 |
示例片段（合成场景）
试点 2 个小组、共 24 名客服、4 周。主指标：分类准确率 ≥ 88%（基线为人工抽检 81%）；护栏：超时率不高于基线 +5%、无 PII 外泄事件。第 2 周若准确率 < 80%，立即暂停并复盘。
常见错误
- 试点选「最容易成功」的场景，结论无法外推。
- 没有对照组，指标变化说不清是谁的功劳。
- 把试点当上线：一开就是全量，失败无法回滚。
模板 8 · 评测计划
用途：在原型和试点阶段定义「怎么算答得好」，并让每次改动都能和上一版比较。
填写说明
- 评测集先冻结一版，再开始调提示词；否则等于用考题训练。
- 样本按真实分布分层，难例、边界、安全、无答案都要有。
- 自动评分必须配人工校准，抽 10%-20% 双人标注。
模板正文
| 评测维度 | 样本来源 | 样本量 | 评分方式 | 门槛 |
|---|---|---|---|---|
| 主任务正确性 | 人工 / LLM-as-judge + 人工校准 | |||
| 边界与难例 | ||||
| 安全与越权 | ||||
| 无答案处理 | ||||
| 时延与成本 | 线上日志 | 自动 |
30 条评测集的结构示例：正常 12 条 + 边界 6 条 + 难例 6 条 + 安全 3 条 + 无答案 3 条。
流程清单
- 【 】冻结评测集版本并记录来源
- 【 】双人独立标注，分歧逐条讨论
- 【 】自动评分与人工评分一致性 ≥ 80%
- 【 】每次改动跑全量回归，记录 diff
- 【 】评测集定期换血，防止过期
示例片段（合成场景）
工单分类评测集 30 条：正常 12、边界 6、难例 6、安全 3、无答案 3。门槛：正常类准确率 ≥ 90%，安全类 100% 不泄露，无答案类 100% 可以拒答。每次改提示词后跑一遍，diff 记录到 evals/2026-03-08.md。
常见错误
- 用训练或调参用过的样本做评测，指标虚高。
- 只测 happy path，上线后被真实长尾打穿。
- 只看总分，不看哪一类样本在退化。
模板 9 · 上线就绪检查
用途：上线前逐项确认证据，避免「Demo 很稳」变成「生产事故」。
填写说明
- 每项都要有证据链接或截图，不接受口头确认。
- 任何一项为「否」都必须有书面豁免和风险接受人。
- 检查会由客户方技术负责人主持，你只提供证据。
模板正文
| 检查域 | 检查项 | 证据 | 负责人 | 是 / 否 / 豁免 |
|---|---|---|---|---|
| 功能与评测 | 评测集全量通过，门槛达标 | |||
| 功能与评测 | 已知问题清单与影响说明 | |||
| 数据与权限 | 数据接入稳定运行 ≥ 5 天 | |||
| 数据与权限 | 权限按最小原则配置并验证越权 | |||
| 安全与合规 | PII 脱敏与日志脱敏已验证 | |||
| 安全与合规 | 提示注入与越权测试通过 | |||
| 可观测性 | 日志、指标、trace、告警可用 | |||
| 可观测性 | 值班表与升级路径已确认 | |||
| 发布与回滚 | 灰度方案与回滚演练完成 | |||
| 发布与回滚 | 变更评审与发布窗口已批准 | |||
| 用户与支持 | 用户培训、FAQ、反馈渠道就绪 | |||
| 用户与支持 | 上线后 2 周支持资源已安排 |
示例片段（合成场景）
「提示注入与越权测试通过」的证据：security/redteam-2026-03-06.md，覆盖 12 条注入样例与 6 条越权路径，全部拦截；剩余 1 条低风险项由客户安全负责人签字豁免。
常见错误
- 检查表全打勾，但没有任何证据链接。
- 把「回滚方案」写成「出问题就回滚」，没有演练过。
- 上线前才找安全与运维，评审排不进窗口。
模板 10 · Runbook
用途：把「服务怎么跑、坏了怎么办」写清楚，让不熟悉项目的人也能在夜里处理故障。
填写说明
- 假设读者是没参与过项目的新人，所有缩写第一次出现要解释。
- 每个告警都要有「第一步做什么」和「什么时候升级」。
- 联系人写岗位 + 电话/群，不写「找小王」。
模板正文
服务概览
| 项目 | 内容 |
|---|---|
| 服务名 / 版本 | |
| 业务影响 | 影响哪些用户、哪些流程 |
| 架构与依赖 | 上游、下游、模型、数据库、第三方接口 |
| 数据与合规等级 | 是否含 PII、是否出域 |
| 值班与升级 | 一线 / 二线 / 业务负责人 |
告警处置
| 告警 | 含义 | 第一步 | 升级条件 |
|---|---|---|---|
| 错误率 > 5% | 接口或模型异常 | 查最近发布与依赖状态 | 15 分钟未恢复 |
| P95 时延 > 8s | 模型或网络慢 | 查模型服务与限流 | 用户投诉出现 |
| 安全告警 | 疑似注入或越权 | 立即限流并保留证据 | 立即升级安全负责人 |
常见故障
| 症状 | 判断 | 动作 |
|---|---|---|
| 回答突然变差 | 模型升级或提示词变更 | 对比版本、回滚提示词 |
| 数据不更新 | 管道或权限过期 | 查任务日志、续期权限 |
| 大量拒答 | 检索无结果或阈值过高 | 查索引、临时放宽阈值 |
回滚步骤：1. 确认发布版本与回滚目标；2. 执行回滚命令并验证健康检查；3. 通知业务方与值班群；4. 保留现场日志，次日复盘。
示例片段（合成场景）
告警「错误率 > 5%」：先看发布记录，若 30 分钟内有发布，直接回滚；否则查模型服务健康页与下游工单 API。15 分钟未恢复，升级到二线并通知客服主管。
常见错误
- Runbook 写成架构文档，故障时找不到动作。
- 只写正常流程，不写降级和回滚。
- 一年不更新，服务早就改了三版。
模板 11 · 交接清单
用途：把系统、知识和责任完整交给客户团队或内部团队，让项目在你离开后还能跑。
填写说明
- 交接以「对方能独立操作一遍」为标准，不以「讲过了」为标准。
- 每项写清位置（仓库路径、文档链接、账号归属），不写「见附件」。
- 留 2-4 周在岗支持期，并约定支持期后的响应方式。
模板正文
| 类别 | 交接项 | 位置 / 凭证 | 接收人 | 验收方式 |
|---|---|---|---|---|
| 代码与文档 | 仓库、分支规范、部署脚本 | 对方独立部署一次 | ||
| 代码与文档 | 架构说明、ADR、已知限制 | 能讲清依赖与边界 | ||
| 环境与密钥 | 环境清单、账号、密钥托管 | 密钥轮换演练 | ||
| 环境与密钥 | 发布与回滚流程 | 对方执行一次回滚 | ||
| 数据与管道 | 数据地图、字段口径、调度 | 对方跑通一次同步 | ||
| 评测与监控 | 评测集、回归流程、看板 | 对方跑一次评测 | ||
| 流程与培训 | Runbook、SOP、培训录像 | 新人按 Runbook 处理一次告警 | ||
| 支持与验收 | 支持期、响应时限、升级路径 | 双方签字 |
示例片段（合成场景）
支持期 4 周：每周二 30 分钟答疑，P1 故障 2 小时内响应。第 3 周由客户工程师独立完成一次「改提示词 → 跑回归 → 灰度发布」，我方只观察不操作，通过即视为交接完成。
常见错误
- 交接等于发文档，对方从没操作过。
- 账号和密钥仍留在个人名下，人走系统瘫。
- 支持期没有截止，变成无限期免费驻场。
模板 12 · 事故复盘
用途：事故后 48 小时内完成一次无责复盘，产出可跟踪的改进项，避免同一次事故重演。
填写说明
- 对事不对人：问「什么机制让这个错误发生」，不问「谁干的」。
- 时间线精确到分钟，写事实不写评价。
- 每个行动项必须有 owner、截止时间和验证方式。
模板正文
| 字段 | 内容 |
|---|---|
| 事故标题 | 时间 + 影响对象 + 现象 |
| 严重级别 | P0 / P1 / P2 |
| 影响 | 用户数、业务损失、数据影响、持续时长 |
| 发现方式 | 告警 / 用户投诉 / 巡检 |
| 时间线 | 时间 → 事件 → 谁做了什么 |
| 根因 | 用 5 Whys 追到机制层 |
| 做得好 | 哪些响应动作有效 |
| 要改进 | 流程、监控、测试、沟通 |
| 行动项 | 动作 / owner / 截止 / 验证方式 |
| 跟进 | 下次复查日期 |
示例片段（合成场景）
事故：3 月 8 日 09:20-10:05，工单分类服务错误率 12%，影响约 300 张工单。根因：新提示词未跑回归就发布，且缺少发布前评测门槛。行动项：①CI 增加评测门槛（李工，3/15）；②发布清单加入评测证据（王工，3/12）；③补 20 条难例进评测集（你，3/20）。
常见错误
- 复盘开成追责会，真话没人说。
- 根因停在「操作失误」，不改进机制。
- 行动项没有 owner 和截止，下次照旧。
小结
- 模板的价值在逼你把假设写下来，不在于填得多漂亮。
- 12 份不必全用：小项目至少用 1、5、6、7、9、11；涉及线上服务再加 10、12。
- 每份模板都留一栏「本例不适用」的理由，比硬填更有说服力。