逻辑学 on 方糖猫Blog

《简单逻辑学》读书笔记：程序员最需要补的一门课，从四个基本原理到谬误识别实战

Wed, 09 Nov 2022 09:30:00 +0800

《简单逻辑学》读书笔记：程序员最需要补的一门课，从四个基本原理到谬误识别实战

D.Q.麦克伦尼（D.Q. McInerny），美国哲学家，《简单逻辑学》（Being Logical: A Guide to Good Thinking）是他写给普通人的逻辑学入门书，全书只有 130 来页，没有符号逻辑公式，全是"怎么想才对"的基本功。为什么一个程序员要读这个？因为我们每天做的事情——写代码、评审方案、排查故障、和产品经理吵架——本质上全是逻辑活动。而大部分工程师（包括曾经的我）从未系统学过一天逻辑，全靠本能硬扛。

0. 全书结构：五层楼

flowchart TB
    L1["第一层 学习逻辑的思想准备<br/>全神贯注 / 确认事实 / 观念要对应对象 / 语言要匹配观念"]
    L2["第二层 逻辑学的基本原理<br/>同一律 / 排中律 / 矛盾律 / 充足理由律"]
    L3["第三层 论证：逻辑学的语言<br/>命题 / 前提与结论 / 演绎与归纳 / 有效与真实"]
    L4["第四层 非逻辑思维的根源<br/>怀疑论 / 玩世不恭 / 盲目乐观 / 眼界狭窄 / 情感"]
    L5["第五层 非逻辑思维的主要形式<br/>28 种谬误大全"]
    L1 --> L2 --> L3 --> L4 --> L5
    style L2 fill:#ffd699
    style L5 fill:#ffcccc

麦克伦尼的讲法是先盖楼（一到三层，什么是"对"），再拆楼（四五层，人是怎么想错的）。我按同样的顺序记，但每一层都配上程序员场景——否则读完三天就还回去了。

1. 第一层：思想准备——逻辑之前，先把输入搞对

这一层讲的东西朴素得让人想跳过，但它指向一个残酷事实：大部分争论根本不涉及逻辑，只是双方输入的事实就不一样。

四个要点：

全神贯注：很多错误不是逻辑错，是根本没看仔细。线上日志看漏一行，结论全盘皆错。
确认事实：事实分两种——事物事实（真实存在的）和事件事实（需要通过证据确认的）。争论前先问：我们争的到底是事实，还是对事实的解释？
观念要对应对象：脑子里的观念（idea）是对客观对象的反映，检验观念对错的标准是它符不符合对象，不是"我有多确信它"。
语言要匹配观念：语言是观念的载体，词不达意是一切沟通灾难的源头。书中给的原则是说简单句、用准确的词、避免模糊和歧义。

踩坑故事 1：一场吵了两小时的会，死于一个词 需求评审，产品经理说"这个页面要快"，后端说"接口 P99 做到 200ms 没问题"，前端说"我这边首屏没问题"，测试说"那我觉得没问题"。上线后客诉爆炸——产品经理说的"快"是整页可交互时间，后端给的是接口耗时，前端盯的是首屏渲染，三个"快"根本不是一回事。麦克伦尼说的"语言要匹配观念"就是这个：争论前先给关键词下操作定义（“快”= TTI < 2s，4G 网络下），能省掉一半的会。现在组里的评审模板第一条就是"定义术语"。

2. 第二层：四个基本原理——逻辑的地基

整本书的承重墙。这四条不是什么高深定理，而是一切正确思考都必须遵守的游戏规则：

