矛盾论 on 方糖猫Blog

《横向领导力》与重读《矛盾论》《实践论》：没有职权时，怎么推动你认为对的事

Thu, 05 Sep 2024 10:00:00 +0800

《横向领导力》与重读《矛盾论》《实践论》：没有职权时，怎么推动你认为对的事

参考书籍：罗杰·费希尔、艾伦·夏普《横向领导力》(Getting It Done)；《毛泽东选集》第一卷《实践论》《矛盾论》（重读，只取实操部分）。目标读者：想往架构师、CTO 方向走的工程师——你会发现越往上走，越多的决策要靠影响力而不是职权推行，尤其跨团队架构治理。阅读目标：回答两个真问题——没有职权时怎么推动人（横向领导力）；冲突和路线之争里怎么判断往哪推（矛盾论）。前者管组织动员，后者管方向判断。

这是情商系列的第三篇。第一篇（《情商》+《被讨厌的勇气》）管自己：觉察情绪、划清课题；第二篇（《关键对话》+《非暴力沟通》）管对话：保住安全感、把评判翻译成观察。这一篇管的是前两篇都解决不了的事——当你判断一件事是对的、但没有职位赋予你推它的权力时，怎么办。

关于毛选部分要先说一句：2017 年我写过一篇《程序员学屠龙术》，那篇是把《实践论》《矛盾论》当认识论总览读。这次重读换了一个更窄、也更狠的读法：只把两论当"识别主要矛盾"的裁决工具用。团队冲突、技术路线之争、技术债该不该还——本质上都是"当前阶段的主要矛盾是什么"的问题。

一、《横向领导力》:权威不在场时的领导

1.1 这本书的前提：等领导来协调，是最贵的协作方式

费希尔是哈佛谈判项目的老教授（《谈判力》的作者之一），这本书回答的问题非常具体：在一个你没有汇报关系的场合——跨部门项目、技术委员会、开源社区——怎么让一群人协作起来把事做成。

书里先破了一个普遍幻觉：“我不是领导，所以领导力不是我的事。“费希尔的反驳：横向协作场景里根本没有领导，“等领导来拍板"这个选项的代价被严重低估了——

领导的信息带宽有限，他用三十秒拍的板，质量受制于他掌握的信息量；
上交决策的同时，也上交了方案的 ownership——“老板定的"是执行阶段最好用的免责理由；
等你有了职权再学领导力，就像等起火再学消防。

1.2 方法骨架：先修自己，再带别人

横向领导力不能直接从"影响他人"开始，书里给了一条严格的次第：

flowchart LR
    A["第一步: 修好自己<br/>五个个人技能<br/>目标、思考、学习<br/>专注、反馈"] --> B["第二步: 明确共同目标<br/>把 我的方案<br/>变成 我们的问题"]
    B --> C["第三步: 影响他人<br/>三招: 提问、作答、示范"]
    C -.->|"别人不买账时<br/>回来继续修自己"| A
    style A fill:#FFD700

五个个人技能里，对工程师最有增量的是思考这一环——书里给了一个四象限思考框架，任何协作僵局都可以往里装：

象限	问题	工程场景示例
数据	现状到底是什么？	接口规范的执行率到底是多少，别凭感觉
诊断	为什么会这样？	不是大家不配合，是规范没有迁移成本预算
方向	应该往哪去？	先冻结核心域接口，边缘接口允许残留
行动	下一步谁做什么？	本周先在一个组试点，出数据再推广

这个框架的价值在于：僵局通常是因为各方在不同的象限里喊话——有人在讲数据，有人在讲行动，听起来是争论，实际是错频。

1.3 踩坑故事一：发通知推规范，响应率是零

第一次做跨团队架构治理时，我的打法是"把事做对”：调研两周，写了一份二十页的接口规范文档，评审通过，然后发全员通知：“自 X 月 X 日起，新接口按此规范执行。”

一个月后执行率接近于零。

用四象限复盘：我在自己的脑子里完整走过了数据→诊断→方向→行动，然后只把最后一环（行动）发给了别人。其他团队看到的不是一个共同问题的解法，而是一份从天而降的约束——他们没有经历诊断过程，自然没有这个方案的情感账户和认知账户。

第二次换成横向领导的打法：先不提方案，用提问开场，一对一问了六个团队的接口人同一个问题：“你们现在的接口对接，最疼的点是什么？"——收获超出预期：四个团队提到的痛点就是我的规范要解决的，但从他们自己嘴里说出来的问题，才是他们的问题。规范内容改了不到 20%，执行率反过来了。

影响力的本质转换：从"我的方案"到"我们的问题”。 方案可以更好，但问题必须是共同的。

1.4 踩坑故事二：等领导拍板，等来一个两边都不满意的三十秒

两个组对服务拆分边界有分歧，我判断这是"需要更高层信息才能定的事”，于是把两个方案写成材料上交，等 CTO 裁决。

材料在领导队列里躺了两周（他有更要紧的事），终于排到，他用三十秒拍了一个折中方案：边界按组织隶属关系切。两边都不满意——技术上是错的，但谁也没有动力再争，因为"老板定的”。

