你有没有见过这种 Upwork 需求：

• “Build an AI chatbot for our internal docs.”
• “Need an agent to automate reporting.”
• “RAG system with UI, should be secure.”

一句话，看起来像“做个聊天机器人”。
但高客单的真实成交点，往往不在“你会不会写代码”，而在你能不能把这句话还原成一套可验收、可上线、可运维的系统。

本篇给你一套可直接复用的“读单法”三件套交付物：

1. 需求澄清问卷（15 问）
2. 技术可行性评估模板
3. 风险识别清单（含应对策略）

目标只有一个：把模糊需求变成可报价、可排期、可验收的交付边界。

---

0. 读单法的底层逻辑：一句需求 = 四个隐形合同

高客单项目里，客户嘴上说“做功能”，但实际在意四件事：

1. 范围：做哪些，不做哪些
2. 验收：怎么证明做成了
3. 风险：最容易翻车的点在哪里
4. 责任：你负责到哪一步，客户要配合什么

可以用一个最简单的结构表示：

你读单的水平，决定你把 A 推到 F 的速度与准确率。

---

1. 从一句话还原系统：用“系统六连问”拆开

我用一个稳定的“六连问”把需求还原成系统：

1. 用户是谁？（内部员工/外部客户/多角色权限）
2. 数据在哪？（文档源、权限、更新频率、格式）
3. 输出是什么？（问答/摘要/表格/动作执行）
4. 质量怎么衡量？（准确率、引用、延迟、覆盖率）
5. 上线形态？（网页/Slack/Teams/插件/API）
6. 运维约束？（内网/合规/审计/成本）

这六问的本质是：把“功能”翻译为“工程约束”。

---

2. 一句话需求的“概率模型”：你在赌什么？

高客单项目失败，常见不是“技术做不出来”，而是需求不确定性过高导致返工。

用一个抽象公式帮你判断“这单是不是坑”：

[
\text{交付风险} \approx \text{需求不确定性} \times \text{集成复杂度} \times \text{验收模糊度}
]

三者任意一个高，你都要用“问卷 + 模板”把它压下来，否则报价越高，亏得越快。

---

交付物 1：需求澄清问卷（15 问，可直接发客户）

你可以把下面 15 问当作“Upwork 首次沟通标准件”，按顺序发出去。
注意：问题不是越多越好，而是每一问都能收敛范围 / 绑定验收 / 暴露风险。

A. 目标与范围（3 问）

1. 这套系统的核心目标是什么？（减少工单/提升检索/自动化流程/合规审计）
2. 你希望它解决的 Top 3 场景分别是什么？（每个场景给 1 个真实例子）
3. 明确一下 不做什么：有哪些功能你认为“可有可无/后续再做”？

B. 用户与权限（3 问）

4. 目标用户有几类角色？（管理员/普通员工/审计员/外部客户）
5. 是否需要 SSO/权限继承？（Azure AD/Okta/Google Workspace/LDAP）
6. 是否存在“按部门/项目隔离”的数据权限？（ABAC/RBAC 需求）

C. 数据与知识源（4 问）

7. 数据源有哪些？（SharePoint/Confluence/Google Drive/数据库/本地文件夹/邮箱）
8. 文档格式占比？（PDF/Word/HTML/图片扫描件）是否需要 OCR？
9. 更新频率与同步方式？（每日/实时/手动触发）是否需要增量索引？
10. 是否允许把数据发送到第三方 API？（若不允许=内网/本地模型路线）

D. 输出与交互（2 问）

11. 输出需要“引用来源”吗？（必须可追溯？引用到段落？）
12. 交互形态偏好？（Web UI/Slack/Teams/Chrome 插件/仅 API）

E. 质量、性能与验收（3 问）

13. 成功的验收指标是什么？（例如：Top-3 命中率、回答可引用率、平均延迟）
14. 期望并发与延迟？（并发用户数、P95 latency 目标）
15. 安全合规要求？（审计日志/脱敏/保留周期/数据出域/地区合规）

用法建议：

• 客户若回答不完整，你就能反向判断“需求成熟度”与“付费意愿”。
• 若客户拒绝回答关键问题（数据权限、验收指标、出域限制），你要提高报价或缩小范围。

---

交付物 2：技术可行性评估模板（可复制成 Notion/Doc）

下面模板的作用是：你用 30 分钟把客户的需求“落到工程现实”，并形成可报价的结论。

2.1 项目基本信息

• 项目名称：
• 客户行业/合规约束：
• 目标上线时间：
• 预算区间（若已知）：
• 交付模式：PoC / MVP / Production

