12 · 句子的密度：一句一信息
你 review 过新人的代码吗？
不是说看逻辑，是看注释。你见过那种注释——一个 if 判断，他写了三行解释：
// 当系统的连接池资源已经被全部占用
// 并且此时有新的请求试图获取连接
// 我们应该直接返回一个错误而不是继续等待
if pool.isExhausted() {
return ErrPoolExhausted
}三行。意思就一个：连接池满了就报错。
你盯着那三行，心里冒出一个声音：兄弟，你不是在写注释，你是在把一句话抻成三段。
但别急着笑他。你写文档的时候，是不是也干过一模一样的事？
你给老板写设计文档，有一句写得很顺：“我们需要设计一个高性能、可扩展、易于维护的系统架构。”
这句话念出来铿锵有力，很有”架构师”的派头。但你停一下，问自己一句——它到底告诉读者什么了？
- 高性能？多高？QPS 多少？P99 多少？
- 可扩展？扩什么？加机器还是加模块？水平还是垂直？
- 易于维护？对谁而言？怎么衡量？新人两天能上手算易维护吗？
一个可验证的信息都没有。
这就是本章要解决的”句子的密度”问题。你以为你在表达，其实你在灌水。这一章，我们把”一句一信息”这件事讲透，让你写完每一句话，都能反问自己一句：这句话，到底往读者脑子里装了什么？
一、先问对问题：为什么我们写句子会”注水”？
在讲方法之前，先搞清楚病因。否则你背了一堆”写作技巧”，一上手还是原样。
我观察过很多工程师（包括我自己）的初稿，注水句最常见的来源，是三个心理错觉：
错觉一：短了显得没水平。
这是最要命的。我们潜意识里觉得，句子越长、定语越多、词越”大”，越显得专业。于是：
“我们应当充分地、全面地、系统地对现有的缓存失效策略进行优化。”
其实就一句：该优化缓存失效策略了。
但写短了，自己心里发虚：这样写，老板会不会觉得我没想清楚？会不会觉得我敷衍？
——不会。老板怕的不是短，是读完不知道你要干嘛。
错觉二：形容词能增加可信度。
我们以为”高性能""稳定""健壮""优雅”这些词往上一堆，方案就显得靠谱。但读者读到的不是”靠谱”，是”空”。因为这些词不可证伪——你说高性能，我没法验证；你说稳定，我也不知道稳定到什么程度。一个不可证伪的形容词，在读者脑子里激不起任何画面，等于没说。
错觉三：把”我思考的过程”当成”你要传递的信息”。
前面那个三行注释，本质是把”我怎么想到这个判断的”写进去了。但读者要的是结论，不是你的思维轨迹。思维轨迹是你写之前自己用的草稿纸，不该进正文。
你发现没有？这三个错觉，根子都在同一条：我们写的时候，想的是”我看起来怎么样”，而不是”读者接收到什么”。
这一条如果不扭转，下面所有方法都是表面功夫。
反问你一句：你上一次写东西，是先想”读者读完这句话会多知道什么”，还是先想”这句话够不够像那么回事”？
二、原理：句子的密度 = 主信息数 ÷ 字数
我们给”句子的密度”下个可操作的定义：
句子的信息密度 = 这一个句子承载的”不可删减的主信息”的数量 ÷ 这个句子的字数。
注意两个关键词：
- “不可删减”——如果删掉某个词，句子意思变了，那这个词在承载信息；如果删掉它意思没变，那是注水。
- “主信息”——不是”字”，是”信息单元”。一个对比、一个数字、一个因果，都算一个主信息。
按这个定义，我们来给句子分个级：
- 高密度句：一个短句，装一个硬信息。“连接池上限 100，超过直接报错。“——18 个字，两个主信息（上限是 100、超限即报错），密度极高。
- 中密度句：有信息，但裹了点修饰。“我们目前把连接池上限设为 100，超限直接报错。“——多了”我们目前把……设为”，是过程描述，密度打折。
- 零密度句：“我们需要一个高性能、可扩展、易于维护的系统。“——字不少，主信息为零。
一句一信息，说的不是”一句话只能有一个字”或”句子越短越好”。它说的是：一个句子，只干一件事。要么陈述一个事实，要么给出一个判断，要么描述一个因果。不要在一个句子里又陈述又感叹又铺垫。
一句里塞两件事，读者读到第二个的时候，第一个已经开始从工作记忆里挥发了。
你回想一下自己读别人代码注释的体验——最舒服的注释长什么样？是不是基本都是”xxx 的时候 yyy”这种结构？一个条件，一个动作。一句一信息。
你其实早就知道什么是对的。只是写正文的时候，把那套直觉弄丢了。
三、反例对照：同样的道理，密度差多少
光说概念没体感，我们拿真实的技术场景做对照。左边是初稿常见的注水句，右边是提密度之后的版本。
| 主题 | 注水句（零/低密度） | 紧凑句（高密度） |
|---|---|---|
| 超时设置 | 为了提升系统的健壮性，我们建议对所有的外部调用都设置一个合理的超时时间。 | 外部调用一律设超时，避免 goroutine 泄漏。 |
| 缓存 | 在高并发的场景下，使用缓存是一个非常有效的提升性能的手段。 | 高并发读，加缓存，命中率 90% 时 QPS 翻三倍。 |
| 重试 | 对于那种偶尔会失败的网络请求，我们应当采取一种适当的重试机制。 | 网络请求偶发失败，重试三次，间隔指数退避。 |
| 索引 | 在数据库的设计过程中，合理地建立索引是优化查询性能的重要方式。 | 给 user_id 加索引，查询从全表扫描降到 B+ 树查找。 |
| 错误 | 当发生错误的时候，我们要进行妥善的错误处理。 | 出错即返回，别吞 error。 |
你看右边这五句，哪句不比左边那句”有水平”？左边那种”为了提升健壮性我们建议设置合理超时”——读三遍你也记不住它到底让不让你设超时。它把”该设超时”这个结论，裹进了一套正确的废话里。
最要命的是最后一句：“当发生错误的时候，我们要进行妥善的错误处理。“——这是宇宙真理，放之四海皆准，等于什么都没说。Go 新手最爱写这种注释，因为它永远没错，但也永远没用。
反观右边：“出错即返回，别吞 error。“——九个字，一个可执行的动作。这就是密度。
四、四个注水陷阱：你正在踩哪一个？
知道原理了，我们来认脸。四种最常见的注水，你自己对照初稿看。
陷阱一：“的”字定语堆叠
“我们正在使用的这套基于 Redis 的、支持分布式锁的、带有自动过期机制的缓存组件……”
读到”缓存组件”四个字的时候，你早忘了开头说啥了。定语全堆在名词前面，读者的工作记忆扛不住。
解法：把”的”字定语改装成谓语，拆成短句。
“我们的缓存组件基于 Redis，支持分布式锁，带自动过期。”
主语出现得早，读者立刻知道你在说缓存；后面的三个特征，一个一个喂，负担轻。
陷阱二：同义反复
“这是一个非常重要的关键因素。” “我们需要对这个方案进行最终的总结归纳。” “这个问题的根本原因是由于xxx导致的。”
“重要的关键因素”——重要和关键是一个意思，叠一起不加倍，只添字。“由于……导致的”——“由于”和”导致”语义重复，留一个。
解法：删到只剩一个。重要就写重要，别加关键；原因就写原因，别用”由于……导致”。
陷阱三：万能形容词
高性能、稳定、健壮、优雅、合理、适当、有效、完善——这八个词，是我见过的工程文档里出现频率最高的”空词”。它们的问题不是不对，是不可证伪、不可衡量。
“合理的超时时间”——多长算合理？“稳定的服务”——SLA 多少算稳定？
解法：用数字、用阈值、用可观察的行为替换。
- “合理的超时” → “超时 3 秒”
- “高性能” → “P99 低于 50ms”
- “稳定” → “月可用率 99.95%”
- “优雅” → 直接删掉，这词在技术方案里基本是注水
陷阱四：从句嵌套
“当我们考虑到用户可能会在弱网环境下使用这个接口，而弱网会导致请求超时，而超时又会触发我们刚才说的重试机制，所以我们需要在客户端也做一层兜底。”
一个句子里三个”而”、三层因果。读者读到第三个”而”，早忘了第一个前提。
解法：把因果链拆成短句，一句一因果。
“用户可能在弱网下用这个接口。弱网会超时，超时会触发重试。所以客户端也要兜底。”
三个句子，三根因果链，清清楚楚。短句不等于幼稚，把复杂的事说简单了，才是真水平。
反问你：上面四个陷阱，你初稿里哪个出现得最频繁？先认自己的账，改起来才有方向。
五、四个提密度的方法：写完一句，做这个检查
方法不是背的，是养成习惯。建议你每写完一段，做一次”密度体检”——对每段里每句话问四个问题。
方法一：每句问”删了它意思变不变？”
这是最核心的一招，叫删除实验（第二章讲过密度，这里是句子级的落地）。
拿你刚写的句子，逐个词删，看意思变不变。删完意思没变的，全是注水，直接删。
“事实上，我们目前所使用的这个方案，其实是可以进一步优化的。”
逐个删：
- “事实上”——删，没变。
- “目前”——删，没变（默认就是现在）。
- “所使用的”——删，变成”我们这个方案”，没变。
- “其实”——删，没变。
- “进一步”——删，变成”是可以优化的”，没变。
删完剩：“我们这个方案是可以优化的。“——13 个字，原句 24 个字，一半是水。
方法二：把”过程描述”赶出正文
你写”我们将会对系统进行监控”，读者要的是”系统会被监控（怎么监、监什么）“，不是”我们打算去监”。
把”我们将会""我们应当""我们需要”这种表态词删掉，直接说动作。
“我们应当对所有外部请求设置超时。” → “外部请求一律设超时。”
少了一层”我建议”的皮，露出”设超时”的肉。
方法三：用具体替换抽象
这一条前面提过，这里给个实操清单：
| 抽象说法 | 具体替换 |
|---|---|
| 尽快 | 今日内 / 2 小时内 |
| 大量 | 10 万条 / 超出阈值 |
| 有时候 | 每周一上午高峰 |
| 比较好 | P99 低 30ms |
| 复杂 | 7 个步骤 / 3 层调用 |
抽象词是模糊的避难所。具体数字逼着你先想清楚，再写。
方法四：长句切两刀
一个句子超过 40 个字（中文），大概率塞了不止一个主信息。切。
切法两种：
- 并列切分：用逗号隔开的并列项，各自成句。
- 因果切分：原因一句，结果一句。
“因为连接池在流量高峰期会被迅速打满而当时又没有限流所以大量请求被阻塞。”
切：
“流量高峰，连接池会被迅速打满。当时没限流，大量请求被阻塞。”
两句话，两个画面。读者脑子不打架。
六、一个完整的改写示范
光拆招不过瘾，我们看一段完整的注水文字，改成高密度版本。
原稿（某设计文档开头）：
“在当今互联网业务高速发展的背景下，随着用户规模的不断增长和系统复杂度的持续提升，传统的单体架构逐渐暴露出了在可扩展性和维护性方面的一些问题。因此，为了能够更好地支撑未来业务的快速发展，我们经过深入的技术调研和审慎的方案评估，决定对现有的系统进行服务化的拆分与重构。”
这段读完，你记住了什么？
——什么都没记住。但你花了 30 秒。
我们来做删除实验和密度体检：
- “在当今互联网业务高速发展的背景下”——这是所有 2020 年之后的技术文章开头标配，删。
- “随着用户规模的不断增长和系统复杂度的持续提升”——这是”为什么要拆”的原因，但太虚。用户规模多大？复杂度怎么体现的？要具体。
- “传统的单体架构逐渐暴露出了在可扩展性和维护性方面的一些问题”——核心信息其实是”单体架构不够用了”，但被裹在”逐渐暴露出……一些问题”里，软。
- “为了能够更好地支撑未来业务的快速发展”——正确的废话，删。
- “我们经过深入的技术调研和审慎的方案评估”——过程描述，读者不关心你调研多深入，关心结论。删。
- “决定对现有的系统进行服务化的拆分与重构”——真正的主信息：“要拆”。
改写版：
“单体架构撑不住了：订单服务上线半年，实例从 2 个扩到 12 个，发布一次要停全站。我们决定拆成微服务。”
32 个字，五个主信息：
- 现状：单体撑不住。
- 证据：订单服务实例 2→12。
- 证据：发布要停全站。
- 结论：拆微服务。
- 隐含因果：因为扩不动、发布疼，所以要拆。
同样的意思，原稿 110 字，改写 32 字。读者省下的 78 字的时间，可以去读真正重要的东西。
这就是密度的力量——不是写得短，是没一个字是多余的。
七、心法：密度是”没有废字”，不是”越短越好”
讲到这儿，必须给你踩一脚刹车，否则容易走偏。
有人看了这章，会走向另一个极端：拼命写短句，恨不得每句五个字，觉得越短越牛。
错。
句子的密度，目标是”没有废字”，不是”字数最少”。
有些地方，你恰恰需要多写几个字，因为那几个字在承载信息：
“这个锁不是互斥锁，是读写锁——读可以并发，写才排他。”
这句不短。但”读写锁”和”互斥锁”的区别是核心信息，必须点明，不能砍。砍了读者就理解错了。
还有些地方，你需要一句”过渡”或”铺垫”，帮读者换脑子。比如两个大章节之间，你写一句”讲完结构，我们来说论证”，这句本身零信息，但它给读者一个路标。路标不是注水，是导航（第三章会专门讲）。
所以密度这条心法，准确说法是：
每一句要么承载信息，要么承担 navigational 功能（路标/过渡/强调）。两者都不是的，删。
强调句算信息吗？“这一点很重要”——不算新信息，但它把读者的注意力按在你刚说的那点上，属于”强调”功能，可以留。但一篇里别超过两三次，多了就滥。
反问你：你觉得自己更容易注水（写太长），还是更容易过头（写太碎）？两种毛病解法不一样——注水靠删，太碎靠并。先认自己是哪种。
八、思考题
思考题一： 下面这句出自某技术周报，请做删除实验，标出所有”删了意思不变”的部分，并写出改写版：
“说实话，我个人觉得我们目前这个定时任务的实现方式，其实是有一些可以进一步优化的空间的。”
思考题二： 找一个你最近写过的注释或文档段落（哪怕三五行），用”四个注水陷阱”逐条扫描，列出你踩了哪几个，改一版。
思考题三： “密度高 = 读者省力”还是”密度高 = 读者费力”？看起来矛盾，其实不矛盾。你怎么理解这句话？
九、参考答案
思考题一：
逐词删：
- “说实话”——删，没变。
- “我个人觉得”——删，默认就是你的看法。
- “我们目前”——“目前”删（默认现在），“我们”视语境，如果是周报可留可删，这里删掉更干净。
- “这个”——删，上下文已知是定时任务。
- “的实现方式”——删，周报里”定时任务”默认指实现。
- “其实”——删。
- “是有一些可以进一步优化的空间的”——核心就”可优化”，“有一些……的空间”是注水壳。
改写：
“定时任务可优化。”
或若想留一点语境：
“定时任务还有优化空间。”
从 34 字到 8 字。注意：如果周报里这是要展开讲的问题，可以更具体：“定时任务每次全量扫表，可改成增量。“——直接给证据，密度更高。
思考题二（示范思路）：
假设原注释：
“这个函数的目的是为了处理用户的登录请求并且返回一个 token 给用户。”
陷阱扫描：
- “的目的是为了”——同义反复（目的=为了），删。
- “并且返回一个 token 给用户”——“给用户”冗余，token 本来就是返回给用户的，删。
改写：
“处理登录请求，返回 token。”
踩了”同义反复”和”冗余指代”两个陷阱。
思考题三：
不矛盾，看两个阶段：
- 写的时候：密度高 = 你费力。你得想清楚每个词干嘛，做删除实验，删掉顺手写的废话。
- 读的时候：密度高 = 读者省力。没有废字，读者句句收到信息，不用来回猜你到底说没说。
很多人怕”写的时候费力”，于是把费力转嫁给了读者——用注水句让写作变轻松，代价是读者读得累、还读不懂。写作的专业，就是作者多费点力，读者少费点力。这是密度这章最底层的一条伦理。
十、动手练习
- 打开你最近写的一篇文档（技术设计、周报、接口说明都行），挑出连续 5 个句子，逐句做删除实验，统计”废字占比”。目标：把废字占比压到 20% 以下。
- 找一段你写过的”正确的废话”（类似”我们应当妥善处理好错误”），改成一句带数字或带动作的话。
- 写一个你最熟的技术概念的单句定义（比如”什么是 goroutine""什么是索引”），要求：不超过 25 字，且不用”高性能/稳定/优雅/有效”这四个词。写完对照：新手能看懂吗？
自评标准：
- 删除实验能说出每句”删了变不变”，且能落地改写 → 过关。
- 改写后的句子，拿给一个不懂该技术的人看，他能说出你在讲什么 → 密度过关。
- 自己回看初稿，能准确指出”那句是路标、那句是新信息、那句是水” → 心法过关。
十一、小结
- 句子的密度 = 不可删减的主信息数 ÷ 字数。一句一信息，是底线。
- 注水的根因是三个错觉：短了没水平、形容词增信、把思考过程当信息。
- 四个陷阱：的的堆叠、同义反复、万能形容词、从句嵌套。
- 四个方法：删除实验、赶走表态词、具体替抽象、长句切两刀。
- 心法：密度是”没有废字”，不是”越短越好”。每句要么承载信息，要么承担导航功能，否则删。
长句的拆法（实战加深）
前面说”一句一信息”，但难免写长句。长句怎么拆才不丢信息？三步：
第一步：找连接词。 “因为/所以/但是/并且/如果”是天然断点。在连接词前断，逻辑不破。
第二步：每半句补主语。 拆开后每句要有清晰主语，别让读者猜”这句谁”。
第三步：读一遍看是否还顺。 断完读，若某半句读着悬，说明它依赖前句——那就别断，或把依赖显式化。
实战：拆这句——
原：“因为我们引入了缓存所以读压力从数据库卸载到内存并且数据库不再成为瓶颈。” 拆：“我们引入了缓存。读压力从数据库卸载到内存，数据库不再成为瓶颈。”
原句 32 字无标点，读者要自己断。拆后两句，句号收束，读感立刻清楚。信息一点没少，呼吸感来了。
心法卡：
一句一信息。
写完一句，问：删了它，意思变不变？
变了 → 留。没变 → 删。
短不是目的，没废字才是。
作者多费力，读者少费力。
下一章我们放大一层：句子组成段落。你会看到，句子密度高，段落不一定清晰——因为还有”节奏”这件事。