产品用户场景覆盖审查-V2
帮助产品经理检查已确认需求范围内，各类用户是否具有相应的场景、规则和产品体现。按当前阶段审查，不声称穷尽所有可能场景。
适用场景
当用户要求基于用户类型审查产品方案、业务逻辑、流程、PRD 或原型的场景覆盖、差异规则及交付完整性时使用。可检查单个功能、单条链路或已确认范围内的完整需求。
1. 确定输入与审查范围
提取需求目标、当前阶段、审查对象、已有用户类型及材料版本。材料可以是文字、文件、截图或可访问的原型。只在信息影响审查时追问，优先复用当前会话中的已确认信息。
识别哪些材料能够实际读取。无法访问的链接、无法辨认的截图或缺失材料，列为证据限制，不推测其内容。
2. 建立用户类型候选清单
保留产品经理提供的类型及业务名称。区分身份/角色与状态/条件；一个用户可同时具备多个状态，状态不一定互斥。
从当前业务证据中检查角色、操作权限、资格条件、生命周期、业务关系及状态变化是否会改变入口、操作、数据范围、规则或结果。仅对存在行为差异的候选项提出补充；不得把通用示例套成项目的既定事实。
为用户类型分配稳定编号 U01、U02……，每个编号对应明确的中文用户名称。所有审查、问题及复查结果均显示“编号＋中文用户名称”，例如“U01 普通用户”。涉及多个用户时逐一列出，不仅填写编号或英文名称。复查保留编号，新增类型追加编号，不因排序改变编号。状态维度独立记录，不自动拆成新的用户角色。
每个候选项记录：名称、角色或状态、证据或推断依据、差异行为、遗漏影响、建议纳入/合并/排除。行为相同的名称建议合并；仅状态不同的情况记录为状态维度。
3. 确认审查基线
将已有类型与候选项一并呈现，明确哪些已确认、哪些待确认。请产品经理确认纳入、合并或排除的结果，以及会影响范围的排除理由。
确认前可以整理材料、提取流程和识别明显矛盾，但候选项相关结论只能标为待确认，不能作为正式缺陷或交付阻碍。不得以用户未回复或等待超时视为批准。
用户在同一会话已确认的基线可直接复用；没有新增候选、范围或关键假设时，不重复要求确认。审查过程中发现新类型时，仅确认新增项。
4. 建立覆盖矩阵并审查
以已确认的用户角色、适用状态与业务场景建立矩阵。只展开业务成立且会改变行为的组合；不生成所有维度的笛卡尔积。共享流程可作为共同规则引用，同时明确适用对象与例外。
根据当前阶段和材料，检查：
- 入口及前置条件：用户如何进入，能否识别适用资格。
- 目标与操作：允许做什么，不允许做什么，操作对象及数据范围。
- 主流程及结果：步骤、分支条件、成功结果与后续动作。
- 异常及恢复：业务相关的拒绝、失败、中断、重试和退出路径。
- 状态变化：资格、身份或业务对象状态变化后，进行中的操作、已选内容和再次进入如何处理。
- 跨角色协作：一方操作如何影响另一方的可见内容、待办、状态与结果。
不强制加入与当前业务无关的异常。例如没有异步操作证据时，不凭空要求超时状态。
5. 对照方案、逻辑与原型
先分别检查规则是否明确、流程是否闭合、产品表达是否充分，再检查材料之间是否一致。
文字规则已覆盖但原型缺少入口、限制反馈、状态或结果时，标明具体缺少的表达。多个用户共享页面不构成问题，只要差异规则和必要反馈清楚。
仅提供原型时，审查可观察到的入口、操作与反馈；不可见的权限、计算、数据范围等规则标为未明确。仅提供方案时，不将缺少原型认定为原型缺陷。
审查结果必须将“受影响用户”与“触发条件”分为独立列；受影响用户填写编号与中文名称，触发条件填写场景成立的具体条件。适用状态及业务场景另列，不与这两列混写。
每条证据定位到文件与章节、页面名称、流程节点或原型节点。没有精确位置时，引用能识别上下文的短片段，不伪造行号或节点。
6. 输出问题与补齐建议
将确定问题、待决策事项和证据不足分开。每条记录必须包含受影响用户、成立的触发条件、观察到的缺口、依据、影响和最小补齐建议。
主覆盖表采用以下状态，并严格按“未覆盖 → 部分覆盖 → 已覆盖”排序：
- 未覆盖：场景已确认适用，且有充分证据表明当前阶段所需规则、流程或产品体现缺失。
- 部分覆盖：部分必要内容已存在，但仍缺关键规则、分支、反馈或结果。
- 已覆盖：当前阶段所需规则和产品体现均有充分证据。
同一状态内按用户编号、场景编号排序；多用户结果按最小用户编号排序，并保留全部受影响用户。覆盖问题清单采用相同排序，主要列未覆盖及部分覆盖问题；已覆盖项保留在覆盖矩阵，关闭问题保留在复查记录。
以下事项分别列出，不混入主覆盖表的三种状态排序：
- 待确认与冲突事项：未明确（材料不足以判断预期行为）、存在冲突（同一条件下的规则或材料互相矛盾）。优先列出阻碍交付判断的事项。
- 不适用事项：业务条件不成立或被明确排除，记录理由及依据。
“材料没有提到”不能直接判为未覆盖；预期行为或材料完整性无法确定时列为未明确。一个场景既有确定缺口又有其他待确认规则时，可分别记录，通过场景编号关联。候选类型未确认时仍仅列为待确认事项。
问题分级：
- 交付前需解决：在已确认范围内，缺失或冲突会阻止开发明确实现关键行为、权限、状态或结果；必须说明具体原因。
- 建议补齐：主要影响提示、可理解性或非关键路径，且核心实现规则已明确。
- 待确认：类型、业务决策或证据尚未确认。只有影响交付范围内关键行为时，才同时注明它阻碍交付判断。
建议属于提案，不作为已确定业务规则。不得自行决定权限、资格、计费、状态转换或用户排除。
7. 复查与交付结论
为基线、矩阵行和问题赋予稳定编号。修订后复用编号，核验问题对应的场景及受影响的相邻分支，避免无依据的全量重复审查。
问题状态为待处理、待确认、已解决、接受风险或范围排除。仅有修改承诺不能标为已解决；需新的材料证据。接受风险或排除范围必须有产品经理明确决定；接受风险不改变原覆盖状态。实际补齐后依据新证据更新覆盖状态，并重新排序。
输出结论：
- 当前范围可交付：本次交付范围的关键规则已明确，无未解决交付阻碍；注明已接受事项与证据限制。
- 补齐后再交付：存在已识别的交付阻碍，逐条列出。
- 证据不足，暂不能判断：关键材料或基线信息不足，列出最小补充项。
局部或早期审查只报告本次检查结果和下一阶段所需信息，不强行给整个产品下交付结论。不使用无依据的覆盖率或分数替代判断。
报告与调用方式
输出正式审查报告或复查报告时，读取 审查报告模板。按照当前范围填写，允许精简无关字段，但不得合并“受影响用户”和“触发条件”，必须保留用户编号与中文名称、规定排序、用户基线、证据、缺口及结论限制。默认在对话中输出；仅在用户要求时生成文件，不因使用本技能自动改写原始方案或原型。
初次使用时，说明本次审查范围，先呈现已有类型及有依据的候选项，再请求确认审查基线。若缺少已有类型，先从材料形成候选清单请产品经理确认，不把推断作为已确认事实。
示例请求：使用本技能检查这份原型；已有用户类型为普通用户和管理员，请补充候选类型，确认后检查各类用户的场景与逻辑覆盖情况。
