设计会话开始时需要统一七层产品设计框架、定位当前决策并避免…

在开始产品/UX 设计会话、需要判断当前应处理哪一层决策并检查下层基础时使用。

适用场景

解决思路

1. 在任何设计会话开始时加载 /layers-intro，获取所有 /layers-* 技能依赖的框架上下文。
2. 用三层七层组织设计工作：Reality（复杂、矛盾、演化，是所有学习的来源）；Problem space（1 Observed behaviour：用户实际做什么；2 The domain：独立于任何产品存在的概念、术语和心理模型；3 User needs：我们认为用户想达成什么以及为什么）；Solution space（4 Product & service strategy：服务哪些需求、瞄准什么业务结果；5 Conceptual model：对象、关系、状态、词汇，独立于任何界面；6 Interaction structure and flow：地点、可供性、连接和流程逻辑；7 Surface：文字、视觉、反馈、层级，即用户实际遇到的内容）。
3. 把这些层视为逻辑依赖关系：下层是上层基础；弱下层会产生向上传播的 UX debt。
4. 不按线性流程推进：可从任意层进入，但每次都检查其下方基础是否稳固。
5. 将设计定义为对解决方案形式的决策；把 form 视为解决方案，把 context 视为必须适配的需求、约束和环境，追求 good fit。
6. 用四类进展推进设计：做出决策；发现尚未做出的决策；评估已有决策是否风险高、不一致或错误；排列决策优先级（下层更基础、出错风险更大）。
7. 让每个技能帮助设计师做出更好的决策，而不是替设计师做决策。
8. 把每个 /layers-* 技能当作某一层的技术库，而不是从头到尾执行的脚本；不要机械走完每步并产出一堆 artefacts。
9. 找出当前层的 live decisions：哪些决策尚未决定、有风险或值得浮出；若不确定，用 /layers-orient 跨所有层找；如果这里没有 live decision，说明并继续，不要制造工作填结构。
10. 针对该决策提供合适技术：每个技能列出技术与适用情境；建议一两个并让设计师选择；技术是做出特定决策的方法，不是要填的框。
11. 处理该决策，只捕获残余物：产出决策所需内容，通常是几行，有时一张图，而不是完整报告；对话是工作表面，捕获是对话后留下的东西。
12. 找到每个技能标明的该层决策与该层纪律，把它们当作脊柱；具体提示词可丢弃，但其服务的决策不可丢弃。
13. 原则1：决策，而非输出。artefacts 只有在代表已做或已浮出的决策时才有用；命名决策，而不只是图。
14. 原则2：先发现再解决。浮出设计师原本不知道需要做的决策，通常比回答已知决策更有价值。
15. 原则3：一次只处理一层。混淆 problem space 与 solution space，或 surface 与 conceptual model，会产生混乱输出。
16. 原则4：向上构建前检查基础。处理上层前审计下一层，标记不稳定性。
17. 原则5：conceptual model 是最被忽视的承重层，给它比舒适感更多关注。
18. 原则6：标出坏决策，而不只是缺失决策。已做出的风险或不一致决策需要被命名，而不是绕过。
19. 原则7：引导，而非被引导。基础决策未做前，不要跳到 surface 输出。
20. 原则8：区分设计原则与实现决策。有些决策无需知道系统约束即可陈述——从用户视角应该发生什么；有些与实现纠缠：表述用户体验需求，形成形状良好的问题，并带入设计+工程对话；不要强行给过早答案。
21. 原则9：捕获决策，而非逐字记录。默认轻量输出：已做决策、已浮出决策、开放问题，仅此而已；不要生成比用户会重读的更长的文档；对话本身已是记录；图只有在编码了决策时才值得保留；每个技能的 Produce 列表是可捕获内容的菜单，不是必须全部写出的命令；只有被要求时才提出扩展。
22. 原则10：向上推进，向下拉回。层不是单向攀爬；当某层工作感觉无根据/漂浮——在没有明确理由下细化结构——通常是因为看不到什么会依赖它；向上探查一两层（画一个 flow、screen、bet）以发现下层实际需要什么，然后回到下层做该工作，使其更清晰且连接到路径；向上探查以学习不等于向上承诺去构建：不要在不稳定下层上最终确定上层，但也不要拒绝向上看一眼。
23. 主动探查时间维度；时间决策常被忽略，集中在两层。
24. Conceptual model 层：决定 intermediate action states——对象在解决前是否经过过渡状态（saving、processing、pending approval），这些是模型状态。
25. Conceptual model 层：决定 read model lag——数据写入与可见之间的差距；表述用户需求；将其作为命名开放问题标给工程。
26. Conceptual model 层：决定 relationship temporality——“all products in Europe”是指现在的组，还是成员变化时的组？这是设计决策。
27. Conceptual model 层：决定 deletion semantics——archive、trash、hard delete 还是 regulatory delete？说明选哪个及原因，实现随后。
28. Conceptual model 层：决定 history——对象过去是什么是否重要？说明它重要本身就是设计决策。
29. Interaction structure 层：决定 post-action state——提交后用户看到什么？重定向列表是否立即反映更改？
30. Interaction structure 层：决定 optimistic vs. pessimistic updates——在服务器确认前显示假定结果，还是等待？说明偏好；若实现不确定，标为开放问题。
31. Interaction structure 层：设计 empty、loading、partial states——每个地方都有时间生命周期，全部设计。
32. Interaction structure 层：设计 error and failure paths——validation failure、server error、network disconnection、concurrent edit；这些是必需设计步骤，不是事后补充。
33. 用 OOUX 对象失败模式诊断：Shapeshifter——同一对象在不同语境下形状显著不同；表面修复：一致对象处理；更深修复：模型没有清楚定义对象时改模型。
34. 用 OOUX 对象失败模式诊断：Masked——不同对象类型看起来一样；表面修复：不同视觉处理；更深修复：模型没有区分它们时改模型。
35. 用 OOUX 对象失败模式诊断：Broken——对象的数据和操作散落在各屏且无交叉链接；这是交互结构问题 → /layers-interaction-flow。
36. 用 OOUX 对象失败模式诊断：Isolated——对象存在但没有可见关系；这是概念模型问题 → /layers-conceptual-model。
37. 用 Nielsen 启发式做根层映射：“Match between system and real world”违规几乎总是根植于 conceptual model，而非 surface；“User control and freedom”是 interaction structure 决策；在 surface 打补丁只治症状不治根因。
38. 捕获工作默认可选且轻量；尽早问一次：要不要保存本次会话决策的简短摘要，还是留在对话里？如果保存：项目中的 Markdown 文件（Mermaid 图在 VSCode 用 Markdown Preview Mermaid Support 扩展原生渲染）、Notion（若 MCP 已连接），还是其他地方？
39. 无论目的地，偏向简短（原则9）：捕获决策，而不是复述讨论；一页会被重读的胜过十页只被略读的；如果更完整写作确实有帮助，主动提出，不要假设。
40. 写 Mermaid 图时，在节点标签内用 `<br/>` 换行，不要用 `\n`，后者会渲染为字面文本。
41. 不确定聚焦哪里时，用 /layers-orient 对七层做快速诊断。
42. 已知在哪一层时，直接跳到对应技能：/layers-observed-behaviour、/layers-domain、/layers-user-needs、/layers-product-strategy、/layers-conceptual-model、/layers-interaction-flow、/layers-surface。

适用边界 · 注意事项

• 不要把每个 /layers-* 技能当作必须从头到尾执行的脚本，也不要在该层没有 live decision 时强行产出全套 artefacts。
• 下层基础不稳定时，不适合在上层最终确定方案。
• 不适合只想要机械生成设计文档、而不是围绕决策进行设计对话的场合。