reviewing-user-flows

reviewing-user-flows — SKILL.md

变体： standard · 适用场景： 将已完成的用户流程文档作为验收门槛进行评审——检查文档是否完整、可顺畅遍历、结构清晰、具备韧性、易于访问且合理，然后输出 VERDICT: approve|revise，并给出可执行的发现。

概述

此技能是用户流程「制作／评审」配对中的评审部分。由手头已有已完成的用户流程文档的评审者加载，并围绕一个问题评判该文档：下游线框图设计能否枚举出每个屏幕？每条路径能否顺畅遍历、恢复并完成（包括由 AT 用户完成），而且流程是否合理？ 用户流程文档映射导航／交互图——入口点和 IA 框架、顺利完成的路径、决策分支、错误／恢复及边缘状态、交互韧性、流程级无障碍性，以及经过的屏幕／状态。此技能采用固定的检查清单（与用户流程作者遵循的标准一致，避免制作标准和评审标准偏离），然后输出一个机器可解析的判定，以及作者可在一轮修订中采取行动的发现。这是一道验收关卡——它不会编写、修复或重绘流程；它只负责评判并返回发现。

何时启用

• 已完成的用户流程文档需要在下游线框图设计开始前作出接受／修订决定。
• 你是刚完成文档的制作方所需的独立评审者／把关人。
• 在先前给出 revise 判定后，重新评审修订后的用户流程文档。
• 评审修订内容——针对先前用户流程文档的带版本差异（差异范围评审，条件 13）。

请勿在以下情况启用：

• 编写或修复用户流程文档 → 使用 authoring-user-flows。此技能不会编写流程。
• 评审屏幕布局／结构（区域布局、内容层级、每个屏幕的组件）或逐屏像素级无障碍性（对比度、目标尺寸、焦点外观）→ 应使用线框图评审技能。此关卡评判的是屏幕如何连接，以及每条路径是否可以完成，而不是屏幕看起来如何。
• 评审上游 PRD（目标、用户画像、指标）→ 使用 PRD 评审技能。
• 检查模板／章节是否符合规范 → 这是模板方面的问题；此技能评判的是质量是否达到标准，而不是是否包含每个标题。
• 评判用户旅程（情绪／渠道／时间跨度）——这是另一种交付物。

工作流

步骤 1：以全新、独立的视角通读全文

从头到尾阅读用户流程文档，仿佛这是你第一次看到它。将上游 PRD（目标和用户画像）与文档一同对照——根据这些目标评判覆盖范围；若提供了设计系统，也应一并参考其中的导航／组件规范；评审修订内容时，则应对照先前版本。你的立场是把关下一个步骤（线框图设计），并为必须实际遍历这些路径的用户把关：如果某项发现表明屏幕无法枚举、路径无法遍历／恢复／完成、不可逆操作缺少防护，或者流程在客观上不符合任务需求，那么这项发现就有分量。注意哪些流程、分支、出口或交接环节至关重要。

步骤 2：执行检查清单——判定每项条件是否通过或存在缺口

对以下每项条件，判定为通过或存在缺口。只有存在真实且明确的缺陷时，条件才算失败——「我会采用不同的画法」不构成缺口（质量条件仅依据客观标准；见条件 12）。对于每个缺口，记录确切位置（哪个流程、步骤、分支、节点或交接环节）以及缺少的内容（步骤 4 会将其转化为可执行的发现）。条件的适用程度应与产品规模相称（见「比例原则」）。

下面的能力边界检查项仅适用于在编写调用中注入了 capability_record，且评审上下文中可用的情况。若不存在，则视为不适用——未定义边界时，不要因为文档缺少能力边界标记而扣分。 保留的核心内容（完整性 + 可遍历性）：