2.2 系统形态（System Shape）

• 渠道：Web / Slack / Teams / API
• 部署：云上 / 内网 / 混合
• 身份认证：SSO / 本地账号 / 无登录
• 数据隔离：单租户 / 多租户 / 部门隔离

2.3 数据可用性（Data Readiness）

• 数据源清单：
• 权限获取方式（API/导出/爬取/人工提供）：
• 文档质量：可复制文本比例 / 扫描件比例 / 是否需要 OCR
• 元数据是否完整（作者、时间、部门、权限标签）：
• 更新策略：全量/增量/事件触发

结论：

• 可直接用 / 需要清洗 / 需要补标签 / 需要权限对齐

2.4 技术路线可行性（Feasibility）

• RAG 必要性：高/中/低
• 是否需要 rerank：是/否（理由）
• 是否需要多模态（图表/扫描件）：是/否
• 是否需要 Agent（工具调用/自动化）：是/否
• 模型与成本约束：云 API / 本地模型 / 混合

2.5 性能与成本粗估（Rough Sizing）

你不需要在读单阶段算得很精，但要能给“量级判断”。

你只要能给出：M 的量级（10万/100万/1000万），就能判断用什么索引、是否需要分片、是否需要异步构建。

2.6 验收方案草案（Acceptance Draft）

• 功能验收：场景用例（不少于 10 条）
• 质量验收：Top-k 命中率 / 引用覆盖率 / 人工评审通过率
• 性能验收：P95 延迟、并发、吞吐
• 安全验收：权限穿透测试、审计日志完整性

2.7 结论（Go / Risky / No-Go）

• Go：可做，建议 PoC→MVP→Prod 分阶段
• Risky：需客户补数据/补权限/明确验收
• No-Go：关键假设不成立（例如数据不可访问、合规不允许、验收无法定义）

---

交付物 3：风险识别清单（高客单必备）

高客单项目，你要像做交付一样做风险。下面清单按“最常翻车”排序。

3.1 需求与范围风险

• 需求持续变更（Scope Creep）

  • 应对：里程碑拆分 + 变更单机制（每次变更影响报价/排期）

• “想要 Agent，但其实没定义动作边界”

  • 应对：先定义工具清单与权限模型，再做自动化

3.2 数据与权限风险（最常见）

• 文档权限无法对齐（RAG 生成越权内容）

  • 应对：索引层权限标签 + 查询时过滤 + 红队测试

• 文档质量差（扫描件/OCR 噪声）

  • 应对：分层处理（可复制文本优先），OCR 作为二期

• 数据更新频繁导致索引过期

  • 应对：增量索引 + 版本号 + 回滚策略

3.3 质量与“幻觉”风险

• 生成回答无引用、不可追溯

  • 应对：强制引用策略（无证据则拒答/提示）

• 评测指标缺失导致“做没做好”说不清

  • 应对：建立小评测集 + 人工评审表单 + 阈值

3.4 性能与成本风险

• 并发上来后延迟飙升

  • 应对：缓存、异步队列、分层检索、限流

• LLM 成本失控

  • 应对：token 预算、摘要缓存、分级模型（cheap→expensive）

3.5 安全与合规风险

• 数据出域限制（不能用云 API）

  • 应对：本地模型方案 + 审计日志 + 脱敏策略

• 审计要求：谁问了什么、用了哪些文档

  • 应对：请求日志 + 引用链路 + 保留策略

3.6 交付与运维风险

• 交付后无人维护，系统快速腐化

  • 应对：SOP + 监控告警 + 版本发布流程

• 客户环境不可控（网络、权限、IT 审批）

  • 应对：明确客户配合清单 + 环境验收前置

---

结尾：把“读单”变成你的高客单护城河

你会发现：
高客单读单不是“更会聊天”，而是你能用一套结构化流程，把客户一句话变成：

• 可落地的系统边界
• 可度量的验收指标
• 可预见的风险清单
• 可执行的报价与里程碑

这就是你从“写代码的人”升级为“交付负责人”的关键一跳。

---

最后留三个问题，欢迎你在评论区直接回答（也可以贴真实需求片段，脱敏即可）：

1. 你最近看到的 Upwork 需求里，哪一句最“短”，但你直觉最“贵”？为什么？
2. 如果客户不愿意提供样本文档与权限信息，你会怎么设计 PoC 的最小可行范围？
3. 你最怕哪一种风险：数据权限、验收指标、还是成本失控？你目前的解决习惯是什么？

下一章：

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