半年后这条边界成了全系统调用链最深的重灾区。

费希尔书里有一句话我这次是真读懂了：横向问题尽量横向解决，上交领导的决策质量受限于领导的信息带宽。 领导拍板的价值不在"他更懂”，而在"他能让争议终止"——这是兜底机制，不是首选机制。首选机制是把争议双方摁在同一张四象限表前面，把数据象限先填满。大多数技术争议，数据填满之后自己就消解了。

1.5 踩坑故事三：复盘文化推不动，直到我把自己摆上解剖台

我曾想在团队里推"故障复盘不追责"的文化，写了流程文档、开了宣讲会，响应寥寥——大家嘴上说好，真出故障还是甩锅现场。

转折点是我自己搞砸了一次发布之后。我没有按惯例低调处理，而是写了一份公开的复盘文档，开头就是决策时间线：我在哪个节点掌握什么信息、做了什么错误判断、当时的替代选项是什么。把自己摆上了解剖台。

效果出乎预料：那次复盘之后，第二个、第三个复盘开始出现，而且质量越来越高。这就是费希尔三招里的第三招——示范（modeling）。提问是让别人思考，作答是给出你的思考，示范是直接做出你希望别人做的行为。三招里示范成本最高、威力最大，因为人们不怀疑你说的是否正确，他们怀疑的是你自己是否照做。

二、重读《矛盾论》《实践论》:裁决工具化

2.1 《矛盾论》的裁决四步

这次重读，我把《矛盾论》压缩成一个在技术争议现场可以当场跑的分析流程：

flowchart TD
    A["列出当前所有矛盾<br/>技术 vs 业务、质量 vs 速度<br/>新框架 vs 存量系统"] --> B["找出主要矛盾<br/>此刻真正限制系统产出的<br/>是哪一个"]
    B --> C["抓矛盾的主要方面<br/>这对矛盾里<br/>哪一方当前起主导作用<br/>撬动它才能改变局面"]
    C --> D["标注阶段性<br/>主要矛盾会转化<br/>今天的正确决策<br/>下个阶段可能就是错的"]
    D -.->|"阶段变化后<br/>重新分析"| A
    style B fill:#FFD700
    style D fill:#FFB6C1

每一步对应《矛盾论》的一个核心概念：列矛盾（矛盾的普遍性）、找主要矛盾、抓矛盾的主要方面、标注阶段性（矛盾的发展与转化）。这套东西听起来抽象，落到技术裁决上极其锋利，看下面的故事。

2.2 踩坑故事四：技术债之争，吵了三次会都没吵对地方

团队为"先还技术债还是先赶业务需求"吵了三次会。还债派列代码腐烂清单，业务派列交付承诺，双方论据都很充分，会议每次都卡在平局。

第三次会后我用矛盾四步重新拆了一遍：

列矛盾：代码质量 vs 交付速度、重构风险 vs 线上稳定、团队技术热情 vs 业务方耐心；
找主要矛盾：当时真正限制产出的是什么？不是代码烂——而是交付速度已经连续两个迭代不达标，业务方的信任濒临破产。信任破产的代价大于一切技术债；
抓主要方面：在"质量 vs 速度"这对矛盾里，当前的主导方面是债务中直接拖慢交付的那一部分——烂代码很多，但只有反复改动、反复出 bug 的三个模块真正在吞噬交付速度；
阶段性：信任修复之后，主要矛盾会转化回代码质量，届时再还其余的债。

决策随之清晰且可辩护：冻结新需求两周，只还那三个模块的债（这是矛盾的特殊性——不是所有债都值得还，还错地方的还债也是浪费），其余债务登记入册排期。两个月后交付恢复，业务方信任回升，剩余债务在后续迭代按计划清偿。

这个案例里矛盾论真正教会我的是：技术裁决不是评判"哪个方案更好"，而是识别"当前阶段的主要矛盾是什么"——方案没有绝对优劣，只有是否对准当前主要矛盾。 还债派和业务派都没错，他们只是各自对准了不同阶段的矛盾。

2.3 踩坑故事五：框架选型之争，主要方面根本不是技术

一次选型评审僵持不下：A 派支持沿用现有框架（稳），B 派支持引入新框架（长期收益大）。双方列的 benchmark、生态对比、社区活跃度，全是技术维度的论据，谁也说服不了谁。

用"矛盾的主要方面"切进去：这对矛盾的表面是"两个框架的优劣"，但当前起主导作用的方面是什么？我列了下双方的实际约束，答案浮出来——是团队对新框架的熟悉度。B 派的三个人玩过新框架，A 派没有人碰过。学习曲线风险，而不是框架性能，才是这个决策真正的支配变量。

看清主要方面之后，决策反而容易了：给两周时间，B 派出一个人带 A 派做新框架的概念验证，用团队真实的学习速度数据来定——而不是用网上的 benchmark 来定。两周后数据出来，团队自己动手做完 PoC 的那天，争议其实已经结束了。