1. 目标/角色覆盖——无遗漏。 每个 PRD 目标（表述为角色要完成的任务）都对应一个流程；每个流程都能追溯到一个目标/角色；标准流程以既定模式为依据（或说明偏离原因）。需提供覆盖映射。缺口：目标没有对应流程、流程不服务于任何目标、没有覆盖映射，或在没有理由的情况下重新设计已解决问题的流程。
2. 定义入口 + 出口。 每个流程都列出所有入口点（主页、深层链接、电子邮件、通知——每个入口点都可能从不同状态开始），以及具体的成功/确认状态（而非抽象的“成功”）；其他出口（取消/放弃/移交）也应清晰妥当。缺口：流程从半空中开始，或结束时没有具体的结束状态。（不可合并基线：每个流程都有成功状态。）
3. 解决每个决策分支。 每个决策都列出所有后续分支；每个分支都指向某个步骤、另一个流程或一个出口。缺口：存在悬空分支，或某个分支没有指向任何地方。
4. 每个错误/边缘状态都有恢复路径——不留死胡同。 适用时，以下情况都应有路径：空值/null、输入无效、超时/网络/集成问题、中断/会话丢失、权限/身份验证、返回/取消——每种情况都应回到一个可继续执行的步骤；每个异步步骤还应包含加载/进行中状态和成功/确认状态。任何状态都不应让用户陷入困境；承载关键流程的状态应明确消息意图——错误 = 原因 + 修复方法，空状态 = 引导用户采取行动，成功 = 结果。缺口：缺少适用状态、错误路径陷入死胡同、异步步骤没有加载状态就直接跳到成功、错误没有恢复路径，或在重要情况下未说明关键状态的消息意图。
5. 步骤明确且可遍历。 读者无需猜测即可跟随叙述；每个步骤都注明屏幕/状态及用户操作，并提供标签。缺口：步骤含糊或节点未标注。
6. 两种表示保持一致。 每个流程都包含 Mermaid 流程图和编号叙述 + 分支/错误列表，且图结构一致；多角色流程使用泳道。缺口：缺少其中一种表示、节点/分支在两种表示中不一致，或多角色流程使用未区分的单一泳道，导致角色分工不明。
7. 屏幕可枚举，便于制作线框图。 屏幕索引应完整涵盖每个流程的所有屏幕/状态（包括加载 + 成功），每项都有一个规范名称，且在图、叙述和索引中完全一致，不遗漏任何项目。缺口：流程引用的屏幕未列入索引、名称不一致、索引中有孤立条目，或没有索引。（不可合并基线：命名 + 索引枚举。）
8. 明确列出假设/待解决问题；流程不等同于用户旅程。 应说明 PRD 信息不足时所作的假设（且这些假设可以被质疑），列出待解决问题，不应暗中作出产品决策；文档应保持为交互关系图（不应按步骤描述情绪/渠道）。缺口：隐藏决策，或将用户旅程内容纳入流程。（不可合并基线：流程与用户旅程的边界。）

