第 3 篇：方案写作——SOW / 里程碑 / 验收标准 / 风险假设的标准模板

第 3 篇：方案写作------SOW / 里程碑 / 验收标准 / 风险假设的标准模板

- [0. 方案写作的核心：把风险转移到"可验证的假设"](#0. 方案写作的核心：把风险转移到“可验证的假设”)
- [1. 为什么要用 Rubric：把"感觉"变成"分数"](#1. 为什么要用 Rubric：把“感觉”变成“分数”)
[交付物 1：SOW 模板（含定价策略，可直接复制）](#交付物 1：SOW 模板（含定价策略，可直接复制）)
- [SOW（Statement of Work）模板](#SOW（Statement of Work）模板)
- - 1) Project Overview（项目概述） Project Overview（项目概述）)
  - 2) Scope（范围边界） Scope（范围边界）)
  - 3) Deliverables（交付物清单） Deliverables（交付物清单）)
  - 4) Acceptance Criteria（验收标准） Acceptance Criteria（验收标准）)
  - 5) Assumptions（关键假设） Assumptions（关键假设）)
  - 6) Risks & Mitigations（风险与应对） Risks & Mitigations（风险与应对）)
  - 7) Change Control（变更控制） Change Control（变更控制）)
  - 8) Pricing（定价策略：三档可选） Pricing（定价策略：三档可选）)
  - 9) Timeline & Communication（节奏与沟通） Timeline & Communication（节奏与沟通）)
  - 10) Ownership & Handover（交付与归属） Ownership & Handover（交付与归属）)
