---
name: omd-pyramid
description: "金字塔结构化表达：把回答/汇报/方案/文档按 Minto 金字塔重组——结论先行、以上统下、归类分组(MECE)、逻辑递进，用 SCQA 开场，标题写成判断句。触发词：金字塔 / 金字塔原理 / 结构化表达 / 结论先行 / 总分总 / MECE / 不重不漏 / 怎么讲清楚 / 汇报怎么说 / 帮我把这段组织好 / pyramid / Minto / SCQA；或把一堆散点要点组织成有说服力的表达时。"
---

# oh-my-dsh · Pyramid 金字塔结构化表达

把「有一堆信息要说」变成「别人一遍就能听懂并照做」。方法论来自 Barbara Minto 的《The Pyramid Principle》：**先给答案，再给支撑，同层不重不漏**。

**本插件新增**（OMC 无对应项）：OMC 的表达类纪律只有 `ai-slop-cleaner`（管字面水分），没有管结构的方法论，所以这一条是 oh-my-dsh 自己补的。DSH 侧的原生载体是 `dsh-ui` 围栏（层级 → 组件）、`omd-hud`（进度快照）与 `todo_write`（骨架落地）。

## 何时用

- 用户说「讲清楚 / 结构化 / 结论先行 / 总分总 / MECE / 帮我组织一下」，或抱怨"说了一堆不知道你想说什么"。
- 交付形态是**给人看的**：汇报、方案、评审结论、调研报告、复盘、PRD、PPT 大纲、邮件/IM 长消息。
- 要点 ≥ 3 条、出现分歧需要裁决、需要对方做决定或采取行动。
- 反例（别硬套）：纯探索性头脑风暴（此时要的是发散，不是收敛）、需要先铺垫情绪的坏消息正文、一步步教学推导——这些见下方「何时不该结论先行」。

## 四根柱子

| 柱子 | 含义 | 失败长相 |
|------|------|----------|
| **结论先行** | 第一句就是答案/建议/裁决，不是背景 | "背景是这样的…然后我们查了…最后发现…" |
| **以上统下** | 上一层是下层的总结；下层回答上一层引发的疑问 | 上层说 A，下层全在讲 B |
| **归类分组（MECE）** | 同层要点互斥不重叠、合计穷尽 | 三条理由里两条其实是一件事；漏掉关键第四类 |
| **逻辑递进** | 同层要么是**归纳**（并列分组，须 MECE）要么是**演绎**（层层推导），二选一不混用 | 重要性倒挂，重点埋在最后一条；把演绎链硬拆成伪并列 |

四条缺一不可：只有「结论先行」是喊口号，只有「分组」是清单。

**演绎只放底层**：演绎链（大前提→小前提→结论）一环断则全塌，结论还埋在链尾——越往上越要用归纳。组内顺序按 **时间 / 结构 / 程度** 三选一。

## 序言：SCQA 开场

结论需要铺垫时（新听者、有冲突、有历史包袱），用 4 句开场，然后**立刻切回结论**：

1. **S 情境**：双方都认同的事实（"当前 v0.2.1 已发布"）。
2. **C 冲突**：打破情境的变化（"但技能清单和计数散落在 README、preset、docs 多处，加一个技能要同步改十几处"）。
3. **Q 疑问**：冲突自然引出的问题（"怎么加才不失控？"）——**这一句通常写出来最好，它是往下走的钩子**。
4. **A 答案**：就是你的结论，与全文第一条完全一致。

S/C 各不超过一句。序言超过 4 行说明你在用背景拖延结论。

## 三层自检（发出去之前逐层过）

**纵向**：从下往上问「所以呢？」——每条论据合起来，是否**足以**推出上层结论？推不出的，要么补论据，要么改结论（多数时候该改结论）。

**横向同层**：对每层做两问——
- *互斥*：两条要点能合并吗？能合并的就是一条，别充数。
- *穷尽*：还缺哪一类？用「按时间 / 按构成 / 按重要度」三个视角各扫一遍找漏项。

**序言**：S 是不是双方真认同？C 是不是真冲突？读者读完 Q 会不会自然想问你的 A？

## 数量与措辞纪律