新增内容（结构、韧性、无障碍、质量、修订）： 9. 导航与 IA 框架（适用时）。对于多端产品，应有导航／应用外壳模型及寻路机制；适用时应处理深层链接（含前置条件检查／恢复），以及跨设备路径差异；每个跨流程交接都指向明确定义的流程，且不存在孤立流程（无法到达且没有出口）。交接指向已移除／未定义的流程，或多端产品的流程忽略导航模型／存在真实的设备差异，即为缺口。简化： 单屏／单流程工具没有应用外壳、跨流程图，且只有一个入口——不构成缺口。 10. 交互韧性（适用时）。每个不可逆／破坏性操作都应提供确认或撤销；每个多步骤流程都应说明是恢复还是重新开始；状态变更步骤应显示发生了什么变化；乐观操作应定义回滚和反馈路径（且不得用于支付／删除）。未加保护的不可逆操作、无提示的状态变更、未说明中断处理方式的长流程，或不安全／无法回滚的乐观操作，均为缺口。简化： 只读流程无需保护／持久化／确认的内容——不构成缺口。 11. 流程级无障碍。每条路径都必须可通过键盘完成（无陷阱），且可通过辅助技术（AT）完成（错误需有提示，不能仅依赖颜色／位置）；步骤／路由变更时应管理焦点顺序（WCAG 2.2 SC 2.4.3）；不得有必须使用鼠标／手势才能完成的步骤。必须使用鼠标的必需步骤、只能通过视觉感知的错误（导致 AT 用户受阻），或步骤变更时未管理焦点，均为缺口。（不可简化的基线：可通过键盘操作；单屏流程对跨步骤焦点管理的要求较低，但路径仍必须可通过键盘／AT 完成。） 单屏像素级 WCAG（对比度／目标尺寸）不在此范围内——这属于线框图／DS。 12. 流程质量（仅限客观标准）。不得存在多余步骤（路径长度不得超出任务所需——路径长度仅在此处评估一次）；应预防不可逆操作（操作前加以保护），而非只在事后补救；不得强迫用户回忆前序步骤已确定的信息，而不将其延续到后续步骤；类似任务应使用一致的路径。路径明显过长且无正当理由、未预防不可逆操作、造成跨步骤回忆负担，或类似流程间存在无正当理由的不一致，均为缺口。主观偏好不构成缺口——“有更好的流程”绝不会触发修改。简化： 简单流程自然符合要求。 13. 限定于差异的审查（仅在评审修订时适用）。审查差异及其连带影响，而非整份文档：未触及的流程保持不变（不得无范围地重新生成）；不得有跨流程交接指向已移除／重命名的流程；屏幕索引不得缺项或存在孤立条目；不得有先前可到达的路径变为无法继续；编辑内容应在图表与叙述间保持同步；文档版本号增量应与变更类别匹配（移除／重命名 MAJOR 流程或移除可到达路径 · 新增 MINOR · 文案修改 PATCH），且变更日志应与差异一致；破坏性移除应附带弃用说明。以上任一项不符合要求，即为缺口。简化： 全新项目的首次构建不涉及此条件。

14. 能力路由（无能力记录时不适用）： 每个跨能力转换都应明确标注源能力和目标能力的 ID；entry_point／exit_point 标签必须与能力记录一致。

第 3 步：确定结论

• approve — 每项适用条件均通过。线框图审查可以列出每个屏幕并走完每条路径；按文档所述，路径可找回、具备韧性、可完成（包括 AT 用户），且客观合理。即使你能想到风格上的改进，也应予以批准；标准是检查清单，而非完美无缺。
• revise — 一项或多项条件存在明确、具体的缺口（目标无对应流程、流程没有入口、分支悬而未决、错误路径走入死胡同、缺少加载/成功状态、不可逆操作未设防护、必需步骤只能用鼠标完成、AT 用户被错误状态困住、路径长度无故过长、交接到已移除的流程、图示与叙述不同步、索引中缺少屏幕、修订版本标注错误等）。

不要为了表明做了工作或索取锦上添花的改进而要求修订；更不能基于主观喜好。条件要么满足，要么不满足。

第 4 步：给出结论和可执行的发现

结论单独占一行——原样写出 VERDICT: approve 或 VERDICT: revise，不得加代码围栏、引号或其他文字（此处的围栏仅作示例）：

VERDICT: approve

然后列出发现。若为 revise，每条发现都必须可执行——指出未通过的条件、确切位置以及如何修复，让作者一轮即可解决。若为 approve，发现可以省略，也可以列出不影响通过的备注。

好的发现会明确指出缺口和修复方法：

revise — 韧性（条件 10）：在流程 3（账户设置）中，“删除账户”从按钮直接进入成功状态，没有确认或撤销步骤。修复：在不可逆删除之前添加确认步骤（或采用可恢复的软删除并提供撤销功能），并说明已删除的内容。

revise — 流程可访问性（条件 11）：在流程 2（引导流程）中，“重新排序优先级”步骤只能通过拖动完成，没有键盘替代方式，因此键盘/AT 用户无法完成该路径。修复：添加可通过键盘操作的重新排序方式（上移/下移控件），并确保焦点移动到重新排序后的项目。

不好的发现含糊不清且无法执行：

流程可以更稳健。（哪个流程？哪个条件？如何修复？）

规则

硬性规则（绝不违反）：

