05 深度优先：一个点讲透的诱惑
第一卷·认知地基 第五章
一、那份”什么都讲了”的文档
去年我帮同事改过一份设计文档。原稿 5000 字，分七节：背景、现状、问题、目标、方案、风险、收益。每一节字数差不多——600-800 字。
我读完，心里很复杂。
文档每节都”讲到”了。背景讲了行业趋势，现状讲了当前问题，问题讲了根本原因，目标讲了未来方向，方案讲了技术选型，风险讲了潜在问题，收益讲了商业价值。
“讲到”就是”讲到了”——每节有一两句话提到这个主题，但没展开。
我同事自己说：“我感觉每个点都提到了，但读者反馈说’读起来散了”不知道重点是什么’。”
我跟他讲：“你这份文档是百科全书式——七个主题每个 700 字，读者读完每个主题都没印象。如果你把 5000 字集中讲两个主题，每个 2500 字，读者会记得非常清楚。”
他不太信：“那另外五个主题不讲吗？”
我说：“讲，但要讲’另一个 5000 字’——你可以分成两份文档。第一份只讲两个核心主题，每个 2500 字；第二份讲其他五个主题，每个 500 字——读者按需查阅。”
后来他按这个思路改了一次，反馈立刻不同——读者看完第一份，能复述出核心论点；看完第二份，能在需要时快速找到信息。
这件事的本质是：广度和深度不能兼得。一份文档要”广”就要牺牲”深”；要”深”就要牺牲”广”。硬要两者兼得，结果就是”广但不深，深但不广”——读者读完什么都没记住。
这一章讲的就是怎么取舍。
二、广度和深度不能兼得——三个限制
为什么不能兼得？因为三个硬约束。
约束一：信息承载能力。
上一章讲过，读者脑子里同时能装的概念是 4±1 个 chunk。一份 5000 字的文档，如果讲 7 个主题，读者读完脑子里要同时装着这 7 个主题的概要——他装不下。即使能装下，他也要分配注意力——每个主题只能分到 1/7 的注意力。
约束二：时间。
读者读一份文档的时间是有限的。30 分钟读完一份 5000 字的文档，平均每个主题不到 5 分钟。这 5 分钟里读者要”理解”——他做不到。读者能做的只是”扫一遍”。
扫完的结果是”每个主题都提到了，但读者记不住任何细节”。
约束三：注意力深度。
读者读一份”讲七个主题”的文档，他的心智模型是”扫读”——每个主题浅看一眼就走。这种模式下，读者不会深度思考、不会自己推导、不会形成自己的判断。
反过来，读者读一份”讲两个主题”的文档，他的心智模型切换成”研读”——每个主题看深一点、想多一点。这种模式下，读者会形成自己的判断。
三个约束指向同一个结论：一份文档要么讲得广但浅，要么讲得窄但深。你必须做选择。
大部分人没意识到自己在做选择——他们以为自己在”广且深”，其实他们在”广且浅”。
三、深度的三个层级
把”深度”这件事拆开来看，所有”深”都跑不出三个层级。
层级一：现象。
发生了什么。
“我们公司的订单查询接口 P99 延迟是 800ms。”
这是事实层——读者知道”现象是什么”。
层级二：机制。
为什么会这样。
“订单查询接口要联合查订单表、用户表、商品表、优惠券表。其中商品表是分库分表的，需要 4 次 RPC 调用。每次 RPC 平均 150ms，所以 P99 是 600-800ms。”
这是机制层——读者知道”为什么会出现这个现象”。
层级三：原理。
底层逻辑是什么。这一层往往涉及更基础的概念。
“订单查询是典型的’读扩散 + 多源 join’场景。这类场景的性能瓶颈在网络往返次数（每多一次 RPC，P99 增加 100-200ms）和 join 算法的复杂度。当数据源超过 3 个时，最佳实践是用’宽表 + 冗余’减少 join，而不是优化单次 RPC。”
这是原理层——读者知道”在更高维度上，这件事应该怎么看”。
三个层级的”读者收获”：
- 现象层：读者知道”是什么”。
- 机制层：读者知道”为什么”。
- 原理层：读者知道”应该怎么看”。
大部分文档只到现象层——“我们的问题是这个，所以我们要做那个”。“为什么会出现这个问题”很少讲；“在更高维度上应该怎么看”几乎不讲。
深度优先的文档，现象层只是入口，重点在机制层和原理层。
举一个反例。我见过一个新人写的故障复盘：
2024 年 5 月 10 日，订单服务出现 5 分钟不可用。原因：数据库连接池耗尽。修复：增加了连接池上限。
三个事实层（时间、原因、修复），没到机制层（为什么连接池会耗尽？），没到原理层（怎么设计才能避免？）。
读者读完，他知道了”有这么一个事故”，但他不知道怎么避免下次——因为作者没讲机制和原理。
一个深度优先的版本：
2024 年 5 月 10 日，订单服务出现 5 分钟不可用。原因：数据库连接池耗尽。
机制：事故当天有个运营活动，订单量是平时的 10 倍。连接池配置是 100，上限是 200。流量高峰时连接池被撑满，新请求排队等待，触发超时重试，重试又占更多连接，最终雪崩。
原理：连接池的容量是按”平均 QPS × 平均响应时间”算的，再加 30% 冗余。但这种算法在流量突发场景下不够——10 倍流量是平均的 1000%，远超 30% 冗余。这种场景下应该用”动态连接池”或”快速失败 + 排队”策略，而不是”扩容上限”。
修复：
- 短期：把连接池上限从 200 调到 500。
- 长期：引入动态连接池，QPS 高于阈值时自动扩容。
这个版本讲了三层：现象（事故是什么）、机制（为什么会发生）、原理（应该怎么设计）。读者读完，不仅知道”有这么个事故”，还知道”下次怎么避免”——他带走的不是事实，是判断。
四、一个点讲透 vs 十个点讲一遍
讲完深度，再讲取舍。
“一个点讲透”和”十个点讲一遍”是两种不同的写作策略。它们各有适用场景。
“一个点讲透”的适用场景：
- 决策类文档：方案推荐、技术选型、设计评审。
- 教程类文章：讲一个具体技术或方法。
- 观点类文章：提出一个判断并论证。
“十个点讲一遍”的适用场景：
- 综述类文章：领域概览、年度总结。
- 参考类文档：API 手册、配置说明。
- 索引类文档：项目 README、知识地图。
判别方法：你的读者读这份文档要做什么？
- 要做决策 → 深度优先（一个点讲透）。
- 要扫一眼找信息 → 广度优先（十个点讲一遍）。
- 要了解全局 → 折中（核心讲透、周边略讲）。
如果你不确定读者要做什么，默认按”决策”来写——一个点讲透。如果读者不需要做决策，他可以跳过这个深度——他没损失；但如果读者要做决策，他没法跳过你的”广”——他要花时间自己提炼重点。
默认深度优先是更稳妥的选择。
五、怎么选”重点”
定了”深度优先”，下一步是选重点——文档里只深度讲哪几个主题。
三个判断标准：
标准一：决策视角。
这份文档要解决的核心决策是什么？所有内容围绕这个决策。
举个反例。我见过一个项目立项文档，决策是”这个项目要不要做”。但文档用了 60% 的篇幅讲”我们的团队”——这不是决策的核心，决策的核心是”项目值不值得做”。
正确的做法：决策是”值不值得做”，那 60% 篇幅应该在”项目价值分析”，20% 篇幅在”风险评估”，20% 篇幅在”团队 + 计划”。
标准二：读者视角。
读者读完这份文档，需要带走什么判断？所有内容围绕这些判断。
举个反例。我见过一个 API 升级文档，读者要带走的是”我什么时候需要升级、升级路径是什么、有什么风险”。但文档用了 40% 篇幅讲”为什么我们要升级”——这不是读者关心的，读者关心的是”我应该怎么做”。
正确的做法：读者的判断是”什么时候 / 怎么做 / 什么风险”，那 40% 篇幅应该在”升级路径”，30% 在”风险”，30% 在”为什么”。
标准三：价值视角。
哪个主题最能改变读者的决策？那个主题就要讲透。
举个反例。我见过一个数据库迁移文档，迁移的”风险点”很多——数据丢失风险、性能下降风险、回滚困难。但文档每条风险用一句话带过。读者读完不知道”最大的风险是什么、应该怎么应对”。
正确的做法：识别”最大风险”——往往是数据丢失——把它单独拎出来讲透。其他风险可以简略。
三个标准指向同一个结论：重点 = 决策核心 = 读者要带走的判断 = 价值最大的点。这三个往往是同一件事的不同说法。
六、深度 vs 广度的合理配比
不同文体的深度广度配比：
| 文档类型 | 深度 | 广度 | 例子 |
|---|---|---|---|
| 技术 RFC | 90% | 10% | HTTP/3 RFC |
| 决策类文档 | 70% | 30% | 技术选型、设计评审 |
| 教程类文章 | 80% | 20% | 写一个算法的教程 |
| 综述类文章 | 20% | 80% | 年度总结、领域概览 |
| 参考类文档 | 5% | 95% | API 手册、配置说明 |
| 索引类文档 | 10% | 90% | 项目 README、知识地图 |
两个极端：
- 技术 RFC：一个协议细节讲 100 页。读者读一个 RFC 只为搞清楚一个具体问题。
- API 手册：几千个 API 一个个列。读者读 API 手册只为查一个具体的调用。
判断你的文档应该是哪种，先看读者用这份文档做什么。
读者用你的文档做什么？看：
- 文档的目标读者是谁？（开发者 / 决策者 / 普通用户）
- 读者读这份文档要回答什么问题？（做一个决策 / 写一段代码 / 了解一个领域）
- 读者读完会做什么动作？（拍板 / 编码 / 写自己的文档）
回答完这三个问题，你就知道你的文档应该是哪种——然后用相应的配比来组织内容。
七、反例：百科全书式文档
最后举一个完整的反例——“百科全书式”文档。
我见过一个产品介绍文档，作者试图把”产品的一切”都讲一遍：
1. 我们是谁
2. 我们的使命
3. 我们的愿景
4. 我们的产品
5. 产品的功能
6. 功能 1 的细节
7. 功能 2 的细节
8. 功能 3 的细节
9. 功能 4 的细节
10. 我们的客户
11. 客户的案例
12. 客户的反馈
13. 我们的优势
14. 我们的劣势
15. 我们的未来
15 节，每节 200 字。作者洋洋洒洒写了 3000 字。
读者读完记住什么？“这个产品好像什么都做。”
为什么？因为这 15 节里没有一节是重点。每节都是 200 字，每节都没讲透。读者要记住 15 个 200 字——他记不住。
深度优先的版本应该是：
1. 这个产品解决的核心问题（300 字，机制层 + 原理层）
2. 我们为什么用这种方案解决（500 字，机制层）
3. 三个关键功能的工作原理（每个 500 字，深讲机制）
4. 不做什么（200 字，明确边界）
5. 谁适合用、谁不适合用（300 字）
5 节，每节深讲。读者读完知道”这个产品解决什么问题、为什么这么解决、关键功能怎么工作”——三个具体的判断。
读者读完会”哦”，不是”啊好多东西”。
“一个点讲透”读者读完能复述，“十个点讲一遍”读者读完啥也记不住。
八、心法：少即是多，但不是少就是多
讲完深度，最后一条心法。
“少即是多”——这个老掉牙的写作原则。但它经常被误用。
误用方式一：以为”少就是写得短”。
不是的。“少”是”讲得窄”，不是”写得短”。一份 5000 字讲两个主题的文档，比一份 1000 字讲十个主题的文档”少”得多。
误用方式二：以为”少就是砍掉细节”。
不是的。“少”是”砍掉无关主题”，不是”砍掉核心主题的细节”。核心主题要讲透，要给细节、给数据、给例子。
误用方式三：以为”少就是不讲反例”。
不是的。“少”是”少主题”，不是”少维度”。讲一个主题要把支持、反对、边界都讲到。
“少即是多”的真正含义：少讲主题，多讲每个主题。
一份文档的主题越少，每个主题能被讲得越深；每个主题讲得越深，读者读完能带走的判断就越多；读者带走的判断越多，这份文档的”充实度”越高。
充实度和字数不成正比。充实度 = 主题数 × 每个主题的深度。当你固定字数时，主题数越少，每个主题的深度越大，充实度越高。
九、思考题
思考题 1：把一份”百科全书式”文档砍到”深度优先”
找一份你最近写的”百科全书式”文档（节数 ≥ 7、节字数差不多）。按本章方法砍到”深度优先”。
具体步骤：
- 列出原文档的所有主题。
- 用”决策视角 / 读者视角 / 价值视角”三个标准筛出”重点主题”（不超过 3 个）。
- 把 70% 的篇幅给”重点主题”，其他主题合并或删掉。
- 重点主题讲到机制层甚至原理层，配数据 + 案例。
写完之后对比新旧版本，自评：旧版本读者读完记住什么？新版本读者读完记住什么？
思考题 2：分析一段”深度优先”的文字
找一段你读过的”深度优先”的技术文章（讲一个具体技术或方法、机制层 / 原理层讲得很透的文章）。做一份”深度分析”：
- 这篇文章的主题数是多少？
- 每个主题讲到了哪一层（现象 / 机制 / 原理）？
- 这篇文章”深度优先”在哪？
- 如果让你加广度，你会加什么？
写一篇 500 字的分析。
思考题 3：把一份”浅”文档升级为”深”文档
找一段你最近写的”浅”文档——只讲到现象层、没到机制层和原理层的。
按以下步骤升级：
- 识别这段文档讲到的”现象”是什么。
- 补一层”机制”——为什么会这样？底层逻辑是什么？
- 再补一层”原理”——在更高维度上，这件事应该怎么看？
写完之后自评：升级后的版本，读者读完能带走哪些”判断”？
参考答案
思考题 1 参考答案
大部分人做完这道题会发现：自己的文档里有 60% 的篇幅是”凑数”——读者读完用不上。
一个常见的模式：
- 1-2 节重点内容，每节 1000 字，讲到机制层。
- 4-5 节周边内容，每节 600 字，只到现象层。
读者读完，重点内容记住了，周边内容基本丢掉——但这 4-5 节占了文档 60% 的篇幅。
砍完之后的版本应该是：
- 1-2 节重点内容，每节 2500 字，讲到原理层。
- 1 节”其他”或”参考”，列出其他主题的简要说明 + 链接。
总字数可能差不多，但深度提升一个档次。
我自己的改稿习惯：写完第一稿后做”主题筛选”——把所有主题列出来，问”如果只能保留 3 个，留哪 3 个”。留下的讲透，删掉或合并到”参考”。
思考题 2 参考答案
深度优先的文字有三个共同点：
-
主题数 ≤ 3。作者把范围砍得很窄，宁可少讲几个主题，也要每个讲透。
-
每主题讲到机制层或原理层。读者读完不只是知道”是什么”，还知道”为什么”和”应该怎么看”。
-
每个主题配数据 + 案例。不是抽象论述，是具体支撑。
你的分析应该围绕这三点写（不一定全部涉及，但至少触及两点）。如果你读完只写得出”作者讲得很深”，说明你还没把”深度”拆开来——回到这一章的核心：深度 = 主题数 × 每个主题的深度。
思考题 3 参考答案
大部分”浅”文档升级后能立刻上一个档次——只需要补”机制”和”原理”两层。
一个反例：我见过一个故障复盘只写”事故是什么、修复是什么”。升级后补了：
- 机制层：为什么会发生？（具体到代码 / 配置）
- 原理层：在更高维度上，应该怎么设计？（具体到架构模式）
升级后的故障复盘，读者读完不只是知道”有这么个事故”，还知道”下次怎么避免”。
我自己的改稿习惯：写完第一稿后做”层次扫描”——对每个主题问”我讲到了哪一层？现象？机制？原理？“。如果只到现象层，问自己”机制呢？原理呢？“。
十、动手练习
练习 1：把一份”百科全书式”文档砍到”深度优先”
找一份你最近写的”百科全书式”文档（节数 ≥ 7、节字数差不多）。按以下步骤砍到”深度优先”：
- 列出原文档的所有主题。
- 用”决策视角 / 读者视角 / 价值视角”三个标准筛出”重点主题”（不超过 3 个）。
- 把 70% 的篇幅给”重点主题”，其他主题合并或删掉。
- 重点主题讲到机制层甚至原理层，配数据 + 案例。
写完之后发给同事，让他读完之后讲”这份文档的核心论点是什么”。如果他能说出来——过关；如果他说不出——重新来。
练习 2：把一份”浅”文档升级为”深”文档
找一份你最近写的”浅”文档——只讲到现象层、没到机制层和原理层的。
按以下步骤升级：
- 识别这段文档讲到的”现象”是什么。
- 补一层”机制”——为什么会这样？底层逻辑是什么？
- 再补一层”原理”——在更高维度上，这件事应该怎么看？
- 删掉无关主题，把篇幅集中在核心主题。
写完之后自评：升级后的版本，读者读完能带走哪些”判断”？
自评标准
练习 1 自评标准：
- 主题数 ≤ 3——硬性指标。
- 每个主题讲到机制层或原理层——硬性指标。
- 同事能用一句话讲出文档核心论点——硬性指标。
练习 2 自评标准：
- 升级后的文档至少补到机制层——过关。
- 升级后的文档补到原理层——优秀。
- 升级后的文档只到现象层——没过关。
十一、小结
这一章把”深度优先”这件事讲清楚了：
| 概念 | 一句话 |
|---|---|
| 广度 vs 深度 | 不能兼得。一份文档要么广而浅，要么窄而深。 |
| 深度的三层 | 现象（是什么）/ 机制（为什么）/ 原理（应该怎么看）。 |
| 一个点讲透 | 主题数 ≤ 3，每个主题讲到机制层或原理层。 |
| 重点的三个标准 | 决策视角 / 读者视角 / 价值视角。 |
| 深度配比 | RFC 90% 深度 / 决策 70% / 教程 80% / 综述 20% / 参考 5%。 |
| 少即是多 | 少讲主题，多讲每个主题。 |
充实度 = 主题数 × 每个主题的深度。固定字数时，主题数越少，每个主题的深度越大，充实度越高。
第一卷到此讲完。回顾一下：
- 第一章《把”写好”两个字拆开》：充实 > 结构 > 修辞
- 第二章《信息密度的四个层级》：L1 / L2 / L3 / L4 的删除实验
- 第三章《结构清晰：读者是迷路的旅客》：帮读者分配注意力
- 第四章《论证扎实：把”我想说的”变成”读者信服的”》：预判反驳并回应
- 第五章《深度优先：一个点讲透的诱惑》：少讲主题，多讲每个主题
这五章合起来是”一份文档充实”的最小集合——密度、结构、论证、深度四个维度，缺一不可。
第二卷”心法篇”开始。我们讲”为什么你总是写到一半卡住”——这是网状思维和线性文本的冲突。读完你会有一把”打开思路”和”整理思路”的钥匙。
心法
充实度 = 主题数 × 每个主题的深度。
固定字数时，主题数越少，每个主题的深度越大，充实度越高。
少讲主题，多讲每个主题。
一个点讲透，胜于十个点讲一遍。