徐术挺-漫思录

04-论证扎实把我想说的变成读者信服的

27分钟阅读

04 论证扎实：把”我想说的”变成”读者信服的”

第一卷·认知地基 第四章

一、会议室里那次失败的汇报

去年你参加过一次方案评审。你做了一个技术选型推荐：项目 A 应该用 PostgreSQL 而不是 MySQL。你做了 30 分钟的汇报，展示了 PostgreSQL 的功能、MySQL 的不足、对比表。

汇报完，组长问了三个问题：

  1. “你说 PostgreSQL 一致性更好，能不能具体说说在我们的场景下，一致性差异会影响什么？”
  2. “你说 MySQL 性能更好，这个’更好’是怎么测出来的？测试场景是什么？”
  3. “你推荐的方案在我们公司有没有类似落地案例？踩过什么坑？”

三个问题里你答得很勉强。第一个答了但绕；第二个承认”我没测过，是看博客说的”；第三个答了”业界普遍用 PostgreSQL”——但被组长追问”业界哪家公司？“之后答不上来了。

最后组长说：“那你下周一补一份详细的对比文档给我，我们再讨论。”

你走出来，心里清楚——你做的不是”论证”，是”主张”。你主张用 PostgreSQL，但你没”论证”为什么。

这件事的本质：主张和论证不是一回事。

主张：我认为 X 应该这样做。 论证：因为 A、B、C，所以 X 应该这样做。

主张是结论，论证是结论的依据。你给读者主张，他可以接受也可以不接受——他没义务信你。你给他论证，他可以自己判断”这个论证是否成立”——他有了信你的依据。

这一章讲的就是怎么把”主张”升级为”论证”。

二、论证的三种武器

把”论证”拆开来看，所有论证都跑不出三种基本形式。

武器一：演绎推理。

从一般到个别。如果一般前提成立、推理过程正确，那么个别结论必然成立。

前提 1：所有分布式系统都必须处理数据一致性问题。 前提 2：我们的订单服务是一个分布式系统。 结论：我们的订单服务必须处理数据一致性问题。

技术文档里”如果 A、B 成立，则 C 必然成立”这类推理都是演绎。

武器二：归纳推理。

从个别到一般。如果观察到多个个别情况都呈现某特征，那么一般性结论可能成立。

观察：GitHub 上排名前 10 的 Go ORM 中，8 个支持 context 传递。 结论：Go ORM 普遍支持 context 传递。

注意：归纳的结论是”可能成立”，不是”必然成立”。归纳永远有反例风险——你可能漏了一个情况。

武器三：类比推理。

A 像 B。B 有 C。所以 A 可能有 C。

PostgreSQL 像 Oracle，都强调强一致性和事务完整性。Oracle 在金融行业普遍使用，金融行业对一致性要求高。所以 PostgreSQL 在一致性要求高的场景下可能比 MySQL 更合适。

类比是”启发式”——它能让人理解一个新概念，但不能证明新概念一定有那个属性。

三种武器的”说服力”：

武器说服力风险
演绎最强前提错了全错；推理过程复杂容易绕
归纳中等永远有反例风险；样本偏差
类比较弱类比往往不严谨；只用于”启发”

好的论证通常是三种武器的混搭——演绎打底、归纳验证、类比辅助。

三、证据的层级：数据 > 案例 > 类比 > 主张

讲完三种推理形式，再讲四种证据——这些证据是”主张”的支撑。

层级一：数据（最强证据）。

数字、时间、测量结果。数据是”客观的”——读者可以验证。

我们的订单查询 QPS 从 200 提升到 1500。

读者可以问”你怎么测的？测试场景是什么？“。如果你的测量方法合理，他信。如果不合理，他不信。但数据本身是”可验证”的，比”我们效果好”这种话强十倍。

层级二：案例。

具体实例。别人怎么做的、我们以前怎么做的。

字节跳动内部用 PostgreSQL 跑订单系统，扛住了双 11 的流量。

读者可以追问”字节的 PostgreSQL 是裸用还是魔改过？“。但案例本身的”具体性”已经比”业界都这样做”强。

层级三：类比。

相似事物的对比。

PostgreSQL 像 Oracle。

类比只能辅助理解，不能证明。读者读完类比，能感知”大概是什么”，但不会立刻信服。

层级四：主张（最弱）。

纯观点。

我觉得 PostgreSQL 比 MySQL 好。

没有数据、没有案例、没有类比支撑。这种主张读者没法验证，只能选择”信你”或”不信你”。

四种证据的强度：

数据 > 案例 > 类比 > 主张

技术文档里一个主张至少要有一个证据。强主张（核心决策）要多个证据，最好混搭。

举一个反例。我见过有人写技术选型文档：