• 只输出一行判定：VERDICT: approve 或 VERDICT: revise——该字面标记必须单独占一行，不能包含其他内容。下游工具会解析它。
• 评审，不创作。 返回问题，不要重绘、修复或补全流程。
• 统一标准。 按照第 2 步中的 14 项条件进行评审——作者也以同一标准产出内容。不要另创条件或采用更严格的个人标准。尤其是，条件 12 仅限客观评估：主观偏好绝不算缺陷。
• 避免误判为 revise。 只要满足所有适用条件，即使是简单产品的小型文档，也应通过。只有存在明确指出的实际缺陷时才要求修改。对于精简原型，新条件（9–13）都可能不适用（参见「比例原则」）——不要因为精简流程合理地省略了不适用的章节，就凭空制造缺陷。
• 避免误判为 approve。 存在真正缺陷时绝不能批准。导致用户无路可走的路径、孤立目标、缺少保护措施的不可逆操作、让辅助技术（AT）用户陷入困境的错误、索引中缺失的屏幕，或指向已删除流程的交接，都应判为 revise。
• 死路和缺少保护措施的不可逆操作会阻断通过。 让用户陷入困境的路径，或没有确认/撤销机制的不可逆操作，始终应判为 revise。
• F5/F6 边界。 逐屏像素级 WCAG（对比度/目标尺寸/焦点外观）属于线框图/设计系统（DS）的关注范围，不属于条件 11；路径长度只在条件 12 中评估一次，不要在条件 11 中重复评估。
• 依据文档所提供的上游内容进行评审。 按其 depends_on 集合进行评估；未产出的上游内容绝不能作为要求修改的理由；如果文档忽略了本应参考的已产出上游内容，则可以据此提出问题。
• 每项修改意见都必须可执行——指出未通过的条件、具体位置和明确的修复方法。

偏好（可覆盖）：

• 按严重程度排列问题——阻断性缺陷（死路、缺少保护措施的不可逆操作、孤立目标、缺失屏幕、让 AT 用户陷入困境的错误）优先，其次是轻微问题。
• 在每项意见中注明条件编号/名称，方便作者对应标准。
• 引用位置时，注明流程以及具体节点/步骤/分支/交接。
• 批准说明应少而明确，且不得涉及阻断问题。

比例原则

「足以绘制线框图 + 流程可走通 + 有韧性 + 无障碍 + 设计稳健」应与产品规模相称。简单产品完全可以只有少量流程、少量边缘状态，没有应用外壳，也没有韧性保障章节；只要小型文档完整，并满足所有适用条件，就应通过。新条件对于精简原型可能不适用：9（单屏工具没有应用外壳/跨流程图），10（只读流程没有需要保护的操作），11（单屏流程的跨步骤焦点管理较简单，但仍须能通过键盘/AT 完成操作），12（琐碎流程自然满足此项），13（绿地项目不涉及差异审查）。有四项条件是始终适用的基线条件——无论规模大小，缺少它们都会导致流程出问题：条件 2（明确的成功状态）、条件 7（规范命名 + 屏幕枚举）、条件 8（流程而非用户旅程）、条件 11（键盘可操作性）。评估完整性和路径质量，而非流程数量；因内容简短而凭空制造缺陷，是这里最常见的评审错误。

易踩之处