- **同层 3–5 条**为最佳。超过 5 条时先问「这几条能不能概括成一层」，而不是继续平铺——分组天生就是用来压缩数量的。
- **标题写成判断句**，不写标签。`缓存不是瓶颈，连接池才是` ✅ ／ `性能分析` ❌。
- 每层要点自带**数字或事实**，形容词不算支撑（"显著提升" → "P95 从 820ms 降到 210ms"）。
- 一页纸骨架：

```
结论     ← 一句话，可决策/可执行
论据 1/2/3  ← 同层 MECE，各 1 行，带数字
支撑       ← 表 / 图 / 证据链（可折叠）
下一步     ← 需要谁、在什么时候、做什么决定
```

## 落到 DSH：金字塔 ↔ dsh-ui 组件映射

结构本身也能用组件承载，别把层级写成流水账。规则见 `genui` skill。

| 金字塔位置 | 组件 | 说明 |
|-----------|------|------|
| 结论 | `callout` / `hero` | 一条回答最多一个 hero |
| 同层论据（3–5 条） | `list` / `table` | ≥3 条并列优先 `list`/`table`，不写 markdown 项目符号 |
| 数字对比 / 指标 | `stat` / `chart` / `table` | 有数就有组件 |
| 层级与派生 | `steps` / `mermaid` / `accordion` | 展示"谁支撑谁" |
| 裁决 / 风险 | `callout` | tone 表态：success / warn / danger |
| 下一步 | `callout`（info）或 `steps` | 永远是最后一项 |

纪律与 `genui` 一致：**同一批数据不重复表达**；组件多不是问题，"每个组件承载不同信息、有焦点层次"才是判据。

## 与其它模式的关系

- **`omd-ai-slop-cleaner`** 管「字面水分」，本 skill 管「结构错位」——先结构后文字，顺序反了会白删。
- **`omd-hud`** 是进度快照，不是结论；HUD 之后仍要有一句金字塔式的结论收尾。
- **`omd-plan` / `omd-review` / `omd-research` / `omd-autoresearch`** 的产出天然是金字塔素材：把它们的表格当层级里的支撑证据，别把过程重讲一遍。
- **`omd-deep-interview`** 收敛出的规格，写给用户时按金字塔呈现（结论 = 定稿的规格，论据 = 关键取舍）。
- **PPT / 文档交付**：一页一结论；页标题即该页的论据，全篇构成金字塔的横向一层。

## 何时不该结论先行

- **坏消息 / 敏感决定**：先 SCQA 建立共识，再给结论；直接甩结论会被当成不体谅。
- **对方尚未认同前提**：先解决前提分歧，否则结论只会引发争论。
- **纯发散**：要的是选项空间，此时结论先行会过早杀死可能性——先列，再收敛，收敛时切回金字塔。
- **唯一可行路径的强操作**：直接给步骤（`steps`），不用论证。

## 收尾：HUD

按 `omd-hud` 输出结构化对照，让「改了什么」一眼可见：

```dsh-ui
{"title":"Pyramid · 结构重组","gap":14,"items":[
  {"type":"row","wrap":true,"items":[
    {"type":"stat","label":"结论位置","value":"第 1 句","delta":"原第 7 段"},
    {"type":"stat","label":"同层要点","value":"4","delta":"-2 (合并)"},
    {"type":"stat","label":"MECE 缺口","value":"补 1 类"}
  ]},
  {"type":"table","columns":["层","原状","改后"],
   "rows":[["结论","埋在最后","首句，判断句"],["论据","6 条混杂","4 条 MECE"],["支撑","散落正文","表 + 证据链"]]},
  {"type":"callout","tone":"info","title":"下一步","content":"按新骨架重写，再用 ai-slop-cleaner 过一遍文字"}
]}
```

## 反模式

- **漏斗式开场**：背景 → 过程 → 结果 → 结论。人类读长文才这样写，读你的回答不这样读。
- **伪 MECE**：三条要点是同一件事的三种说法（"更快 / 性能更好 / 延迟更低"）。
- **层级错位**：论据不支撑结论，只是因为「我想说」才写进去。
- **标签标题**：`## 性能分析` 不传递任何判断，读者得自己总结——那就等于没写。
- **贪多**：一层塞 9 条。宁可新起一层，也不要平铺。
- **结构压过事实**：金字塔是组织方式，不是让弱论据显得强的化妆术；论据不足时该改的是结论。