authoring-user-flows

authoring-user-flows — SKILL.md

变体： standard · 使用时机： 产品负责人正在为某个产品／功能编写（或修订） 用户流程文档，需要流程推导方法和生产级标准（可走通性 + 结构 + 韧性 + 无障碍 + 质量 + 修订），并通过单独的模板工具组织章节结构。

概述

此技能用于编写用户流程文档：产品的导航／交互图——用户从哪里进入，流程所在的信息架构（IA）框架是什么，用户沿着怎样的理想路径前进，路径在哪里分叉，经过哪些屏幕／状态，出错时会发生什么，路径是否具有韧性且无障碍，以及流程是否足够好。它提供的是判断标准（如何根据上游目标和先例推导流程，而不是凭空臆造；如何确保路径不会走入死胡同；如何让图表和叙述保持同步；如何修订而无需重新绘制），而不是章节列表——结构由模板工具提供。此文档位于已批准的 PRD（提供目标和用户角色）之后、线框图之前（流程中提及的每个屏幕都会成为线框图目标）。范围是交互图，而非像素、PRD 中的产品决策，也不是用户旅程图（情绪／渠道／触点随时间变化不在范围内）。

何时启用

• 根据已批准且包含目标和用户角色的 PRD，为产品或功能编写用户流程／任务流程／交互流程文档。
• 修订现有用户流程文档，纳入范围明确的变更（添加／更改／移除流程或路径）——采用版本化增量，而非重新生成（见步骤 11）。
• 映射用户经过的路径（进入 → 步骤 → 分支 → 错误／恢复 → 退出），以便后续线框图阶段能够枚举每个屏幕。

以下情况请勿启用：

• 审查／评判已完成的用户流程文档——这属于审查阶段的门禁（reviewing-user-flows），它会验证此技能所遵循的同一标准。
• 设计屏幕布局／像素——这属于 authoring-wireframes，它会使用这些流程。每个屏幕的像素级无障碍（对比度／目标尺寸）也由该技能负责。
• 编写上游 PRD，或重新决定产品目标／用户角色。
• 编写用户旅程（情绪／渠道／随时间变化）——这是另一种交付物。

输入

阅读计划交给你的所有文档——即你的 depends_on 集合（由发现阶段确定、会为本文档提供信息的上游文档）——并将本文档的内容追溯到这些文档。典型的上游文档是 PRD（目标和用户角色）；设计系统（如有）提供流程所引用的导航／应用外壳和组件词汇；修订时，现有用户流程文档也会作为输入提供。不要假设输入固定不变：列出的上游文档只是参考，而非上限。务必做到自包含——根据实际收到的任何上下文产出内容；如果缺少预期的信息来源文档，就基于现有信息继续，并将缺口明确列为假设，绝不要编造内容来填补。并且，如有研究能力可用（deep-research），就用它来参考领域惯例和先例流程模式，而不只是填充模板。

能力上下文（如有提供）： 如果调用方注入了 capability_record（来自 capability-map.yaml product_capabilities 的记录），请在步骤 1 之前阅读。它定义你的范围边界：owns = 你负责涵盖的实体；refs = 你会引用但不负责涵盖的实体；publishes／consumes = 你会说明的事件；entry_points／exit_points = 用户如何进入和离开；has_ui／has_api／has_persistence = 适用的界面。存在此记录时，必须将其视为硬性约束——不得超出它定义的边界。

工作流

先使用模板工具进行编排。 起草前，先通过内容模板工具（content-template-gateway 能力，或已安装的其他模板提供方）获取用户流章节结构。该工具会提供每个流程的槽位（目标/PRD 对应关系、入口点、流程图、叙述、分支、错误/恢复、弹性与系统状态、 无障碍、屏幕/状态、成功），以及导航与 IA、跨流程转换、屏幕索引、假设和 版本控制/变更日志章节。绝不要硬编码另一套大纲——此技能负责用推导出的内容填充模板槽位，而不是重新定义模板。

如果注入了全部能力记录：使用 exit_points → entry_points 链映射跨能力用户旅程。为每个流程标注其经过的能力 ID。单个能力内的流程必须限定在该能力的 entry_points/exit_points 范围内。

步骤 1：为每个目标/角色推导一个流程——将其视为一项任务，并以既有模式为依据

