om-ux-shape

塑造有用的功能

先将模糊需求转化为明确的产品决策，再把它变成界面。 通过一个轻量流程，将用户价值、业务价值、交互质量、AI 行为、交付约束和证据联系起来。

输入 — 功能构想、现有概念或产品领域，或已确定但仍需补充实施细节的方向。 输出 — references/report-templates.md 中的一份已填写模板。

选择模式

• 塑造（Shape）：适用于模糊的机会、需求或功能构想。此为默认模式。
• 评审（Review）：适用于现有概念、流程、设计、原型或产品领域（包括由 om-ux-review-pr 移交的整个模块）。
• 交接（Handoff）：适用于方向已确定，但仍缺少可供实施的行为细节的情况。

仅当请求确实横跨多个模式时才组合使用，并且绝不要让小任务承担完整流程。

谁会阅读结果

开始撰写前先确定这一点，因为它决定了输出需要具体到什么程度。如果不明确，就先询问；否则，默认面向上下文最少的读者：他们将负责构建或绘制，不了解设计系统，也没有参与过讨论。请为他们撰写。资深设计师可以快速浏览具体的答案；抽象的答案却无法供任何人直接实施。

必须阅读的内容

这些不是可有可无的背景资料。符合条件时，必须在完成该步骤前加载相应参考资料：跳过会导致本技能旨在防止的问题，也就是答案听起来合理，却没有做出任何决定。

条件	加载
处于塑造或评审模式	references/decision-framework.md
已提出、暗示或已存在 AI	references/ai-interaction.md，然后为通过评估的内容阅读 references/hai-guidelines.md 和 references/reward-and-mental-models.md
正在定义成果或验证指标	references/human-value-metrics.md
撰写任何结果之前	references/report-templates.md
交付任何结果之前	references/quality-rubric.md

references/foundations.md 说明了流程背后的理由；仅在调整流程或改进此技能时阅读。

操作原则

1. 从影响重大的问题出发，而不是从用户要求的界面入手。
2. 将需求视为有待验证的主张，直到有证据支持为止。
3. 标明事实、推断、假设和待解问题。绝不捏造研究、用户引述、指标或约束。
4. 将用户成果与业务影响联系起来，但不要用业务价值替代用户价值。
5. 优先选择最小且连贯的端到端方案，而不是堆砌功能。
6. 推荐一个方向。不要躲在未经排序的选项列表后面。
7. 每个 UI 元素都必须物有所值，能够支持操作、决策、状态呈现、说明或恢复。
8. 将 AI 视为一种具有不确定性、延迟、成本和故障模式的设计材料，而不是默认界面。
9. 保留有意义的人为控制，尤其是针对影响重大或难以撤销的操作。
10. 根据决策的风险，调整流程和输出的深度。

工作流

务必先检查： 若存在 .ai/skills/om-ux-shape/SKILL.md，则遵循其中的要求；安全规则始终优先。

0. Agent 式设置 — 遵循 references/agentic-setup.md：仓库本地的覆盖约定、存在时作为约束的设计约定，以及不可信内容边界。共享的沟通和报告规则位于 references/rules.md。

1. 明确决策。 说明要做出的决策、主要参与者及其所处情境、预期的用户和业务成果，以及采用的模式和深度。只询问答案可能实质性改变方向的问题；否则，明确标注假设后继续。

2. 建立证据清单。 按照 references/decision-framework.md（§2）区分已知、推断、假设和未知事项。按决策风险而非好奇心对未知事项排序。

3. 诊断。 用一句话说明阻碍进展的主要因素，并区分底层任务与所请求的功能。然后定义一个主要行为结果、其可能产生的业务影响，以及防止有害优化的护栏。框定问题并严守结果纪律：references/decision-framework.md（§1、§3）；选择能体现人们确实有所受益的信号：references/human-value-metrics.md。

4. 检验所提机制。 涉及 AI 时，运行 references/ai-interaction.md 中的必要性门槛，并明确考虑基于规则的替代方案；通过门槛的设计随后要依据 references/hai-guidelines.md 进行检查，并依据 references/reward-and-mental-models.md 检查其偏好错误决策和首次接触时的表述。对于任何功能，依据 references/decision-framework.md（§4）评估四项产品风险（价值、可用性、可行性、商业可行性）；对于 AI，还要增加信任、安全、隐私和模型质量风险。

5. 选择方向。 生成两到三种有实质区别的机制，依据 references/decision-framework.md（§5）进行比较，并选出一种，说明决定性权衡。依据 references/evidence-tiers.md，如实标注支撑论点的关键主张所属的证据等级。在 Review 模式下，按影响 × 频率 × 覆盖范围排列发现，绝不能按修复难易程度排序。

6. 确定最小且完整的功能。 明确一个主要任务及其顺畅路径、建立信任所需的最少状态和恢复路径，以及明确的现在、以后和不做事项划分（references/decision-framework.md §6）。虽精简但无法正常运作的切片不是 MVP：最小且完整的功能应能端到端完成一项真实任务，并能应对可能发生的故障。

7. 具体规定交互契约。 说明入口和触发条件、所需信息、系统响应、主要决策与操作、相关的空状态、加载状态、部分完成状态、成功状态、错误状态和权限状态，以及编辑、撤销、关闭、重试、回退或升级处理路径，并明确无障碍和内容要求。对于 AI，还要说明能力表述、不确定性、解释、数据使用、反馈、控制，以及模型无法提供帮助时的行为。

   具体意味着：点名屏幕，点名组件（如有契约注册表，则使用其中的组件），并写出实际的标签、标题、空状态句子和错误消息，而不是只描述它们。“添加一个有帮助的空状态”意味着工作尚未完成；完成版应说明屏幕显示什么，以及用户会看到的具体文案。如果读者无法根据你的输出构建或绘制出来，这一步就尚未完成。

8. 降低风险并交付。 指出尚未验证且风险最高的假设，选择可能改变决策的最小测试，并说明每种测试结果会触发什么操作（references/decision-framework.md §7）。然后填写 references/report-templates.md 中对应的模板，并在交付前应用 references/quality-rubric.md：诊断、用户结果、完整范围、AI 必要性或 AI 控制与恢复任一项得分为零，都意味着结果尚未准备就绪。披露重要的证据局限：区分已检查或已测试的行为与提议和假设。将常规框架检查留在内部；保留实施所需的具体状态和恢复路径。

响应行为

• 先给出建议或结论。
• 使用浅显的语言描述具体的产品行为；过程叙述应短于其所支持的决策。
• 对于低风险工作，减少细节；对于影响重大、新颖或可直接实施的工作，增加细节。
• 如果证据不足以支持明确的建议，请说明哪些内容尚属暂定，并提出最小化的学习步骤。
• 如果用户要求构建该功能，请使用此工作流进行决策，然后继续实施。Handoff 的格式旨在供该集合中的实施技能使用；om-ux-review-pr 会对最终的 PR 进行复盘。