技术写作指南：用信息密度和删减法，把内容写成干货

1. 别把干货当成一种文体它是一条信息筛选标准做了这些年内容我最怕看到标题写着纯干货三个字点进去却是一堆正确的废话。什么是正确的废话就是那些你读完之后什么都记不住、什么都不会做、什么都不敢试的内容。干货这个标签现在已经被用滥了被用来包装各种注水内容。但我想换个角度聊这件事干货不是一种文体不是排版风格也不是把内容写成第一步、第二步、第三步就完事。干货是一条信息筛选标准——你写的每一个句子都必须通过读者看完能做什么这个检验通不过的就删掉通过了才留下。我见过太多人写技术分享一上来先铺垫半小时背景随着某某技术的发展近年来某某领域逐渐兴起这些句子单独看没错但它不构成任何行动指令。读者是来解决问题、学方法、找参考的不是来听你铺垫情怀的。干货内容的第一性原理很简单你想让读者看完之后做什么、知道什么、避免什么然后把与之无关的一切都砍掉。这篇文章我就用我自己操盘过的几个模拟项目来拆解到底什么叫不说废话、全是干货以及在实操层面你怎么判断自己写出来的东西是干是湿。2. 干货的前提是条理性先梳理逻辑骨架再下笔很多人写内容不是没干货而是把干货藏在了一大堆文字里读者得自己挖。这就像你把工具全扔进一个抽屉然后告诉别人东西都在里面自己找吧——信息是有的但获取成本太高读者就没耐心了。2.1 三段式骨架目标、路径、验证我写任何一份实操内容都会先在心里搭一个三段式骨架目标这段内容要帮读者解决什么问题解决到什么程度算成功。路径从头到尾的操作路径是什么每一步的关键动作和判断标准是什么。验证做完之后怎么确认自己真的做对了。举个例子。我做过一个某跨平台系统的部署与性能调优模拟项目一开始写分享稿第一版本写了三千字啰啰嗦嗦从安装环境讲到配置文件想到哪写到哪。后来我重新梳理骨架把内容改成三块第一块写部署前的环境检查和依赖关系明确列出我要装什么、为什么装、装错会有什么后果第二块写配置参数怎么选、依据是什么、怎么根据服务器配置做调整第三块写怎么验证部署结果用哪些命令、哪些指标来确认系统跑起来了。结果就是同样的信息量第二版的阅读时间少了三分之一但读者反馈说看完就动手了而第一版看完之后还是不知道从哪开始。这就是条理性的价值——它让读者知道每一步在整条路径中的位置。2.2 逻辑递进而不是信息堆砌干货内容最常见的毛病是信息堆砌——所有信息都是真的但相互之间没有逻辑关系。这有点像有人往你桌上堆了一摞资料说这些都看看而不是告诉你先看这份再看那份最后看那份。我在整理实操经验时习惯用一条问题链来组织内容先做什么为什么先做这个做完之后怎么判断结果对不对结果不对的情况下最可能的原因是什么怎么排查排查完之后下一步做什么这条问题链的本质是把时间顺序和因果关系结合起来。时间顺序解决的是先做哪一步因果关系解决的是为什么这一步能推出下一步。两者缺一不可。只有时间顺序没有因果逻辑读者就只能照猫画虎一旦中间出偏差就不知道怎么办只有因果逻辑没有时间顺序读者就像拿到一张地图却没有路线知道该往哪去不知道先迈哪只脚。我用过一个笨办法来判断自己的内容有没有逻辑**把每段的第一句话单独拿出来读一遍。**如果这些第一句话连起来读是通顺的、有递进的说明结构没问题如果连起来读是跳跃的、并列的、甚至矛盾的那就得重新梳理。这个办法我用了很多年实测很稳。3. 实操写作的核心从我知道到你会了干货的标准不是我把我知道的都写出来了而是你跟着我的内容做完之后真的会了。这个转变的关键是把自己从知识拥有者的视角切换到操作者的视角。3.1 用操作视角而不是理论视角写内容我复盘过自己写过的内容发现一个规律只要我写的是这个参数是什么、那个配置有什么作用反馈就一般只要我写的是你先做这几步、做完检查这几个点、遇到这个问题就按这套逻辑排查反馈就好得多。原因很简单——前者是知识后者是能力读者要的是能力。举个例子。我参与过一个某图像处理Demo的模拟项目涉及图像增强算法的参数调整。第一版我写了一段内容来解释算法原理和各个参数的理论意义写得挺全面但读者反映看懂了但是不会调。后来我改了一个方向改成了这样拿到一张测试图先把处理管线跑通确认从输入到输出的全链路没报错。用一个固定的参数组合做基准记录输出结果。只动一个参数记录结果变化其他参数保持不动。找到效果最好的参数区间再微调相邻参数做组合。同样的知识换了一个叙述方式读者从知道这些参数是什么变成了知道怎么把它调好。这就是操作视角和理论视角的区别。3.2 参数和配置怎么选要把为什么讲透我在内容中很少只说我把线程数设成了8因为我清楚读者照着设成8只能解决他这一次的问题换一个场景就不知道怎么变通了。所以凡是涉及参数和配置我都会把怎么选的逻辑一起写出来。比如我那个某跨平台系统的部署项目线程池的大小不是拍脑袋定的。我先分析了项目的核心任务类型这个系统的主要负载是处理短连接请求每个请求的处理时间是毫秒级的而且是IO密集型、不是计算密集型。基于这个特征线程数可以比CPU核心数多出不少——因为大量线程都在等待IO真正占满CPU的时间很少。我当时的参考公式是线程数 CPU核心数 × (1 平均等待时间 / 平均计算时间)。我实测下来这个公式的估算值还需要再乘一个0.8到1.2之间的系数调整因为实际操作中还有锁竞争、调度开销这些公式里没算进去的因素。我会把这些调整逻辑、我踩过的坑、实测数据都写出来这样读者拿到的不止是一串数字而是一套可以迁移的方法。3.3 场景化叙述才是干货的记忆锚点纯理论、纯步骤的干货读者看完可能记不住。我给内容加记忆点的常用办法是——关联场景。场景是读者最容易产生代入感的地方也是记忆最牢固的地方。拿参数配置来说如果只写把内存池调大读者过两天就忘了。但如果写有一次线上请求量突然翻了五倍我发现内存池太小导致频繁GC系统吞吐量掉了百分之四十我当时就是通过调整这个参数恢复了稳定代价是占用内存多了几百兆——这个具体的场景读者就能记住以后自己遇到类似情况就能联想起来。我不提倡编造场景我自己写的场景全是模拟项目里真实复盘出来的。这么做的好处是内容不会变成干巴巴的说明书而是有场景、有起因、有结果的完整经验。读者记住一个场景就等于记住了一套处理问题的模板。4. 用删减法写内容每一段都要经过信息密度检验写完初稿只是开始真正让内容从有水变干货的是删减。我写过一篇典型的技术分享初稿三千字定稿一千八百字删掉了四成的内容但读者反馈信息量更大了。为什么因为删掉的是那些看似有用但实际没用的内容。4.1 三类必须删掉的废话我自己总结了三类必须删掉的内容供你对照检验第一类铺垫类废话。在这个技术快速发展的时代随着用户需求的不断增长这类句子没有任何一个读者会因为看了这句话而行动。删掉之后对内容毫无损伤那它就是在稀释干货。我自己写内容时有个硬规矩开头第一段必须直接进入主题如果第一句话不能让我明确知道这篇文章要解决什么问题我就重写。第二类正确的废话。要注意测试要保证质量要做好文档这些话都对但说了等于没说。它们的共同特征是不包含任何新的信息量。我在写项目复盘时会把这类话替换成具体做法。比如不写要注意测试而是写我用了三层测试单元测试测函数逻辑、接口测试测模块间通信、端到端测试测完整链路每一层都有具体的触发时机和判定标准。**第三类连自己都不信的句子。**如果你的内容里有些话你自己从来没实践过、没验证过只是按理说应该这样我建议你删了。一个读者如果真的按你说的步骤做了然后发现不对他损失的不止是时间还有对你后续所有内容的信任。写干货内容有一条底线你写出来的每一条建议都应该是你亲手做过、亲眼见过结果的。4.2 信息密度检验的三道关卡我每次写完内容会做一次三道关卡的检验替换检验把这一段删掉后面的内容是否依然完整如果删掉后不影响读者理解和操作说明这段是冗余的。行动检验读完这一段的读者是否知道该做一个什么具体动作如果读者读完只是哦了一声没有对应的行动指令说明这段没有干货。细节检验如果把这段话里的数字、参数、命令、步骤全部换成泛泛的描述这段话还剩多少有效信息如果什么都不剩说明细节不够需要补。举个例子。我写某图像处理Demo的调优内容时初稿里有一段调整对比度可以让图像更清晰通过了替换检验删掉后不影响理解但没通过行动检验和细节检验。我改成我用增强算法处理一批低对比度测试图固定其他参数把对比度系数从1.0逐步调到1.6每0.1一档人眼观察过曝和细节保留的平衡点大约在1.2到1.3之间具体取值还要看图片的原始亮度分布。这样细节就有了读者就知道怎么动手了。4.3 数据的东西宁可多不要少我自己的经验还有一个干货内容里数据是硬通货。具体的时间、数量、比例、参数是干货和注水的分界线。比如我不要写调整后系统性能显著提升而是写把连接池上限从50调高到200之后模拟并发从100涨到400线程池拒绝率从18%降到2%以下平均响应时间从340毫秒降到96毫秒。但我也要提醒你一句数据必须是真实的不能为了效果编数据。我所有写出来的数据都来自模拟项目实测或可复现的基准测试。读者照着做哪怕环境不同也应该能得到趋势一致的结论这才叫干货。如果你拿一组没法验证的数据出来读者一旦复现不了你这个内容的可信度就归零了。5. 起标题和写开头让读者第一眼就知道值不值得读干货内容做得好还要有配得上它的标题和开头。之前截至这里我一直在聊内容结构的骨架和写作方法接下来聊一聊门面——因为再好的干货如果读者没点进来价值就无法传递。5.1 标题要承诺一个具体结果我说过好的标题不是哗众取宠而是给读者一个承诺。你的标题实际上在回答读者的一个问题**我为什么要花时间看这篇**回答得越具体点击率和阅读完成率就越高。举个例子。系统性能调优实践这个标题读者不知道看完能获得什么太模糊了。而并发从100到400线程池拒绝率从18%降到2%我做了什么就具体得多因为它是结果导向的读者一看就知道看完能收获什么。我自己起标题有三条原则有数字有结果三个配置项两个指标7天这类数字给读者明确的预期。有场景有感受踩过的坑实测发现真实案例这类词会让读者觉得这是实操内容不是空谈。不夸大不骗人标题许诺的内容正文必须给到一次夸大可能让读者再也不看你的内容。5.2 开头前100字定生死我写过那么多内容之后得到一个强烈的体感**开头前100字基本决定了读者会不会读完这篇内容。**前100字如果还在客套、铺垫、做连接过渡读者大概率就会退出。我自己的开头套路是这样的直接告诉读者三件事——这篇内容讲什么、你读完之后能解决什么问题、我凭什么有资格讲。三句话说完最多不超过一百五十字。然后直接进入正题。我写某跨平台系统部署的内容时开头是这样写的这篇讲系统从零到一部署完整流程。读完你能独立完成环境检查、依赖安装、配置调优和结果验证。这些都是我在模拟项目里踩过坑之后整理出来的每一步都标注了判定标准和排查方向。然后直接开始第一部分。没有任何废话读者在第一屏就知道这篇内容的价值点在哪。6. 复盘与迭代让干货能力持续升级的闭环你可能会问我我写完了、发出去了然后呢答案是然后才是整个创作闭环里最容易被人跳过、但价值最大的一步——复盘。6.1 复盘反馈数据但更复盘读者的真实反应我做过一个测试同样主题的内容我出了两个版本一个偏理论讲解一个偏实操步骤发布到同一批读者里。结果实操版的收藏率比理论版高出不少但我注意到评论区里仍有人说没解决我的问题。我开始细看留言发现读者说的问题不是步骤不够细而是他们拿到的原始条件和我不一样。比如我写的是模拟环境下的压力测试他们实际想要的是生产环境下的压测方案虽然方法论相似但他们实际操作时没有合适的模拟环境。这时我要做的不是解释方法论是通用的而是补一篇没有模拟环境时怎么做压测的内容把数据采集和推导过程写清楚帮读者在受限条件下也能得出相对可靠的结论。复盘的真正意义不是看阅读量涨了多少而是从读者的提问和反馈中找到你没讲透的地方。读者的每一个问题都是下一篇内容的标题。6.2 六个月后再读自己的旧内容我还有一条个人习惯每隔几个月翻出自己写过的一篇旧内容以读者的视角重新读一遍。这个方法特别照妖镜——自己能清楚地看到当初那段自以为讲明白了的配置说明其实跳过了好几处关键细节那个简单来说的步骤其实并没有那么顺。发现问题之后我会把旧内容更新一遍重新发布。这就是内容复利——一篇干货不是写完就结束了每一次复盘和迭代都会让它更干、更有价值。做过几个轮次更新的内容它们的质量一定比自己写完就丢的那些高出一大截。另外每次复盘后我会顺手记一个小本本这个阶段读者最常问的五个问题、最容易卡住的三个环节、最让我意外的一个使用场景。这个小本本不断积累就是你后续内容选题的富矿也是一个博主从普通写手逐步积累经验池的过程。7. 干货包装成分享而不是说教机会在细节里关于干货的最后一个问题我觉得值得单独拉出来聊聊为什么有些干货内容读者明明知道有用却不爱看因为写作姿态不对。你一眼就能看出什么内容是在分享什么内容是在教育读者。分享的姿态是我来告诉你我是怎么做的哪里做成了哪里没做成你参考着看。说教的姿态是你应该这么做不应该那么做。前者让读者觉得你把自己踩过的坑摊开来给他们看后者让读者觉得自己是学生正被人拉开黑板。我自己写内容时有两个具体技巧多用我而不是你写我在这里卡了半小时原因是什么比注意这里很容易出错更容易让人听进去。你分享自己的经历读者自然会对号入座你直接给指令读者反而会抵触。保留失败和意外我会把第一个版本为什么不行、第二个版本改了什么、最终结果如何完整地写出来而不是只写最终成功的版本。失败和意外的价值在于它们让成功的步骤显得更可信同时也告诉读者你如果一次没做对不是你的问题这个过程原本就需要折腾。我自己写内容有一条默认的原则**我可以展示我在某个问题上花了多少冤枉时间但要确保读者读完之后不需要再花同样的冤枉时间。**这就是干货的真正的含义——帮读者把弯路走直然后让弯路成为内容的一部分而不仅仅展示一条终点的路标。