将每个 PRD 目标视为角色要完成的一项任务（用角色自己的话描述目标，并包含其功能/社交背景），每组目标/角色对应一个流程。不同角色可能以不同方式实现同一目标——分别为他们创建流程，并说明其差异的原因（心智模型/情境），而不是将其合并。这样可确保没有遗漏：每个 PRD 目标/角色组合都有对应流程，且每个流程都能追溯到一个目标/角色。以既定交互模式为每个流程提供依据，例如该任务的标准身份验证/密码重置/结账/引导/OAuth 模式，以及产品既有的交互模式——不要重新设计已有成熟方案的流程；如需偏离，必须说明理由。先填充覆盖映射；这是其余内容的主干。让文档聚焦于流程，而非旅程——不要为每个步骤描述情绪/渠道。

步骤 2：搭建导航与 IA 框架

绘制单条路径前，先确定其所处的结构框架（按比例填写——单屏工具中的大部分内容可省略）：

• 入口点分类——涵盖每个入口（主页、深层链接、电子邮件/邀请、 通知、营销活动），以及每个入口抵达的状态（通过深层链接进入的用户 可能会跳过某些步骤）。
• 导航/应用外壳模型 + 路径指引——各流程运行所依托的常驻界面、每个流程在 IA 中的位置，以及用户始终如何返回到已知位置（不能让用户脱离外壳而无路可退）。如果存在设计系统的外壳，请引用它。
• 深层链接/路由——对于可路由的产品：记录经过的路由，以及缺少前置条件时的拦截/恢复机制（深层链接指向需要先完成前序步骤的状态 → 过渡页面 → 恢复流程）。
• 跨设备差异——指出不同设备形态下路径（而不只是布局）的差异，例如移动端多一个步骤或原生子流程。

步骤 3：先梳理成功路径

对每个流程，先用简明语言列出大多数用户会走的关键路径——入口 → 有序步骤 → 成功出口，暂不考虑错误。为每个步骤经过的屏幕/状态命名，并使用稳定名称，在流程图、叙述和索引中保持完全一致。先以此为骨架，再逐步加入复杂情况；不要从边缘案例开始。

步骤 4：列出所有决策分支

在用户可以选择不同路径的每个节点，列出所有分支，并将每个分支指向某个步骤、另一个流程或明确的出口。某个决策存在未映射的分支，就会在构建后期暴露问题。不能留下缺少一条路径的“是/否”。如果流程之间存在交接，请在跨流程转换章节中记录，并确认目标流程确实存在（不能交接到未定义或已移除的流程）。

步骤 5：逐项检查边界情况和状态，确保没有死路

在每个步骤中按此固定清单逐项检查，确保覆盖全面，而非凭灵感发挥；并将各个状态视为路径经过的节点（它们会成为线框图目标）：

• 空值 / null · 无效和极端输入（边界值 0/1/最大值/最大值+1）· 超时 / 网络 / 集成错误 · 中断 / 会话丢失 · 权限 / 身份验证拒绝 · 返回 / 取消。
• 加载 / 进行中状态——每个异步或耗时步骤都要经过此状态 （骨架屏 / 加载指示器 / 进度）；将其绘制出来（异步步骤 = 触发 → 进行中 → 成功 | 错误），以便纳入屏幕索引。
• 成功 / 确认状态——用户看到的具体“目标已达成”状态（确认屏幕 / 参考编号 / 收据），而不只是抽象的“成功”。

对于每种适用情况，都要为用户提供一个状态和返回有效操作步骤的恢复路径——绝不让用户陷入困境。每个错误状态都要说明出了什么问题以及如何解决。

步骤 6：增强交互韧性并显示系统状态

除了错误恢复，还要增强路径的韧性（适用时补充；详见 references/resilience-and-states.md）：

• 撤销 / 不可逆操作需确认——每项破坏性或不可逆操作 （删除 / 付款 / 发送 / 最终提交）都必须提供确认或撤销；可逆操作优先提供撤销，而非模态确认。
• 恢复还是重新开始——每个多步骤工作流都要说明中断后的处理方式（哪些内容会保留、 保留多久），不可在重新加载时静默丢弃。
• “变更内容”反馈——每个状态变更步骤都要显示其结果，而不只是“完成”（已保存为草稿、已授权 $X、已提交为 #1234）。
• 乐观更新还是确认后更新——对于异步操作，要说明采用哪种方式；乐观更新仅适用于低风险操作（绝不用于付款 / 删除），并且必须定义失败时的回退 + 反馈。

步骤 7：检查流程级无障碍性

