Principle 01
结论先行
Answer First — 把答案放在第一句话，把论据放在后面
Pyramid · 核心结构
原则表述
读者打开一份备忘录、邮件、报告，最想知道的是"所以呢？（So what?）"。把这个答案放在最前面，再展开论据与细节。不要让读者像看侦探小说一样翻到最后一页才知道凶手是谁。
名家原话
"Readers can absorb your ideas with less effort if you give them the major idea before you give them the individual ideas being grouped. The reader will be looking for a structure linking the sentences together. To make sure he finds the one you intended, you must tell him in advance what it is."
— Barbara Minto, The Pyramid Principle, Ch. 1
中译：先给出主要观点再给出被归类的子观点，读者吸收起来更省力。读者一定会去寻找连接这些句子的结构——为了确保他找到的是你想要的那个，你必须事先告诉他。
原理解读
人脑的工作记忆有限（Miller 7±2 法则）。当读者先看到散乱的细节，他必须一边读一边猜测"这些是要说什么"，认知负担成倍增加。结论先行的写法让读者一开始就拿到"心智地图"，后面的每个细节都能挂上去。这与亚马逊 6 页备忘录、麦肯锡 SCR (Situation–Complication–Resolution)、军队 BLUF (Bottom Line Up Front) 同源。
修改示范
After reviewing Q3 metrics, analyzing user feedback from 12 interviews, and benchmarking against three competitors, we have come to the conclusion that we should sunset the legacy API by year-end.
We should sunset the legacy API by year-end. Q3 metrics, 12 user interviews, and three competitor benchmarks all converge on this conclusion.
关于明年研发预算分配的问题，经过与各团队的多轮讨论，结合过去一年的产出数据以及战略优先级的考虑，我们建议将更多资源投入到 Agent 方向。
建议明年将 60% 研发预算投入 Agent 方向。理由有三：去年产出数据、战略优先级与团队意愿一致指向此处。
适用场景
- ✓ 决策备忘录、领导汇报、技术 RFC 的 Summary、邮件主体
- ✓ 任何"读者比作者更忙"的场合
- ✗ 不适用：悬念叙事、故事性写作、需要慢慢铺陈情感的文学
- ✗ 谨慎使用：当结论会让人立刻情绪反弹时，需要先共情后给结论
常见错误
- 把"背景介绍"写成第一段，结论在第三页才出现
- 用"经过仔细分析……"作为开头，浪费读者第一句注意力
- 把行动建议藏在"接下来该怎么办"的最后
- 结论与论据顺序颠倒，论据先写得多，结论虚弱
- 担心"显得突兀"而在结论前加一长串铺垫
关键参考
Barbara Minto《The Pyramid Principle: Logic in Writing and Thinking》（1978，金字塔写作的奠基之作） · Amazon S-Team Memo 模板（结论与建议在 Section 1）
"The single most important sentence in any article is the first one." — William Zinsser. In a memo, that first sentence carries the recommendation.
本周习作
翻出你过去一个月发的三封工作邮件。把每封邮件的第一句话剪出来贴在一起。问自己：单看这三句话，读者能否知道你想要什么、建议什么、决定什么？如果不能，把每封邮件改写成第一句话就是结论的版本——不超过 15 个汉字或 12 个英文词。
Principle 02
MECE 结构
Mutually Exclusive, Collectively Exhaustive — 子论点之间相互独立、合起来完全穷尽
Pyramid · 分组逻辑
原则表述
支撑一个论点的子论点（金字塔的下一层）必须满足两个条件：彼此不重叠（Mutually Exclusive），合起来完整覆盖问题（Collectively Exhaustive）。否则读者会觉得"还有什么没说"，或者"这两点是不是一回事"。
名家原话
"The ideas at any level in the pyramid must always be mutually exclusive and collectively exhaustive. This is the single most important rule of analytic thinking that I learned at McKinsey."
— Barbara Minto, The Pyramid Principle
中译：金字塔任一层级的观点必须相互独立、完全穷尽。这是我在 McKinsey 学到的最重要的分析思维规则。
原理解读
MECE 不是为了好看，是为了让读者放心。当读者看到"我们从三个维度看：成本、收益、风险"，他立刻能判断"嗯，这三块加起来确实覆盖了"。但如果你写"从财务、技术、成本三个维度"——成本是财务的子集，读者会潜意识警觉：作者的思维是不是有漏洞？MECE 是写作的"信号"，传递作者已经把问题想透。
修改示范
这次故障原因有三：代码 bug、监控不到位、技术债务。（"代码 bug" 和 "技术债务" 重叠，且没覆盖"流程问题"）
这次故障可归因为三类：代码（bug + 技术债）、流程（缺少 code review）、监控（无告警阈值）。
Our users fall into three groups: enterprise, SMB, and developers. (Developers cuts across enterprise and SMB — not mutually exclusive.)
Segmented by company size: Enterprise (>1000 employees), Mid-market (100–1000), SMB (<100). Persona is tracked separately as an attribute.
适用场景
- ✓ 战略分析、原因诊断、方案对比、用户分群
- ✓ 任何需要"穷尽可能性"的论证
- ✗ 不适用：感性叙事、文学随笔（强求 MECE 会显得机械）
- ✗ 谨慎使用：在快速沟通中过度追求 MECE 会拖慢决策
常见错误
- 分组维度不一致（一半按部门分，一半按地域分）
- 列出 5 条理由，其中 2 条说的是同一件事
- 遗漏"其他/默认"那一类（不周延）
- 分类过细，子项之间区分度低
- 用"等等"草草收尾——实际上是没想清楚
关键参考
Barbara Minto《The Pyramid Principle》Ch. 6 "Imposing Logical Order" · Ethan Rasiel《The McKinsey Way》（MECE 在咨询实务中的应用）
"If you can't say it MECE, you haven't thought it through." — A common saying at McKinsey. MECE is less about the output and more about the discipline of the input.
本周习作
选一个你正在面对的工作问题（如"为什么用户留存下降"），用 MECE 拆解出 3–5 个原因类别。然后做两个检查：(1) 任意两类之间是否真的没有重叠？(2) 把所有类别合起来，是否覆盖了 100% 的可能性？若不行，调整分类维度，直到满足。把这个金字塔贴在墙上一周。
Principle 03
自上而下 vs 自下而上
Top-Down vs Bottom-Up — 两种构建金字塔的工作流
Pyramid · 写作流程
原则表述
金字塔可以两种方式建造：自上而下是"先定结论，再往下找论据"；自下而上是"先把材料铺开，再归纳出结论"。前者快但容易武断，后者慢但容易迷路。成熟的写作者两种都用：自下而上做研究，自上而下做表达。
名家原话
"Building a pyramid top-down is generally easier than trying to build it bottom-up. This is because your easiest starting point is what you know about the subject. And what you know best is its purpose — the question it will answer in the reader's mind."
— Barbara Minto, The Pyramid Principle, Ch. 4
中译：自上而下构建金字塔通常比自下而上更容易。因为最容易的起点是你已经知道的——你最了解的就是它的目的：它要回答读者心中的哪个问题。
原理解读
自下而上（grouping → summarizing）适合还在探索的阶段：你不确定结论是什么，需要让数据说话。自上而下（hypothesis → testing）适合表达的阶段：你已经想清楚，要把它讲明白。最大的错误，是用自下而上的方式去做表达——把所有研究过程都倒给读者，让他自己拼。
▲ Main Point (Answer)
/ \
/ \
Sub1 Sub2 Sub3 ← MECE
/|\ /|\ /|\
数据 事实 例证 ← 论据
修改示范
（自下而上原稿）我们调研了 23 个用户、看了 6 个月数据、做了竞品分析。数据显示 DAU 下降 15%，访谈中 18 人提到 onboarding 太长，竞品的 onboarding 平均 2 步。所以可能需要简化 onboarding。
（自上而下改写）建议本季度简化 onboarding 至 2 步。三类证据支撑：（1）DAU 下降 15% 的主因是首次使用流失；（2）23 个用户访谈中 18 人主动提到"步骤太多"；（3）主要竞品已稳定在 2 步以内。
（思考阶段）我先不下结论，把 Q2 所有故障都列出来：1 月 3 起、2 月 5 起、3 月 2 起……（这是自下而上的草稿，留给自己）
（表达阶段）Q2 故障率上升 40%，主要由发布流程不规范导致。下面分三类原因展开……（这是自上而下的成稿，给读者）
适用场景
- ✓ 自上而下：你已经知道结论，需要高效表达（90% 的工作沟通）
- ✓ 自下而上：探索性研究、用户访谈归纳、未知领域调研
- ✗ 不适用：把自下而上的全过程展示给读者（除非读者明确要求"过程"）
- ✗ 谨慎使用：自上而下过早封闭，会错过反直觉的发现
常见错误
- 把研究过程当成报告交付（"我做了 A，然后做了 B，最后发现 C……"）
- 自上而下时，结论是先入为主的偏见而非真分析
- 跳过自下而上直接写，论据其实不存在
- 在同一篇文档里混用两种结构，读者迷路
- 用"过程展示"来证明自己"工作量大"——读者只关心结论
关键参考
Barbara Minto《The Pyramid Principle》Ch. 4 "Building a Pyramid Structure" · Paul Graham《The Age of the Essay》（思考的过程 vs 思考的呈现）
"Think bottom-up, write top-down." A working motto. The reader doesn't need your scaffolding — only the building.
本周习作
找一份你以前写的较长的文档（>500 字）。先标出每段的核心论点（这是它"应该"出现的位置）。然后重新排列，让"答案"出现在第一段第一句，论据按 MECE 分组排在后面。对比改写前后——哪一版你更愿意作为读者读？
Principle 04
SCQA 导言结构
Situation–Complication–Question–Answer — Minto 的故事化开场公式
Pyramid · 开场技艺
原则表述
Minto 提出：任何严肃文档的开头，都应该是一个微型故事——情境 (Situation)、冲突 (Complication)、问题 (Question)、答案 (Answer)。先让读者认识"我们在哪里"，再揭示"出了什么变化"，让他自然产生"那怎么办"的问题，最后给出你的答案。
名家原话
"The classic pattern of an introduction is: Situation, Complication, Question, Answer. Together, they tell a 'story' that draws the reader into recognizing your question as his question, so that he will be interested in your answer."
— Barbara Minto, The Pyramid Principle, Ch. 3
中译：导言的经典结构是：情境—冲突—问题—答案。它们共同讲述一个"故事"，让读者认同你的问题就是他的问题，从而对你的答案产生兴趣。
原理解读
纯结论的开头有时显得"砰"地一下，缺少铺垫；纯背景的开头又拖沓。SCQA 是两者的折中：情境是读者熟悉的事实（共识），冲突是新出现的变化（紧张），问题是冲突逼出来的疑问（钩子），答案是你的论点（解决）。这是亚里士多德修辞学、好莱坞剧本、亚马逊 6 页备忘录开场共享的底层结构——人类从公元前就靠它讲故事。
修改示范
建议升级核心数据库到 PostgreSQL 16。理由是性能、安全和成本。
【情境】我们的核心数据库自 2021 年起运行 PostgreSQL 12。【冲突】上月 PG 12 已进入官方 EOL 倒计时，预计 11 月停止安全补丁。【问题】我们应该升级到哪个版本，何时升？【答案】建议本季度内升级至 PG 16，三个理由：安全合规、性能提升 30%、长期支持至 2028。
本周我们要决定 Q3 是否上线 Agent 功能。请大家发表意见。
【S】上季度我们承诺过用户 Q3 会有 AI 助手功能。【C】然而上周技术评审发现核心模型延迟未达可用标准。【Q】我们应该按期上线、延期、还是降级方案上线？【A】建议降级方案上线：先发布"指令模式"，三个月后补"对话模式"。
适用场景
- ✓ 决策备忘录、提案、产品 PRD 开场、季度总结开场
- ✓ 需要让读者"理解为什么这件事现在重要"的场合
- ✗ 不适用：纯信息更新（如周报数据）不需要故事化
- ✗ 谨慎使用：太短的沟通（Slack 消息）会被 SCQA 拖累
常见错误
- 情境写成宏大背景（"在这个 AI 飞速发展的时代……"）——空洞
- 冲突不真实，是硬造的紧张感
- 问题不是读者真正的问题，是作者自己关心的
- SCQA 拖到三段才走完，失去开门见山的力度
- 把 SCQA 当固定模板填空，缺乏自然语气
关键参考
Barbara Minto《The Pyramid Principle》Ch. 3 "Why a Storylike Introduction?" · Amazon Working Backwards / PR-FAQ 模板（与 SCQA 同源的叙事化开场）
"Every good piece of writing begins with both a mystery and a magic trick." — A useful re-framing: Situation+Complication is the mystery, Answer is the magic.
本周习作
选一个你下周需要发出的决策邮件或提案。用 SCQA 写一个 4 句话的开头：一句情境、一句冲突、一句问题、一句答案。让一位同事只读这 4 句话，问他：你知道我想要什么决策吗？你觉得这件事紧迫吗？如果两个答案都是"是"，开头就成功了。