01 把”写好”这两个字拆开
第一卷·认知地基 第一章
一、一个尴尬的下午
上周你在公司内网写了一份设计文档，主题是”为什么要把订单服务从用户服务里拆出去”。
你写了三千字，分四节：背景、现状、问题、方案。你自认为逻辑通顺、用词规范、还做了两个图表说明。你甚至专门花了半小时，给”现状”那一节做了一个时序图——箭头画得清清楚楚。
文档发给组长。
五分钟后组长回复：
“行，按这个改。”
你盯着这五个字看了十几秒，心里有点怪。说不上来哪里不对，但隐约觉得，这篇文档”失败”了。
不是失败在”被否”——被否你反而知道哪里不行。失败在”被同意但没反应”。组长读完”同意”，但你没感觉到他”被说服”。他没追问、没质疑、没提反对意见。这种”无质疑通过”，有时候比”被否”更让人不安。
更让你不舒服的是第二天。新人小李过来问你：“哥，订单服务为啥要拆出来？”
你给他指了文档。他读完，回了一句：
“哦。”
你问他看懂了吗。他说：“看懂了。”
你追问：“那你觉得为什么？”
他沉默了三秒，说：“就是……按文档写的那样拆。”
你心里咯噔一下。
他看懂了字，没看懂意思。
或者他看懂了意思，但说不出意思——这两种情况的根是同一个：你的文档里没有意思，只有字。
“没有意思”是什么意思？不是指文档里没有字——你写了三千字，每个字都是字。是指文档里没有”为什么是这样”。你的文档告诉了读者”现状是这样""我们决定拆”，但没告诉读者”为什么现状是这样是错的""为什么拆能解决问题”。
读者读完，他知道你做了什么决定；但他不知道这个决定背后的逻辑。他”看懂了字”，但没”理解意思”。
这件事的本质，我们这一章要拆开来讲。
二、“写好”不是一个东西，是三个东西
你可能会想：“我没讲清楚吗？我分了四节，每节都写了呀。”
问题不在”讲没讲”。问题在于你讲的内容里，没有”意思”。
讲个细节。你的”问题”那一节，是怎么写的？
你可能写的是：
当前订单服务与用户服务耦合严重。订单服务依赖用户服务的接口获取用户信息，用户服务依赖订单服务的接口查询订单状态。两服务通过 RPC 调用形成循环依赖。
这一段”看起来”讲清了问题。它用词规范，描述清晰，结构合理。但你读一遍会发现——这一段讲的是”现状”，不是”问题”。
“两服务循环依赖”是现状。“这个问题导致什么后果”——你没讲。“循环依赖为什么是错的”——你没讲。“不解决会怎样”——你没讲。
你讲了”是这样”，没讲”为什么是这样是错的”。
这就是”没意思”的具体含义。
为了把这件事讲清楚，我们把”写好”这两个字拆开。
“写好”不是一个东西，是三个东西。
| 层级 | 回答的问题 | 充实的标志 | 不充实的标志 |
|---|---|---|---|
| 充实 | 读者读完，多知道了一些东西吗？ | 读者能用自己的话复述你的核心论点 | 读者只能说”看了” |
| 修辞 | 读者读起来，是顺畅还是别扭？ | 句子通顺，节奏舒服 | 拗口、堆砌、刻意 |
| 结构 | 读者读的时候，能跟着你的思路走吗？ | 一段一推进，有路标 | 段落无序，主题跳来跳去 |
三件事有先后顺序：充实 > 结构 > 修辞。
意思是：先把”读者能不能多知道”解决了；再解决”读者能不能跟着走”；最后才是”读者读起来爽不爽”。
顺序颠倒过来会怎样？
颠倒过来就是大部分人写文档的路径：先想”我要用什么句式""我要不要分个一二三四""我要不要加个图表”，最后才想”我要讲什么”。
这条路写出来的东西，结构很漂亮、修辞很讲究，但没有内核。
你刚才那篇设计文档，问题就在这里：四节齐全，结构清楚，但”问题”那一节是”现状的描述”，不是”问题的本质”。读者读完知道”现状是这样”，但不知道”为什么要改”。所以组长”同意”，但没”被说服”。所以新人”看懂了”，但说不出”为什么”。
修辞和结构都没错，错的是没把”充实”放在第一位。
三、充实的判据：一条标准
充实的判据只有一条：
读者读完之后，能用自己的话复述你的核心论点。
这条标准听起来简单，用起来极难。
你试试你上周写的那份文档。如果新人小李读完，合上文档，你能问他三个问题：
- 这篇文档要解决的问题是什么？
- 这个问题的根本原因是什么？
- 我们选的方案为什么能解决它？
如果他能用自己的话答出来——文档是充实的。
如果他答不出来，或者只能复述文档里的原话——文档不充实。
为什么”用自己的话”重要？因为复述这个动作本身就是理解力的证明。读者能用不同于你原文的句子表达你的意思，说明他真的理解了；只能背诵你的原话，说明他在”装作看懂”。
绝大部分文档不充实，都是因为这个测试过不了。
但请注意，这条标准不能用来要求”零基础读者”。你的目标读者如果有基本背景（比如”知道公司业务""知道技术栈”），那他能复述；如果你的目标读者连业务都不知道，那再充实的文档也复述不出来——这不是充实的问题，是读者错位的问题。
读者错位有两种典型：
第一种是”高估读者”。你以为读者懂，其实他不懂。这种情况通常是”充实”做错了——你跳过了关键论证步骤。
第二种是”低估读者”。你以为读者不懂，其实他懂。这种情况通常是”修辞”做错了——你花太多笔墨解释读者已经知道的事。
这两种情况都不是”充实”的问题，是”读者建模”的问题。我们后面会用整整一章讲。
这一章先把”充实”这条判据钉死。读者能不能用自己的话复述你的核心论点——这一条胜过任何”读者反馈”。
四、修辞不能补位
讲到这里，你可能会想：“那我学点修辞手法不就行了？”
不行。
修辞是给”已经充实的内容”加分的，不是给”空虚的内容”补位的。
这是个很常见的误解。大部分人以为”写得不好”是”修辞不够”，所以去背成语、背句式、背排比。结果呢？空虚的内容加上花哨的句式，反而更让人想吐。
我见过一个同事写年终总结：
在过去的一年里，我们砥砺前行，攻坚克难，谱写了新的篇章；在新的一年里，我们将继续发扬拼搏精神，再创辉煌。
看上去漂亮得很。但他写的不是年终总结，是模板填空。
“砥砺前行”换成”勇往直前”、“攻坚克难”换成”乘风破浪”、“谱写篇章”换成”书写历史”，意思完全一样——因为本来就没有意思。
修辞不能让空虚变充实，只能让充实变得”读起来更顺”。
反过来：充实的文字加上修辞，是锦上添花；空虚的文字加上修辞，是雪上加霜。
你可能反驳：“但有的文章看起来很朴素，也很充实呀。”
对。但朴素不等于没修辞——朴素是一种克制的修辞。它拒绝堆砌、拒绝华丽、拒绝用形容词代替信息。这种”克制”本身就是修辞，而且往往是更难掌握的修辞。
我们后面讲”句子密度""段落节奏""标点节奏”那些章会专门讲。
我顺手举两个例子，让你感受一下”朴素且充实”和”华丽且空虚”的差距。
华丽且空虚：
在这个瞬息万变的时代，技术的革新日新月异。我们身处其中，唯有不断学习、不断进步，才能跟上时代的步伐，不被时代所淘汰。学习是一个持续的过程，需要我们保持初心，保持对知识的渴望，用行动去诠释学习的真谛。
读完你有什么感觉？“哇，好有道理。“——然后呢？然后没有了。这段话你删了它，什么都不会失去——因为它本来就没装任何东西。
朴素且充实：
Go 1.18 之前，开发者要在编译期检查某个类型是否实现了某个接口，只能写一个带 compile-time 断言的 dummy 变量：
var _ MyInterface = (*MyStruct)(nil)这种写法能用，但有三个问题：
- 占用一行代码，IDE 里会显示一个变量名（虽然实际未使用），影响阅读。
- 如果类型签名变化（比如接口增删方法），IDE 不会主动提示”这里需要更新”，开发者要等到编译报错才知道。
- 它不表达意图——下一个读代码的人会想”为什么要写这一行？是不是有特殊用途？”
Go 1.18 引入了类型参数的
~T形式，但更重要的是为interface引入了方法集检查的工具。这是语言级别的支持，意味着检查可以从”开发者写一行 hack”变成”工具自动做”。
读完你有什么感觉？“哦原来是这样。“——而且你能讲给别人听。
两段对比，第一段占了字数，但读完什么都不知道；第二段字数更少，但读完你多知道了三件事（三个问题）和一个演进（Go 1.18 的改进）。
第一段是修辞，错把修辞当充实。第二段是朴素，但朴素不挡充实。
我见过太多人写第一段。他们以为”字数多 = 内容多”，其实字数多只能说明”凑字多”。
五、结构不是装饰，是路径
再讲一个常见的误解：把结构当作”装饰”。
很多人写文档，第一步是确定”我要分几节”。这一步是对的。但接下来他们把”分几节”当成”结构”——分了三节就叫”有结构”，分了一节就叫”没结构”。
不是的。结构是”读者跟着你走的路径”，不是”段落有几节”。
读者读你的文档，他不知道你要讲什么。他只能一段一段往下读。如果他读到第二段不知道第一段和第二段的关系，他就开始迷糊了。如果他读到第四段已经忘了第二段说什么，他就开始跳读了。如果他读到结尾还没搞清楚”你这篇文档到底要说什么”，他就放弃了——但不会告诉你放弃，他会说”我看了，写得不错”，然后再也不会打开。
结构是给读者的”路标”：
- 一节讲完，要让读者知道”这一节和下一节是什么关系”——是递进？是并列？是因果？
- 一段写完，要让读者知道”这段在推进什么”——是论证？是举例？是反例？
- 一句话说完，要让读者知道”这句话和上一句是什么关系”——是承接？是转折？是举例？
如果你的段落之间没有这些关系，读者就迷路了。读者迷路了不会告诉你，他会沉默，然后说”看了”。
我那个同事写的”砥砺前行、攻坚克难”那段，看起来”有结构”——“过去""现在""未来”三段。但三段之间没有递进，没有因果，只有时间顺序——而时间顺序本身就是最弱的结构。
真正的结构，是”信息之间的逻辑关系”，不是”信息出现的时间顺序”。
后面第 8 章”金字塔原理”会专门讲这个。三种基本的逻辑结构——递进、并列、对比——怎么用、什么时候用、什么时候不用。读完你会建立一套”路标体系”，让自己的每一段、每一节都有清晰的方向感。
六、读者反应的两个真相
讲完上面三件事，再讲两个关于”读者反应”的真相。这两个真相看着不舒服，但很重要。
真相一：沉默不等于认同。
你的文档发出去没人反馈，不一定是因为”大家都同意”。很多时候是因为：
- 读者读了，没看懂，但不好意思说。
- 读者读了，觉得哪里不对，但说不上来。
- 读者读了，被其他事打断，再也没回来。
- 读者压根没读——邮件被标记后沉底。
沉默是反馈的最弱信号。你的文档发出去了，得到一句”行”和”毫无反应”，信号强度其实差不多——都说明”读者没被你打动”。区别只是”被动接受”还是”主动跳过”。
所以你写完文档，不要等别人给你反馈。自己用”读者能不能用自己的话复述”这一条判据自检。这是你能控制的、最直接的充实度测试。
真相二：被夸不等于写得好。
另一个让人难受的真相：你写一篇文档，发出去，同事说”写得真好，逻辑清楚”。你很高兴。但三个月后这个同事遇到类似的问题，他不会再翻你这篇文档——他会再问你一遍，或者上网搜一篇新的。
为什么？因为他”被夸”的时候，他没真的”学进去”。他夸的是你这篇文档的”形式”——分节清楚、用词规范、有图有表。但他没拿走你这篇文档里的”判断”——你对问题的诊断、你的方案选择、你的推理过程。
他夸的是修辞和结构，不是充实。
你写文档的真正目标，是让读者拿走一个判断。这个判断要被他内化，下次遇到类似场景能自己拿出来用。
我自己的写作习惯：写完一篇文档，我会回头看一遍结尾。如果结尾是”以上就是 XXX，请大家按这个执行”——我立刻把结尾删掉，改成”读者读完应该带走什么”。这个”应该带走什么”才是我写这篇文档的目的。
如果我说不出来”读者应该带走什么”，说明我还没想清楚我要写什么——这种情况下我不应该发文档，应该回去重新想。
七、心法：充实优先，三件事的次序
讲到这里，把”写好”拆成三件事的逻辑就跑通了。最后一条心法送给你：
写之前，先问自己一个问题：读者读完这篇，能多知道什么？
如果这个问题答不上来，再多的修辞、再漂亮的设计、再工整的章节，都是浮云。
写完之后，再问自己一个问题：这篇文档，如果让一个背景相当但没参与项目的同事读，他能用自己的话讲清楚”我为什么这么写”吗？
如果能，文档是充实的。 如果不能，回到第三问：你的核心论点是什么？你讲清楚了吗？
这条心法是后面所有章节的总开关。看到后面任何技法——大纲、金字塔、句子密度、段落节奏——都先回到这条心法：这条技法让读者”多知道”了吗？如果没有，砍掉。
技术人写文档最容易犯的错，是用”看起来专业”代替”读起来有收获”。我见过无数设计文档，看起来像模像样——分了 N 节、画了 N 个图、引了 N 个 RFC——但核心论点说不清。这种文档不是”写得不好”，是”写得空”。
写得不丑和写得充实之间，隔着一道”读者能不能复述”的鸿沟。鸿沟这边是”形式完整”，鸿沟那边是”内容到位”。大部分人卡在鸿沟这边——他们把”形式完整”当终点，没意识到终点在那边。
下一章我们讲”信息密度的四个层级”，把这条鸿沟量化——让你知道每段话、每句话、每个词到底在”充实”什么、“修辞”什么、“凑字”什么。读完那章，你会有一套可以直接套用的自检方法。
八、思考题
思考题 1：找一份你最近写的文档，自检一下
拿出一份你最近写的工作文档——设计文档、邮件、报告、PPT 备注、博客草稿，都可以。
不要选你写得最得意的。选你”觉得写得一般但又说不上来哪里不好”的。这种文档最有诊断价值。
把文档打印出来，或者另存一份副本。然后拿一支笔，对每一段做一件事：在段首标一个字母——
- A：这一段读完，读者能多知道一个事实 / 观点 / 结论。
- B：这一段读完，读者只获得了”修饰性内容”——比如情绪渲染、重复表达、抽象描述。
- C：这一段读完，读者什么也没多知道，但读起来更顺了——比如过渡、衔接、铺垫。
- D：这一段读完，读者什么都没多知道，也读不顺——纯凑字。
标完之后统计 A / B / C / D 各占多少。
如果 A 不到 30%，说明你的文档”充实度”严重不足。 不要急着改文字，先回头想：你这篇文档要解决的核心问题是什么？你每一段是不是都在”解决”这个问题？
思考题 2：把一段”看起来漂亮”的文字改成”充实”的版本
下面这段话”看起来”不错，但读完你什么也没多知道。试着把它改写成”充实”的版本——让读者读完能多知道一两件事。
原文：
在这个瞬息万变的时代，技术的革新日新月异。我们身处其中，唯有不断学习、不断进步，才能跟上时代的步伐，不被时代所淘汰。学习是一个持续的过程，需要我们保持初心，保持对知识的渴望，用行动去诠释学习的真谛。
提示：先想这段话”想说什么”——按原文的样子，它想说”要持续学习”。但它没说什么具体场景、什么具体方法、什么具体案例。充实版本的关键是补上这些。
思考题 3：分析一段”看起来朴素但充实”的文字
找一段你最近读过的”看起来朴素但读完有收获”的文字——可能是 RFC、可能是学术论文、可能是一位资深工程师写的博客、可能是某个开源项目的 README。
逐段分析：
- 每段的”核心论点”是什么？
- 段与段之间是什么逻辑关系？（递进？因果？对比？）
- 这段文字用了什么技法让”朴素”但不”空洞”？
写一篇 500 字的”读后感”，说清楚它为什么充实。
参考答案
思考题 1 参考答案
大部分人做完这道题会发现：自己写的东西里 B 和 D 占了一半以上。
一个常见的模式：
- 开头一段”宏大叙事”——B 类，纯氛围。
- 中间几段”罗列现状”——B 或 C 类，描述但没论证。
- 结尾一段”展望未来”——B 或 D 类，无内容的展望。
这些段加在一起字数很多，但读完读者还是不知道”你到底要说什么”。
做完这道题的标准动作：
- 重写开头：开头不要写”宏大叙事”，直接抛出”这篇文档要解决的问题”。
- 砍掉现状：如果”现状”不直接支撑问题，砍掉。
- 结尾要交付：结尾不要”展望”，要交付一个”读者可以带走的东西”——一个决策、一个判断、一个行动项。
我自己的习惯是：写完第一稿之后，先把 B 和 D 砍掉，再重新组织剩下的段落。砍的过程会疼，因为你会发现有一半的字数是无效的。但砍完之后，剩下的东西会自动变结实。
思考题 2 参考答案
一个改写示范：
我从 2018 年开始写 Go，到现在 5 年。中间有两次明显感觉”卡住了”——一次是 2019 年学 channel 调度，一次是 2021 年学 GMP 模型。两次卡住的根因是同一个：我没读过 Go runtime 的源码，只读过二手的解释文章。
那之后我定了一条规矩：任何我想”精通”的特性，必须读一遍 runtime 或 stdlib 的相关源码。读完源码不一定全懂，但至少知道”真相在哪个文件里”，下次卡住时可以回头查。
这条规矩带来的副作用：我现在读别人的代码，第一反应是”这个作者读过源码吗”。读过源码的人写的代码，和没读过的人写的代码，质感不一样。
你如果是初学者，别急着读源码。先写 2 万行 Go 再说。那时候你会有自己的疑问，带着疑问读源码，效率高十倍。
这段改写后，“充实”在哪？
- 多知道一个事实：作者从 2018 年开始写 Go，有 5 年经验。
- 多知道一个观点：任何想”精通”的特性必须读源码。
- 多知道一个判断：初学者不要急着读源码。
- 多知道一个观察：读过源码的人写代码质感不一样。
四件事。原文那段话只表达了”要持续学习”一件事，而且没表达清楚。
思考题 3 参考答案
朴素但充实的文字有四个共同点（这四点会在后面章节展开）：
- 每段只做一件事。一段一推进，没有一段同时讲两件事。
- 段首句就是核心论点。读者读段首句，就知道这段在讲什么。
- 段与段之间有显式连接。“因为""所以""但是""举个例子”这些连接词会出现——但不是为了修辞，是为了”路标”。
- 结尾段不”总结全文”。结尾段是”交付物”——一个决策、一个判断、一个留给读者的钩子。
你的读后感应该围绕这四点写（不一定全部涉及，但至少触及两三点）。如果你读完只写得出”作者写得好”这种笼统的话，说明你还没把”好”拆开来——回到这一章的核心：把”写好”两个字拆开。
九、动手练习
练习 1：重写一份你的工作文档
找一份你最近写的工作文档（不要选最得意的）。按本章的方法重写一遍：
- 先写出这篇文档要解决的核心问题（一句话，不超过 30 字）。
- 列出 3-5 个读者读完要”多知道”的东西（每条不超过 20 字）。
- 按这 3-5 条组织段落——每段对应一条。
- 写完之后回头检查：开头是不是直接抛出问题？每段是不是只做一件事？结尾是不是有”交付物”？
写完发给你身边一个同事，让他用一句话讲出你这篇文档的核心论点。如果他讲不出来，说明你还没改到位。
练习 2：把”反例”那段话扩写成”充实”版本
把第六节里那段”看起来漂亮但空虚”的话，扩写成”充实”版本——补上具体场景、具体方法、具体案例。
具体要求：
- 字数不限，但每段都要 A 类（读者读完多知道一件事）。
- 不要用”砥砺前行""攻坚克难""谱写篇章”这类短语。
- 写完之后自己读一遍，问自己：如果一个新员工读，他能讲出”我应该做什么”吗？
自评标准
练习 1 自评标准：
- 同事能用一句话讲出你的核心论点——过关。
- 同事讲不出，但你能指出文档里哪个段落是核心论点——勉强过关。
- 同事讲不出，你也指不出——没过，重新来。
练习 2 自评标准：
- 新员工读完知道”我应该做什么”——过关。
- 新员工读完知道”我应该做什么 + 为什么”——优秀。
- 新员工读完只感觉”好有气势”——没过关。
十、小结
这一章把”写好”两个字拆成了三件事：
| 层级 | 是什么 | 怎么判断 | 顺序 |
|---|---|---|---|
| 充实 | 读者读完多知道一些东西 | 读者能不能用自己的话复述你的核心论点 | 第一 |
| 结构 | 读者能跟着你的思路走 | 段与段之间有没有清晰的路标 | 第二 |
| 修辞 | 读者读起来顺畅 | 句子通顺、节奏舒服 | 第三 |
充实的判据是硬约束：读者能不能用自己的话复述你的核心论点。这一条不过，结构和修辞都白搭。
修辞不能补位。修辞不能给空虚的内容补内容，只能让充实的内容读起来更顺。
结构不是装饰。结构是给读者的”路径”，让读者知道”下一段是什么关系”。
写之前，先问自己：读者读完这篇，能多知道什么？答不上来，就不要发。
下一章我们讲”信息密度的四个层级”——把”充实”这条判据量化到每段话、每句话、每个词。让你下次写完一段话，能直接判断”这段话在充实什么、修辞什么、凑字什么”。
心法
写之前，先问自己一个问题：读者读完这篇，能多知道什么？
写完之后，再问自己一个问题：读者能不能用自己的话复述我的核心论点？
这两个问题答不上来，再多修辞、再工整结构，都是浮云。