确保每种用户画像（包括辅助技术用户）都能完成每条路径（详见 references/flow-accessibility.md）。这是流程级无障碍，不是逐屏像素级 WCAG （后者属于线框图 / 设计系统范畴）：

• 全程可通过键盘完成，不得有键盘陷阱。
• 步骤 / 路由变更时的焦点顺序（WCAG 2.2 SC 2.4.3）——焦点移动顺序要有助于理解；步骤 / 路由变更时，焦点应移至新内容，而非丢失。
• 确保辅助技术用户可完成每条路径——包括顺利和不顺利的路径；错误必须通过程序化方式传达，不能只靠颜色 / 位置提示。
• 不得存在只能用鼠标 / 手势操作的必经步骤（每个步骤都要有键盘替代操作）。

步骤 8：应用客观的流程质量启发式原则

让流程不只是完整，还要优质——采用其中可客观检验的部分（主观品味不在范围内；详见 references/flow-quality.md）：

• 预防错误优于恢复错误——在不可逆操作发生前加以防护（确认 / 预览 / 启用前验证），而非只在操作后提供恢复方式。
• 识别优于回忆——步骤应展示前序步骤已确定的信息；不得要求用户“记住第 2 屏上的代码并在第 4 屏输入”，却不自动带入。
• 不添加无谓步骤——路径长度不得超出完成任务所需（只在此处评估路径长度，不在无障碍性评估中重复评估）。
• 保持一致性——相似任务应在不同流程中采用相似路径；遵循平台 / 设计系统规范，或说明偏离之处。

步骤 9：绘制两种记法，并保持同步

每个流程都要绘制两次：一份 Mermaid 流程图（开始／结束使用终止符，屏幕／状态使用矩形，决策使用菱形，边带有标签），以及一份带编号的叙述和明确的分支／错误路径列表。对于多参与方流程（用户 ⇄ 系统 ⇄ 管理员、第三方提供商、审批交接），使用泳道（每个参与方对应一个 Mermaid subgraph），明确说明各方的职责。两种记法必须描述同一张图——一种记法中有而另一种没有的节点／分支就是缺陷。明确说明承载关键信息的状态所传达的信息意图（错误 = 原因 + 修复方法，空状态 = 引导用户采取操作，成功 = 结果），并确保每个屏幕在图表／叙述／索引中都使用同一个规范名称。

步骤 10：将 PRD 内容不足之处列为假设／未解决问题

如果 PRD 未说明流程所需的内容，请写明假设（方便审阅者提出质疑），并将所有尚未解决的决策列为未解决问题——绝不要默默编造产品决策并将其藏在流程中。将仅属于用户旅程的内容（情绪／渠道）排除在外；如果确实需要，请将其提升为上游参考。

步骤 11：修订时——界定连带影响范围，编辑而非重绘，为文档设定版本

收到现有用户流程文档和范围明确的变更时，应将其视为有版本控制的源代码（参见 references/amend-method.md）：

1. 界定连带影响范围——哪些流程／分支／路径受变更影响，以及连带影响：交接到已变更／已移除流程的跨流程交接、已移除路径所引用的屏幕索引条目、发生移动的分支目标。
2. 编辑而非重绘——在原位置进行最小幅度的编辑；未触及的流程（图表、叙述、索引行）保持逐字节不变。不要无故重新编号。
3. 更新版本 + 变更日志——提升文档自身的版本（MAJOR = 移除／重命名流程或移除可达路径；MINOR = 新增流程／分支／路径；PATCH = 措辞／记法），并按流程／路径粒度添加 Keep-a-Changelog 条目。
4. 安全地弃用——在 MINOR 版本中弃用流程／路径（标记并注明替代项），然后再于 MAJOR 版本中移除；屏幕移除时，清理索引并确认没有剩余路径引用它。

步骤 12：交付前根据下方标准进行自检

执行质量标准检查。在将文档交给审阅或线框图设计之前，修正所有不符合项。

规则

硬性规则（绝不违反）：

