高信噪比写作

解决什么问题

一篇技术文档被读一半就关掉，往往不是因为信息太少，而是因为读者在找到答案前先撞上了三层废话：复述提问的开场、毫无信息量的过渡句、以及把同一观点换个说法讲三遍的重复总结。更隐蔽的浪费是结构本身——标题和列表看起来条理清晰，实际承载的信息量为零。

这个技能要解决的问题只有一个：让读者花 30 秒拿走核心结论，花 5 分钟拿走全部细节，中间每一秒都不浪费。压缩的是表达方式，不是信息量。

核心能力

倒金字塔结构。 任何超过 3 段的回答按固定顺序组织：先用 1-3 句直接给出核心结论，不铺垫；再用一张图或一个列表展示结论由哪几部分支撑，让读者决定要不要往下读；然后把细节挂在框架的对应节点下逐层展开；最后可选地说明边界条件。反例是 "这是一个很好的问题，在讨论 X 之前我们先了解一下 X 的历史背景"，正例是 "结论：用方案 B，原因有三，下面逐一展开"。

五条硬规则。

• 术语首次出现时在同一句话内给出解释，每个抽象概念后紧跟一个足够小的具体例子（一行代码优于一段代码）
• 显式标注信息性质：[事实] 可验证，[推断] 可能出错，[建议] 是主观判断，[关键] 漏掉会出错——[事实] 与 [推断] 混在一起是最危险的废话，因为它不占字数，占的是读者的信任成本
• 格式跟随信息形态：多对象多维度对比用表格，有依赖顺序的操作用编号步骤，因果推导用 A → B → C 推导链且每个箭头都要能被质疑，不跳步
• 只重组不删信息：低优先级内容降级到背景或附录，而不是删除
• 长度自适应：简单问题一句话答完，不套结构

废话黑名单。 明确禁止复述提问、空洞开场、无信息过渡、重复总结、对冲式含糊（"这取决于具体情况" 必须说清取决于哪个变量、取什么值时结论是什么）、礼貌性填充和同义反复。

技术文档模板。 针对四类常见文档给出顺序约定：API 文档把最小可运行示例放在参数表之前；设计文档要求先写否决理由再写入选理由；故障排查按现象 → 根因推导链 → 修复步骤 → 验证 → 预防组织；README 的快速开始必须能盲目复制粘贴成功。

适用边界

输出前有 4 问自检：前 3 行是否包含核心结论？有没有删掉后信息量不变的句子？[事实] 与 [推断] 是否会被读者混淆？每个表格和列表是否真的匹配信息形态，还是只是 "看起来有条理"？

两个反模式警告值得单独强调。一是过度结构化：3 句话的回答不需要标题和列表，结构本身也占带宽，为结构而结构就是新形式的废话。二是标注滥用：全文都是 [关键] 等于没有 [关键]，标注占比超过 20% 时需要重新审视。