flowchart LR
    A["同一律<br/>事物只能是其本身<br/>A 是 A"] --> G["灰度思考的天敌：<br/>概念被偷换而不自知"]
    B["排中律<br/>对于任何事物<br/>在一定条件下<br/>要么成立 要么不成立<br/>没有中间状态"] --> G2["'既死又活'只在<br/>量子力学里合法"]
    C["矛盾律<br/>同一时刻<br/>同一事物不能<br/>既是这样又不是这样<br/>A 不能同时是非 A"] --> G3["发现矛盾 = 发现错误<br/>不是'辩证看待'"]
    D["充足理由律<br/>任何事物存在<br/>都有充足理由"] --> G4["没有'无缘无故'<br/>事故复盘的第一原理"]
    style A fill:#ffe6cc
    style B fill:#ffe6cc
    style C fill:#ffe6cc
    style D fill:#ffe6cc

逐条说它们在工作里的样子：

同一律：概念被偷换是最常见的思维故障。踩坑故事 1 的"快"就是违反同一律——同一个词，中途换了对象，论证全部作废。
排中律：在明确条件下，命题非真即假。“这个功能有没有 bug” 没有"大概也许有"。测试同学最懂这条。
矛盾律：同一时刻同一方面，A 不能同时是非 A。代码里一个变量不能既是 true 又是 false——编译器天天在替你执行矛盾律，脑子却经常放水。
充足理由律：凡事必有原因。这是排查故障的世界观——线上问题不存在"灵异事件"，只有"还没找到的原因"。

踩坑故事 2：“灵异 bug"追查到凌晨四点 服务每天凌晨固定时间偶发 502，日志干净得像没发生过。组里讨论逐渐滑向玄学：“可能是云厂商网络抖动"“要不加个重试试试”。我后来把"充足理由律"四个字贴在显示器边上，逼自己一条一条排除：时间固定 → 必有定时事件 → 查 crontab 没有 → 查 K8s 层 → 发现是宿主机每天凌晨的镜像 GC 把节点磁盘打满了。所有"灵异"都是对理由的放弃。这个习惯比任何排查技巧都值钱。

3. 第三层：论证的结构——前提、结论、有效与真实

逻辑的核心动作是论证：从前提推出结论。这一层有三个必须分清的概念。

3.1 演绎与归纳

flowchart LR
    subgraph 演绎["演绎推理：从一般到个别"]
        D1["大前提：所有接口超时<br/>都会触发熔断"] --> D3
        D2["小前提：支付接口超时了"] --> D3["结论：支付接口<br/>必然触发熔断<br/>（保真）"]
    end
    subgraph 归纳["归纳推理：从个别到一般"]
        I1["过去 10 次大促<br/>缓存都扛住了"] --> I3["结论：这次大促<br/>缓存大概率扛得住<br/>（不保真，只给概率）"]
    end

演绎保真，归纳不保真。 工程师日常 90% 的推理是归纳（“上次这么改没问题”），却经常拿它当演绎用（“所以这次一定没问题”）——大促翻车史就是归纳翻车的合订本。

3.2 有效 ≠ 真实

这是全书我最想加粗的一对概念：

有效（valid）：推理形式正确——前提真，则结论必真。
真实（sound / true）：不仅形式对，前提本身也得是真的。

一个论证可以完全有效但结论荒谬，只要前提是假的：

flowchart TD
    P1["前提 1（假）：所有用 Java 的系统都慢"] --> C["结论：订单系统慢<br/>✔ 推理形式有效<br/>✘ 前提假 所以结论不可信"]
    P2["前提 2（真）：订单系统用 Java 写的"] --> C
    style P1 fill:#ffcccc

踩坑故事 3：技术选型里的"大厂这么干” 评审一个方案，同事的论证是：“Netflix 用了微服务（真），我们要支撑大流量（真），所以我们也应该上微服务（形式上说得过去）。“这个论证真正的漏洞藏在一个没说出口的前提里：”我们的组织规模和 Netflix 一样需要微服务"——40 人的团队和几千人的团队，这个前提是假的。后来那个项目拆出 30 个服务，三个人维护，一次发布要排两小时依赖序。识别隐藏前提，是评审别人方案的第一刀。 麦克伦尼书里说"结论不能反映前提的量”（全称前提出特称结论没事，反过来必错），实战版就是：把没说的前提挖出来晒一晒。