• **组合，而非重复。**章节结构由模板工具提供；此技能绝不提供与之竞争的大纲。
• **推导，而非臆造——双向皆如此。**每个流程都对应某个 PRD 目标／用户画像；每个 PRD 目标／用户画像都有对应流程；标准流程遵循既定模式，或明确说明偏差。不得有孤立项，也不得重新发明已有解决方案的流程。
• **不留死路。**每个决策分支都必须有明确结果；每种错误／边缘状态都必须提供返回有效步骤的恢复路径。
• **两种表示法保持同步。**每个流程都包含 Mermaid 流程图，以及描述同一张图的编号叙述和分支／错误列表；涉及多个参与者时使用泳道。
• **每个屏幕只有一个规范名称。**名称在图表、叙述、各流程列表和索引中保持一致，修订时也必须一致。名称不一致会破坏枚举。
• **屏幕可枚举。**屏幕索引是所有流程中全部屏幕／状态的完整并集（包括加载和成功状态），这样才能枚举所有待制作线框图的内容。
• **不可逆操作必须设防。**每项破坏性／不可逆操作都必须提供确认或撤销方式。
• **流程，而非旅程。**只呈现交互图；不涉及情绪、渠道或时间跨度。
• **修订，而非重新生成。**变更时，在原位置编辑受影响的流程并更新文档版本；绝不重绘未受影响的流程。
• **能力边界（提供 capability_record 时）。**将文档输出限定在该记录的边界内。生成边界之外的内容（将 refs 实体视为归属对象，或设计超出 exit_point 的流程）属于范围违规，等同于臆造规范中不存在的内容。

偏好（可覆盖）：

• 每种目标／用户画像组合对应一个流程；当不同用户画像的流程出现分歧时，应拆分共享目标（并说明原因）。
• 叙述使用通俗语言；展开缩写；为图表中的每条连线标注说明。
• 根据 PRD 中的目标／用户画像数量和产品复杂度调整文档篇幅——轻量工具只需填写少数几个章节（无需应用外壳或韧性部分）；既不凑篇幅，也不删减内容。在适用的情况下填写导航与 IA／韧性／无障碍部分。

注意事项

• **只编写理想路径。**这会让流程变得脆弱——大多数真实用户都会偏离理想路径。边缘情况检查清单（步骤 5）和韧性部分（步骤 6）旨在系统性地确保覆盖全面。
• **状态变更未告知。**如果某个步骤更改状态后继续推进，却没有反馈“发生了什么变化”（步骤 6），流程看似完整，却会让用户摸不着头脑。
• **遗漏加载／成功状态。**如果流程从触发直接跳到成功，就会隐藏待设计的进行中和确认屏幕（步骤 5）。
• **图表与叙述不一致。**只编辑其中一项而忘记另一项，会导致内容自相矛盾。这是同一产物的两种呈现形式；每次变更都要核对并保持一致。
• **在流程中臆造产品决策。**将假设单独提取出来（步骤 10）。
• 各章节中的屏幕名称不一致（修订时也可能如此）。所有位置都必须使用一个稳定名称——这是修订时最常见的回归问题。
• **辅助技术用户受困于错误状态。**错误状态若只在视觉上明显、却未被播报，使用屏幕阅读器的用户就会困在原地，而视力正常的用户却能继续恢复操作（步骤 7）。
• **变更时重新生成。**修订时重绘未受影响的流程会造成文档反复变动，并破坏跨流程图（步骤 11）。

反模式

• “有图就够了。” 单靠流程图，无法通过文本逐步跟进；编号叙述 + 分支列表不是可选项。
• “我自己把章节列表写进文档就行。” 这会造成重复，还会偏离模板。始终通过模板工具编排结构。
• “边缘情况以后再管——先把正常流程发布。” 缺少分支、未处理的状态，以及没有防护措施的不可逆操作，都会导致用户受阻。
• “PRD 没写，所以我自己决定就好。” 未明确说明的产品决策应放在假设/待解决问题中。
• “顺便把布局也做了。” 屏幕布局属于下游文档；这里仅描述导航图。逐屏像素级无障碍设计也一样，归线框图/设计系统负责。
• “逐步标注用户的感受。” 那是用户旅程，不是用户流程。
• “新增一个流程就重画整份文档。” 只修改差异部分，并为文档更新版本。

生产级质量门槛

用户流程文档满足以下所有要求时，才算达到门槛（审核侧的关卡采用相同标准；要求会随产品而变化——精简文档满足每一项适用要求即可通过）：

