论证断在哪一步，决定了你接下来该修什么
下面五个场景都基于论证规则重构，不是原书案例的直接搬运。
每个场景对应一种最常见的论证断裂。识别断裂类型是修论证的前提——你不知道论证断在哪里，就不知道该补什么。
方案汇报被一个"为什么"问倒
你在季度评审里提议调整定价策略。PPT 做了十五页，数据、图表、竞品分析都有。领导只问了一句："所以你的核心理由是什么？"
你愣住了。
这不是准备不充分。是准备的方向错了——堆了大量信息，但没有搭论证。
典型错法：把材料当前提。十五页 PPT 里有大量信息，但没有一页在说"因为 A 和 B，所以应该调价"。结论藏在标题里，理由散在各个角落，听众自己拼不出来。
这种错法的根源是混淆了"准备充分"和"论证完整"。你可以对一个话题了解得非常深入，但如果你没有把理由和结论之间的关系说清楚，听众只看到一堆信息，看不到你的推理。
论证规则怎么切进去：韦斯顿的第一条规则——先写下你的结论，再逐条列出支撑它的理由，每条理由单独站得住。回到那份 PPT，不是加更多数据，是在第二页写清楚："调价的理由有三个，分别是……"。
下次做汇报前，试试把你的结论和理由写在一张纸上，不超过五行。如果五行写不下，说明你要么理由太多需要筛选，要么结论还不够明确。
做完这一步，你会发现那十五页里能支撑结论的可能只有三页。其余的是背景，不是前提。
边界：并不是每次汇报都需要把论证写成论文。但凡有人可能问"为什么"，你就需要事先回答好这个问题。判断方法：如果你删掉所有图表，只留三句话，还能让人知道你的理由——论证就搭完了。
用大厂案例推销本地方案
你在团队讨论中说："字节跳动就是这么做增长的，我们也应该这样。"有人问："字节的用户规模和我们一样吗？"
你说不上来。
这种场景在技术选型、产品策略、营销方案讨论中反复出现。
一个听起来有说服力的类比，经常经不起一个追问。
典型错法：类比只看表面。字节和你的公司可能都在做用户增长，但驱动增长的关键变量完全不同——预算、市场阶段、用户构成、数据基础。
类比论证不是"他们做了我们也做"，是"在与结论相关的关键维度上，两者确实相似"。维度对不上，类比就不成立。
怎么修：把类比拆开。先明确你想论证的结论是什么，再找出和这个结论直接相关的维度。如果在关键维度上两者差异很大，这个类比就不能用——换一个更接近的例子，或者换一种论证方式。
不是所有"别人怎么做"都能构成论证。大部分时候，它只是一个未经检验的类比。
边界：类比论证不是不能用。当两个场景在关键维度上确实高度相似，类比是最直觉、最有说服力的论证方式之一。关键不是"不要类比"，是"类比前先拆维度"。
一个好的类比会让你说出："在市场阶段、团队规模和用户构成这三个维度上，我们和 X 公司确实接近。"一个坏的类比只能说："他们做了，所以我们也应该做。"
用专家头衔堵住质疑
项目会上你引用了某位行业大佬的观点来支撑技术选型。有人问这位大佬有没有在类似规模的项目上用过这个方案。你回答："他是这个领域最有名的人，应该没问题。"
典型错法：用名气代替资质。权威论证有严格限定：这个人在这个具体问题上有专业经验。跨了领域、换了规模、过了时效，权威就失效。一位分布式系统专家对前端架构的看法，不比一位有经验的前端工程师更可靠。
怎么修：引用前先过三个问题。这个人在这个具体领域有直接经验吗？他的判断是基于什么条件做出的？条件和你的场景匹配吗？
三个问题答完，有时候你会发现：与其引用权威，不如直接摆你自己的理由。
常见变体：不只是引用名人。团队内部的"老张说的"也是权威论证。老张在数据库选型上有十年经验，他说用 PostgreSQL 就可以当论据——但如果讨论的是前端框架，老张的经验就不直接相关了。权威论证的有效性严格绑定在"这个人 × 这个问题"的交叉点上。
反驳变成互相指责
团队复盘会上，有人指出上线流程有漏洞。负责人的第一反应是："你自己上次也出过线上事故。"讨论偏离了流程问题，变成了互相翻旧账。
典型错法：人身攻击替代了论证回应。对方提出的是一个关于流程的论证，你回应的却是关于这个人的评价。不管对方过去犯过什么错，他现在说的话要么有道理，要么没道理——和他是谁无关。
人身攻击之所以危险，不只是因为它不礼貌——而是因为它会让整个讨论从"这件事该怎么处理"滑向"你是什么人"。一旦滑过去，论证就彻底终止了。
韦斯顿的谬误清单里，人身攻击排在第一位。不是因为它最复杂，是因为它最常见、最容易触发、破坏力最大。
怎么修：听到对方的论点后，先用一句话复述它。"你的意思是上线流程缺少 X 环节？"复述完，再决定是同意、部分同意还是反驳。反驳的对象是他的理由，不是他这个人。
这条规则在情绪上来时最难执行。但也正是情绪上来时最需要它。一个判断标准：如果你的回应里出现了"你""你们"而不是"这个理由""这条建议"，你大概率已经滑向了人身攻击。
边界：在非正式闲聊中偶尔吐槽不算人身攻击。这条规则管的是你试图回应一个论证的时候——那个时刻，你的回应必须指向理由，不指向人。
分析报告写了十页，每段在讲不同的事
你写了一份市场分析报告。自己读了一遍，觉得每段都有道理，但串起来不知道在说什么。同事读完说："你的结论到底是什么？"
典型错法：有信息，没论证。十页里每段都在陈述一个事实或一个观点，但段和段之间没有推理关系。读者看完知道了很多事情，却不知道你想让他们得出什么结论。
这是最常见的论证性写作问题：作者把收集信息和搭建论证混为一谈。数据收集完了，但从数据到结论的推理链完全缺失。
论证性写作的规则：先写下你的核心结论，把它放在开头。然后每段只做一件事——支撑结论的一个理由。理由之间有先后逻辑就按逻辑排，没有就按重要性排。最后，把最有力的反对意见纳进来，说明为什么你的理由仍然成立。
做完这个重组，十页可能变成五页。但每一页都在推进论证，而不是堆砌信息。
段与段之间要有推理连接。"此外""另外"不算连接——它们只表示"下面还有一段"。"因为上一条成立，所以接下来看……""有人会反驳说……但……"——这种才是推理连接。
报告的价值不在页数。在于读完之后，读者知道你的结论是什么、理由是什么、你考虑过什么反对意见。
一个自检方法：写完报告后，让一个没参与项目的人读第一页。如果他能说出你的结论和核心理由，论证就搭通了。如果他只能说"你分析了很多东西"——论证还没搭完。
边界：不是所有文档都需要论证性写作。纯记录性文档（会议纪要、进度更新）不需要论证结构。但凡你在文档里表达了一个立场或建议，读者就有权问"为什么"——那你就需要论证。