3.3 三段论的正确姿势

经典三段论（Barbara 式）长这样：

flowchart TD
    M1["大前提：所有 M 都是 P"] --> CC["结论：所有 S 都是 P"]
    M2["小前提：所有 S 都是 M"] --> CC
    NOTE["中项 M 必须至少周延一次<br/>（在前提里覆盖其全部外延）<br/>否则：中项不周延谬误"]

书里给了判断三段论的各种规则（两个否定前提推不出结论、前提有一个特称结论必须特称……）。不用全背，记一个最常被违反的：从"有些"不能推出"所有”。“有些用户反馈卡顿”→“所有用户都卡”，产品需求文档里每周都能看到这种滑坡。

4. 第四、五层：谬误大全与它的根源

4.1 高频谬误速查表（配程序员真实病例）

书里列了 28 种谬误，我挑工作中真正高频的，每个配一个我亲眼见过的病例：

谬误	一句话识别	程序员病例
稻草人	把对方观点扭曲成好打的版本再攻击	A 说"这个接口要加缓存"，B 反驳"你想把所有数据都堆进 Redis 吗？内存不要钱？"
诉诸权威	因为某人/某公司牛，所以它对	“阿里就是这么设计的”——阿里的约束条件和你的不一样
后此谬误（post hoc）	先后发生 ≠ 因果关系	“昨天上了新版本的网关，今天接口慢了，肯定是网关的锅”——实际是运营商骨干网抖动
非黑即白	把多选硬压成二选一	“要么全部重写，要么继续忍受烂代码”——还有渐进重构这条正经路
草率概括	样本太小就下结论	“内测 3 个用户都没问题，可以全量”
循环论证	结论早已藏在前提里	“这个方案好，因为它是最佳实践；为什么它是最佳实践？因为它好”
偷换概念	同一律被违反	评审时"性能"一词在响应时间和吞吐量之间反复横跳
诉诸情感	用同情/恐惧代替论证	“这个需求不做，运营同学这个月 KPI 就完了”
错误类比	相似点不够撑起结论	“人脑用神经元，所以堆足够多 if-else 也能产生智能”
民主谬误	多数人认同 ≠ 正确	团队投票决定"这个并发问题不会有事"

踩坑故事 4：一次后此谬误引发的连环故障 我犯过最严重的一次逻辑错误就是后此谬误。某次发布后接口耗时上涨，我看了发布时间线就断定是新版本的锅，拍板回滚。回滚后耗时没有恢复——真正的元凶是同一时段上游投放活动带来的流量结构变化（慢接口流量占比升高）。但因为"回滚"这个操作本身又成了新的干扰变量，我们白白多排查了三个小时，还多承受了一次回滚的风险。教训刻在墙上：先看监控全局，再对时间线；时间先后是嫌疑，不是定罪。

4.2 谬误的根源：不是坏，是这些心理

第四层回答"人为什么会想错"，比谬误清单本身更有价值：

怀疑论过头：把"不可知"当逃避思考的挡箭牌（“日志也可能是错的，别查了”）；
玩世不恭：预设一切论证都是利益伪装，于是不再需要听任何论证；
盲目乐观：只寻找支持自己方案的证据（确认偏误的近亲）；
眼界狭窄：只在自己熟悉的工具箱里找解决方案——手里只有锤子；
情感：书里说得最透的一句大意是，情感越浓烈，论证越要让位给冷静。线上事故复盘最怕带情绪，一甩锅逻辑就死了。

5. 逻辑训练方法：可执行的每日清单

逻辑是技能不是知识，看十遍书不如每天练十分钟。我自己执行过的训练计划，按性价比排序：

5.1 每日三题（合计约 15 分钟）

