需求分析
需求分析
客服主管希望让 AI 自动分派工单，一线客服却常因转错部门而返工。团队需要查清分派慢在哪里、哪个问题值得投入，再决定如何处理。
需求分析把模糊诉求转成有证据支持的问题定义，再决定哪些方案值得验证或交付。本文以客服工单案例贯穿各个环节。
需求分析四步
整篇文章按收集 → 判断 → 分级 → 拆解展开：
flowchart LR
collect[收集：机会与假设] --> assess[判断：证据与需求定义]
assess --> rank[分级：验证或交付]
rank --> deliver[拆解：验收与停止条件]
deliver -. 结果回填 .-> assess图展示四步的工作顺序。每一步都要保留尚未验证的主张；调查结果会推动下一轮判断。
- 收集：保存原始诉求，检查机会方向，追问任务与动机，写出待检验的主张及方案候选（详见下文「需求来源」「机会识别与产品策略输入」「JTBD 与 Y 模型」）。
- 判断：核对证据支持的主张，对问题做三维度初筛，比较方案带来的用户价值，写出问题陈述与目标（详见「判断需求的价值」）。
- 分级：区分验证任务与交付需求，再决定优先级；证据不足的方案不因评分靠前就直接排期（详见「需求分级」）。
- 拆解：对获准执行的事项写出用户故事、验收标准、边界和出错处理；验证任务也要写明成功标准与停止条件。
四步中有六个决策点，前一步的产出成为后一步的输入：
| 四步 | 决策点 | 要回答的问题 | 留下的产出 |
|---|---|---|---|
| 收集 | 机会识别 | 什么方向值得调查？ | 机会范围与未知约束 |
| 收集 | 假设 | 用户遇到什么问题？有哪些解法？ | 可检验的主张与方案候选 |
| 判断 | 证据 | 每项主张得到什么支持？ | 证据与缺口 |
| 判断 | 需求定义 | 要解决哪个问题，目标如何衡量？ | 问题陈述与目标口径 |
| 分级 | 优先级 | 先验证还是进入功能排期？ | 验证任务或功能级别 |
| 拆解 | 验收 | 怎样执行、验收和停止？ | 用户故事与验收标准 |
市场机会表示值得调查的方向，需求定义描述得到证据支持的用户问题，功能方案用于解决该问题。例如「希望自动分派工单」是一个功能提议，需要回到分派耗时与转错返工的工作场景。AI 方案还需要验证模型能力、数据质量和业务收益（参见《启示录》精读笔记中的价值风险）。
一、收集：识别机会与提出假设
需求来源
- 用户反馈：客服记录、App Store 评论、社区吐槽、用户访谈。AI 产品额外有两类高价值反馈：模型出错被纠错的记录（说明能力边界与用户期待）、"拒答/答非所问"日志
- 数据分析：用户行为数据、搜索词、漏斗流失点。AI 产品加上对话日志：用户改写提问、放弃对话、复制粘贴输出，都是需求信号
- 竞品观察：竞品的新功能、差评集中的点。AI 产品迭代快，竞品差评往往集中在幻觉、延迟与不可解释——这是现成的改进方向
- 技术驱动：AI 能力跃迁带来的新可能性（模型新能力 → 新场景）。这是 AI 时代增长最快的来源，也是最容易产生伪需求的来源——能力是必要条件，不是充分条件
机会识别与产品策略输入
机会是值得调查的问题空间。市场阶段、竞争位置、公司目标、技术可行性和数据资产用于检查这个方向是否符合经营条件。这里的技术与数据判断只需识别明显障碍和验证路径；模型效果与数据质量要在后续验证。五个因素缺少资料时标记「待查」，不能当作已经通过：
| 因素 | 要回答的问题 | 不成立的表现 |
|---|---|---|
| 市场阶段 | 市场处于早期、增长、成熟还是衰退？ | 衰退市场里投入大资源 |
| 竞争位置 | 我们是领先者、追随者还是补位者？ | 落后方做同质化功能 |
| 公司目标 | 机会推进哪个业务目标（OKR/北极星）？ | 答不上来，做出来无人接 |
| 技术可行性 | 模型现在能做到什么程度？ | 上线后才发现能力不够 |
| 数据资产 | 我们有数据喂给模型和评测吗？ | 没有评测集与反馈闭环 |
市场阶段决定证据要求与迭代速度。下表「早期 / 增长 / 成熟 / 衰退」与产品生命周期的导入 / 成长 / 成熟 / 衰退同义，经营策略以生命周期页为准：
| 阶段 | 特征 | 证据要求 | 迭代速度 |
|---|---|---|---|
| 早期（导入期） | 需求未验证、竞品少、玩家多 | 定性 + 行为证据为主，容忍失败，快速试错 | 周级，先跑通再优化 |
| 增长（成长期） | 需求已验证、正在规模化 | 行为数据 + 业务结果，验证留存与成本结构 | 双周级，速度优先 |
| 成熟（成熟期） | 红海竞争、替换成本高 | 实验证据 + 明确 ROI，证明"显著优于"现有方案 | 月级，谨慎投入 |
| 衰退（衰退期） | 需求萎缩、用户在流失 | 只做防御性低成本改动，不做新探索 | 慢，以回收为主 |
公司战略与约束是需求的筛选条件，不是背景噪音。立项前逐条过：
- 这个需求推进公司的哪个目标？答不上来，至少不是战略级需求
- 目标客群覆盖了吗？给谁做的，谁买单，谁决策？
- 渠道可达吗？产品在目标客群会出现的渠道里吗？
- 品牌允许吗？功能的调性是否与品牌承诺冲突？
- 合规允许吗？数据获取、内容安全、行业监管是否挡路（AI 功能还要查生成式内容合规，见出海与合规）？
机会筛选的产出写成「目标客群 × 待解决的场景 × 经营目标 × 待查约束」。从中提出具体用户的问题主张，再用证据判断问题和解法；仅有机会方向不能进入功能排期。
从诉求形成假设
JTBD 与 Y 模型
Jobs-to-be-Done（JTBD）把需求拆成四个要素（Christensen 等 2016，"Know Your Customers' Jobs to Be Done"，HBR）：
| 要素 | 要回答的问题 |
|---|---|
| 任务 | 用户要完成什么"雇佣"产品的活？ |
| 动机 | 为什么是现在？不做的代价是什么？ |
| 情境 | 什么时间、地点、状态（情绪、设备、压力）下发生？ |
| 替代方案 | 现在怎么解决的？包括直接竞品、替代品、"不解决" |
询问现有做法和「暂时不处理」的后果，才能比较方案带来的改善。未找到现有做法时，继续调查任务发生的频率、限制条件与使用者，不能直接认定问题不存在。
苏杰的 Y 模型连接表层诉求（1）、目标动机（2）、产品功能（3）和人性/心智（4）（出自《人人都是产品经理 2.0》，本站有精读笔记）。实际分析时，先记录用户的说法，再追问任务、动机与顾虑，随后提出功能候选。访谈得到的描述与推测仍须分别核实；Y 模型本身不提供验证结果。
以客服工单为例，主管先提出「自动分派」；追问后要分别记录分派耗时、转错返工，以及客服是否在意误判责任。随后才能提出其他方案，如「系统给出路由建议，由客服确认」。此时两种功能都只是候选，验证方式见下文贯穿案例。
二、判断：检验证据与定义需求
证据强度与样本思维
按主张分别回答「凭什么信」：问题是否存在、影响范围多大、方案能否改善、用户会否采用，使用的证据各不相同。下表列出五类证据及其适用边界：
| 层级 | 证据类型 | 能证明 | 不能证明 |
|---|---|---|---|
| 1 | 定性证据（访谈、日记、现场观察） | 问题存在、动机、情境、语言 | 规模、频率、因果 |
| 2 | 描述性数据（问卷、调研） | 分布、倾向、人群画像 | 真实行为、因果 |
| 3 | 行为数据（日志、漏斗、留存、搜索词） | 用户实际做了什么 | 动机、因果 |
| 4 | 业务结果（收入、留存、转化、成本） | 是否变好、是否值得 | 是不是这个改动导致的 |
| 5 | 实验证据（A/B、随机对照） | 因果 | 长期效果、外部效度 |
三条纪律，违反任何一条都是证据误用：
- 访谈无法证明市场规模：访谈 8 个人说"很痛"，只能说明"存在这问题"，不能说明"有 100 万用户痛"（层级 1 不能证明层级 3 的问题）
- 调研不能替代行为证据：问卷里说"我会用"的用户，上线后大半不用——自我报告有系统性偏差（《The Mom Test》的核心警告：问出来的都是好话）
- 行为相关不自动推出因果：使用时长与满意度正相关，可能是满意度高才用得久，也可能只是重度用户自我说服——要分因果，上实验（层级 5）
每个需求主张至少需要哪种证据：
| 主张 | 最低证据 | 理想证据 |
|---|---|---|
| "用户有这个问题" | 5-8 次访谈 + 行为日志佐证 | 访谈 + 行为 + 业务结果三角互证 |
| "问题影响 X% 用户" | 有抽样框的问卷 | 行为数据（按人群分桶） |
| "解法会带来 Y 改善" | 行为基线与受控试用结果 | 实验证据或同期对照组 |
| "用户愿意付费" | 定价访谈（弱信号） | 假门测试 / 真实转化数据 |
证据不足时，将未决主张转成有成功标准的验证任务；验证结果决定是否继续投入功能开发。
判断需求的价值
问题筛选：频率、规模、收益
对从机会中提出的问题主张做初筛，记录已知数据、未知数据及获取方式：
- 频率与强度：出现多少次，造成多少等待、返工或损失
- 用户规模：影响多少用户
- 付费潜力或经营收益：外部产品关注买单者是否愿意付费；内部工具关注节省的人力、错误成本及业务收益
三项指标帮助判断问题是否值得继续调查；缺少规模或收益数据时，记录缺口及验证任务。频率高且强度低的诉求，也可能无法覆盖推理与维护成本。对有证据支持的问题，再比较候选方案与当前做法的用户价值。
已有用户的重要性和满意度研究可以补充初筛：机会评分 = 重要性 − 满意度，用于寻找用户认为重要、现有体验又不足的问题（成果驱动创新，Anthony Ulwick）。问卷分值需要核对样本和用户行为；新市场缺少既有满意度，无法直接使用这种评分。得分还受到公司目标、技术可行性与投入成本的约束。
用户价值公式与相对价格（俞军）
俞军的两个公式用于比较候选方案与现有替代方案（出自《俞军产品方法论》，本站有精读笔记）：
- 用户价值 = 新体验 − 旧体验 − 替换成本。比较同一用户在相同任务上的新旧体验，计算学习、迁移、复核与信任等替换成本。AI 的输出需要用户核查时，复核负担可能抵消节省的时间
- 相对价格 =（直接成本 + 交易成本）÷ 效用组合。从用户或买单者的视角记录付费、使用时间、等待和培训等代价，再比较获得的效用；企业侧的推理费用还需计入投入核算。二者的计量主体与单位须保持一致
按同一人群、同一任务比较新旧体验，列明节省时间、错误率、学习成本和信任成本等可观察项目；没有数据的项目保留为待检验主张。公式表达比较关系，主观分值不能替代行为数据，也不能把不同单位的成本与效用直接相减。用户价值初步成立后，还需核算组织收益、开发及运行成本，才能决定投入。
需求定义
将已获支持的问题写成「用户、情境、现有做法、问题及影响」，同时标注指标基线、目标的统计口径和未决事项。问题陈述不包含候选功能；尚未取得方案效果的证据时，将预期改善写成验证目标。客服案例中的问题陈述与目标见下文「需求定义：陈述问题与目标」。
三、分级：确定验证与交付顺序
需求分级
有明确的问题定义后，先判断证据是否足以支持功能排期。证据不足的方案安排验证任务；进入交付候选的方案，再比较收益、成本与时机，最后确定级别。
优先级模型
下面的工具各有用途：KANO 区分体验类型，RICE 与 WSJF 比较交付顺序，MoSCoW 协商本次交付范围。机会评分用于已有用户研究数据的问题筛选，见前文「判断需求的价值」。使用前先明确要回答的问题，并准备相应的数据；需要其他提问结构时可参考思维模型。
KANO 模型（Kano et al., 1984）
- 分类：基本型（必须有，缺失即不满——AI 产品的幻觉问题属于此类）、期望型（线性，越多越好——回答质量）、兴奋型（惊喜，缺失无感——超出预期的功能）；另有无差异型（有无都不影响满意度）和反向型（有了反而不满，例如风险敏感用户面对「自动执行」）
- 用法：问卷配对题（有/无两问）把需求分类，用于体验分层与差异化机会识别
- 失效条件：分类依赖用户感知，同一需求不同人群分类不同；无法在同一类内排序
- 常见误用：把"兴奋型"当"必做"；把基本型缺陷（幻觉、超时）当优化项；漏掉反向型，把「有人喜欢的自动化」当成全员必做
RICE 评分（Intercom 提出）
- 公式：RICE =（Reach × Impact × Confidence）÷ Effort
- 参数：Reach 受影响用户数/周期；Impact 对单个用户的影响（0.25-3 分档）；Confidence 对前两者的信心（50%-100%）；Effort 人月数
- 适用：功能候选排序，尤其有影响面数据时
- 失效条件：Impact 打分高度主观；Confidence 常被自欺（填 100% 的项目最多）；忽略依赖与时序——高 RICE 的项目依赖低 RICE 的基建时，顺序会错
- 常见误用：把分数当结论，不回到业务目标；用同一份 Impact 档位跨产品线比较
WSJF（SAFe 敏捷）
- 公式：WSJF =（业务价值 + 时间关键性 + 风险降低/机会开发）÷ 任务规模
- 核心思想：延迟成本（Cost of Delay）——晚做一个月损失多少
- 适用：迭代内排期，多需求竞争同一批资源时
- 失效条件：分值膨胀（都打 5，分母成为唯一变量）；任务规模估算误差被放大
- 常见误用：只适用于 backlog 排期，不适合战略选择——它不回答"做不做这个产品"
MoSCoW 分类（DSDM 范围管理；步骤与 AI 案例见思维模型 · MoSCoW）
- 分类：Must（必须有）、Should（应该有）、Could（可以有）、Won't（本次不做）
- 适用：固定时间盒（固定发布日）下的范围协商
- 失效条件：全员 Must（等于没分）；Won't 无人认领，范围悄悄蔓延
- 常见误用：把它当排期工具——它是分类不是排序，同类内部还要再排；交付排期里的 Must / Should / Could 见项目管理与迭代
优先级是组合判断
优先级不是模型打出的一个分数，而是 问题严重度 × 用户规模 × 价值强度 × 成本/风险 × 时机 的组合判断：
- 问题严重度：不解决的代价——安全事故 > 核心流程崩溃 > 效率损失 > 体验瑕疵
- 用户规模：受影响人数 × 影响频率
- 价值强度：比较候选方案与当前流程的收益及替换成本；未取得方案效果时保留为假设
- 成本/风险：开发成本、推理成本、技术风险、合规风险
- 时机：模型能力是否就绪、市场窗口、依赖是否到位、数据是否可及
五个维度列全再讨论，而不是乘出一个分数。常见偏科：只看用户规模（做出大而低频的功能）、只看严重度（被少数关键用户绑架）、只看技术兴奋（上线无人用）。
依据上述判断给获准交付的事项分级；验证任务另记验证目标与期限，不提前贴上功能级别：
| 级别 | 描述 | 处理方式 |
|---|---|---|
| P0 | 不做会出事的 | 立即排期 |
| P1 | 核心体验/核心场景 | 优先排期 |
| P2 | 重要但可延后 | 排入后续迭代 |
| P3 | 锦上添花 | 视资源情况 |
P0-P3 的治理规则
分级表之外，还要有治理规则，否则分级会在两轮迭代内烂掉：
- P0 准入条件：必须同时满足：① 不做导致安全/合规问题、不可逆损失或核心流程崩溃；② 有行为数据或业务结果支撑；③ 有明确负责人与异常处理方案；④ 资源已预留。缺少任何一项都不列为 P0；若问题或方案效果仍缺证据，安排验证任务，再决定功能级别
- 避免全 P0：全部 P0 = 没有优先级。每个迭代 P0 设数量上限（建议 1-2 个），超出的进 P1 排队
- 降级与撤回机制：每迭代复核一次——P0 无进展且证据转弱，降 P1；需求被行为数据证伪（如上线后无人用），撤回并归档，记录教训
- 容量预留：迭代预算分成"确定性需求"与"探索/技术债"两部分，另预留 15%-20% 给突发事件与验证任务——AI 产品的验证（评测、spike）也是工作量，不预留就会挤掉
- 技术债与依赖：P2/P3 的技术债要登记（债务也是需求，不登记就永远不还）；跨团队依赖写进需求文档，排期前确认依赖就绪，否则 P0 会被依赖卡死
多角色与产品类型
需求分析需要核对不同角色的诉求：用户（用的人）、买单者（付钱的人）、决策者（拍板的人）、管理员（配置的人）、运营者（维护的人）可能关心不同结果。
以客服工单案例为例，目前只有主管和一线客服的反馈。其他角色的想法需要调查：
| 角色 | 已知反馈 | 需要调查的关注点 |
|---|---|---|
| operator（客服主管） | 希望加快分派，提出方案 A | 谁对错误分派负责，如何追踪修正 |
| user（一线客服） | 转错部门后需要返工 | 接受建议后是否还需耗时复核 |
| buyer（买单者） | 尚未访谈 | 成本、合规与运行风险 |
| sponsor（业务负责人） | 尚未访谈 | 响应时长与客户体验的目标 |
目前只能确认两种声音。方案 B 保留人工确认，可以先测试节省时间与错误率变化；买单者和业务负责人的要求仍需核实，不能据此声称所有角色已经接受方案 B。
裁决规则三条：① 以可度量的业务结果为最终准绳，不按嗓门；② 角色权重按产品战略定——平台型产品 user 优先，企业服务 buyer 优先，合规敏感行业合规优先；③ 无法当场裁决的冲突，降级为"先验证"（用行为数据说话），不硬排。
不同产品类型的需求差异：
- B2B 产品：多角色是常态，需求文档必须写清"谁受益、谁买单、谁决策、谁维护"四列；价值主张要分别对 buyer（ROI、降本）与 user（效率、体验）讲
- 平台产品：用户是下游开发者，需求要抽象成"可复用的原子能力"；证据看开发者流失率、集成失败率、API 调用增长
- 内部工具：用户是员工，需求来自真实工作流，决策链短但组织政治强；证据 = 流程耗时、工单量、手工重复度
- 增长型功能：实验驱动，需求自带指标与 A/B 计划；证据要求最高——要判断归因，必须能区分"是这功能带来的增长"还是"大盘波动"
四、拆解：交付可验收的工作
AI 需求的特殊性
AI 需求在通用框架之上有五项硬性差异：
- 数据依赖：明确测试样本、标签来源和反馈数据如何回流
- 能力边界：用真实样本试跑，确认模型可完成的任务与失败场景
- 幻觉风险：列出错误类型、处理方式及人工接手条件
- 成本敏感：根据调用量核算 token 成本及维护成本
- 模型替换成本：换模型 = 换能力边界与成本结构，需求要留出抽象层：把模型调用封装成接口，别把 Prompt 写死在业务代码里
AI 特判五查
拆解 AI 验证任务时，按数据、能力、错误处理、成本、模型替换的顺序检查，并将已确认与待验证的事项分别记录：
1. 数据可得性：先确定评测集的典型、边界、对抗样本与异常样本来源，再明确谁负责标注、如何回填用户纠错。缺少可用样本时，将数据建设列为验证任务（评测集构建见评估与评测，标注管理见数据与标注）。
2. 能力可行性 spike：用 10—50 条有参考结果的真实样本，在 Playground 或官方 API 试跑，记录准确率、失败输入和输出格式。提示词实验方法见 Anthropic 官方提示词工程指南。根据结果界定方案可处理的输入范围与异常处理方式。
3. 幻觉与延迟：验收标准里写清——输出质量（评测集通过率）、错误容忍度（哪些错误类型可接受，哪些零容忍，如承诺赔付类）、超时（P95 延迟上限）、超时与低置信度时的行为（转人工/重试/降级）。"答错不可怕，答错后没有兜底才可怕"。
4. 成本上限：单次调用成本（输入/输出 token × 单价）× 调用量 = 月成本，方法见 LLM 成本测算；写清缓存策略（相同输入命中缓存，长上下文场景尤其关键）与预算护栏（日成本超限自动降级到小模型或关停，由谁触发、何时触发）。
5. 模型替换与供应商依赖：需求是否绑定模型？写"需要能完成 X 任务的模型"而不是"需要 GPT-4o"；换模型后的行为变化（输出风格、格式稳定性、延迟）与成本变化要预演——封装成接口、评测集跨模型可跑，替换就是一次 A/B，而不是一次重构。
自动执行类需求（Agent）额外参考 Anthropic 的 Agent 设计模式：人工确认环（human-in-the-loop）放在哪些节点，直接影响风险与用户体验，这是需求层就该定的决策，不是开发层的细节。
需求拆解产物
在判断环节先写出问题陈述与业务目标；批准验证任务或交付事项后，再补齐验收有据的文档。九个字段的模板：
| 字段 | 写什么 | 颗粒度 |
|---|---|---|
| 问题陈述 | 谁、在什么情境、有什么问题、现在怎么解决 | 一段话，不含解法；含解法就是跳步 |
| 假设 | 价值假设（用了觉得值）与能力假设（模型能做） | 一句一个，必须可被数据推翻 |
| 用户故事 | 作为\<角色>，我想\<做什么>，以便\<获得什么> | 一个故事对应一个验收场景，别把系统当角色 |
| 验收标准 | 输入 → 输出 → 边界 → 出错处理 | 每条可测、可量化；禁用"流畅/好用/智能" |
| 非目标 | 明确不做、不优化的范围 | 每条防一次范围蔓延 |
| 依赖 | 数据、模型、接口、其他团队 | 每条依赖有负责人与就绪时间 |
| 风险 | 模型/数据/合规/体验风险 | 每条有应对动作，不写"加强关注" |
| 指标 | 成功指标 + 当前基线 + 目标值 | 上线后能从系统里算出来 |
| 回滚条件 | 什么指标、什么表现触发回滚，谁执行 | 有数字、有责任人 |
颗粒度的判据：开发拿到文档不需要再问"你是什么意思"，验收时不需要争论"这算不算完成"。写"AI 总结会议纪要"要写清：输入什么格式、多长；输出多长、术语怎么处理；模型出错时怎么办（重试/截断/提示用户）。"一句话需求让开发猜"的结果是开发按自己的理解做，验收对不上，返工一轮——AI 产品还多一层：不写评测标准，连"对没对"都无法判断。
完整 PRD 的写法见 AI 产品 PRD；上线后的监控、校准与回滚见 AI 产品开发生命周期（CC/CD）。
贯穿案例：AI 客服工单助手
以下访谈、日志数字和组织背景都是教学案例设定，用于演示如何记录证据与未知事项；它们不代表真实企业的调研结论。方案效果、评测阈值和经营收益均待检验。另见 AI 产品 PRD 示例 中的交付文档字段。
客服主管说：「工单分派太慢了，能不能让 AI 帮我们自动分派？」一线客服也很头疼：「我老是转错部门，转过去又退回来。」主管想让工单分得快一些，客服希望少些返工。眼下还得弄清楚，时间花在了哪里，工单又为什么会转错。
一、收集
机会识别：确定调查范围
案例设定为现有客服团队的内部工具，目标是降低首次分派耗时和错误分派率。五个因素分别产生以下结论：
| 因素 | 已知或待查 | 对机会范围的影响 |
|---|---|---|
| 市场阶段 | 内部工具的外部市场阶段未调查 | 本轮只研究现有团队的流程改进，不据此推断外部市场机会 |
| 竞争位置 | 人工判断部门是现有做法；其他工具待调查 | 把当前人工流程作为比较基线，核对是否已有可用方案 |
| 公司目标 | 案例设定要缩短分派耗时、减少转错；负责人需确认目标与资源 | 未获得确认前，只批准调查，不承诺功能排期 |
| 技术可行性 | 尚未运行真实样本评测 | 将四类工单的分类能力列为验证任务 |
| 数据资产 | 案例设定有历史工单日志；标签质量待确认 | 可以调查现状，评测集仍需主管标注 |
机会候选空间：现有客服团队在首次分派工单时耗时较长、可能转错部门。是否值得投入 AI 方案，还取决于战略确认、现有工具调查、能力验证和收益评估。
假设：从诉求到可检验主张
一线客服收到退款、物流、投诉或咨询工单后，要判断归属部门；现在靠看标题、查部门表或问同事。主管提出的方案是 A：全自动分派。沿着「分派耗时、转错返工」这两个问题，还可以提出 B：系统建议部门，由客服确认。客服是否担心 AI 误判带来的责任，需要在访谈中核实。知识库问答和自动回复涉及其他任务，另行调查。
| 待检验主张 | 什么结果会推翻它 | 获取证据的方法 |
|---|---|---|
| 问题：首次分派耗时及转错会影响客服工作 | 日志显示耗时短、转错少，或访谈指出主要瓶颈在其他环节 | 核对首次分派时间、改路由记录和具体工作场景 |
| 方案 A：全自动可以节省更多时间，且误判代价可控 | 错误分派、责任风险或异常处理成本无法接受 | 使用标注样本测能力，再调查风险和人工兜底成本 |
| 方案 B：建议加人工确认能减少耗时，且不会增加错误 | 对照当前流程后耗时无改善，或错误分派率升高 | 在真实工单的受控试用中比较耗时、采纳率和改路由率 |
| 价值：省下的时间与返工成本能覆盖使用及维护成本 | 净节省低于系统投入，或客服不愿采用 | 核算人力、推理、培训成本与实际采纳情况 |
Y 模型帮助追问动机和寻找其他解法，表中的主张还要逐项检验。假如客服确实担心误判责任，人工确认值得测试；担心责任本身不能证明 B 会缩短分派时间。
二、判断
证据：记录支持范围
案例设定访谈 6 名客服，发现有人靠经验猜测部门并经历退单；历史日志记录首次分派平均耗时 40 分钟、错误分派率 15%、日均 500 张工单。小问卷里 80% 受访者认为判断部门耗时，但样本框与人数未给出，不能推断全体客服的比例。
| 主张 | 现有支持 | 尚未获得的证据 |
|---|---|---|
| 分派环节存在耗时与转错 | 访谈描述加上日志中的耗时和错误率 | 对照其他环节的耗时，确认主要瓶颈 |
| 问题影响的范围 | 日均 500 张工单属于处理量 | 涉及的客服人数、受影响客户数及不同类型工单的分布 |
| 方案 A 安全且更有效 | 无能力及风险评测 | 分类准确率、异常率、人工兜底及合规检查 |
| 方案 B 能改善工作结果 | 无方案试用数据 | 同期对照的分派耗时、采纳率、错误分派率 |
| 投入具有经营价值 | 无成本与收益核算 | 实际节省的工时、培训与运行成本 |
证据结论：已有材料支持「当前分派流程存在问题」，尚未验证 A 或 B 的改善效果，也没有为知识库问答和自动回复提供需求证据。
价值判断：比较问题与候选方案
问题初筛：现有记录显示日均处理 500 张工单、首次分派平均耗时 40 分钟、错误分派率 15%；还需要确认有多少时间用于判断部门、多少客服受到影响。省下的工时和返工成本也尚未测算。目前值得验证分派问题，尚无法估算投入回报。
方案比较：旧做法是客服人工判断部门，转错后还要返工。方案 A 可能省去判断时间，也可能增加误判与善后成本；方案 B 保留人工确认，仍有查看建议、复核、培训和建立信任的成本。两个方案都没有试用结果，无法断言哪个带来的用户价值更高。相对价格还需比较使用者付出的时间与获得的效用；推理费用、维护成本另计入组织投入。
需求定义：陈述问题与目标
问题陈述：现有客服团队在收到退款、物流、投诉及咨询工单后，需要确定归属部门。案例中的首次分派平均耗时 40 分钟、错误分派率 15%；人工判断与退单返工影响响应速度。需降低首次分派耗时及错误分派率，并保持对分派决定的责任可追溯。
目标与边界：以工单日志为基线，和客服主管约定目标值、观测周期与统计口径，再通过试用检验改善幅度。这里关注工单分派，知识库问答和对客户自动回复需另行调查。
三、分级
优先级：安排验证与功能决策
方案 A 和 B 都针对已记录的分派问题，但现有日志只说明当前流程的状况。若用 RICE 或 WSJF 排功能优先级，以下数据还需要取得：
| 方案 | RICE 所需数据 | WSJF 所需数据 |
|---|---|---|
| A 全自动分派 | 实际改善幅度、可靠性、开发工作量 | 延迟交付的损失、误分派的风险与工作量 |
| B 路由建议并由客服确认 | 建议采纳率、改善幅度、开发工作量 | 延迟交付的损失、人工确认成本与工作量 |
本轮决策：安排 B 的验证任务，暂不承诺上线。B 保留客服确认，便于先观察建议能否缩短分派时间；A 涉及自动执行，还需额外验证误判代价和异常处理。此时没有足够的数据计算两个模型的排名。知识库问答与自动回复涉及其他问题，须各自调查。
按本页的 P0 准入条件，当前资料未证明不做分派改进会造成安全、合规、不可逆损失或核心流程中断，因此没有 P0 功能。待方案效果、投入与负责人得到确认后，再讨论 B 是否作为 P1 功能排期。验证期间发现高风险事件，应根据事件证据重新评估级别。
四、拆解
拆解：写出验证任务与交付条件
- 验证任务：主管标注 50 条历史工单，覆盖 30 条典型、10 条边界、10 条对抗样本；先测分类准确率与失败类型。建议达到预先商定的准确率阈值（例如整体 ≥ 90%、对抗样本 ≥ 80%）才进入受控试用；试用中记录当前流程和方案 B 的分派耗时、采纳率、错误率及投诉变化。未达到阈值时停止功能排期，记录需修正的能力边界。
- 候选用户故事：作为一线客服，我希望查看工单的路由建议并自行确认或改路由，以便更快完成首次分派。
- 拟定验收标准：输入工单描述后展示建议部门与简短理由；客服可确认或改路由并留下记录。超时、无法判断或风险较高时提示人工处理；P95 延迟目标为 3 秒以内。展示的置信度需要先完成校准，阈值须通过评测确定。以上均为拟定标准，尚未得到达标结果。
- 成本与模型边界：假设一次调用 0.02 元、每天 500 次、每月 30 天，推理费用约 300 元；重试、峰值调用、维护和培训需另算。记录模型版本及跨模型评测结果，保留人工流程作为异常处理路径。
验证通过且经营收益成立后，交付文档再确定上线范围、指标目标、资源负责人及停止条件；AI 产品 PRD 提供完整字段与示例。
常见误区
误区一：用户要什么就给什么
听到「我要导出 Excel」，就排期做导出。先弄清楚用户想把什么信息发给谁，再比较 Excel、分享链接等办法。
误区二：自己拍脑袋定需求
团队觉得新功能一定有人用，却没有调查具体任务和现有做法。把判断写成可检验的主张，再安排调查或试用。
误区三：需求分析只做一次
用户行为、产品能力和替代方案都会变化。每轮迭代复核问题是否还存在、证据是否仍适用。
误区四：把"模型能做"当成"用户需要"
模型完成了演示，只说明一种实现路径可能可行。用户是否需要、愿否采用、是否值得投入，还需分别调查。
误区五：访谈几句就当证据
少量访谈可以帮助理解情境与动机；影响人数看抽样或日志，方案效果看试用结果。证据须对应各自主张。
误区六：一张评分表决定优先级
RICE 和 WSJF 的输入若缺少依据，得分也无法支持排期。先补齐影响面、方案效果与工作量，再讨论排序。
误区七：让框架伪装成结论
填完 JTBD、Y 模型或 KANO 表格，还需写明已经得到哪些证据、哪些主张尚待检验、下一步安排什么。
练习
练习
从真实工作中选择一个 AI 场景，按收集、判断、分级、拆解记录：机会的五个因素各有何依据？哪些主张还缺证据？三维度筛选和新旧体验比较分别得出什么？问题如何定义？有足够数据后再用 RICE 与 WSJF 排序；缺少参数时列出验证任务。
下一次收到需求，先问自己三个问题：用户真正要解决什么问题？证据够不够？做到什么程度算完成？
来源说明
官方文档/博客：
- Anthropic Prompt Engineering Overview（提示词实验与能力验证方法）
- Anthropic Building Effective Agents（Agent 设计与人工确认环）
经典著作与论文：
- Kano et al., 1984, "Attractive quality and must-be quality"（KANO 模型）
- Christensen et al., 2016, "Know Your Customers' Jobs to Be Done"（HBR，JTBD）
- Eric Ries, 2011, The Lean Startup（验证式学习、价值/增长假设）
- Marty Cagan, 2018, INSPIRED（价值风险、发现与交付）
- Teresa Torres, 2021, Continuous Discovery Habits（持续发现）
- Melissa Perri, 2019, Escaping the Build Trap（以产出代替价值的陷阱）
- Rob Fitzpatrick, 2013, The Mom Test（访谈问事实不问承诺）
仓库原创读书笔记：
- 《俞军产品方法论》精读笔记：用户价值公式、相对价格、交易成本
- 《人人都是产品经理 2.0》精读笔记：Y 模型、KANO 应用
- 《启示录》INSPIRED 精读笔记：价值风险、MVP 是原型
- 《精益创业》精读笔记：最小验证、转型或坚持
发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用