推荐使用 PostgreSQL。因为它一致性更好、性能更好、生态成熟、社区活跃、文档完善、迁移成本低。

这是六条”主张”——每一句都是观点，没有一句是证据。读者读完，不知道”一致性更好是怎么定义的""性能更好是和谁比""生态成熟是怎么衡量的”。

主张堆叠不是论证。主张 + 证据 = 论证。

四、怎么用证据支撑主张

把”主张 + 证据”组合起来，有四种典型的论证结构。

结构一：主张 → 证据 → 主张。

先抛主张，再用证据支撑，最后重申主张。

推荐 PostgreSQL（主张）。我们的压测显示 PostgreSQL 在 1000 并发下 P99 延迟 50ms，MySQL 是 120ms（数据）。所以 PostgreSQL 在我们的场景下性能更优（重申主张）。

结构二：数据 → 主张 → 证据。

先给数据，从数据推出主张，再用其他证据支撑。

我们的压测显示 PostgreSQL 在 1000 并发下 P99 延迟 50ms，MySQL 是 120ms（数据）。这意味着在我们的场景下 PostgreSQL 性能更优（主张）。字节跳动内部也用 PostgreSQL（案例）。所以推荐 PostgreSQL（结论）。

结构三：反例 → 主张。

先给反例，主张作为对反例的反驳。

有人说 MySQL 性能更好（反例）。但我们的压测显示 PostgreSQL 在 1000 并发下 P99 延迟 50ms，MySQL 是 120ms（数据反驳）。在我们的场景下，PostgreSQL 更合适（主张）。

结构四：让步 → 反驳 → 主张。

先承认对方有道理的部分，再反驳，再主张。

MySQL 在读多写少的场景下确实更快（让步）。但我们的订单服务是写多读多——每秒 5000 写、1000 读（数据）。在这种场景下 PostgreSQL 优势明显（反驳）。推荐 PostgreSQL（主张）。

四种结构适用于不同场景。结构一最直接，结构四最难但最有说服力。技术评审里结构四最常用——你要让对手”心服口服”，必须先承认他说的有道理的部分，再反驳。

五、反向论证：考虑读者的反驳

讲到这里有一个关键：好的论证不是”自圆其说”，是”预判读者的反驳并回应”。

读者读你的论证，他脑子里会自动产生反驳：

  • “你说的数据是怎么测的？”
  • “你举的案例是在我们这种规模吗？”
  • “如果有反例怎么办？”
  • “业界真的普遍这样做吗？”

如果你的论证里已经预判并回应了这些反驳——读者读完会”哦”。如果你的论证里没有回应——读者会默默产生怀疑，但他不会说出来，他的怀疑会让你”读起来不踏实”。

举一个反例。我见过有人写技术选型：

推荐 Kubernetes。因为它扩展性好、生态成熟、社区活跃、迁移路径明确。

读者读完会想：“扩展性好是怎么定义的？和我们现在的 ECS 比呢？生态成熟怎么衡量？迁移路径明确具体是什么？”

这些疑问作者没回答。读者心里带着这些疑问，他会”读起来不踏实”。

反过来——

推荐 Kubernetes。理由三点：

  1. 扩展性：我们的服务 QPS 波动在 10 倍以上（数据）。Kubernetes 的 HPA 能基于 CPU 利用率自动扩容（机制说明）。我们手动扩容需要 30 分钟（数据反例），Kubernetes 自动扩容需要 30 秒（数据）。所以 Kubernetes 在我们这个波动幅度下更合适。

  2. 生态：Kubernetes 的 Operator 生态覆盖了我们 80% 的中间件（数据）。每个 Operator 都有生产级别的社区维护（案例）。

  3. 迁移路径：我们已经用了 Docker，迁移到 Kubernetes 主要工作是改 deployment YAML（具体动作）。预计工作量 1 人月（数据）。

这段论证读者读完会”哦”。因为他可能的反驳都已经被作者预判并回应了。

预判反驳的方法：

把自己放在读者的位置，读完自己的论证，问自己：“我会问什么？“把这些问题写出来，然后回头补论证。

我自己的写作习惯：写完论证后，专门花 15 分钟做”反向预演”——假装自己是反对者，写出可能反驳的 5 个问题。然后回头看我的论证有没有回应这 5 个问题。如果有 2 个没回应，我就补。

这个习惯让我的论证文档比大多数同事的”扎实”一个档次。

六、技术文档里几个常见的论证陷阱

讲完论证的正面，再列几个反面——技术文档里几个常见的论证陷阱。这些陷阱很常见，但都能识别、能避免。

陷阱一：诉诸权威。

“Google 用了 X，所以 X 是好的。”

