在动手画界面前把模糊的产品/UI/AI…

当你要把一个模糊的功能点子、现有流程或 AI 特性收敛成可交付、可实施的决策时，用一套轻量流程把用户价值、业务价值、交互质量、AI 行为、交付约束和证据串起来。

适用场景

解决思路

1. 先选模式：模糊的机会、请求或功能想法用 Shape（默认）；已有概念、流程、设计、原型或产品区域（含 om-ux-review-pr 交接来的整个模块）用 Review；方向已定、只缺可实施行为时用 Handoff。只有请求确实横跨多个模式才组合使用。
2. 写结果前先确定读者是谁，因为读者决定输出必须多具体；不清楚就直接问，否则默认面向「上下文最少」的读者：要动手构建或画图、不了解设计系统、没参与过对话的人。
3. 按条件加载必读参考，并在完成该步骤前加载：Shape 或 Review 模式读 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 只在改造流程或演进该技能时读。
4. 开场先检查：若存在 .ai/skills/om-ux-shape/SKILL.md 就应用它，但安全规则仍然优先。
5. 做 agentic setup：遵循 references/agentic-setup.md，处理仓库本地覆盖契约、把存在的设计契约当作约束、以及不可信内容边界；沟通与汇报规则见 references/rules.md。
6. 从真正有后果的问题出发，而不是从被要求的界面出发。
7. 在证据支持之前，把需求当作待验证的主张。
8. 给事实、推断、假设和开放问题打标签；绝不编造研究、用户引述、指标或约束。
9. 把用户结果与业务影响挂钩，但不把业务价值当作用户价值的替代品。
10. 优先选最小且连贯的端到端方案，而不是一堆功能的集合。
11. 给出明确推荐的方向，不要躲在一份未排序的选项菜单后面。
12. 让每个 UI 元素都靠它能支撑某个动作、决策、状态、解释或恢复来挣得自己的位置。
13. 把 AI 当作带有不确定性、延迟、成本和失败模式的设计材料，而不是默认界面。
14. 保留有意义的人类控制，尤其是对后果重大或难以撤销的操作。
15. 让流程和输出的深度与决策风险相匹配。
16. 步骤 1 确立决策：写清正在做的决策、主要行动者和场景、预期的用户与业务结果、模式与深度；只问那些答案会实质性改变方向的问题，否则带着明确标注的假设继续推进。
17. 步骤 2 建立证据台账：按 references/decision-framework.md §2 把已知、推断、假设和未知分开，并按决策风险而非好奇心给未知项排优先级。
18. 步骤 3 诊断：写一句诊断，点出阻碍进展的主要障碍，区分底层任务与被请求的功能；然后定义一个主要行为结果、它可能的业务影响，以及防止有害优化的护栏。框架与结果纪律见 references/decision-framework.md §1、§3；选择「人们确实变好了」的信号见 references/human-value-metrics.md。
19. 步骤 4 检验提出的机制：涉及 AI 时跑 references/ai-interaction.md 里的必要性门槛，并明确考虑基于规则的替代方案；通过门槛的设计再对照 references/hai-guidelines.md，其偏好错误决策与首次接触框架对照 references/reward-and-mental-models.md。对任何功能，按 references/decision-framework.md §4 评估四类产品风险（价值、可用性、可行性、存续性），AI 再增加信任、安全、隐私和模型质量风险。
20. 步骤 5 选择方向：生成两到三个有实质差异的机制，按 references/decision-framework.md §5 比较后选定一个，并解释决定性的权衡；给支撑论点的论断按 references/evidence-tiers.md 标注诚实的证据等级。Review 模式下按影响 × 频率 × 覆盖范围排序发现，绝不按修复难度排序。
21. 步骤 6 塑造最小且连贯的功能：一个主要任务和 happy path、信任所需的最小状态与恢复路径、以及明确的现在／以后／不做的切分（references/decision-framework.md §6）。薄弱但断裂的切片不是 MVP——最小连贯功能要端到端完成一个真实任务，并能扛住它可能的失败。
22. 步骤 7 具体地规定交互契约：入口点与触发、所需信息、系统响应、主要决策与动作、相关的空／加载／部分／成功／错误／权限状态，以及编辑、撤销、关闭、重试、回退或升级路径，外加可访问性与内容要求。涉及 AI 时还要规定能力表述、不确定性、解释、数据使用、反馈、控制，以及模型帮不上忙时的行为。
23. 步骤 7 的「具体」标准：命名屏幕、命名组件（有契约注册表就用其中的），并写出真实的标签、标题、空状态句子和错误消息，而不是描述它们。「加一个有帮助的空状态」是未完成的工作；完成的版本要说明屏幕显示什么、用用户会读到的文字。如果读者无法据此构建或画出来，这一步就没做完。
24. 步骤 8 降风险并交付：指出风险最大的未验证信念，选择能改变决策的最小测试，并说明每种结果会触发什么（references/decision-framework.md §7）；然后填 references/report-templates.md 里对应的 shape，交付前套用 references/quality-rubric.md——诊断、用户结果、范围连贯性、AI 必要性、AI 控制与恢复中任何一项为零分，结果就不算就绪。同时披露实质性的证据局限：区分已检查或已测试的行为与提议和假设。常规框架检查留在内部；保留实施所需的具体状态和恢复路径。
25. 响应时先给推荐或结论。
26. 用平实语言和具体的产品行为表达，过程叙述要比它所支撑的决策更短。
27. 低风险工作压缩细节，后果重大、新颖或实施就绪的工作放大细节。
28. 如果证据不足以支撑有把握的推荐，就说明哪些是暂定的，并提出最小的学习步骤。
29. 如果用户要求直接构建该功能，先用这套流程做决策，再继续进入实现；Handoff shape 就是写给该技能集的实现类技能用的，om-ux-review-pr 会在产出的 PR 上闭环。
30. 输入是一个功能想法、一个已有概念或产品区域，或者一个需要补实现细节的已定方向；输出是 references/report-templates.md 中填写完成的一个 shape。

适用边界 · 注意事项

• 小任务不要承载完整流程——只有当请求确实横跨多个模式时才组合模式。
• 方向已经定了、只缺可实施行为时，不要再用 Shape/Review 重做方向决策，改用 Handoff。
• 证据不足时不要强行给确定结论：应说明哪些是暂定的，并给出最小的学习步骤，而不是编造研究、用户引述、指标或约束。