1. 目标/用户画像覆盖——没有遗漏。 每个 PRD 目标/用户画像（以待完成任务的形式描述）都对应一个流程；每个流程都能追溯到来源；标准流程以对应模式为依据。
2. 导航与 IA 框架（适用时）。入口点分类完整；多界面产品应包含导航/应用外壳模型和路径指引；适用时应说明深层链接和设备差异；跨流程交接均有明确去向。
3. 明确入口与出口。 每个流程都列出所有入口点（+落地状态）和具体的成功/确认状态；其他出口也应清晰明确。
4. 每个决策分支都有明确结果。 每项决策都列出所有分支，且每个分支都有明确结果。
5. 每种错误/边缘状态都有恢复路径——不能有死路。 在适用时，应包含清单中的状态（包括加载 + 成功），并提供返回路径；错误应说明发生了什么以及如何处理。
6. 交互韧性（适用时）。为不可逆操作设置防护；说明多步骤流程如何恢复/重新开始；状态变更步骤应提供“发生了什么变化”的反馈；乐观操作应支持撤销。
7. 流程级无障碍。 每条路径都可通过键盘和辅助技术（AT）完成；步骤/路由变更时设置焦点顺序；错误应有播报；不能有仅支持鼠标的步骤。
8. 流程质量（客观）。 不应有多余步骤；防止不可逆操作发生，而不仅是在事后恢复；不应要求用户跨步骤记忆信息；相似任务的处理方式应保持一致。
9. 步骤明确且可逐步跟进。 读者无需猜测即可按叙述逐步操作；每个步骤都应注明屏幕/状态及用户操作。
10. 两种表示保持一致。 流程图与叙述 + 分支/错误列表应表示同一张图；多参与者流程应使用泳道。
11. 屏幕可枚举，便于绘制线框图。 索引应涵盖完整并集（包括加载 + 成功状态）；每个屏幕使用唯一规范名称；不能有遗漏的屏幕。
12. 明确列出假设/待解决问题。 说明精简 PRD 所需的假设；不能有未明确说明的产品决策；不能包含用户旅程内容。
13. 正确修订（迭代时）。变更范围明确并在原处编辑；未修改的流程保持不变；文档应更新版本并记录变更日志；有破坏性的删除应标记为弃用。

输出

一份用户流程 Markdown 文档：包含每份文档的版本标头和覆盖映射（PRD 目标／用户画像 → 流程）、导航与信息架构部分、每个流程各自的章节（每章包括同步的 Mermaid 流程图 + 编号叙述 + 分支／错误列表，以及入口、韧性与系统状态、流程级 无障碍、屏幕／状态（包括加载和成功），以及成功标准）、跨流程过渡列表、屏幕索引、 假设／待解决问题部分，以及版本记录／变更日志部分——并依照模板工具的结构编写。 该文档由审核端的关卡使用（按上述标准评判文档），并供下游线框图设计使用（枚举流程中 提及的每个屏幕）。方法和标准与媒介无关：未来的设计工具后端只会改变呈现方式，不会 改变推导过程或标准。

相关内容

• 模板提供方（content-template-gateway capability）——提供本技能据以编写的 用户流程章节结构；此处绝不重复。
• 研究能力（deep-research，否则使用网页搜索）——为领域惯例、既有流程模式和 推导依据提供支撑。
• 上游输入——PRD（流程要实现的目标和用户画像），以及在适用时提供的设计系统 （流程引用的导航／应用框架和组件）。绝不从空白页面开始。迭代时，需提供现有的用户流程文档。
• reviewing-user-flows——审核端的关卡，用于验证是否符合相同标准； 编写端和审核端使用同一套标准来源。
• authoring-wireframes——下游使用方；流程中提及的每个屏幕都会成为线框图目标， 因此完整的屏幕索引是交接约定。逐屏像素级无障碍不属于本技能的职责。

渐进式披露

• references/resilience-and-states.md——撤销／确认、恢复／重新开始、系统状态、 乐观式与已确认式操作，以及加载／成功／状态矩阵的详细说明（步骤 5–6）。
• references/flow-accessibility.md——将 WCAG 2.2 SC 2.1.1 / 2.4.3 应用于流程； 路由变更时的焦点顺序；辅助技术的可完成性；流程与像素级设计的边界（步骤 7）。
• references/flow-quality.md——映射到流程的 Nielsen 10 项启发式原则；客观评估子集； 不得无依据要求修改的边界（步骤 8）。
• references/amend-method.md——界定影响范围、编辑而非重画、文档版本控制与变更日志、 弃用（步骤 11）。
• references/sources.md——推导方法和标准的研究来源。

正文篇幅预算

• description ≤ 1,024 个字符（agentskills.io 上限）。
• 正文约 500 行／5,000 个 token（软性目标——质量优先；若持续超过 700 行／7,000 个 token，则标记提醒）——每轮都保留在上下文中。
• 每个参考文件：超过 10k 个 token 时警告，超过 25k 时报错。