用途
自上而下备忘录是一套书面沟通方法，核心是“答案先行”。它依据明托金字塔原理，用于任何带有建议或发现的书面表达，例如给高管的邮件、需要对方回复同意或否定的 Slack 消息、简报文档与读前材料、应当推动决策的状态更新，以及带有明确观点的内部博客或 wiki 页面。资料说明，它也被称为 BLUF（结论前置）或明托金字塔，属于同一种思路的不同叫法。
主要能力
- 结论优先：第一句话即表明你持什么观点、要什么，读者读到此处即可停下。
- 2 至 4 个支撑论点：资料推荐“三”最理想；超过 4 个说明尚未完成综合，少于 2 个说明这更像一句话而非备忘录。
- 论点层面 MECE：各论点不重叠，且共同捍卫结论，若都成立则结论必然成立。
- 证据挂在各自论点下：每条论点下放 2 至 4 条具体、有出处的证据，便于读者跳到其存疑的论点查证。
- 背景置后或删除：多数“背景”段源于作者不敢直接给答案，应删减。
- 一份备忘录一个答案：有两个建议就写两份备忘录。
使用方式
输出格式为：一行结论；可选一行说明请求或意义；随后是“论点 1/2/3”及各自证据要点；可选最多 3 条风险或未决问题；可选背景。资料所列的输入要求包括：答案（你真正的观点）、读者身份（高管／同级／团队，影响用词与深度）、读者需做的决定（如有）、2 至 4 条理由及其具体来源。执行步骤为：一句话写出结论；列出 2 至 4 条论点并检验其联合是否必然推出结论；做 MECE 检查；在每个论点下堆放具体证据，避免“很多人”“显然”这类表述；通读并测试“随处可停”原则；删掉一切无法向上支撑结论的内容，尤其是我方背景、过程说明和“顺便交代一下背景”之类的话。
适用场景
资料给出两个示例：一是给 CEO 的收购建议备忘录，结论为“不应收购 Vega Labs”，并从价格、核心工程团队流失风险、整合风险三方面论证；二是发给同级的一条 Slack 消息，结论为“砍掉 Pro 档、并入 Team”，列三条理由、一条风险并提问是否在周五定价评审前对齐。示例格式展示了结论、论点、证据、风险、请求的排列顺序。
限制
资料明确列出不适用场景：真正处于探索阶段的思考、个人叙述、回顾、事后复盘等以时间顺序为要的场合；需要正式结构的决策产物应改用 Decision Memo Builder；没有建议的纯状态更新只需用清晰的列表。常见错误包括：埋没结论，“如你所知／为提供背景”之类开场白，用“定价”这类话题而非“定价是独立价值的 2.4 倍”这类主张充当论点，证据不能支撑其上论点，论点超过 4 个，以及把建议藏在“考虑事项”中。资料未提供该技能的安装命令、价格、平台支持或具体代码实现。