• 只因内容齐全就批准，而不看是否可走通／具备韧性。 所有流程都有涵盖，但文档仍然无法走通——某个分支缺少一侧、错误没有恢复路径、图表内容不一致、删除操作没有防护，或错误状态让 AT 陷入困境。应判断每条路径能否走通、恢复、完成且逻辑健全，而不是模板是否填满。
• 漏掉死胡同／未设防的不可逆操作。 两者都藏在异常路径中；顺利路径看起来总是完整的。沿着每个分支和错误追踪到终点，并检查每个不可逆操作是否有防护。
• 漏掉无提示的状态变更／缺失的加载状态。 某个步骤修改了内容却没有说明“发生了什么变化”，或某个异步步骤直接跳到成功状态，读起来似乎完整，实则存在缺口（条件 4/10）。
• 只看一种表示形式。 只读图表而跳过叙述（或反过来），必然会漏掉同步缺陷（条件 6）。
• 把像素级 WCAG 要求套用到条件 11。 对比度／目标尺寸属于线框图／DS 范畴，不属于流程级无障碍要求。不要重复评判。
• 对简单产品错误地要求返修。 精简流程可能会恰当地省略产品并不具备的应用外壳、韧性或设备差异；不适用的边缘状态不构成缺口。新增条件会层层叠加——应根据产品规模调整判断标准。
• 因个人偏好而要求返修（条件 12）。 “我会用不同方式设计”绝不构成缺口。条件 12 只依据客观标准。
• 收到修订内容却重新评审整份文档。 针对修订内容，应将评审范围限定在变更及其连带影响（条件 13）；不要重新争论未改动的流程。
• 判定词漂移。 “Approved”、“LGTM”、“needs work”或埋在其他内容中的判定结果都无法解析。必须单独一行写出字面形式 VERDICT: approve|revise。

反模式

• 敷衍批准。 只扫一遍顺利路径，就在未追踪异常路径、不可逆操作或 AT 路径的情况下批准。
• 吹毛求疵地要求返修。 把图表样式、节点形状或措辞问题包装成缺口来阻止通过，或因主观偏好要求返修。只有真正明确的阻塞问题才应要求返修。
• 悄悄重绘。 在评审过程中直接撰写内容，会混淆产出与评判的界限。
• 凭空添加条件。 添加作者从未产出的私设要求（例如“每个步骤都要体现情绪”，或主观上的“更顺畅的流程”），会导致评审标准偏离产出标准。
• 评判布局、像素或目标。 按钮的位置／对比度（线框图／DS），或某个目标是否值得实现（PRD）——这些都超出此评审环节的范围。
• 含糊的判定结果。 “基本批准，但是……”或给出两行判定结果。只能有一个决定。

输出

针对一份用户流程文档，给出一份评审结果：

• 一行判定结果——单独一行逐字写出 VERDICT: approve 或 VERDICT: revise。
• 发现的问题——若判定为 revise，每个阻塞缺口列出一条可执行的问题说明（未通过的条件 + 位置 + 具体修复方法）；若判定为 approve，可选择列出非阻塞备注。

抽象的使用方是负责协调产出→评审循环的任何实体：approve 表示接受该用户流程文档并进入下一阶段（线框设计）；revise 表示将问题反馈给产出方，进行范围明确的修订。

相关内容

• authoring-user-flows——负责产出的部分；它按照本技能评判所依据的同一标准编写流程。将两者配对可确保标准只有一个来源，避免产出与评审的标准发生偏差。
• wireframes-review 技能——负责下一个文档的同级评审环节（逐屏布局 + 逐屏像素级无障碍）。这是不同的评审环节，有不同的标准；本技能评判的是导航图及路径可完成性，并据此为其提供屏幕列表。
• PRD-review 技能——负责上游文档（目标／用户画像／指标）的评审环节。本技能会根据这些目标检查覆盖情况，但不会重新评判这些目标。
• user-flows template / content-template 工具——负责各章节的结构；本技能评判的是是否符合质量标准，而非结构是否合规。

渐进式披露

• references/completeness-walkability-bar.md — 展开说明 13 项条件，包括各项条件的通过／差距信号、比例失衡情形，以及已完成的发现示例。 当某项条件处于临界状态、需要更明确地判断是否通过或存在差距时加载。
• references/sources.md — 审查方法、流程与用户旅程的界限、韧性／无障碍／质量条件，以及差异审查的研究来源。

正文预算

• description ≤ 1,024 个字符（agentskills.io 上限）。Claude 会在列表中将 description 与 when_to_use 的合计长度截断至 1,536 个字符。
• 正文约 500 行／5,000 个 token（软性目标——质量优先；若持续超过 700 行／7,000 个 token，则标记出来）——每轮都保留在上下文中。
• 每个参考文件：超过 10k 个 token 时警告，超过 25k 个 token 时报错。参考文件总计：超过 25k 个 token 时警告，超过 50k 个 token 时报错。