第 5 章 从需求到 SOW 与评估集
第 4 章 Discovery 跑完两周，你拿到了三样东西：一份 3 页的 Discovery 报告、一句话的真实问题加一个 outcome 数字、50 条客户工单种子样本。
你的老板会问：”好，下周可以开始写代码吗？”
不行。还差三样东西，否则下周写代码就是凭信仰：
- 评估集 v0——把 outcome 翻译成可自动跑的考试卷
- 验收标准——客户和你公司对”过线”的统一定义
- SOW——把 12 周的边界写死，避免范围蠕变
这一章讲怎么把 Discovery 的三样东西转成这三份”工程合同物”。这是 Discovery 阶段的最后一公里，也是 Scaffolding 阶段开工的入场券。
5.1 三份合同物的关系
它们是同一件事的三种语言：
- 评估集：工程师能跑的语言（输入、期望输出、通过条件）
- 验收标准：客户能签字的语言（数字、时间、边界）
- SOW：法务能盖章的语言（范围、责任、付款、退出）
Discovery 报告
↓
┌─────────┼─────────┐
↓ ↓ ↓
评估集 验收标准 SOW
(技术) (业务) (商务)
│ │ │
└────────┬─────────┘
三者一致
↓
开工写代码
为什么要分三份？因为它们各自的读者不同。工程师不读 SOW，法务不懂评估集，客户业务方既看不懂也不签技术文档。三份各自给一群读者，但三份必须互相对应——评估集里测什么，验收标准里就要写什么数字；验收标准写的边界，SOW 里就要列在 scope 里。
三者不一致 = 项目内部对”成功”的定义不一致 = 后期一定有撕扯。第 5.5 节会给一个三向对照清单，确保一致。
5.2 评估集 v0：工程师的考试卷
为什么要建评估集
第 2 章铁律 2 已经讲过为什么——这里展开评估集在项目生命周期里四个阶段的作用：
- 开发期间：每个 PR 自动跑分，避免”改了 A 把 B 改坏了”的回归。
- 上线前：客户 sign-off 的”过线分数”，写进合同。
- 上线后：模型升级、上游数据漂移的早期预警。系统某天分数掉了 5 个点，自动报警。
- Handoff 后：客户自己能跑评估集监控系统，不依赖你。
第 2 章讲了怎么在第一周从 0 到 30 条冷启动；Discovery 两周下来这 30 条会扩成 50 条种子样本（多出来的 20 条是 Discovery 期间业务方共同筛出的代表性 case）。这一章讲怎么从 50 条种子扩到 200 条全量评估集、怎么定结构、怎么打分。
一个最小评估集长什么样
目录结构：
evals/
├── README.md # 怎么跑、怎么读结果
├── seed_samples.jsonl # 50 条种子样本（来自 Discovery）
├── golden_set.jsonl # 100 条带标准答案（人工标注）
├── adversarial.jsonl # 30 条边角 / 攻击 / 异常输入
├── metrics.py # 评分函数
├── runner.py # 跑批入口
└── reports/ # 历史跑分快照
一条样本应该带的字段，以保单条款问答为例：
{
"id": "eval-007",
"category": "重疾险-等待期",
"input": {
"user_question": "我刚买的重疾险，2 周后体检发现甲状腺结节，能赔吗？",
"context_hint": "投保人的保单号: P-2024-XXX-001"
},
"expected": {
"must_contain_keywords": ["等待期", "90 天", "180 天", "确诊时间"],
"must_not_contain": ["不能赔", "肯定赔"],
"min_relevance_score": 0.8,
"reference_answer": "重疾险一般有 90-180 天等待期, 等待期内确诊的疾病保险公司有权拒赔。具体以您的保单为准。"
},
"metadata": {
"source": "客服工单 #2024-1042",
"annotator": "李某 (业务专家)",
"difficulty": "medium",
"weight": 1.0
}
}
读这个 schema 注意几件事：
- 不是只有 input/output。每条带分类、来源、难度、权重——这些字段在你想看”系统在哪一类问题上掉链子”时是关键。
- 不是只有”标准答案”。三层约束：必须包含的关键词（命中正确性）、不能包含的词（避免错误判断）、参考答案（用于语义相似度）。
- 不是一个分数。多个 metric 合成——单一分数会掩盖问题。
评分的三种打法
每条样本最终要算一个分。三种打法各有适用场景：
规则打分——最便宜也最稳。关键词命中、黑名单未命中、JSON Schema 校验。适合”必有 / 必无”的硬约束（保单号必须出现、绝对禁止说”肯定赔”）。不适合自然语言流畅度、风格判断。
语义相似度——中等成本。把答案和参考答案各做一次 embedding，算 cosine。适合开放问答的相关性检验。不适合精确数字（”30 天”和”31 天”语义相似度高，但业务上不能等同）和列表完整性。
LLM-as-judge——最贵也最灵活。用一个强模型（GPT-4 / Claude）判断答案对不对。适合风格、复杂判断、多维度打分。警告：被 judge 的模型不能和被测模型是同一个 family——这叫”同源偏置”，模型对自己生成风格的输出会系统性给高分（一些公开研究显示偏置可达 5-15 个点）。如果你在测 Claude，judge 用 GPT-4 或 Llama；测 GPT-4，judge 用 Claude。
实操建议：三层都用，按权重合成。一个常见配比是规则 30% + 相似度 30% + LLM-judge 40%。具体权重根据你的项目调，最好让客户业务方看着你调——他们对”哪种正确性更重要”有发言权。
在 AWS 平台上跑评估
如果项目跑在 Bedrock 上，平台原生提供 Evaluations 能力，可以省掉一些自己造轮子的活。三种 job 类型：
- Model Evaluation：评估单个基础模型的输出（不带 RAG / Agent）。用于选模型——比如你在做 Claude vs Nova vs Llama 的对比。
- Knowledge Base Evaluation：评估 RAG 系统的召回质量和生成质量。自动算 Context Relevance 和 Answer Faithfulness 两个核心 RAG 指标。
- Agent Evaluation：评估 agent 的多步推理路径。关键指标包括步骤数、工具调用准确率、最终输出的对错。
最小可跑流程：把 jsonl 数据集传到 S3 → 控制台创建 Evaluation Job（选 type、evaluator、metrics）→ 跑完看 Report（总分、分维度分数、失败样本 CSV、Trace 链路）→ 把 Report 接入 CI（Bedrock Eval API 在 PR 触发时跑，不过线 block merge）。
具体 API 和控制台入口随产品迭代变化，使用前以 docs.aws.amazon.com 为准。
评估集做错的常见姿势
入门者最容易踩的几个坑：
- 用训练数据当评估集——模型记住了答案，分数虚高。Scaffolding 阶段每周跑 0.95，上线一跑生产降到 0.6。
- 全是高频典型问题——缺边角，上线后被边角问题打爆。一定要留 20-30% 的位置给 adversarial 样本。
- 只有”成功样本”，没有”应该拒答”的样本——模型乱答 PII、越权问题、价值观敏感问题。这一类必须显式纳入评估集。
- 一条样本只算一个分——出问题时定位不到是召回错了还是生成错了。
- 评估集只在客户 demo 前跑一次——失去了”开发约束”的意义。CI 跑、本地跑、每天回归都要跑。
5.3 验收标准：客户的签字栏
验收标准是写给客户业务方和你公司商务方共同签字的文档。它的核心要求是可验——任何一个可能的争执，都能用这份文档里的某句话裁定。
一个反例和一个正例
反例——多数合同里长这样：
系统应能准确回答客户的保单咨询问题，准确率应达到行业领先水平。
这句话没法验。什么叫”准确”？什么叫”领先”？谁判？项目结尾你和客户必然吵架。
正例——可验版本：
验收标准 v1.0
─────────────────────────────────────────────────
环境：客户 staging (与生产同等数据，匿名化处理)
评估集：v0.1 共 200 条 (客户业务专家共同标注)
通过条件 (同时满足):
1. 整体准确率 ≥ 85% (关键词召回 + 语义相关 + LLM-judge 综合)
2. 高频问题 (top 20) 准确率 ≥ 95%
3. 安全性指标: 拒答 PII / 越权问题 100%
4. 性能: P95 响应时间 ≤ 3 秒 (P95 = 95% 请求快于该值)
5. 持续 7 天无人工干预、自动跑分稳定
不达标的处理:
- 单项不达标 → 修复后重跑
- 整体不达标 → 双方协商: 延期 OR 砍范围
验收节点:
- Day 60: 中期检查 (达成 70% 即可)
- Day 84: 正式验收
验收负责人:
- 客户方: [业务总监] + [IT 总监]
- 我方: [FDE] + [Tech Lead]
读这份验收标准注意：5 个要素都齐——数字（一组阈值）、时间（评估窗口加验收日期）、集合（在哪个评估集上算）、环境（在哪个环境跑）、不达标处理（谁有权延期、谁有权砍范围）。任何一个少了都会在项目尾声变成纠纷。
5 个必有要素的核对清单
| 要素 | 含义 | 没写的后果 |
|---|---|---|
| 数字 | 一个或多个具体阈值 | 客户后期可以说”我觉得不达标” |
| 时间 | 评估窗口、稳定时长、验收日期 | 客户可以无限延期验收 |
| 集合 | 在哪个数据集上算（评估集 v0.X，标明版本） | 双方对”什么样本算”扯皮 |
| 环境 | 在哪个环境跑（dev / staging / prod 影子流量——影子流量指生产真实请求复制一份发给系统但不返回结果给用户，只用于评估） | 客户在生产跑出来分低，吵 |
| 不达标处理 | 谁有权延期、谁有权砍范围 | 不达标时没人敢拍板，项目卡死 |
谁来定数字
客户业务方提期望、FDE 提评估方法、商务方做最终调节。三方都不能单方决定：
- 客户单方决定 → 数字大概率太高（”行业领先水平”），项目交付不了
- FDE 单方决定 → 数字大概率保守（”我们能做到的”），客户不认
- 商务单方决定 → 数字大概率被合同模板套用，没业务含义
最常见的扯皮发生在数字本身——客户说要 95%，你说 80% 才现实。这时候两个方法处理：
- 拿 baseline 跑给客户看。在评估集 v0 上跑一次最简单的 baseline（一个不调优的 LLM 直接回答），出一个数字，然后说”这是地板，我们的工程目标是从这个数字往上拱多少”。客户看到地板会重新校准期望。
- 分梯度验收。Day 60 中期 70%，Day 84 正式 85%。客户接受梯度比直接接受一个高指标容易得多。
5.4 SOW：商务的合同物
SOW (Statement of Work) 是把 outcome、验收标准、时间、钱写成法律文件。
FDE 必须亲自起草 4 段：Scope、Deliverables、Acceptance Criteria、Change Management——这 4 段都是”项目内容怎么定义、按什么验收、谁有权改”。FDE 自己写，因为只有 FDE 知道工程上能做到什么、做不到什么。
FDE 应该 review 但不必起草的段落：付款节点（商务）、IP 归属（法务）、保密 / NDA（法务）、违约责任（法务）、终止条款（法务和商务）。这些段落客户会用他们的合同模板，你不需要重写，但要 review——尤其确认”付款节点和 Deliverables 时间能对得上”，不要付款节点比 deliverable 早一周或晚两周。
下面展开必须自己起草的 4 段。
必须由 FDE 起草的 4 段
第一段：Scope（做什么 / 不做什么）
Scope (in):
- 保单条款 RAG 问答 (v0.1 评估集 200 条覆盖范围内)
- 客户经理 Web 端调用 (OpenAPI v1)
- CloudWatch 监控接入
- 一次 Handoff 培训 (4 小时)
Scope (out):
- 移动端集成 (客户自行做)
- 多语言支持 (仅中文)
- 投保前的销售话术 (不在范围内)
- 历史数据迁移 (客户自行准备数据)
Scope (out) 比 Scope (in) 更重要。这是 SOW 里你能给客户最值钱的东西——边界。客户可能本能反应是”为什么写这么多不做的”，你可以解释：”写清楚不做什么，是为了我们集中精力把要做的做透。”
第二段：Deliverables（交付物清单）
D1: Discovery 报告 (Week 2)
D2: 评估集 v0.1 (Week 3)
D3: 可演示 Demo + 评估报告 (Week 6)
D4: 生产部署 + 监控仪表盘 (Week 10)
D5: Runbook + 评估 v1.0 + 培训 (Week 12)
每个交付物要带接收人 + 接收方式 + 接收标准。比如 D3 不是只交付一个 demo 链接——是交付”客户业务总监在客户 staging 环境演示通过、过线分数 ≥ 70%、附评估报告 PDF”。
第三段：Acceptance Criteria（验收标准）——直接复用 5.3 的内容。
第四段：Change Management（变更管理）
变更触发条件:
- 客户提出新需求 → 走变更流程
- 客户业务方向变化 → 走变更流程
变更流程:
Step 1: 客户书面提变更请求
Step 2: FDE 5 工作日内评估变更对范围 / 时间 / 预算的影响
Step 3: 双方决定:
Option A: 接受变更 → 修订 SOW + 调整时间表 + 调整预算
Option B: 推迟到 Phase 2
Option C: 不做
无变更流程的口头需求 → 不进入 backlog
没有变更流程 = 客户每周给你新需求 = 项目永远不结束。
一个真实反例
12 周项目，SOW 里写了”AI 助手帮助销售提高效率”。第 4 周客户加了”也帮采购部用一下”，FDE 没拒绝。第 8 周采购部说”我们要的不是这个”，要重做。第 12 周交付不了，项目延期。
复盘：原始 SOW 没写 Scope (out)、没写变更流程。”销售”和”采购”是两个工作流，本来不该混。
这是 FDE 项目失败模式排第一的：scope 没写死。第一周宁可花两小时多写 Scope (out) 和变更流程，也不要让项目失败。
5.5 三份合同物的相互校验
写完评估集 + 验收标准 + SOW，做一次三向对照：
| # | 校验问题 | 不通过怎么办 | 真实失败样子 |
|---|---|---|---|
| 1 | 评估集里的每个 metric 在验收标准里都有对应的数字阈值吗？ | 没有就在验收标准里加 | 项目尾声客户发现你 LLM-judge 拿了 0.92，他要的是关键词召回 0.95 |
| 2 | 验收标准的”过线分数”能用评估集真实算出来吗？ | 不能就改 metric 的定义 | 验收标准写”自然程度高”，但评估集里没有衡量自然度的 metric |
| 3 | SOW 的每一项 Deliverables 都有对应的验收条件吗？ | 没有就补 | D3 demo 交付了客户说”这不是我们要的”，但 SOW 没说怎么验 demo |
| 4 | SOW 的 Scope (out) 在评估集里真的没出现吗？ | 出现就从评估集移除 | SOW 写”不做多语言”，但评估集里有 5 条英文样本，跑分把它们算进去 |
| 5 | SOW 的变更条款能 cover 评估集更新吗？ | 不能就补”评估集每月更新一次”的条款 | 第 8 周加了 50 条新样本，分数掉了，客户不认账，吵这是”标准变了” |
这 5 个对照看起来枯燥，但每一个都对应一个真实失败模式。第三周花一天做这件事，可以避免第十一周的崩盘。
5.6 一个端到端例子
把第 4 章的 Discovery 报告 + 这一章的三份合同物串起来，看一个完整的项目地基长什么样：
─── Discovery 输出 ─────────────────────────────────────
真实问题:
客户经理找一份保单条款的中位时间是 4 分 30 秒，
每月发生 1.2 万次。
期望 outcome:
3 个月内中位时间降到 30 秒以内。
种子样本:
客服工单导出 1000 条 → 业务专家筛 50 条代表性。
─── 评估集 v0.1 ────────────────────────────────────────
数据集: seed_samples (50) + golden_set (150) = 200 条
metrics: keyword_recall (规则)
semantic_similarity (cosine, 0.7+)
llm_judge_accuracy (Bedrock Claude)
评分公式: 0.3 × keyword + 0.3 × similarity + 0.4 × judge
通过分: 0.85
─── 验收标准 ───────────────────────────────────────────
环境: 客户 staging (脱敏数据)
通过条件:
1. 评估集总分 ≥ 0.85
2. Top 20 高频问题分 ≥ 0.95
3. P95 latency ≤ 3 秒
4. 中位时间从 4:30 降到 ≤ 30 秒 (实际样本统计)
5. 7 天稳定无人工干预
验收日: 第 84 天
─── SOW 关键段落 ───────────────────────────────────────
Scope (in): 保单条款 RAG (中文)
Web 端 OpenAPI
CloudWatch 监控
4 小时 Handoff 培训
Scope (out): 移动端 / 多语言 / 销售话术 / 数据迁移
Deliverables: D1 Discovery 报告 (W2)
D2 评估集 v0.1 (W3)
D3 Demo (W6)
D4 生产部署 (W10)
D5 Runbook + 评估 v1.0 + 培训 (W12)
变更流程: 书面 → FDE 5 工作日评估 → 修订 SOW
总预算: ¥XX
首付/中付/尾付: 30% / 40% / 30%
这一套合同物加上 Discovery 报告，是你接下来 12 周的工作图纸。Scaffolding 阶段写代码时遇到的所有”做不做这个、过不过线、改不改 scope”的判断，都在这套图纸里有答案。
5.7 第二周到第三周的踩坑
把这一章和上一章合起来看，Discovery 整个阶段（典型 1-3 周）最容易踩的几个坑：
评估集留到上线前才补。违反第 2 章铁律 2，等于整个 Scaffolding 阶段都没有 ground truth。
验收标准写”行业领先水平”等无法度量的话。无法验等于无法过，项目尾声必扯皮。
SOW 没写 Scope (out)。范围蠕变排第一的来源。
SOW 没写变更流程。客户每周加需求，永远做不完。
评估集等于训练集。数据泄露，分数虚高，上线翻车。
三份合同物不一致就开工。项目内部对”成功”的定义不同，第十周必然撕。
评估集只让 FDE 标注。没有业务专家校准，模型对了客户也不认。
收尾
到这一节结束，Discovery 阶段彻底闭环：你有了真实问题 + outcome 数字 + 50 条种子 + 200 条评估集 + 验收标准 + SOW。这一套东西签字之后，项目从”想清楚要做什么”进入”动手做”——Scaffolding 阶段。
Part III 进入 Scaffolding 阶段。第一个问题是：技术栈选什么？面对一个客户的实际项目，你应该怎么决定用哪个模型、用什么编排框架、要不要上 agent 平台。第 6 章用一个完整的工业制造案例展开——选型会议室、跨模型实测、决断流程，全部用真实数据。
本章引用的公开资料
- A. Lawrence, Forward Deployed Engineer Rule Book (2025) — scope 写死和变更流程的论述
- Conikeec, The Forward Deployed Engineer Playbook: A Practitioner’s Field Manual (Early Draft) (Substack) — “如果你写不出评估集，说明你还没真懂这个问题”的来源