Google 用 X 是事实。但”Google 用”不等于”X 是好的”——Google 的场景和你的场景可能完全不同。Google 用 PostgreSQL 跑广告业务，不代表你的订单服务用 PostgreSQL 就好。

正确做法：举和你场景相似的案例，而不是”业界巨头都这样做”。

陷阱二：诉诸新颖。

“X 是最新的技术，所以应该用 X。”

“最新”不等于”最好”。最新的技术往往意味着文档少、案例少、踩坑经验少。

正确做法：用”成熟度""社区活跃度""生产案例数量”等具体指标，而不是”是不是新”。

陷阱三：诉诸传统。

“我们以前一直用 X，所以应该继续用 X。”

“以前一直用”不等于”应该继续用”。环境在变、技术在变、需求在变。

正确做法：每次选型都要重新论证，不能用”历史”代替”论证”。

陷阱四：虚假两难。

“要么用 X，要么用 Y。”

列出两个选项让读者选，但忽略了其他可能性。实际可能还有 Z。

正确做法：列出所有候选方案，分别论证。

陷阱五：错误类比。

“X 像 Y，Y 有特性 A，所以 X 有特性 A。”

类比的两个对象可能只在某些维度相似，在另一些维度差异巨大。

正确做法：类比要明确”在哪个维度上相似""哪些维度不相似”。

陷阱六：循环论证。

“X 是好的，因为 X 是对的。”

用结论证明结论。

正确做法：论证的”前提”必须独立于”结论”。

这六个陷阱在技术文档里都极常见。识别它们的方法：读自己的论证，问自己”这个论据是事实还是主张？""这个事实是怎么得出的？“。如果是主张、事实可疑，那就是陷阱。

七、心法：论证是对话，不是独白

最后一条心法。

很多人写论证，是”自说自话”——他把自己知道的全部写下来，希望读者看完和他想的一样。

但好的论证是对话——作者预判读者的反驳、回应读者的疑问、承认对方有道理的部分、反驳对方不对的部分。

这意味着写论证之前，你要先想象一个读者。这个读者有知识、有立场、有反驳能力。你要让他”心服口服”，必须：

  1. 让他知道你在说什么（结构清晰）——上一章讲的。
  2. 让他知道你说得有道理（论证扎实）——这一章讲的。
  3. 让他知道你考虑过他的反驳（反向论证）——这一节讲的。

这三件事都做了，读者读完会”哦——原来是这样”。

这三件事只做了前两件，读者读完会”哦”。一个”哦”和一个”哦——“的差距，就是”主张”和”论证”的差距。

下一章我们讲”深度优先：一个点讲透的诱惑”——这是充实度的最后一个维度。前三章讲了”密度""结构""论证”，合起来是”一个文档充实”的最小集合。但还有一个维度：在一份文档里，多个点都讲一点 vs 一个点讲透，哪种更好？下一章回答这个问题。

八、思考题

思考题 1：把一段”主张”改写为”论证”

拿一段你最近写的主张式文字——技术选型、方案推荐、设计决策——按本章第四节的方法改写为论证。

具体步骤：

  1. 识别主张：列出你这段文字的所有主张。
  2. 补证据：对每条主张补至少一个证据（数据 / 案例 / 类比）。
  3. 加反驳预判：写出读者可能的 3-5 个反驳，每个反驳写回应。
  4. 重组结构：用第四节四种结构之一重组整段。

写完之后做”反向预演”——读一遍自己的论证，问自己”如果我是反对者，我会问什么”。如果有 2 个问题没回应，再补。

思考题 2：分析一段”论证扎实”的文字

找一段你读过的”论证扎实”的技术文档（学术论文、技术 RFC、技术博客都可以），做一份”论证分析”：

  1. 这段文字用了哪几种推理（演绎 / 归纳 / 类比）？
  2. 这段文字用了哪几种证据（数据 / 案例 / 类比 / 主张）？
  3. 这段文字预判并回应了哪些反驳？
  4. 这段文字”扎实”在哪？

写一篇 500 字的分析。

思考题 3：识别一段文字里的论证陷阱

拿一段你最近写的文档（设计文档、邮件、博客），按本章第六节列出的六个陷阱（诉诸权威、诉诸新颖、诉诸传统、虚假两难、错误类比、循环论证）逐项检查。

每一项检查写 50-100 字：哪里有陷阱？怎么改？

参考答案

思考题 1 参考答案

大部分人做完这道题会发现：自己原来的”论证”全是主张，没几条有证据。

一个常见的模式：

  • “我们用 X 因为它好。“（纯主张，无证据）
  • “我们用 X 因为业界普遍用。“（诉诸权威）
  • “我们用 X 因为它新。“（诉诸新颖）

