1 · 读书笔记：程序员的认知心得

https://renzhi.shaogefenhao.com

一句话补充如下点：

• 是什么（What）— 理论/原则，建立认知模型
• 为什么（Why）— 背后的动机、约束与权衡
• 怎么做（How）— 技巧 + 实践 + 边界（该做与不该做）

1.1 · 核心观点：

认知能力（晶体智力）= 知识 + 经验 + 工作策略。想通问题背后的逻辑，可以抵消大量的努力。但”做到”比”知道”更重要。

• What: 用哲学（认识论、逻辑学、方法论）构建程序员的认知体系，再用生活经验校验，形成解决软件工程问题的思维模型。
• Why: 软件工程中的很多困境（架构不合适、沟通不畅、技术选型失误）根源不是技术能力不足，而是认知层次不够——看问题的角度太窄、太浅。
• How: 以哲学为骨架（对错观、洞穴寓言、奥卡姆剃刀、主客体、否定之否定），以生活为验证，以旁观者视角打破思维定势，在低谷中锤炼认知。

1.2 · 启发点（关键洞察）：

1. 对错是相对的，用”合规律性 / 合目的性 / 合规范性”替代简单的对错判断。技术讨论中用”合适 / 不合适”代替”对 / 错”，避免无效争论。
2. 货物崇拜编程：混淆”相关性”与”因果性”。大公司用了 X 成功 ≠ 用 X 就能成功。引入技术/实践前，必须分析它解决的矛盾是否是你的主要矛盾，以及它带来的新成本。
3. 奥卡姆剃刀 + 思维经济：好的模型是用最少的概念解释最多的问题。架构设计中，能用状态前置条件检查解决的问题，就不要引入分布式锁。
4. 洞穴寓言的双重启示：认知局限来自信息输入不足 + 信息处理”程序”低效。提升认知 = 拓宽感知渠道 + 升级思维模型。
5. 主客体思维：面向对象的”骨相”是哲学认识论的主客体关系。Service 是业务主体，Entity 是业务客体，业务逻辑发生在主体中，这样代码才像自然语言一样流畅。
6. 否定之否定分析法：评估新技术时问三个问题——①它解决的旧矛盾是不是我的主要矛盾？②它带来什么新矛盾？③新矛盾我能否接受？
7. 笛卡尔分解法：学习和解决问题的核心方法——分解到显而易见，逐步攻克，无法理解就回退到上一步确保前置知识彻底掌握。
8. 领导力的本质：创造让他人行动的条件，而不是恳求/推着他人行动。组织是个体权利让渡的结果，个体利益受损时团队就会崩溃。

1.3 · 行动：

1. 技术讨论/选型时，用”否定之否定三问”做决策清单，写下旧矛盾、新矛盾、可接受度。
2. 遇到复杂问题时，先 Put everything on the table——把所有假设写下来，不预设方案，逐一验证排除。
3. 警惕货物崇拜：引入任何实践前，分析它的收益和成本，而非只看成功案例。

1.4 · 金句：

1. “花半秒钟就看透事物本质的人，和花一辈子都看不清事物本质的人，注定是截然不同的命运。” ——《教父》
2. “Make everything as simple as possible, but not simpler.” ——爱因斯坦
3. “小孩子才谈对错，成年人只谈利弊。”
4. “创造让他人行动的条件，而不是恳求他人行动。”
5. “生命总会找到出路。” ——《侏罗纪公园》马尔科姆博士
6. “大道甚夷，而民好径。” ——分解看似最慢，实际上是最快的路线。