flowchart LR
    T1["题 1 · 改写三段论<br/>找一条工作群里的断言<br/>补出隐藏前提<br/>检验有效性和真实性<br/>3 分钟"] --> T2["题 2 · 谬误狩猎<br/>刷一条新闻评论区<br/>或技术论坛热帖<br/>指出至少一个谬误并命名<br/>5 分钟"]
    T2 --> T3["题 3 · 费曼复述<br/>把今天解决的一个问题<br/>用'前提→推理→结论'<br/>写给外行看<br/>5 分钟"]

题 1 的素材库：需求文档、技术方案、复盘报告——全是现成的"论证"，练习补全隐藏前提。坚持两周，你看任何方案都会自动开始找"他没说出口的那句话"。
题 2 的关键是命名：不是"我觉得不对"，而是说出"这是稻草人/后此/诉诸权威"。能命名 = 能复现 = 下次自己犯的时候能识别。
题 3 是最狠的：写给外行看会暴露一切含糊之处。写不清楚 = 没想明白，没有例外。

5.2 每周一练（约 30 分钟）

复盘改写：从团队事故报告里挑一份，重写因果链——区分"时间相关"和"因果相关"，标注每一环的证据等级（监控数据 / 推断 / 猜测）。
对立面练习：选一个自己坚信的技术观点（如"微服务优于单体"），强迫自己写出反方的最强论证（steel man，稻草人的反面）。写不出来说明你并没有真正理解自己观点的边界。

5.3 进阶阅读材料（按顺序读）

《学会提问》（Asking the Right Questions）——本书的最佳续集，把"找前提、找谬误"训练成肌肉记忆；
《超越感觉》（Beyond Feelings）——更系统的批判性思维教材，第四章"证据"专治后此谬误；
《思考，快与慢》——从认知科学解释谬误的根源，回答"人为什么天生想不对"；
《金字塔原理》——逻辑的另一半：想对了之后怎么结构化地表达；
Paul Graham 的 How to Disagree—— disagreement hierarchy，一张图分清"反驳论点"和"骂人"的七个层级，网上吵架和 Code Review 通用。

5.4 把训练场搬回工作

Code Review 是最好的逻辑训练场：每条评论强制写成"前提（代码事实）→ 推理（规则/经验）→ 结论（建议）“三段式，杜绝"感觉不太好"式评论；
复盘会立一条规矩：只接受带证据的因果链，“可能、感觉、应该是"后面必须跟验证计划；
技术方案模板加一栏：“本方案的隐藏假设”，写上线的开关。

思考与感悟

1. 逻辑学是程序员被拖欠最久的一门课。 我们学数据结构、学操作系统、学分布式，唯独没人教"怎么想才对”。可工作五年之后回看，造成最大损失的从来不是不会某个技术，而是：把先后当因果、把权威当论证、把概念吵岔了两个小时。这本书 130 页，两天读完，补的是地基。

2. 逻辑的敌人不是愚蠢，是情绪。 书里最触动我的不是谬误清单，是"非逻辑思维的根源"那一章——怀疑论、玩世不恭、盲目乐观，全是心理防御机制，不是智力问题。复盘会上一句"当时是谁决策的”，逻辑就死了。想练好逻辑，先练把情绪和论证分开的本事。

3. “能命名"是内化的分界线。 知道"诉诸权威"这个词之前，我也天天犯；学会之后，每次脱口而出"大厂都这么干"时，脑子里会有个小声音报名字。语言是观念的载体——给谬误命名，就是给自己的思维装监控。

4. 对工程师来说，逻辑的最终形态是工程习惯。 充足的日志（充足理由律的落地）、明确的术语表（同一律的落地）、灰度发布（对归纳不保真的敬畏）、复盘模板（反后此谬误的流程化）——好的工程实践背后全是逻辑学。这本书读完，你会重新理解这些实践"为什么是它们”。

与君共勉。

程序员逻辑思维训练手册：书单、方法与 12 周刻意练习计划

Sun, 04 Sep 2022 10:00:00 +0800

