用途
Shaping 是一套结构化方法论，用于与用户协作地定义问题（需求）并探索解决方案选项（形态）。它把「要解决什么」和「怎么解决」分开管理，通过反复迭代让两者互相校准，适合在正式实现之前对齐方向。
主要能力
- 需求集 R：用编号（R0、R1、R2…）定义问题空间，需求由协作协商产生，并跟踪状态（核心目标、未决、倾向是/否、必须有、最好有、排除）。需求描述「需要什么」，不描述「是否被满足」。
- 方案形态 S：用字母（A、B、C…）表示互斥的解决方案路径，需从中选一个。形态内部用 C1、C2、C3… 表示组件（组合使用），用 C3-A、C3-B… 表示某组件的备选方案（每个组件选一个）。
- 适配检查（Fit Check）：一张决策矩阵，行是需求、列是形态，用 ✅/❌ 二元判断每个形态是否满足每条需求，失败原因写在 Notes 中。
- 宏观适配检查（Macro Fit Check）：面向高层、需求已分块、机制多为 ⚠️ 的早期形态，每个形态两列——Addressed?（高层是否触及）与 Answered?（能否追溯到具体机制）。
- Spike 调查：针对机制或可行性不确定的组件，用独立文件记录调查问题、目标与验收标准，先弄清现状再决定是否推进。
- Breadboard 映射：把系统映射为 UI 与非 UI 的可供性（affordance）表格及按 Place 分组的接线图，用于理解改动落点或把高层形态具体化。
- 多层级一致性：shaping 文档、slices 文档、各 slice 计划构成从高到低的层级，高层是低层的设计视图，低层包含更多细节；任何变更都要判断是否影响上下层，并在同一次操作中同步更新，避免文档漂移。
使用方式
- 开始会话：提供两个入口——从 R（需求）出发，描述问题、痛点或约束，逐步积累需求并让形态自然浮现；或从 S（形态）出发，先画出已有方案，再反向提取需求。没有固定顺序，R 与 S 在整个过程中互相影响。
- 处理已有 shaping 文档：若已选定形态，只展示该形态的适配检查（如 R × F），并汇总未解决项（未决需求或该形态标 ❌ 的需求）。
- 阶段推进：分为 Shaping（探索问题与方案空间、选定并细化形态，产出含 R、形态、适配检查、breadboard 的 shaping 文档）与 Slicing（拆分为可演示的垂直切片）两个阶段。当形态通过适配检查、已被 breadboard 成具体可供性、且需要规划实现顺序时，从 Shaping 进入 Slicing。没有 breadboard 过的形态无法切片。
- 可能动作（可任意顺序）：填充 R、勾画形态、细化组件、细化可供性、探索备选、检查适配、提取需求、breadboard、spike、决策、切片。
关键约定
- 展示完整表格：展示 R 或任何 S 时始终显示每一行，不摘要、不缩写，包括子部件与所有备选。
- 变更标记：重新渲染需求表或形态表时，用 🟡 标出每一处改动或新增的行，置于变更单元格内容开头。
- 适配检查为二元：只用 ✅ 或 ❌，不使用 ⚠️ 或其他符号；⚠️ 仅用于部件表的 Flag 列。
- 需求分块：顶层需求不超过 9 个，超出时归组为带子需求（R3.1、R3.2…）的块。
- 部件必须是机制：描述要构建或改变的东西，而非意图或约束；避免 R 与 S 之间出现同义反复。
- 部件应为垂直切片：避免「数据模型」这类横向分层，把数据模型与它支撑的功能放在一起；重复逻辑应提取为独立部件供其他部件引用。
- 层级记号：先用扁平记号（E1、E2…），仅在部件过多、需要展示结构或便于沟通时引入层级（E1.1、E1.2…）。
- CURRENT 保留名：用 CURRENT 描述现有系统，作为理解改动落点的基线。
- Flagged Unknown（⚠️）：部件可被高层描述但机制未明，标 ⚠️；带 ⚠️ 的部件在适配检查中必须记为 ❌，因为 ✅ 是对「知道如何满足」的声明。早期形态可有许多 ⚠️，但被选中的形态应无 ⚠️，或明确用 spike 解决。
- 表格是事实来源：breadboard 的 UI 与非 UI 可供性表定义 breadboard，Mermaid 图只是渲染；收到反馈时先改表，再改图。
- Spike 文件管理：spike 始终放在独立文件（如 spike.md 或 spike-[topic].md），可独立于 shaping 文档共享或处理。
适用场景
需要先对齐问题再选择方案的协作场景，例如产品功能设计、系统改造、方案选型等。尤其适合需求与方案需要反复迭代、且希望保留决策审计轨迹的团队协作。
限制
资料未提供该方法的工具依赖、平台支持、收费或价格信息。其效果取决于团队是否严格遵循多层级一致性与完整表格展示等约定；若文档层级之间失去同步，方法论将无法正常运作。