技术争议僵持不下的信号，往往是双方都在论证次要方面。 主要方面一旦显形，多数争议会自己消散。

2.4 《实践论》：没有调查，就没有发言权

《实践论》的认识循环，这次重读我把它画成了工程里的决策循环：

flowchart LR
    A["实践<br/>调研、试点、动手"] --> B["感性认识<br/>一堆碎片事实"]
    B --> C["理性认识<br/>抽象出规律和判断"]
    C --> D["再回到实践<br/>拿判断去做决策"]
    D -->|"结果检验认识<br/>错了就修正"| A
    style C fill:#FFD700

两条实操推论：

**“没有调查就没有发言权”**放在技术评审里就是：没看过代码、没跑过压测、没找当事人聊过的人，意见权重应当打折。评审会上嗓门最大的意见经常是调查量最小的；
认识必须在实践里检验——所以推规范不要先写完美文档再全面铺开，先在一个组试点，拿数据，修正，再推广。我在第一篇情商笔记里写的人际复盘、第二篇里的会前利益假设，本质都是这个循环的人际版。

三、两本书合流：一个管方向，一个管动员

	回答的问题	核心工具
《矛盾论》《实践论》	往哪推：当前阶段的主要矛盾是什么	矛盾四步、实践认识循环
《横向领导力》	怎么推：没有职权时如何让人跟你走	四象限思考、提问/作答/示范

缺了前者，横向领导力会变成高效的错误——动员能力很强，方向是歪的；缺了后者，矛盾分析会变成孤独的正确——判断很准，但只有你一个人信。方向判断和组织动员，是"影响力"这件事的两条腿。

四、配套练习：主动认领一次"得罪人"的事

理论读完，这个阶段的实修作业只有一道：主动认领一个有人反对、但你判断为对的技术决策（偿还某块技术债、统一某个接口规范、砍掉某个半成品项目），完整走一遍下面这个剧本：

flowchart LR
    A["第一步: 私下沟通<br/>裁决前一对一<br/>听懂每个反对者的<br/>真实顾虑"] --> B["第二步: 争取盟友<br/>让关键人的意见<br/>提前进入方案"]
    B --> C["第三步: 会上裁决<br/>用矛盾分析陈述理由<br/>明确代价和推翻信号"]
    C --> D["第四步: 事后安抚反对派<br/>承认损失 不推翻决策"]
    D -.->|"全程记录<br/>写成一篇人际 ADR"| A

每一步的要点，都是前面三篇笔记的工具在实战里汇合：

私下沟通：用的是关键对话的"从心开始"和非暴力沟通的"观察而非评判"。反对者在会上说的话是立场，私下说的才接近利益——故事二里那些"回头再说"，一对一的时候往往有真东西；
争取盟友：就是毛选统一战线的工程版——裁决前让关键人的意见进入方案。方案里有他的一句话，他在会上就是你的盟友；这不是搞政治，是让方案吸纳真实约束；
会上裁决：陈述结构用矛盾四步——当前主要矛盾是什么、为什么这个方案对准它、代价是什么、什么信号出现时该推翻。最后一条最值钱，它告诉反对派：这不是我的面子，这是一个可验证的赌注；
事后安抚反对派：回到《被讨厌的勇气》——安抚是承认对方承担了损失（“这个决定让你的组多背了两周工作量，我记着”），而不是推翻决策也不是假装没有代价。课题分离：做对决策是我的课题，消化失望是他的课题，但承认损失、记在账上，也是我的课题。

成不成，这一遍走下来都是教科书级的一课——成了，你收获一套可复用的推动剧本；败了，人际 ADR 里会留下一次完整的归因记录。

五、我的思考和感悟

1. 裁决者挣的不是"判断正确"的钱，是"判断正确之后还能推行"的钱。 技术判断力决定你能不能看清主要矛盾，横向领导力决定看清之后局面会不会动。我身边技术判断一流、推行能力为零的人不少，他们的共同遭遇是：正确的意见被无视，然后抱怨组织愚蠢——抱怨组织愚蠢，是用课题上交的方式逃避自己的课题。

2. 重读毛选最大的变化，是读懂了"阶段性"三个字的分量。 2017 年第一次读《矛盾论》，读出来的是热血——抓主要矛盾，大刀阔斧。这次读出来的是沉重——主要矛盾会转化，意味着今天无比正确的决策，明天可能就是主要障碍。两年前我认为绝对正确的技术选型，今天就在还债清单上躺着。这不是当年错了，是阶段变了。裁决者必须习惯一件事：你的每个决策都自带保质期。

3. “没有调查就没有发言权"是对评审文化最狠的一条建议。 技术会议里意见的质量分布，和发言者的调查量分布高度相关——但和职级、嗓门、口才几乎无关。把"你调研过吗"变成评审会的合法问题，会议质量会立刻改观。

4. 争取盟友不是搞政治，但拒绝争取盟友一定是搞砸。 工程师对"会前串联"有本能的道德洁癖，觉得方案好就该在会上赢。现实是：会上才第一次听到方案的人，默认反应是防御——这和信息量无关，和安全感有关（第二篇的场）。会前一对一不是阴谋，是给对方消化信息的时间。