改写后的版本应该是：

  • “我们用 X 因为我们的压测显示 P99 延迟 50ms（数据），而 Y 是 120ms（对比数据）。在我们的场景下（具体场景），X 优势明显（结论）。”
  • “业界公司 Z、W 也用 X（具体公司名，不是’业界’）。Z 的 QPS 是我们的 10 倍（具体数字），所以 Z 的场景比我们更难，X 在更难场景下能扛住（推导）。”

我自己的改稿习惯：写完第一稿后，专门把每条主张标出来，对每条主张问”证据呢？“。没有证据的要么补证据，要么删掉。

思考题 2 参考答案

论证扎实的文字有三个共同点：

  1. 证据混搭。数据 + 案例 + 类比，三种都用。这种混搭让读者从多个角度相信结论。

  2. 反驳预判。作者会主动写”有人可能认为…”，然后反驳。这种”主动预判”让读者觉得作者考虑过他的意见。

  3. 数据具体。不是”性能好”而是”性能好 30%“，不是”业界都用”而是”GitHub 排名前 10 中 8 个用”。具体的数字和案例比模糊的描述强十倍。

你的分析应该围绕这三点写（不一定全部涉及，但至少触及两点）。如果你读完只写得出”作者写得很有道理”，说明你还没把”扎实”拆开来——回到这一章的核心：扎实的本质是预判反驳并回应。

思考题 3 参考答案

做完这道题大部分人会发现自己至少踩过 2-3 个陷阱。

最常见的三个陷阱：

  • 诉诸权威：用”Google / Amazon / 阿里都这样做”代替论证。读者读不出”他们为什么这样做”。
  • 诉诸新颖：用”这是最新技术”代替论证。新技术不一定好。
  • 虚假两难：列两个选项让读者选，但实际还有第三个、第四个。

改写方法：

  • 诉诸权威 → 换成和你场景相似的具体案例。
  • 诉诸新颖 → 换成成熟度、社区活跃度、生产案例数量等具体指标。
  • 虚假两难 → 列出所有候选方案，分别论证。

我自己的写作习惯：写完论证后专门做”陷阱扫描”——把六个陷阱列出来，逐项问自己”我这一段踩了哪个”。踩了哪个就改。

九、动手练习

练习 1：把一段主张改写为论证

找一段你最近写的主张式文档（技术选型、方案推荐、设计决策都可以），按以下步骤改写：

  1. 列出所有主张，每条主张标号。
  2. 对每条主张补至少一个证据（数据 / 案例 / 类比）。
  3. 写出读者可能的 3 个反驳，每个反驳写回应。
  4. 用四种论证结构之一重组整段。

写完之后做”反向预演”——读一遍自己的论证，问自己”如果我是反对者，我会问什么”。如果有 2 个问题没回应，再补。

练习 2：做”陷阱扫描”

找一份你最近写的 1000 字以上的文档，按六个陷阱逐项扫描：

  1. 诉诸权威？
  2. 诉诸新颖？
  3. 诉诸传统？
  4. 虚假两难？
  5. 错误类比？
  6. 循环论证？

每一项扫描写 50-100 字的结论：哪里有陷阱、怎么改。

自评标准

练习 1 自评标准：

  • 每条主张都有至少一个证据——过关。
  • 至少 3 个读者反驳被预判并回应——过关。
  • “反向预演”能找到 2 个未回应的反驳——重新来。

练习 2 自评标准：

  • 找到至少 2 个陷阱——过关。
  • 对每个陷阱都有具体改写方案——过关。
  • 没找到陷阱——重新读一遍自己的文档，再做一次扫描。

十、小结

这一章把”论证”这件事拆成了三块：

概念一句话
论证 ≠ 主张主张是结论，论证是结论的依据。
三种推理演绎（一般→个别）、归纳（个别→一般）、类比（A→B）。
四种证据数据 > 案例 > 类比 > 主张。
论证结构主张 → 证据 → 主张 / 数据 → 主张 → 证据 / 反例 → 主张 / 让步 → 反驳 → 主张。
反向论证预判读者反驳并回应。
六个陷阱诉诸权威、新颖、传统、虚假两难、错误类比、循环论证。

扎实的本质是预判反驳并回应。论证不是”自说自话”，是”对话”。

一篇文档的”扎实”做到位，读者读完会”哦——“。否则只是”哦”。

一个”哦”和一个”哦——“的差距，就是”主张”和”论证”的差距。

第一卷的最后两章到此为止。下一章讲”深度优先”——为什么少写一点反而写得好。

心法

主张不是论证。每条主张都要有证据。

数据 > 案例 > 类比 > 主张。

论证不是独白，是对话。预判读者的反驳并回应。

一个”哦”和一个”哦——“的差距，就是”主张”和”论证”的差距。