程序员逻辑思维训练手册：书单、方法与 12 周刻意练习计划

写这篇的动机很直接：「我感觉自己逻辑思维很弱」是我听过最多、也最难回答的自我评价。它太大了，大到无从下手。
这篇的思路：先把「逻辑思维」这个模糊的大词拆成五种具体的、可单独训练的能力，再给每种能力配书、配练习、配检查清单，最后拼成一份 12 周计划。跟着清单做就行，不用自己设计训练方案。

第一篇先诊断：逻辑思维不是一个东西，是五个东西

「逻辑思维弱」是个无法改进的表述——就像说「我身体不好」而不说「我 5 公里跑不下来」。先拆开：

flowchart TD
    L["逻辑思维"] --> A["1 概念清晰<br/>说的每个词都有明确所指<br/>症状: 需求评审说不清<br/>变量命名含糊"]
    L --> B["2 推理链条<br/>从前提一步步走到结论<br/>症状: 排查 bug 靠猜<br/>改 A 坏 B 想不到为什么"]
    L --> C["3 抽象分层<br/>能切换粒度看问题<br/>症状: 代码揉成一团<br/>说不清系统架构"]
    L --> D["4 边界意识<br/>看到输入就想边界与异常<br/>症状: 上线后被空指针/<br/>越界/并发打脸"]
    L --> E["5 因果辨析<br/>区分相关/因果/巧合<br/>症状: 复盘归错因<br/>优化没效果"]

对照一下，你的「弱」大概率集中在其中两三个上。诊断的意义在于：五种能力的训练方法完全不同，混着练等于白练。

能力	最痛的日常场景	对应训练
概念清晰	需求理解偏差、命名糟糕	定义练习、费曼讲解
推理链条	debug 靠蒙、日志看不出因果	假设-验证法、画调用链
抽象分层	代码越写越乱、讲不清架构	分层画图、重构练习
边界意识	边界 bug 反复出现	防御性 checklist、测试先行
因果辨析	复盘甩锅、优化玄学	五问法、对照实验

思考与感悟之一：编程本质是「用精确的语言描述精确的推理」。IDE 不会因为你概念模糊而报错，编译器不会因为你因果搞错而拒绝构建——代码能跑通和逻辑是对的之间，隔着一万个线上事故。这也是为什么逻辑思维的训练必须在代码之外单独进行。

第二篇书单：按能力分级，别从《离散数学》开始

2.1 入门层：先把「讲道理」的基本功补上

书	练什么	怎么读
《简单逻辑学》（D.Q. 麦克伦尼）	概念清晰 + 推理链条	薄，一周读完。重点看「论证的前提与结论」「常见谬误」两章
《学会提问》（尼尔·布朗）	因果辨析	批判性思维入门，重点看「证据的效力」「有没有替代原因」
《金字塔原理》（芭芭拉·明托）	抽象分层（表达侧）	结论先行、以上统下。对写技术方案、汇报、写博客立竿见影

2.2 进阶层：直接长在编程上的思维

书	练什么	怎么读
《怎样解题》（波利亚）	推理链条	数学书的外壳，debug 的内核。「弄清问题→拟定计划→执行→回顾」就是排查 bug 的标准流程
《系统之美》（德内拉·梅多斯）	抽象分层 + 因果辨析	库存、流量、队列都是系统。看完你会用「反馈回路」的眼光看重试风暴、缓存雪崩
《程序员修炼之道》	全部五种	工程场景化的思维训练，DRY、正交性、曳光弹，每一条都在教你怎么把问题切干净

2.3 硬核层：可选，别勉强

《离散数学及其应用》：命题逻辑、集合、图论——编程的数学地基。只建议读前三章，当工具书查。
《思考，快与慢》：知道大脑什么时候在骗你。和编程不直接相关，但和「复盘归错因」直接相关。

选书原则：一次只读一本，读完一本书的每一章都要落到「这周我在代码里用了它哪一点」。 读而不用的思维书，和收藏夹里的技术文章没有区别。