5. 三篇笔记合起来的完整链条：先能觉察自己的情绪（第一篇），再能在对话里听懂别人（第二篇），最后能在没有职权的情况下推动局面（第三篇）。这个顺序不可颠倒——自我管理是影响力的信用基础，听懂他人是方向判断的信息基础。

六、行动清单（12 周版）

阶段	动作	检验标准
第 1-2 周	盘点手头所有僵局，用四象限表各装一遍，找出"错频"的对话	至少 2 个僵局定位到象限错频
第 3-4 周	选一个推动事项，把"我的方案"改写成"我们的问题”，找 3 个关键人一对一	3 份对方痛点的第一手记录
第 5-6 周	对当前最大的技术争议跑一次矛盾四步，写出主要矛盾和主要方面	一页纸分析，能向中立方讲清楚
第 7-10 周	认领那件"得罪人"的事，按四步剧本完整走一遍	走完私下沟通→争取盟友→会上裁决→事后安抚全流程
第 11-12 周	把整个过程写成一篇人际 ADR：判断、理由、代价、结果、下次怎么改	一篇可复盘的记录，至少 3 条归因

参考与延伸

罗杰·费希尔、艾伦·夏普《横向领导力》，核心章节：五个个人技能、四象限思考法、影响他人的三招（提问、作答、示范）。
《毛泽东选集》第一卷《实践论》《矛盾论》。重读建议：别从头读到尾，带着一个正在僵持的真实争议去读，读一段就往里套一次。
旧文衔接：《程序员学屠龙术》——那篇是两论的认识论总览，本篇是两论的裁决工具化，建议按"总览→工具"的顺序读。
系列前两篇：《情商》与《被讨厌的勇气》（自我觉察与课题分离）、《关键对话》与《非暴力沟通》（安全感与语言精度）。

程序员学屠龙术：把《毛选》读成一份改世界的工程手册

Fri, 29 Sep 2017 18:20:17 +0800

程序员学屠龙术：把《毛选》读成一份改世界的工程手册

目标读者：刚入行或入行几年、感觉"学了很多技术却依然迷茫"的程序员。
阅读目标：把《毛泽东选集》读成一份"认识世界、改造世界"的工程手册，能看懂、能用上、能回答"我到底该往哪里去"。
声明：本文是一份方法论视角的学习笔记，不讨论具体历史是非、不摘政治口号；只关心一件事——这套思想作为"屠龙术"，对写代码、做技术、过生活有什么启发。姊妹篇：如果你不懂算法，那就让你领教下佛法——那篇讲"如何观察自心"，这篇讲"如何改造世界"。

0. 先回答一个问题：毛选为什么被叫作"屠龙术"？

网上有个流传很广的说法：《毛选》是"屠龙术"。

意思是说，它不是成功学、不是职场厚黑学，而是一套完整的、经过大规模实践检验的"如何分析复杂局面并改造现实"的方法论。屠龙，指的是面对看起来根本打不过的庞然大物——强大的对手、绝望的处境、盘根错节的旧秩序——并且真的找到了下刀的地方。

程序员为什么该读它？一句话：

佛学教你观察自己的心，毛选教你改造外部的世界。一个向内，一个向外，合起来才是完整的"修行"。

而且《毛选》的行文极其"工程师友好"：没有玄学、没有黑话、没有"信我者灵"。它的论证方式永远是——先调查现状，再分析矛盾，然后给出假设，最后到实践中检验。这不就是 measure → analyze → hypothesize → test 吗？

flowchart LR
    A[毛选] -->|不是语录| B[方法论文集]
    B --> C[调查现状]
    C --> D[分析矛盾]
    D --> E[实践检验]
    E -->|修正认识| C

1. 核心地图：从"实践"到"矛盾"再到"人民"

如果模仿姊妹篇里"无我→无法→无空"的解构，毛选的核心骨架也可以画成三级台阶：

阶段	关键词	核心动作	对应篇目
第一步	实践	认识只能从实践中来，到实践中去	《实践论》
第二步	矛盾	分析问题时抓主要矛盾，看矛盾的特殊性	《矛盾论》
第三步	人民	一切方法论的落脚点：为谁服务、依靠谁	《为人民服务》《愚公移山》

注意：这三步不是三条知识，而是一套完整的闭环——认识世界靠实践，改造世界靠抓矛盾，而改造世界是为了什么、靠什么力量，靠"为人民服务"这四个字来定锚。

flowchart LR
    subgraph 屠龙术三级台阶
    A[实践论<br/>认识从哪来] -->|有了认识才能分析| B[矛盾论<br/>刀子往哪下]
    B -->|分析为了行动| C[为人民服务<br/>行动为了谁]
    end
    C -->|再回到实践| A

下面的每一节，就是一级台阶的展开。

2. 第一步：实践——《实践论》是程序员最好的认识论

2.1 《实践论》到底说了什么？

全文其实就论证一件事：

人的正确认识，只能来自实践；而检验认识对不对，也只能回到实践。

