上一篇讲的是“开口之前先判断对方要拿这些信息做什么”。判断完了，紧接着的问题就是：同一堆信息，先说哪一句？这篇只讲这一件事——结论先行。
“先说结论”不等于“只报结果”
回到接口延期的例子。同样的事实，两种开场：
A：“上周三开始对接，对方文档写得不清楚，来回问了两轮，周四发现字段对不上……”
B：“本周的功能验收要挪到下周一，整体上线时间不受影响。”
B 是结论先行。项目经理听到 B，可以当场决定验收安排要不要动；听到 A，只能一边攒信息一边猜你要说什么，猜到第四句才等到那个决定真正需要的一句话。
还有一种更常见的走形：C——“我讲一下联调的情况，分三点。”这句话听起来像开场里的“结论”，其实只是节目单，它说的是你打算讲什么，不是你的判断是什么。判断一句话算不算结论，有个很朴素的标准：它是不是一个可能被反对的判断。 英文商业写作里常举的例子是，“北区选址的几个方案”不是结论，因为没人能反对它；“拿下北区、砍掉扩建”才是结论 3。
为什么先把判断给出去，对方才接得住
这不只是礼貌问题，背后是一个关于记忆的机制。
教育心理学家 David Ausubel 在上世纪六十年代提出过一个概念，叫 advance organizer（先行组织者）。做法是：在讲细节之前，先给一个比后面内容更抽象、更概括的上位框架，让后面那些零散信息有地方可挂。Ausubel 强调它不等于摘要或概览——摘要和后面的内容处在同一个抽象层级上，而 organizer 要高一层，作用是“认知脚手架” 4。
搬到汇报里：第一句给出的判断就是那个脚手架。一串没有归属的细节，对方很难记住，也容易记错；归到一个判断下面，就好记得多。没有这个钩子，他得一边听一边自己猜结构——等你讲到第九句，他已经挂错了地方，后面的话全白说。
美国陆军的写作规范把这个做法写得很直白：AR 25-50 要求军队写作把要点放在开头（bottom line up front，缩写 BLUF），ST 22-2 把这套要求列为标准并说明它对口头沟通同样适用 15。
还要注意“放进第一句”和“放在第一段末尾”不是一回事。如果一段背景铺三行才落到结论，对方在读到你的结论之前，已经在按自己的想法往下推了。
后面每一句，都在接住前一句引出的疑问
Barbara Minto 在《金字塔原理》里把顺序讲得更细 2。她说，人的思考是分层的：上层的一个判断，会在听者心里生成一个疑问（“为什么？”“你怎么知道的？”“那我该做什么？”），下面那一层就是要回答这个疑问。
所以结论先行不是把一个孤零零的结论扔出去，而是搭起一条“问题—回答”链：
- 第一句给判断：验收顺延到下周一，上线时间不变。
- 对方心里立刻冒出来的是“为什么差两天，卡在哪”，第二层回答它：字段映射没对齐。
- 再下一句回答“那需要我做什么”。
用同一套逻辑检查自己的提纲也很简单：从第一句往下读，每层都问一句“它有没有回答上一层刚引出的疑问？”如果某一层答的是别的问题，结构就断了——那个内容本身再正确，对方也会觉得你跑题。
第一句前面，到底要不要铺垫
要，但只需要一句。
Minto 提出的 SCQA 框架把这件事说清楚了 3：Situation（对方已经接受的现状）、Complication（打破现状的那个变化）、Question（变化在对方心里引出的问题）、Answer（你的结论）。Situation 的作用是建立共同起点，必须是对方本来就认可、不会争辩的事；Answer 只有在前两条站得住时，才真的是“答案”。
回到接口延期：“这个模块原本按老字段做”是对方也知道的事实，属于 Situation；“对方这周改了接口定义”是他还不知道的变化，属于 Complication；由此产生的问题，和你的回答才接得上。
这也解释了为什么有人学了“结论先行”，照着念，效果反而更差：他把背景整段砍了，第一句直接是“我建议换方案”。在对方那儿，这句话既不像答案，也不像在回答他的问题，而是一个突然冒出来的意见。
准确的规则是：压缩背景，而不是取消背景。 一句 S 加一句 C，最多两句话，然后立刻给结论。展开过程、试过哪几个方案、谁说过什么，都留到他问“怎么发现的”再讲。
假如对方连 Complication 都不认（他不觉得“对方改了接口”算什么），那你要先处理的不是结论，而是这个分歧：“你觉得这个改动不影响进度，这点我得先跟你对齐。”先校准问题，再给答案。顺序反了，就变成各说各话。
进度、问题、请求，各自怎么排
三种最常见的汇报，骨架是同一个：一句话结论 → 支撑它的两三条依据（每条依据本身也是一句小结论）→ 明确的请求。
依据的顺序有个原则：按对方可能追问的顺序排，不按事情发生的顺序排。他最可能先问的放前面。
- 报进度：先给“能不能按期”的判断（“按期，但只剩一天余量”），再给关键依据（“联调还剩一个字段”），最后是请求（“不用你做什么，周四我再同步一次”）。时间线放到最后，只在他问“怎么拖到现在”时才展开。
- 报问题：先给“问题是什么、影响多大”（“线上有个数据错误，影响三个客户，今天能修完”），再给已经采取的动作，最后是需要他做的决定。不要从“我昨天在查日志”讲起。坏消息同样结论先行，但结论里必须带着影响和打算——只扔一句“出问题了”，对方只能自己脑补最坏情况，然后来追问你本来可以一次讲清的事。
- 提请求：请求本身就是结论，放在第一句 1。写清楚要谁、在什么时间、做什么决定。如果有几个选项，就把选项摆出来，而不是问“你看怎么办”。
按经历的顺序讲，接口延期这件事会变成：先对接→文档不清→问了两轮→发现字段不对→开了个会→还要两天。你讲完了，对方还得自己把这串话折成一个判断；结论先行做的事，就是你替他把这一步先做了。
什么时候不该结论先行
有三类场合，先说结论会起反作用。
第一，对方还不在你的问题里。换了人、时间隔得久、背景变了，先花一句对齐现状，否则你的结论落不到他关心的问题上。
第二，你要的是他的想法，不是他的批准。在需要别人贡献方案的讨论里，过早给结论会把讨论变成“同不同意我”，其他选项被压下去。这时候可以先给问题和已知约束，把结论留到后面。
第三，你自己也还没有结论。别为了结构好看编一个假判断。这时诚实说清手里的事实、目前倾向哪个方向、哪里还不确定，比假装笃定有用得多。
另外一句提醒：结论先行是结构问题，不是语气问题。第一句可以短、可以保守（“目前看能按期，但只有一天余量”），但不能模糊到听不出你的判断是什么。
开口前的三句自查
把你要说的第一句单独拎出来，问三个问题：
- 它是一个可能被反对的判断吗？（“关于联调的情况汇报一下”不是。）
- 对方听完这一句，知不知道接下来要做什么决定或动作？
- 后面的每一句，是不是在回答上一句引出的疑问？
第 3 点如果答不上来，多半不是表达问题，而是你自己还没想清楚这几件事之间是什么关系。结论先行考验的不是话术，是你有没有先把事情想成一个判断。