flowchart LR
    A["入门层<br/>讲道理的基本功"] --> B["进阶层<br/>长在编程上的思维"]
    B --> C["硬核层<br/>数学地基 可选"]
    A -.->|"每章落到<br/>一次代码实践"| P["不是读完<br/>是用完"]
    B -.-> P
    style P fill:#e8f4e8

第三篇日常训练法：把练习藏进你每天都在做的事里

刻意练习的关键不是额外抽两小时，而是改造已有的工作动作。五个场景，每个配一个可检查的动作：

3.1 写代码前：先说清，再动手（练概念清晰）

接到需求后，强制自己写三句话再开编辑器：

这个功能的输入是什么？（精确到字段和类型）
输出是什么？什么情况算成功？
有哪三种必然失败的情况？

写不出来，就是概念还没清晰，回去问。这一步能拦掉一半的返工。

3.2 排查 bug：假设-验证法（练推理链条）

禁止「改一下试试」。用 debug 日志模板强制走流程：

写下假设：「我认为是 X 导致 Y，因为 Z」
写下验证方式：看什么日志/加什么断点能证实或证伪
验证结果与假设不符时，先怀疑假设，不要怀疑现象
修复后写下：根因是什么？为什么之前的推理没走到这？

波利亚的「回顾」一步，90% 的人会跳过——而推理能力的增长恰恰只发生在这一步。

3.3 讲清楚一个模块：费曼技巧（练抽象分层）

每月一次，挑你负责的一个模块，画一张三层图讲给同事（或 AI）听：

第一层：一句话说清它是干什么的
第二层：三个以内的子模块 + 它们之间的关系
第三层：被追问时才能展开的细节

讲卡壳的地方，就是你分层的薄弱处。能给 AI 把一个需求描述到它一次生成正确代码，是概念清晰度的绝佳试金石——prompt 写不清楚，多半是自己也没想清楚。

3.4 Code Review：五问清单（练因果辨析）

这个改动解决了什么问题？（还是先有的方案？）
问题和改动之间是因果还是相关？（「上次加了缓存就好了」是相关，不是因果）
有没有替代原因能解释这个现象？
这个改动的副作用边界在哪？
如果它是错的，我们多快能发现？

3.5 复盘：只问「为什么链」（练因果辨析）

线上事故复盘禁用「我疏忽了」「运气不好」这类不可证伪的词。只允许五问法往下钻，直到钻出一个可执行的流程或工具改进为止。「粗心」不是根因，「为什么粗心能穿过所有防线到达线上」才是。

思考与感悟之二：所有训练法的共同点是「把隐式思维变成显式文字」。脑子里的推理可以偷步、可以跳步、可以自我欺骗，落在纸上的推理不能。写作是逻辑思维最便宜的压力测试。

第四篇 12 周刻意练习计划

每周一个主题。规则：周末用 30 分钟对照自检清单打分，三项里两项不达标，下周重复同一主题。宁可 12 周练成 6 项，不要 12 周路过 12 项。

flowchart TD
    subgraph P1["第 1-4 周 概念与推理"]
        W1["W1 定义练习<br/>读《简单逻辑学》<br/>给 10 个日常用词写精确定义"]
        W2["W2 需求拆解<br/>每个需求先写输入/输出/失败<br/>再动手"]
        W3["W3 假设-验证 debug<br/>每个 bug 走完整模板"]
        W4["W4 谬误识别<br/>读《学会提问》<br/>在技术讨论里找出 5 个逻辑谬误"]
    end
    subgraph P2["第 5-8 周 抽象与边界"]
        W5["W5 金字塔表达<br/>读《金字塔原理》<br/>写 2 篇结论先行的技术方案"]
        W6["W6 费曼讲解<br/>画 1 张三层模块图并讲出来"]
        W7["W7 边界清单<br/>给负责的接口建防御性 checklist"]
        W8["W8 测试先行<br/>一个完整功能 TDD 写下来"]
    end
    subgraph P3["第 9-12 周 因果与系统"]
        W9["W9 复盘训练<br/>读《系统之美》<br/>找 1 个旧事事故做五问法复盘"]
        W10["W10 对照实验<br/>一次性能优化用基准数据说话"]
        W11["W11 解题流程<br/>读《怎样解题》<br/>按四步解 5 道算法题并写回顾"]
        W12["W12 综合输出<br/>写 1 篇技术博客<br/>把 12 周里最有体感的一条讲透"]
    end
    P1 --> P2 --> P3