毛泽东把它概括成一个循环：

实践 → 感性认识 → 理性认识 → 再回到实践检验 → 修正后再实践……
“实践、认识、再实践、再认识，这种形式，循环往复以至无穷。”

换成程序员的话：没有人靠读文档学会编程，也没有人靠想明白了一个 bug。

2.2 程序员的"感性认识"与"理性认识"

《实践论》里有个非常精准的分层：

感性认识：你直接接触到的现象——日志报错、页面白屏、接口超时。
理性认识：你把现象抽象成规律——“这是连接池耗尽导致的级联超时”。

新手最常犯的错，是两个极端：

极端	表现	《实践论》的诊断
只停留在感性	看到报错就百度，抄一个答案，能跑就行	“认识停留在感性阶段，是片面的、表面的”
空想理性	不看日志不复现，坐在椅子上"推理"bug	“理性的东西所以靠得住，正是由于它来源于感性”

真正高效的 debug 流程，就是《实践论》的微缩版：

flowchart TD
    A[观察现象<br/>感性认识] --> B[提出假设<br/>理性认识]
    B --> C[设计实验<br/>最小复现]
    C --> D[验证结果<br/>实践检验]
    D -->|假设错了| B
    D -->|假设对了| E[修复+总结规律]
    E -->|规律进入经验库| A

“最小复现"就是实践论里"由特殊到一般"的工程化。 把 5000 行的线上系统压缩成 20 行能复现 bug 的 demo，本质上就是一次"去粗取精、去伪存真、由此及彼、由表及里”——这十六个字出自《实践论》。

2.3 一句可以直接贴在显示器上的话

“你要有知识，你就得参加变革现实的实践。你要知道梨子的滋味，你就得变革梨子，亲口吃一吃。”

想学 Kubernetes？别再看第七篇入门文章了，去把本地集群搭起来、亲手搞挂一次再修好。梨子不会因为你读了十篇梨评就变成甜的。

3. 第二步：矛盾——《矛盾论》教你把刀子下对地方

3.1 主要矛盾：性能优化的第一性原理

《矛盾论》最锋利的概念是：

在复杂事物的发展过程中，有许多矛盾存在，其中必有一种是主要的矛盾，它规定和影响着其他矛盾的存在和发展。

翻译成工程语言：系统慢，先 profile，别猜。

新人优化代码的典型翻车现场：把一个 Python 循环从 for 改成列表推导式，沾沾自喜提速 30%，结果系统 99% 的时间花在了一次没有索引的数据库查询上。这就是没抓主要矛盾——你优化了"规定和影响"之外的东西。

flowchart TD
    A[系统很慢] --> B{主要矛盾在哪?}
    B -->|不 profile 直接猜| C[优化了字符串拼接<br/>提升 0.1%]
    B -->|先测量| D[发现 99% 耗时在 DB 慢查询]
    D --> E[加索引/改查询<br/>整体提速 50 倍]
    style C fill:#fdd,stroke:#a00
    style E fill:#dfd,stroke:#0a0

“没有全局在胸，是不会真的投下一着好棋子的。”——《矛盾论》这句话，就是"先 profile 再优化"的 1937 年版本。

3.2 矛盾的特殊性：世界上不存在"最佳实践"

《矛盾论》的另一半是：不同质的矛盾，要用不同质的方法解决。

这是对"银弹思维"最狠的一击。新人最容易陷入的幻觉是：存在一个"最佳实践"，学会就能套用到所有项目。而现实是：

创业公司活命期的代码和大厂核心系统的代码，矛盾性质完全不同（一个要速度，一个要稳定）；
一次性的迁移脚本和要维护十年的框架，该用的工程标准完全不同；
甚至同一个系统，MVP 阶段和规模化阶段的"正确架构"也不同。

“用不同的方法去解决不同的矛盾，这是马克思列宁主义者必须严格地遵守的一个原则。”

所以下次有人跟你说"XX 才是唯一正确的写法"，你可以在心里默念：具体问题具体分析。这不是和稀泥，而是《矛盾论》的核心操作。

3.3 矛盾的转化：bug 和本事是一对矛盾

《矛盾论》还有一个常被忽略的洞察：矛盾双方在一定条件下互相转化。

一个让团队通宵的线上事故（坏事），如果复盘到位，就变成了系统的混沌工程清单和每个人的排障直觉（好事）；
一个让你痛苦的重构需求（负担），做完之后变成了你简历上最硬的项目（资产）。

转化的关键在于"条件"——而条件是人创造的。 事故不会自动变成经验，复盘这个动作才是转化的条件。这就引出了后面的"批评与自我批评"。

4. 配套武器一：《反对本本主义》——没有调查，就没有发言权

这篇文章写于 1930 年，批评的是那些"拿到马克思主义本本就当圣旨"的同志。放到今天，它精准命中的群体是——不看代码就谈架构的人、不复现就下结论的人、不调研就抄方案的人。

4.1 程序员版本的"本本主义"