[交付物 2：里程碑拆解范式（可直接套用）](#交付物 2：里程碑拆解范式（可直接套用）)
- [2.1 三段式里程碑：PoC → MVP → Production](#2.1 三段式里程碑：PoC → MVP → Production)
- - [Milestone 1：PoC（1--2 周）](#Milestone 1：PoC（1–2 周）)
  - [Milestone 2：MVP（2--4 周）](#Milestone 2：MVP（2–4 周）)
  - [Milestone 3：Production（2--6 周，视复杂度）](#Milestone 3：Production（2–6 周，视复杂度）)
- [2.2 里程碑写法模板（每个 milestone 必填 6 行）](#2.2 里程碑写法模板（每个 milestone 必填 6 行）)
[交付物 3：验收 Rubric（评分量表，避免扯皮）](#交付物 3：验收 Rubric（评分量表，避免扯皮）)
- [3.1 Rubric 表（可直接贴到 SOW 附录）](#3.1 Rubric 表（可直接贴到 SOW 附录）)
- - [A. 功能完成度（0--3）](#A. 功能完成度（0–3）)
  - [B. 质量与可信度（0--3）](#B. 质量与可信度（0–3）)
  - [C. 性能与稳定性（0--3）](#C. 性能与稳定性（0–3）)
  - [D. 安全、审计与可运维（0--3）](#D. 安全、审计与可运维（0–3）)
- [3.2 验收流程模板（建议固定写进 SOW）](#3.2 验收流程模板（建议固定写进 SOW）)
- [结尾：你写的不是 Proposal，而是"交付契约"](#结尾：你写的不是 Proposal，而是“交付契约”)
- 下一篇：

你是不是也遇到过这种 Upwork 场景：

你技术上完全能做，但客户一句"Can you send a proposal?"，你就开始写长篇自嗨文案；
你写了方案，客户说"Looks good"，然后项目一启动就开始改需求；
最难受的是：做完了，客户说"Not what I expected"，你却拿不出一条"验收条款"反击。

高客单项目里，方案不是文案 ，而是一份"可执行合同"：

它的作用是把"不确定性"压缩到你可控的范围，并把付款与验收绑定。

本篇给你三套可直接复制的交付物：

SOW 模板（含定价策略）
里程碑拆解范式（从 PoC→MVP→Prod）
验收 Rubric（评分量表，避免扯皮）

0. 方案写作的核心：把风险转移到"可验证的假设"

一句话总结：
SOW = 交付范围 + 验收标准 + 风险假设 + 变更机制。

如果缺任何一块，你就会在"无限返工"里消耗利润。
客户一句需求
范围 Scope
验收 Acceptance
假设 Assumptions
风险 Risks
里程碑 Milestones
报价 Pricing
变更机制 Change Control

1. 为什么要用 Rubric：把"感觉"变成"分数"

没有 Rubric 的验收，是主观争论；有 Rubric，验收就变成评分。

你可以用一个抽象公式理解"验收争议"的来源：

Rubric 的作用就是把"验收模糊度"降到最低。

交付物 1：SOW 模板（含定价策略，可直接复制）

下面是我建议的 SOW 结构。你可以当作 Upwork Proposal 的"骨架"，并在附件中以 PDF/Doc 形式发给客户。

SOW（Statement of Work）模板

1) Project Overview（项目概述）

Business Goal（业务目标）：一句话描述要解决的业务问题
Target Users（目标用户）：角色与权限（Admin / User / Auditor）
Success Definition（成功定义）：用 1-3 条可度量指标表达"成功"

示例（可替换）：

"将内部文档检索从关键词搜索升级为可引用的问答与摘要"
"上线一个可审计的 AI 助理，支持权限过滤与引用追溯"

2) Scope（范围边界）

In Scope（包含）

数据接入：___（SharePoint/Confluence/Drive/DB）
索引与检索：切分、向量化、检索、可选 rerank
生成：带引用回答、拒答策略
交付形态：Web UI / API / Bot（写清楚）
基础运维：日志、监控最小集、部署文档

Out of Scope（不包含）

OCR/扫描件处理（如不做）
多语言/多模态（如不做）
复杂工作流自动化 Agent（如不做）
生产级 SSO/复杂 RBAC（如不做或另计）

Non-goals（明确不追求）

"100% 正确"
"覆盖所有历史文档"
"无人工参与即可完全自动化"

3) Deliverables（交付物清单）

PoC/MVP/Prod 对应交付物（写成可勾选列表）
文档：架构图、部署手册、运行手册、验收报告
代码：Repo、CI、配置模板、示例数据（如可提供）

4) Acceptance Criteria（验收标准）

把验收拆为三类：功能、质量、性能/安全。每条必须可测。

Functional：场景用例通过（≥X 条）
Quality：引用可追溯率、Top-k 命中率、人工评审通过率
Performance：P95 延迟、并发、吞吐（按环境说明）
Security/Compliance：审计日志、权限穿透测试、脱敏策略

（Rubric 在文末附录详述）

5) Assumptions（关键假设）

你必须写这一段，否则你在替客户承担环境与数据风险。

客户能提供可访问的数据源与必要权限
数据格式与质量满足最小要求（可复制文本占比、元数据完整度）
客户提供 10--30 条真实问题作为评测集
客户指定验收人并在里程碑周期内完成反馈

6) Risks & Mitigations（风险与应对）

把风险写出来不是"吓客户"，而是"对齐现实"。

数据权限对齐失败 → 采用权限标签过滤 / 先做单部门 PoC
文档噪声/OCR → 二期处理 / PoC 排除扫描件
需求波动 → 变更机制 / 增补里程碑
成本/延迟不达标 → 降级策略（缓存、分层模型、限流）

7) Change Control（变更控制）

任何新增需求进入 Change Request
变更影响：范围 / 排期 / 费用三项必须至少一项调整
每周一次范围确认（Scope checkpoint）

8) Pricing（定价策略：三档可选）

这里给你一个"结构化定价"写法，不像硬广，但让客户感到专业。

Option A: Fixed-price by Milestones（按里程碑固定价）

适合：需求较清晰、客户配合度高
优点：客户易决策，你易绑定验收与付款

Option B: Time & Materials with Cap（工时制 + 上限）

适合：需求不稳定、探索性强
写法：给出每周节奏 + 总上限 cap，避免客户焦虑

Option C: PoC First, then Expand（先 PoC 再扩展）

适合：高不确定性项目（最推荐）
优点：先用 1--2 周验证数据与可行性，再谈生产化预算

定价原则（写进 SOW 的一句话即可）：

"Pricing reflects scope, data readiness, security requirements, and acceptance rigor."

9) Timeline & Communication（节奏与沟通）

每周例会：1 次（30--45 min）
异步沟通：Upwork / Slack（写清楚）
里程碑验收反馈 SLA：例如 48 小时内确认

10) Ownership & Handover（交付与归属）

代码归属、部署归属、第三方 API Key 归属
交付后支持期（例如 7/14 天 bugfix window）
生产环境运维责任边界（你负责"可运行"，客户负责"资源/账号/合规审批"）

交付物 2：里程碑拆解范式（可直接套用）

里程碑拆解的原则：每一步都要产出可验收的"证据"，并逐步降低不确定性。

2.1 三段式里程碑：PoC → MVP → Production

锁定数据/范围/指标
补安全/监控/压测
PoC: 可行性验证
MVP: 可用系统
Prod: 可上线可运维

Milestone 1：PoC（1--2 周）

目的：验证"数据能用、检索有效、引用可追溯"
产出：

数据接入 + 最小索引（小样本）
Top-k 检索效果展示（含失败案例）
初版问答（强制引用）
PoC 评测集（10--30 问）+ 基线结果
验收证据：
Demo 视频/录屏
评测表（命中率、引用率）
风险清单更新

Milestone 2：MVP（2--4 周）

目的：让系统"能用"，并能被真实用户试用
产出：

全量/增量索引策略
UI 或 API（按约定）
权限过滤（至少做到"部门级/空间级"）
Prompt/模板可配置
基础日志与错误追踪
验收证据：
用例通过清单（≥X 条）
用户试用反馈（≥Y 人/≥Z 天）
性能初测（P95 延迟）

Milestone 3：Production（2--6 周，视复杂度）

目的：上线可运维、可审计、可回滚
产出：

部署自动化（Docker/CI）
监控告警（最小可观测集）
审计日志与脱敏
压测报告与容量建议
SOP：故障、回滚、重建索引
验收证据：
压测报告
审计样例（可追溯链路）
Runbook/SOP 文档

2.2 里程碑写法模板（每个 milestone 必填 6 行）

你可以复制这个结构去写每个里程碑：

Goal（目标）：
In Scope（范围）：
Deliverables（交付物）：
Acceptance（验收）：
Client Inputs（客户配合项）：
Risks（风险/阻塞项）：

这 6 行能极大减少"客户不配合但怪你"的概率。

交付物 3：验收 Rubric（评分量表，避免扯皮）

Rubric 的关键不是"写得漂亮"，而是让客户在验收时只能回答：达标/不达标/差一点。

下面给你一个通用 Rubric（适用于 RAG 与 Agent 项目），分四大维度，每维 0--3 分，总分 12 分。你可以设定：≥9 分通过；7--8 分带整改通过；≤6 分不通过。

3.1 Rubric 表（可直接贴到 SOW 附录）

A. 功能完成度（0--3）

0：核心场景无法跑通
1：部分场景可用，但经常中断
2：核心场景基本可用，偶发问题可复现可修复
3：所有约定场景稳定通过，边界条件处理明确

B. 质量与可信度（0--3）

建议至少包含两项指标：引用覆盖率 + 人工评审通过率。

0：回答不可追溯，幻觉频繁
1：有引用但不稳定，相关性不足
2：引用稳定，少量错误可通过"拒答/澄清"控制
3：引用到段落级，错误率低，拒答策略有效

可选量化口径示例（按项目改）：

C. 性能与稳定性（0--3）

0：延迟不可接受/经常超时
1：单用户可用，并发下明显退化
2：达到约定 P95 延迟与并发目标（在约定环境）
3：有缓存/限流/降级策略，峰值可控

D. 安全、审计与可运维（0--3）

0：无日志/无权限控制
1：有基础日志，但无法追溯引用与请求链路
2：具备审计日志与最小监控告警，权限过滤通过测试
3：有 SOP、回滚与重建索引流程，可观测指标齐全

3.2 验收流程模板（建议固定写进 SOW）

System Vendor(You) Client System Vendor(You) Client 提交验收问题集/用例运行评测与录屏输出结果+引用链路+日志提交验收包(报告/录屏/指标) 依据Rubric评分通过/整改项/不通过原因

验收包建议包含四件套：

Demo 录屏
指标表（含失败例）
运行日志/审计样例
已知问题与下一步建议

结尾：你写的不是 Proposal，而是"交付契约"

当你开始用 SOW + 里程碑 + Rubric 写方案，你会发现：

客户更愿意为"确定性"付费；
你更容易用"假设与验收"挡住无限返工；
你报价更稳，因为你能解释成本来自哪里。

最后留三个问题，欢迎你在评论区回答（越具体越好）：

你目前写 Upwork proposal 时，最容易被客户"反复改需求"的是哪一段？
你更倾向用 Fixed-price 还是 T&M？你的"踩坑原因"是什么？
如果客户坚持"不提供评测问题集"，你会如何在 SOW 里写验收与责任边界？

《第 4 章 RAG 工程底座 - 分块、索引、混合检索、Rerank 的可复用参数体系》