每周自检清单（通用模板）

本周的书读了吗？哪一章的观点我这周真的用了？
本周的练习动作做了几次？（写次数，不写「做了」）
有没有一个具体场景，我能说出「如果没有这周的训练，我会做错」？

两个提醒

不要同时练多项。认知资源有限，一周一个主题已经很难。觉得慢，说明做对了——肌肉记忆的形成从来是慢的。
输出强制闭环。第 12 周的博客不是可选项。能把「我怎么练的」讲清楚，本身就是五种能力的综合考试。

思考与感悟之三：逻辑思维不是天赋，是可分解、可练习、可度量的技能组——和学一门框架没有本质区别。区别在于框架三个月过期，这套东西跟你三十年。投资回报率不在同一个数量级上。

附：一句话总纲

诊断先行：先弄清弱在五种能力的哪几种，再选训练。
书不在多：一本一用，每章落到代码里才算读过。
改造日常：练习藏进写需求、debug、CR、复盘里，不靠额外抽时间。
显式化：把推理写下来，写下来就不能骗自己。
12 周起评：周末自检，不达标就重复，最后以一篇博客闭环。

逻辑学 on 方糖猫Blog

《简单逻辑学》读书笔记：程序员最需要补的一门课，从四个基本原理到谬误识别实战

《简单逻辑学》读书笔记：程序员最需要补的一门课，从四个基本原理到谬误识别实战

0. 全书结构：五层楼

1. 第一层：思想准备——逻辑之前，先把输入搞对

2. 第二层：四个基本原理——逻辑的地基

3. 第三层：论证的结构——前提、结论、有效与真实

3.1 演绎与归纳

3.2 有效 ≠ 真实

3.3 三段论的正确姿势

4. 第四、五层：谬误大全与它的根源

4.1 高频谬误速查表（配程序员真实病例）

4.2 谬误的根源：不是坏，是这些心理

5. 逻辑训练方法：可执行的每日清单

5.1 每日三题（合计约 15 分钟）

5.2 每周一练（约 30 分钟）

5.3 进阶阅读材料（按顺序读）

5.4 把训练场搬回工作

思考与感悟

程序员逻辑思维训练手册：书单、方法与 12 周刻意练习计划

程序员逻辑思维训练手册：书单、方法与 12 周刻意练习计划

第一篇 先诊断：逻辑思维不是一个东西，是五个东西

第二篇 书单：按能力分级，别从《离散数学》开始

2.1 入门层：先把「讲道理」的基本功补上

2.2 进阶层：直接长在编程上的思维

2.3 硬核层：可选，别勉强

第三篇 日常训练法：把练习藏进你每天都在做的事里

3.1 写代码前：先说清，再动手（练概念清晰）

3.2 排查 bug：假设-验证法（练推理链条）

3.3 讲清楚一个模块：费曼技巧（练抽象分层）

3.4 Code Review：五问清单（练因果辨析）

3.5 复盘：只问「为什么链」（练因果辨析）

第四篇 12 周刻意练习计划

每周自检清单（通用模板）

两个提醒

附：一句话总纲

第一篇先诊断：逻辑思维不是一个东西，是五个东西

第二篇书单：按能力分级，别从《离散数学》开始

第三篇日常训练法：把练习藏进你每天都在做的事里