本本主义的表现	正确做法（调查研究）
“这个框架大家都在用，我们也上”	先搞清楚自己的业务量级和团队能力
“这个 bug 应该是缓存问题”	先复现、看日志、抓数据
“文档就是这么写的，照着做”	文档可能过时，读源码确认实际行为
“网上说这种设计模式好”	你的问题规模需要用模式吗？

毛泽东的原话狠得多：

“没有调查，没有发言权。”
“你对于某个问题没有调查，就停止你对于某个问题的发言权。”

在 code review 里，这就是最高准则：没读过这段代码的上下文，就不要对它的设计指手画脚。

4.2 调查的技术：像做需求分析一样做"社会调查"

《反对本本主义》里列了调查的具体方法：开调查会、找了解情况的人、定调查纲目、亲自出马、做记录。这套东西和今天产品经理做用户访谈、工程师做技术调研（technical due diligence）的流程几乎一模一样。

程序员空闲时间最值得做的一项"修行"就是这个：对自己每天使用的系统做一次调查。 你公司的数据从哪进、从哪出？钱从哪来？用户真正的痛点是什么？多数程序员写了五年代码都答不上来——这就是"对本本很熟、对现实很盲"的现代版。

5. 配套武器二：《改造我们的学习》——学习要"有的放矢"

5.1 三种学习态度

这篇文章里，毛泽东批评了"不注重研究现状、不注重研究历史、不注重马列主义的应用"的学习，提倡的是四个字：有的放矢——“的"是靶子（中国革命的实际问题），“矢"是箭（马列主义的立场观点方法）。

程序员的学习通病，用这三个"不注重"来套，严丝合缝：

不注重研究现状：收藏了 200 篇"必学清单”，但从不研究自己手头项目缺什么。
不注重研究历史：用着框架却不懂它解决的历史问题（为什么有 React？之前痛在哪？），于是永远在追新。
不注重应用：学完的设计模式没地方用，三个月就忘光。

5.2 有的放矢的学习法

学习的第一原则：以当前要解决的实际问题为靶子，去选箭，而不是先囤一屋子箭再找靶子。

flowchart TD
    A[工作中遇到的真实问题] --> B[拆解需要哪些知识]
    B --> C[针对性学习<br/>读书/文档/源码]
    C --> D[立刻应用到问题上]
    D --> E[复盘:学到的是否解决了问题]
    E -->|产生新问题| A
    F[无的放矢:<br/>囤课/追热点/焦虑式学习] -.->|死循环| F
    style F fill:#fdd,stroke:#a00

这条循环和《实践论》的循环是同构的：实践产生真问题，真问题驱动真学习，真学习回到真实践。 这就是为什么"项目驱动学习"对程序员永远有效——它不是学习技巧，它是认识论。

6. 《论持久战》：给"速成焦虑"和"躺平论"各一耳光

6.1 两种必败论调

《论持久战》写于抗战最黑暗的 1938 年，当时流行两种声音：亡国论（打不过，完了）和速胜论（一口气就能赢）。毛泽东说：都不对。这是一场持久战，会经过战略防御、战略相持、战略反攻三个阶段。

把"抗战"换成"程序员的成长”，这段分析惊人地贴合：

1938 年的论调	今天的版本	为什么错
亡国论	“35 岁必被淘汰，这行完了，躺平吧”	低估了主观能动性和积累的价值
速胜论	“三个月精通 AI，弯道超车年薪百万”	低估了问题的复杂度和时间的必要性

6.2 成长的三个阶段

flowchart LR
    subgraph 程序员的持久战
    A[战略防御期<br/>0-2年<br/>活下来,补齐基础] --> B[战略相持期<br/>2-6年<br/>大量枯燥的积累<br/>看不到质变]
    B --> C[战略反攻期<br/>6年+<br/>经验开始复利<br/>能独立定义问题]
    end
    B -.->|大多数人在此放弃<br/>误以为相持=失败| D[躺平/转行]
    style D fill:#fdd,stroke:#a00

相持阶段是最难熬的：每天的工作看起来都一样，学的技术似乎总在过时，同龄人好像都比你快。《论持久战》的价值就在这里——它告诉你相持不是失败，相持是规律。“亡国论"和"速胜论"在相持阶段最容易蛊惑人心，因为两者都是不愿面对长期性的精神捷径。

6.3 能动性：持久战不是干等

注意，《论持久战》不是"熬着就行”。它的核心概念是自觉的能动性：

“一切事情是要人做的……做就必须先有人根据客观事实，引出思想、道理、意见，提出计划、方针、政策、战略、战术，方能做得好。”

持久战的意思是：承认客观规律（成长需要时间），同时最大限度发挥主观能动性（每天都在正确地积累）。 既不躺，也不疯。

7. 空闲时间的修行：把"整风"开成个人的 code review

7.1 复盘：屠龙术里的"冥想"

姊妹篇讲佛学的冥想是"观察自心"；毛选里对应的功夫是批评与自我批评，以及它的日常版——复盘。

毛泽东有个著名公式：“团结—批评—团结”——从团结的愿望出发，经过批评与自我批评，在新的基础上达到新的团结。把这个公式的对象从"同志"换成"自己"，就是一个极高质量的个人复盘模板：

