第 7 章 · 你的第一个部署
本章你会学到：怎么用三个实战 Lab 完成第一次完整部署，怎么选择适合自己的场景，以及怎么把过程整理成作品集。
一句话：你的第一个部署应该小到一个人能做完，又完整到能证明方法有效——重点不是技术多先进，而是每一步都有证据。
一个现场片段
以下为合成场景，用于说明典型情境，不对应任何真实客户。
一位刚转岗的读者花了两个星期做了一个客服 AI 助手。演示会上，他把一个真实工单粘进去，模型准确地说出了分类、还写了一段回复，全场鼓掌。
业务负责人问了三个问题：「比现在的规则快多少？」「分错了会怎样？」「上线之后谁维护？」
他答不上来。因为他没有基线，没有评测集，也没想过错分的后果。技术上他没做错什么，但他做的是一次表演，不是一个部署。更要命的是，这场演示让他误以为自己已经会了——直到真的接手一个项目，才发现自己缺的不是模型调用，而是定义、验证和交接。
这一章要解决的，就是从这个尴尬里走出来：把「我能做出一个 demo」变成「我能交付一个有证据、有边界、能维护的小系统」。
为什么必须做项目
读到这里，你已经知道现场五问、六阶段、价值证据金字塔。但知识和动作是两回事。
做一次项目，你会得到四样读书给不了的东西：
- 基线感：亲眼看到规则基线有多差、模型比它好多少，你对「AI 到底带来多少提升」才有真实判断；
- 评测感：知道什么叫「这个数字可信」——样本从哪来、口径是什么、哪一类最差；
- 取舍感：亲手放弃过功能，才知道范围收窄为什么是 FDE 的核心动作；
- 复盘素材：面试里最值钱的不是成功故事，而是「我判断错了，后来怎么发现、怎么改」。
| 维度 | 只读文章 | 做一个 Lab |
|---|---|---|
| 输入 | 别人的结论 | 你自己造的数据和指标 |
| 输出 | 笔记 | 可运行系统 + 评测报告 |
| 反馈 | 无 | 跑出来的数字会打脸 |
| 失败成本 | 很低 | 很低（数据是合成的） |
| 能写进简历 | 很难 | 一页纸作品集 |
第一个部署的合理预期
不要把 Lab 想成「要做出产品」。它是一次压缩版部署：范围窄、数据合成、用户是同学或同事。据 Sierra 官方博客 2025-09-02 的匿名客户总结，五个客户的上线时间最快不到两周、最慢六周（官方口径）；Sierra 官网 2026-03-17 的客户案例里，Vivid Seats 用四周上线、自助解决率提升 40%（公司披露口径）。这些都是产品化公司的数字，不代表你要做到同样速度，但可以帮你校准「一个小场景大概要多久」。
项目驱动学习的三个原则
做 Lab 时，用三条原则约束自己，它们也是 FDE 在现场的工作方式：
- 窄到一个人能做完。一个队列、一个部门、一种文档类型，就是 v1 的全部范围。范围每扩大一倍，需要的数据、评测和沟通成本大约翻两倍；对第一个项目来说，窄是唯一能保证做不完风险可控的办法。
- 永远有对照组。规则基线、人工基线、上一版模型，至少有一个。没有对照，你的「提升」无法被验证，也无法说服业务方。
- 留证据。每次评测记录数据版本、提示词版本、模型版本、指标口径。三个月后回看，你要能解释「当时为什么得出这个结论」——这也是面试里最容易被追问的部分。
这三条的共同点是：它们都在对抗「自我感觉良好」。演示会给你错觉，数字不会。
三个 Lab：先选一个
| Lab | 一句话 | 适合谁 | 技术重点 | 作品集产出 | 难度 | 周期 |
|---|---|---|---|---|---|---|
| Lab A · 客服工单智能分流 | 把工单分到对的队列 | 想练完整交付闭环 | 分类、置信度、人工复核 | 分流系统 + 评测报告 | ★★☆ | 15-20 小时 |
| Lab B · 合同条款审查 | 把合同里的风险条款标出来 | 法务、采购、咨询背景 | RAG、引用校验、缺失检查 | 审查助手 + 漏检分析 | ★★★ | 12-16 小时 |
| Lab C · 企业知识助手 | 让员工问到带引用的答案 | 企业 IT、产品、知识管理 | 检索、权限、无答案处理 | 知识助手 + 权限红队 | ★★★ | 12-16 小时 |
三类人这么选：
- 第一次完整做项目：选 A。它的六阶段最齐，风险最低，最容易一个人做完；
- 日常和文档、风险、合规打交道：选 B。它训练「可核对」的肌肉：引用、缺失、人工复核；
- 在企业内部推动落地：选 C。它训练权限、治理和「敢说不知道」，这三件事在企业里最容易翻车。
还有一个更实际的选择标准：选你身边有人愿意试用的问题。有 3 个真实用户愿意每周给你 20 分钟反馈，比技术选型重要得多。
以 Lab A 为主线，走一遍六阶段
下面把 六阶段交付法 放到 Lab A 的场景里。每个阶段给：目标、动作、产出、退出标准，以及它在 Lab 里的压缩方式。
Lab 是真实部署的压缩版：真实项目按第 6 章的节奏走（发现约 2 周、定义 1-2 周、原型 2-4 周、试点 4-8 周、生产 2-4 周），你在 Lab 里用 15-20 小时把同样的动作各做一遍，重点是产出物和判断标准，而不是真的等 12 周。按每周 3-5 小时的业余节奏，Lab A 大约 5-6 周完成：
| 周次 | 阶段 | 本周产出 | 检查点 |
|---|---|---|---|
| 第 1 周 | 发现 + 定义 | 发现记录、项目章程、标签体系 v1 | 能复述现场五问；owner 认可指标 |
| 第 2 周 | 原型（数据与基线） | 合成数据、标注集、规则基线 | 基线可复现 |
| 第 3 周 | 原型（模型与评测） | 可演示原型、评测 v1、校准表 | 超过基线 10 个点 |
| 第 4 周 | 试点（模拟） | 盲测集结果、模拟周报 | 自动档抽检准确率 ≥ 95% |
| 第 5 周 | 生产（纸面演练） | 上线就绪包、Runbook、回滚演练 | 回滚能在 5 分钟内完成 |
| 第 6 周 | 移交 | 交接文档、复盘、作品集一页纸 | 别人能按文档复现评测 |
发现 Discover（真实项目约 2 周 / Lab 内约 2 小时）
目标：确认这个问题值得做，并找到真实的痛。
你要做的动作：
- 找 3 个一线使用者聊 30 分钟，问「最近一次让你骂人的工单是什么」；
- 影子跟岗 2 小时，看他们实际怎么分类、卡在哪；
- 抽 50 张历史工单读一遍，统计有多少是多问题混杂、信息缺失；
- 用现场五问收敛：谁痛？痛多大？现在怎么解？为什么是现在？谁为结果买单？
产出：一页发现记录（流程、痛点、基线数据、风险）。
退出标准：你能用一段话说清这五问，且业务负责人听完说「对，就是这个」。
别跳过发现
直接问客户「你想要什么功能」，你会得到一个功能清单；问「你上一次因为这件事加班是什么时候」，你才会得到真实约束。
定义 Define（真实项目 1-2 周 / Lab 内约 2 小时）
目标：把问题收窄成一个可验证的 v1。
你要做的动作：
- 砍范围：只做一级分类和分派，不做自动回复、不做优先级、不做多语言；
- 定指标：主指标 macro-F1、护栏指标自动子集准确率、业务指标首次分派时长；
- 定基线：先写规则分类器，跑出基线数字；
- 写项目章程：问题、用户、指标、边界、数据来源、风险、退出标准。
产出：项目章程（模板见 附录 B），一页纸。
退出标准：业务 owner 认可指标口径，并且明确「哪些不做」。
原型 Prototype（真实项目 2-4 周 / Lab 内 5-7 小时）
目标：用最小成本证明「模型 + 人工复核」比基线好。
你要做的动作：
- 造数据：合成 800 条工单，标注约 500 条，划分 few-shot、开发集、评测集、盲测集；
- 跑规则基线，记录 macro-F1 和每类 F1；
- 接 OpenAI 兼容 API，按 JSON 契约输出分类、置信度、原文依据；
- 用开发集校准置信度，确定自动 / 建议 / 人工三档阈值；
- 做一版可演示界面（命令行或简单网页都行）。
产出：可运行原型 + 评测报告 v0。
退出标准：在评测集上 macro-F1 超过基线至少 10 个点（示例标准，按你的场景调整），且错误能被解释。
试点 Pilot（真实项目 4-8 周 / Lab 内约 3 小时模拟）
目标：在小流量、有人盯着的情况下验证真实表现。
Lab 里怎么模拟：没有真实流量，就用盲测集 + 2 位同学扮演复核者，按下面的动作做一次模拟试点，产出周报；真实项目里这一步要真实用户、真实流量和每周复盘，持续 4-8 周。
你要做的动作：
- 先跑影子模式：模型只记录、不生效，连续 3 个工作日比对人工结果；
- 放 10% 流量，中低置信度全部人工确认，自动档抽检；
- 每周复盘：修正样本分类、错误归因、更新提示词与阈值；
- 盯三个数：自动档抽检准确率、人工修正率、首次分派时长。
产出：试点周报 + 评测报告 v1。
退出标准：连续 2 周自动档抽检准确率 ≥ 95%、修正率 ≤ 15%、无安全类错分、P95 时延达标。
生产 Production（真实项目 2-4 周 / Lab 内 2-3 小时纸面演练）
目标：让它能安全地长期运行。
Lab 里怎么演练：用开关模拟回滚、把监控指标写成看板草图、把 Runbook 写到「别人能照着操作」；真实项目里要真的接监控、真的演练。
你要做的动作：
- 补监控与告警：错误率、P95 时延、修正率突增、成本超预算；
- 写 Runbook：模型超时、返回非法 JSON、供应商故障、置信度分布异常各怎么办；
- 做权限与数据处理：脱敏、日志保留、访问控制；
- 做回滚开关：一键回到 100% 人工，并真的演练一次；
- 渐进放量：10% → 30% → 60% → 100%，每档设定放量与回滚条件。
产出：上线就绪包（检查清单 + Runbook + 灰度方案）。
退出标准：on-call 有人、回滚演练通过、SLO 达标。
移交与规模化 Handover & Scale（真实项目持续 / Lab 内约 2 小时）
目标：让系统离开你也能活，并把现场发现变成可复用的东西。
你要做的动作：
- 写交接文档：架构、指标、常见故障、评测集维护方式；
- 培训使用者与维护者：怎么改标签、怎么跑评测、怎么换模型；
- 明确评测集 owner，约定每月补充、每季度重评；
- 做一次产品反哺：把分类体系、提示词模板、评测集结构整理成可复用资产；
- 复盘：哪些判断错了、哪些风险没预料到。
产出：交接清单 + 复盘报告 + 一条产品需求。
退出标准：客户团队能独立跑评测、独立改提示词，你只做季度评审。
六阶段不是瀑布
真实项目会回退：试点发现标签体系有问题，要回定义阶段改；生产发现成本过高，要回原型阶段做取舍。阶段是检查点，不是流水线。
六阶段各自的常见错误
| 阶段 | 常见错误 | 后果 | 避免方法 |
|---|---|---|---|
| 发现 | 只和 IT 聊，不跟用户聊 | 定义出来的是「IT 想要的功能」 | 影子跟岗 + 找一线用户 |
| 定义 | 定了准确率目标，却没有基线 | 无法证明价值 | 先跑基线再定目标 |
| 原型 | 用真实数据反复调提示词 | 过拟合，上线崩 | 开发集调、评测集只跑 |
| 试点 | 直接全量放开、没有监控 | 出事无感知 | 影子模式 + 灰度 |
| 生产 | 没有回滚开关 | 故障时长不可控 | 上线前演练回滚 |
| 移交 | 文档只写「怎么用」，不写「怎么坏」 | 出故障没人会修 | Runbook + 故障演练 |
Lab B / C 和 Lab A 的差异
同样套六阶段，三个 Lab 的重心完全不同：
| 维度 | Lab A 工单分流 | Lab B 合同审查 | Lab C 知识助手 |
|---|---|---|---|
| 输入 | 短文本工单 | 长文档合同 | 多源知识库 + 用户身份 |
| 核心风险 | 分错队列、安全类漏放 | 高风险条款漏检、编造引用 | 越权泄漏、幻觉答案 |
| 主指标 | macro-F1 + 自动覆盖率 | 高风险召回 + 引用正确率 | 引用准确 + 无答案正确率 |
| 人工角色 | 复核低置信度分派 | 法务做最终判断 | 用户反馈 + 知识管理员修复 |
| 最难的部分 | 置信度校准与阈值 | 缺失条款检查与引用校验 | 权限前置过滤与拒答 |
| 发现阶段重点 | 看坐席怎么分派 | 和法务一起写 playbook | 摸清文档分布与权限模型 |
Lab B 的差异：它是「找问题」而不是「做分类」。合同里最危险的是「该写没写」的条款，所以除了检索，还要有独立的缺失检查；所有结论必须能点回原文，且产品必须明确「不构成法律意见」。在发现阶段，你最重要的访谈对象是法务，产出物是一份 playbook，而不是数据标注规范。
Lab C 的差异：它是「受约束的问答」。技术上最容易被低估的是权限：必须在检索前过滤，而不是生成后删；产品上最容易被低估的是拒答：员工能接受「没找到」，不能接受「编一个」。在发现阶段，你要摸清文档分布在哪些系统、权限怎么同步、谁是内容 owner；在试点阶段，一定要做权限红队。
如果你选 B 或 C，在六阶段上额外注意三件事：
- 发现阶段多花时间：B 需要和法务一起写 playbook，C 需要摸清文档与权限；这两件事做浅了，后面全是返工；
- 原型阶段先搭「引用 / 权限」的骨架：不要等模型效果好了再补引用校验和权限过滤，它们会改变架构；
- 试点阶段必须红队：B 测「漏检 + 编造引用」，C 测「越权 + 追问绕过」；自己测不出来，就找同事扮演攻击者。
作品集包装
做完 Lab，把它压缩成一页纸。结构固定，六块：
| 板块 | 写什么 | 判断标准 |
|---|---|---|
| 问题与用户 | 谁痛、痛多大、现在怎么解 | 不用术语也能听懂 |
| 基线 | 现有做法 + 数字 | 有口径、可复现 |
| 方案与取舍 | 架构 + 为什么这么选 + 放弃了什么 | 能说出至少一个放弃的方案 |
| 指标与证据 | 主指标、护栏指标、评测集结构 | 数字成对出现，不挑好的说 |
| 风险与控制 | 人工复核、回滚、安全边界 | 能回答「出错会怎样」 |
| 复盘 | 判断错在哪、重做怎么改 | 具体、可验证 |
别这样写作品集
- 「准确率 95%」——哪个集合？多少条？基线多少？
- 「效率提升 10 倍」——谁的时间？怎么算的？
- 「已上线」——试点还是全量？灰度多少？谁维护？
- 「效果很好」——没有数字的形容词一律删掉。
改写示例：
- 原句「模型准确率很高」→「在 200 条合成评测集上 macro-F1 0.84，规则基线 0.55；自动档覆盖 38%，自动子集准确率 96%」；
- 原句「大幅提升效率」→「试点 10% 流量两周，首次分派中位时长从 4 分钟降到 50 秒，人工修正率 12%」；
- 原句「已经上线」→「完成影子模式与 10% 灰度，正在 30% 灰度；回滚演练 1 次，耗时 2 分钟」。
一页纸可以用这个结构（Markdown 直接写）：
# 项目名：一句话说明它解决什么问题
- 问题与用户：
- 基线（现有做法 + 数字 + 口径）：
- 方案与架构（附 ASCII 图）：
- 放弃的方案与原因：
- 指标（主指标 + 护栏指标 + 评测集结构）：
- 风险与控制（人工复核 / 回滚 / 安全边界）：
- 复盘（判断错在哪、重做会怎么改）：写完用这份清单自检：
- 每个数字都带口径：数据集、样本量、版本
- 至少写了一个放弃的方案，并说明原因
- 回答「出错会怎样」：人工复核、回滚、安全边界
- 复盘里有判断错误，而不只是成绩
- 别人只看 README 和报告就能复现
常见失败与反模式
| 失败 | 典型症状 | 根因 | 补救 |
|---|---|---|---|
| 数据拿不到 | 卡在「等客户给数据」两周 | 把真实数据当前置条件 | 先用合成/公开数据跑通全流程，同时并行申请数据 |
| 没有基线 | 只有模型结果，没有对照 | 想跳过「土办法」 | 先写规则基线，哪怕只有 20 行 |
| Demo 很酷但没人用 | 演示掌声，试点没人点开 | 没有真实用户参与定义 | 找 3 个用户，从发现阶段就拉进来 |
| 评测集泄漏 | 指标高得离谱，上线打回原形 | 评测样本进了提示词或 few-shot | 四个集合分离，盲测集最后只跑一次 |
| 范围太大、没有 owner | 三个月还在「完善功能」 | 想一次解决所有问题 | 砍到一个队列/一个部门，找 owner 签字 |
| 把试点当上线 | 试点效果好就全量放开 | 没有灰度与回滚 | 补监控、告警、回滚演练再放量 |
| 只盯模型不盯流程 | 准确率上去了，业务指标没动 | 把 AI 当孤立组件 | 先画流程，找到真正的瓶颈 |
| 没算人工复核成本 | 复核把人累垮，最后干脆关掉 | 只算调用成本，不算人的时间 | 把复核工时算进总成本 |
本章小结
- 做项目的价值在于获得基线感、评测感、取舍感和复盘素材，而不是多一个 demo。
- 三个 Lab 选一个做完：A 练完整闭环，B 练可核对，C 练权限与拒答。
- 六阶段是检查点不是瀑布：每个阶段有产出和退出标准，允许回退。
- Lab B/C 与 Lab A 的根本差异在「风险类型」和「人工角色」，不在技术栈。
- 作品集一页纸，数字必须带口径；失败和取舍比成绩更有说服力。
练习
- 写项目章程：选一个 Lab，按「问题、用户、指标、边界、数据来源、风险、退出标准」写一页。判断标准：另一个人读完能说出「做什么、不做什么、怎么算成功」。
- 做一次 Go/No-Go 评审：让一位同伴扮演业务负责人，用 15 分钟挑战你的章程。判断标准：你能回答「基线是多少」「错了会怎样」「谁维护」三个问题。
- 写一页纸作品集：按六板块结构写，数字全部标口径。判断标准：删掉所有形容词后，仍然能看出价值和边界。
下一章：第 8 章 · 生产化、评测与安全——demo 和上线之间，到底隔着什么。