需求评审里，用户故事“角色空泛、价值不清”往往不是写作者态度问题，而是表达环节缺少可核对的检查点。本文给出一套诊断路径：先用症状清单判断故事是否属于这两类问题，再分别用证据确认角色和价值问题的成因，最后按步骤改写，并用四项标准验证修正是否到位。
要点总览（TL;DR）
- 角色空泛看两处：角色栏写成“用户”“系统”等泛称，故事里又找不到该角色在什么条件下触发动作；价值不清看价值句是否只复述功能动作，说不清谁因此改变了什么行为或结果。
- 角色空泛有三种常见成因：角色来源不清、多人共用同一角色、角色按系统模块而非使用者划分。排查顺序是先确认角色真实存在，再确认触发场景是否唯一，证据不足记为待澄清。
- 价值不清分三类：价值句缺失、价值句空转、价值归属错误。统一追问“谁在什么条件下会改变什么行为或结果”，用具体场景反证，说不清变化就记为待澄清。
- 修正按两条线进行：角色线补职责、补触发场景、拆分多角色故事；价值线改写价值句、补可观察结果、补验收条件。改写只调整表达，不擅自扩大或缩小需求范围。
- 修正后用四项标准验证：角色可指认、场景可复述、价值可观察、验收条件可判定；并把检查项固化进故事模板与评审清单，在进入开发前设置固定检查点。
角色空泛、价值不清在评审中长什么样
评审现场判断一个故事是否属于本文讨论的问题，可以看两个位置：角色栏和价值句。角色栏出现“用户”“系统”“管理员”这类泛称，且故事里找不到这个角色在什么条件下触发动作，就属于角色空泛。价值句写成“系统支持导出报表”“页面展示订单列表”，只是把功能动作换了一种说法，说不清谁因此改变了什么行为或结果，就属于价值不清。
这两类问题有共同的外部特征：评审时有人追问“这个用户具体是谁”“做完之后谁会因此做什么”，写作者需要现场补充信息才能回答。出现这种情况，说明故事本身没有承载足够的信息，而不是评审者理解能力不足。
需要区分表达问题与需求内容未澄清。表达问题的特征是：需求方向已经明确，只是故事没写清楚角色和价值；补上职责、场景和价值句即可完成修正，不需要重新讨论需求做不做。需求内容未澄清的特征是：连业务方也说不清这个角色是否存在、这个价值是否成立，此时应回到需求分析与澄清环节，不在表达修正阶段下结论。
评审时可用的症状对照清单如下，命中任意一项即标记为待修正：
| 检查位置 | 症状表现 | 判定 |
|---|---|---|
| 角色 | 写成“用户”“系统”“相关人员”等泛称，无法指认到具体岗位或使用者类型 | 角色空泛 |
| 角色 | 角色可指认，但故事中没有说明该角色在什么场景、什么条件下触发这个动作 | 角色空泛 |
| 角色 | 一个故事同时服务多个角色，动作和价值混在一起 | 角色空泛（需拆分） |
| 价值 | 价值句只复述功能动作，如“支持批量导入” | 价值不清 |
| 价值 | 价值句写的是团队内部收益，如“减少开发返工”，却放在用户故事的价值位置 | 价值不清（归属错误） |
| 价值 | 追问“谁在什么情况下获得什么结果”时，现场无法给出具体回答 | 价值不清（待澄清） |
角色空泛的常见成因与排除证据
角色空泛通常有三种成因假设，评审时应逐条验证，而不是凭印象认定。验证顺序建议先确认角色是否真实存在，再确认其触发场景是否唯一。
假设一：角色来源不清。写作者凭印象填了一个角色，没有对照真实的角色清单或访谈记录。验证证据是：能否在角色清单、用户访谈记录或使用场景描述中找到这个角色的出处。找不到出处，说明角色来源不清，需要回到需求澄清确认角色是否存在。
假设二：多人共用同一角色。不同岗位的使用者被合并写成“用户”，导致故事无法说明谁触发、谁受益。验证证据是：使用场景描述中是否出现两个以上职责不同的使用者，且他们的操作目的不同。若存在，说明需要拆分角色，而不是继续用泛称覆盖。
假设三：角色按系统模块而非使用者划分。故事写成“订单模块需要……”，把系统组件当成了角色。验证证据是：角色名称是否对应一个能执行动作、能获得结果的人或岗位。对应不上，说明角色划分口径错了，应按使用者重新划分。
| 原因假设 | 验证证据 | 确认后的处理方向 |
|---|---|---|
| 角色来源不清 | 角色清单、访谈记录中查不到该角色 | 回到需求澄清确认角色是否存在 |
| 多人共用同一角色 | 使用场景描述中出现职责不同的多类使用者 | 按使用者拆分故事 |
| 角色按系统模块划分 | 角色名称对应系统组件而非可执行动作的人 | 按使用者重新划分角色 |
排查顺序上，第一步只回答“这个角色是否真实存在”，证据不足时记为待澄清，不直接判定需求不成立；第二步确认“这个角色的触发场景是否唯一”，若一个故事覆盖多个触发场景，同样标记为需要拆分。两步都通过，角色维度才算排查完成。
价值不清的成因与验证方法
价值不清可以分成三类，处理方式不同，评审时需要先判定属于哪一类。
价值句缺失。故事只有角色和动作，没有价值描述。这类问题最容易识别，补写价值句即可。它与价值句空转的区别在于：缺失是没写，空转是写了但没说出结果。
价值句空转。价值句存在，但只是功能动作的同义复述，例如“支持按条件筛选订单”写成价值是“让用户能筛选订单”。判断方法是把价值句中的功能词去掉，看剩下的是否还是一个可观察的结果；如果去掉后句子不成立，说明价值句在空转。
价值归属错误。把团队内部收益写成用户价值，例如“减少测试回归工作量”“降低开发沟通成本”。这类收益真实存在，但归属对象是团队而非故事中的角色，应移到团队目标或技术任务中描述，用户故事的价值位置留给使用者获得的结果。
验证方法是统一追问一句：“谁在什么条件下会改变什么行为或结果？”回答需要包含具体角色、触发条件和可观察的结果。若回答仍然停留在功能层面，可以用具体场景反证：设想这个功能上线后，该角色在某个真实业务场景中的操作是否发生变化；说不清变化，就说明价值尚未确认，记为待澄清。
| 成因类型 | 识别特征 | 验证追问 | 判定结果 |
|---|---|---|---|
| 价值句缺失 | 故事中没有价值描述 | 这个角色做完动作后获得什么 | 补写价值句 |
| 价值句空转 | 价值句去掉功能词后不成立 | 谁的行为或结果发生了可观察的变化 | 改写价值句 |
| 价值归属错误 | 收益对象是团队而非使用者 | 这个收益由谁承担、由谁获得 | 移到团队目标，重写用户价值 |
按问题类型修正用户故事的步骤
修正按角色和价值两条线分别进行，每条线有固定顺序，避免边改边扩范围。
角色修正三步。第一步补职责：把泛称替换为有明确职责的岗位或使用者类型，并写清这个角色负责什么。第二步补触发场景：说明该角色在什么业务条件下会执行这个故事中的动作。第三步拆分多角色故事：一个故事只保留一个主要角色，其余角色的动作拆成独立故事或作为后续故事处理。
价值修正三步。第一步改写价值句：按“谁在什么情况下获得什么可观察结果”重写，去掉功能动作的复述。第二步补可观察结果：结果需要能被业务方在验收时指认，例如处理时长、错误数量、可完成的操作。第三步补验收条件：把价值落到可判定的验收条目上，使评审和测试有共同依据。
改写前后对照示例如下（示例为演示情景）：
| 项目 | 改写前 | 改写后 | 改动点 |
|---|---|---|---|
| 角色 | 用户 | 区域仓库的入库管理员 | 补职责与使用者类型 |
| 场景 | （未写） | 每日到货集中入库、需要核对批次时 | 补触发条件 |
| 价值 | 系统支持批量导入入库单 | 入库管理员在集中到货时一次导入整批单据，当天完成入库登记，不再逐单录入 | 价值句改为可观察结果 |
| 验收条件 | （未写） | 一批 50 条单据可一次导入；导入后可在列表中核对批次与数量 | 补可判定条目 |
改写时保留原有需求方向和功能范围，只调整表达。修正过程中有一条风险边界：不擅自扩大或缩小需求范围。若改写时发现角色是否存在、价值是否成立需要业务判断，回到需求澄清环节处理，不在表达修正阶段替业务方做决定。
修正后的验证与复发预防
修正是否完成，用四项标准逐条核对，四项均满足才算通过：角色可指认，评审者能说出这个角色是谁、负责什么；场景可复述，能用一句话复述该角色在什么条件下触发动作；价值可观察，价值句描述的结果能在验收时被指认；验收条件可判定，每条验收条件都有明确的通过与否。
评审检查点建议设在故事进入开发之前，由需求负责人自检、评审主持人确认。检查点只做两件事：对照症状清单标记问题故事，对照四项标准确认修正结果。检查记录随故事一起保留，便于后续追溯。
复发预防的重点是把检查项固化下来，而不是依赖每次评审的临场提醒。具体做法有两条：一是把角色职责、触发场景、价值句、验收条件作为故事模板的固定字段，新建故事时即需填写；二是在评审清单中加入本文的症状对照项，作为进入开发前的必查内容。
在工具层面，这类检查点需要故事模板和评审记录有稳定的承载位置。ONES Wiki 支持使用模板库一键创建文档，页面组可关联项目，使需求与文档互相对应，适合把故事模板和评审清单放在与需求同一项目下维护；其版本记录支持查看与回滚，便于追踪模板和清单的调整过程。ONES Assistant 可基于项目、工作项和 Wiki 页面等上下文回答问题并执行后续操作，在整理评审记录、把结论保存为工作项或 Wiki 页面时可以减少重复录入；具体可用范围以产品实际支持为准。工具承载的是检查点的执行与留痕，角色和价值是否成立，仍以评审中取得的证据为准。
常见问题
评审时间有限，怎么快速判断一个故事该标记为待修正还是当场放过？
先做一次低成本筛查：看角色栏能否指认到具体岗位或使用者类型，看价值句去掉功能词后是否还成立。两项都通过的故事可以当场放过；任一项不通过，就标记为待修正，不在评审现场展开成因分析。
标记之后，成因验证和改写放到评审后单独处理，由写作者按角色线和价值线分别排查。这样评审只承担识别职责，避免因逐条深挖而拖长会议。
一个故事同时服务多个角色，是拆成多个故事还是保留一个主故事？
建议一个故事只保留一个主要角色，其余角色的动作拆成独立故事或作为后续故事处理。判断依据是触发场景：如果不同角色的操作目的和触发条件不同，合并写会让价值句无法落到具体使用者身上，拆分后每个故事的角色、场景和价值都能独立核对。
拆分时保留原有需求方向，只调整表达颗粒度。若拆分后发现某个角色是否存在需要业务判断，回到需求澄清环节确认，不在表达修正阶段替业务方下结论。
价值句里写“减少开发返工”这类团队收益，一定要删掉吗？
这类收益本身真实，问题在归属对象。用户故事的价值位置留给使用者获得的结果，团队内部收益可以移到团队目标、技术任务或改进项中描述，两者分开记录，避免用户故事的价值句被团队视角占位。
如果团队收益确实是这个故事的主要目的，说明它更接近技术任务而非用户故事，可以按任务类型管理，不必强行套用用户故事模板。
修正后的故事在验收时发现价值仍然说不清，应该退回哪一步？
先回到价值验证的追问：“谁在什么条件下会改变什么行为或结果？”如果回答仍然停留在功能层面，说明价值在修正阶段只是换了措辞，并未取得证据支持，应记为待澄清，回到需求分析与澄清环节确认价值是否成立。
如果价值本身成立、只是验收条件写得不可判定，则属于表达问题，补写可判定的验收条目即可，不需要重新讨论需求方向。
把检查项固化进故事模板后，如何避免模板字段被形式化填写？
模板字段只是承载位置，关键在评审检查点是否真的核对。建议检查点只做两件事：对照症状清单标记问题故事，对照四项标准确认修正结果，并把检查记录随故事保留。
在工具层面，可以用 ONES Wiki 的模板库统一创建故事模板与评审清单，页面组关联项目使需求与文档对应，版本记录便于追踪模板调整过程；ONES Assistant 可基于项目与 Wiki 上下文整理评审记录、把结论保存为工作项或页面，减少重复录入，具体可用范围以产品实际支持为准。