flowchart LR
    A[肯定自己做对的部分<br/>团结] --> B[诚实指出问题<br/>批评]
    B --> C[不带自我攻击地<br/>形成改进项]
    C --> D[和自己达成新的团结<br/>继续上路]
    B -.->|错误示范:<br/>批评变自我攻击| E[我不行/我没救了]
    style E fill:#fdd,stroke:#a00

关键区别：批评的对象是"事"，不是"人"。 “这次上线没写回滚方案"是批评；“我真是个废物"是自我攻击，恰恰是《实践论》批评的——脱离实际现象、空谈本质。

7.2 每周 30 分钟的复盘仪式

可执行的最小版本，每周五下班前：

本周的实践：做了什么？（列事实，不评价）
感性材料：哪里卡住了？情绪在哪里波动过？（这就是佛学的"觉察”，只不过对象是自己的工作）
理性提升：把卡住的原因抽象成一条规律，写下来。一句话就行。
下周的实验：基于这条规律，下周改一个具体行为。

坚持一年，你会得到 52 条自己从实践中长出来的规律——这比读 52 篇经验帖值钱得多，因为它们经过了你的实践检验。

7.3 冥想 × 复盘的组合拳

空闲时间的修行可以这样搭配，两套体系各取所长：

时段	动作	来源	作用
编译/部署等待的碎片时间	安般念：观察三次呼吸	佛学（姊妹篇 8.1 节）	把注意力拉回当下
被 bug/需求变化搞到情绪上头	STOP 公式：停—呼吸—观察—回应	佛学（姊妹篇 8.3 节）	防止情绪化操作
每周五 30 分钟	团结—批评—团结复盘	毛选	把经验沉淀成规律
每季度一次	“调查研究”：我所在的系统/行业发生了什么变化？	毛选《反对本本主义》	防止闭门造车

佛学负责让心不乱，毛选负责让经验不浪费。 一个管"稳”，一个管"进"。

8. 工作与生活的平衡：为人民服务，包括为你自己

8.1 先把"为了谁"想清楚

《为人民服务》全文不到八百字，核心只有一句：我们这个队伍完全是为着解放人民的，是彻底地为人民的利益工作的。

对程序员的启发不是喊口号，而是一个极其实际的追问：你写的代码，在为谁服务？

如果只服务 KPI，你会在每次绩效面谈前焦虑到失眠；
如果只服务技术虚荣心，你会把简单系统过度设计成简历展品；
如果能找到"它真的帮到了某群人"的那个点，工作的意义感会自己长出来。

这不是鸡汤，是动机管理。“为了谁"是行为系统的 root 配置，配错了，上面跑什么进程都会慢慢跑偏。

8.2 愚公移山：长期主义的生活版

《愚公移山》的结尾说：愚公感动了上帝——而"这个上帝不是别人，就是全中国的人民大众”。剥掉修辞，它的意思很朴素：

方向对了的长期努力，会不断把旁观者变成同盟者，把不可能变成时间问题。

工作生活平衡也是一座山。它不是某个周末"想通了"就能解决的，而是每天把锄头挥下去：今天准点下班去运动了，这周把复盘做了，这个月拒绝了一个明显会 burn out 的排期。平衡不是一个状态，是一万次微小的选择。

8.3 身体是革命的本钱：一条不需要引用的常识

持久战的第一资源是"人"。程序员的"人"就是你的身体和注意力：

睡眠是 GC，长期不 GC 的系统没有不出事的；
运动是混沌工程，平时主动施压，真出故障时才扛得住；
冥想和复盘是监控告警，让你在 burn out 之前先收到报警，而不是在宕机后读事故报告。

任何要求你长期透支身体的"奋斗"，都是速胜论的变种——它透支的是相持阶段最需要的东西。

9. 我们到底应该往哪里去？

这是姊妹篇最后一章的问题，也是所有方法论绕不开的终点。现在手里有两套答案了：

佛学的答案：安住当下，不执着于任何固定的"我必须成为什么"，随缘调整。
毛选的答案：发挥自觉的能动性，调查研究，抓主要矛盾，打持久战，改造世界。

一个向内收，一个向外放。听起来矛盾——但它们恰恰回答了这个问题的两半：

9.1 佛学回答"怎么去"，毛选回答"去哪找方向"

佛学的"不执着"解决的是心态：不要被结果绑架，不要焦虑，不要在内耗中空转。但它不直接告诉你方向在哪。

毛选补上了这一半：方向不是想出来的，是调查研究出来的。

你纠结"要不要转行 AI"“要不要去大厂"“要不要搞副业”——这些问题的答案不在冥想垫上，也不在别人嘴里，而在对客观现实的调查里：这个行业在发生什么变化？我手里有什么牌？哪件事的主要矛盾已经成熟到可以动手了？

flowchart TD
    A[我往哪里去?] --> B{心态问题<br/>还是方向问题?}
    B -->|焦虑/内耗/怕失败| C[佛学工具:<br/>觉察当下,放下执着<br/>稳住心]
    B -->|不知道选哪条路| D[毛选工具:<br/>调查研究,分析矛盾<br/>小步实践试探]
    C --> E[心稳了之后]
    D --> F[实践中得到反馈]
    E --> D
    F -->|认识深化,修正方向| A

先稳心，再调查，然后小步实践，用实践反馈修正方向。 这就是两套体系合起来的完整答案。

9.2 “能动性"与"不执着”：看似相反，实则互补

毛选讲"人定胜天"式的能动性，佛学讲"因缘和合"的不执着，矛盾吗？

不矛盾，它们管的是不同的环节：

行动时，用毛选：全力以赴，调查研究，抓主要矛盾，做就是了。“当面不说、背后嘀咕"式的内耗才是敌人。
结果前，用佛学：尽人事之后，接受结果不完全由你控制。成了不飘，败了不塌——《金刚经》叫"应无所住而生其心”。

用程序员的话说：写代码的时候用毛选（对每一行负责），等 CI 的时候用佛学（结果已经不由你控制，深呼吸）。

9.3 一个可执行的结论

所以，我们到底应该往哪里去？

往"调查清楚的主要矛盾"那里去，用持久战的方式去，带着不执着结果的心去。

具体一点：

方向从调查来，不从焦虑来。 每年做一次认真的自我"社会调查”：行业趋势、自己的能力盘点、真正在意什么。
选定主要矛盾，集中兵力。 一段时间内只主攻一件事——《毛选》里叫"集中优势兵力，各个歼灭敌人"，程序员叫单线程深度工作。
按持久战的节奏走。 允许自己处于相持阶段，用复盘保证每天在积累，拒绝速成幻觉，也拒绝躺平叙事。
结果交给无常。 努力了，方向可能就变了，环境一定会变——那就再调查、再分析、再出发。

姊妹篇的结尾说：没有一个固定的"我"必须成功。这篇补上后半句：

也没有一个现成的"路"等在那里等你发现。路是调查研究出来的，是一步一步实践出来的——“踏平坎坷成大道”，大道不在别处，就在你下一步的调查和实践里。

10. 思考与感悟：两个让我停下来的瞬间

写这篇笔记时，有两个地方让我停下来想了很久，记录在案。

10.1 感悟一：屠龙术最狠的地方，是它拒绝神秘化

读毛选最大的意外是它的"朴素"。一个真的改造了亿万人命运的体系，方法论核心居然只是：去现场看看（调查）、想清楚主要问题是什么（矛盾）、做了再改（实践）。没有任何一步是普通人做不到的。

这反过来照出了技术圈的荒诞：我们热衷造神——框架之神、方法论之神、大神程序员——然后跪在神龛前说我学不会。而《实践论》冷冷地说：你要知道梨子的滋味，就亲口吃一吃。 大神的能力也不是天降的，是实践循环转得比你多、复盘比你勤。

10.2 感悟二：佛学和毛选，救的是同一个人

以前我觉得这两套东西气质相反：一个出世，一个入世。放在一起读才发现，它们救的是同一种病——被念头和情绪劫持、失去行动能力的人。

佛学治"想太多"：看清念头只是念头，别被焦虑钉在原地。
毛选治"不行动"：别空谈了，去调查，去实践，梨子咬一口才知道味道。

程序员这个职业，恰好两种病都高发：信息过载带来的焦虑瘫痪（想太多），和教程囤积带来的虚假勤奋（不行动）。冥想让心安静下来，复盘让经验沉淀下来，调查让方向清晰起来，实践让一切落地。 这就是我理解的、一个程序员版本的"修行"。

11. 总结：一张速查表

篇目	核心工具	解决的程序员问题
《实践论》	实践—认识—再实践	学习只看不做、debug 靠猜
《矛盾论》	抓主要矛盾、具体问题具体分析	优化不 profile、迷信银弹
《反对本本主义》	没有调查就没有发言权	不调研抄方案、空谈架构
《改造我们的学习》	有的放矢	囤课焦虑、学用脱节
《论持久战》	三阶段、自觉的能动性	速成焦虑与躺平叙事
《为人民服务》《愚公移山》	为了谁、长期主义	意义感缺失、工作生活失衡
（配套）佛学工具	冥想、觉察、不执着	内耗、情绪化、怕结果

最后，用两句跨越一千三百年的对话收尾：

惠能说：真理不在文字里，在你当下的觉知里。
毛泽东说：真理不在本本上，在你的调查和实践里。
合起来就是：别坐着想了，也别跪着学了——站起来，去调查，去实践，去观察自己的心。路在脚下，也在心里。

参考阅读

《实践论》（1937）
《矛盾论》（1937）
《反对本本主义》（1930）
《改造我们的学习》（1941）
《论持久战》（1938）
《为人民服务》（1944）、《愚公移山》（1945）
姊妹篇：《如果你不懂算法，那就让你领教下佛法》

本文为个人学习笔记，方法论视角，不代表对历史细节的完整考据。若有理解偏差，欢迎理性讨论。