21 · 证据的层级：数据 > 案例 > 类比 > 主张
你写过这种句子吗：
“限流非常重要，我们必须重视。”
读者看完，心里一句：“凭什么？”
你没给理由。这就是只有主张，没有证据。主张是”我说它重要”，证据是”它为什么重要”。没有证据的主张，读者默认不信——不是因为你不可信，是因为人的脑子对”无证据的断言”有本能的防备。
反过来，你写：
“我们不设限流，去年大促一次突发流量打满连接池，全站 40 分钟不可用，损失订单 200 万。加了令牌桶限流后，同样的突发，只拒绝 5% 的请求，核心链路没挂。”
读者：信了。因为你给了案例 + 数据。
这章讲一个写作者必须刻进骨子里的东西：证据有层级。你扔什么级别的证据，决定读者信到什么程度。用错层级，再对的论点也显得空。
一、先问对问题：读者为什么不信”空主张”？
先理解读者的防备从哪来。
读者每天被无数断言轰炸：“这个方法最高效""这个框架最先进""这个一定要用”。大部分没证据。他学会了：听到断言，先打折。打折到什么程度？取决于你后面跟的证据。
- 你只说”重要” → 他打一折（“又来了”）。
- 你给个案例”我上次崩了” → 他打五折（“你那是特例吧”）。
- 你给数据”崩了 40 分钟损失 200 万” → 他打八折（“有数，信”）。
- 你给数据 + 机制”损失 200 万，因为连接池满后新请求阻塞，雪崩” → 他全信。
所以证据层级，本质是读者信任的刻度尺。你每抛一个主张，得配够级的证据，否则主张悬空。
反问你：你写东西，主张和证据的比例是多少？是不是”主张多、证据少”，甚至”只有主张”？读者给你的信任折扣，你猜打了几折？
二、原理：四级证据，从弱到强
把证据排个序，从弱到强：
主张（最弱） < 类比 < 案例 < 数据（最强）
第四级 · 主张（assertion） “限流很重要。""这个方案更好。” 只有你的话。不可证伪、无支撑。读者防备最强。 用途：作为”论点标题”可以，但绝不能作为”唯一支撑”。每个主张下面，必须垫更硬的证据。
第三级 · 类比（analogy） “限流像水库闸门，洪峰来了关小点。” 帮理解，但不证真（第二十章讲过类比只是桥）。读者觉得”哦我懂了”，但不等于”哦你说的对”。类比在证据链里排第三，弱。
第二级 · 案例（case） “我们去年大促没限流，崩了 40 分钟。” 真实发生的事。比类比硬，因为”真出过”。但案例是个例，读者会质疑”那是你特殊情况吧”。所以案例强于类比，弱于数据——除非案例足够典型且多。
第一级 · 数据（data） “崩了 40 分钟，损失 200 万；加限流后同突发只拒 5%。” 可量化、可证伪、可复现。数据最强，因为它不依赖”你信不信我”，而依赖”数字摆在这”。读者没法用”特例”搪塞数字。
关键规律：越靠下的证据，越’客观’、越难反驳；越靠上的，越’主观’、越易被打折。
所以写作的铁律：
核心论点，用数据 + 案例垫底；辅助说明，可用类比；主张只能当’论点标签’，不能当’唯一证据’。
三、每个论点，配够级的证据
不同重要度的论点，配不同级别的证据：
核心论点（你最想让读者信的）：数据 + 案例双垫。
论点：“高并发必须限流。” 证据：案例（我们崩过 40 分钟）+ 数据（损失 200 万、拒 5% 保住核心）。双保险，读者全信。
次级论点（支撑核心的）：案例或数据其一。
论点：“令牌桶比漏桶适合突发流量。” 证据：数据（令牌桶允许突发 100 请求/秒，漏桶恒定 50，突发场景令牌桶不误杀）。一个数据够。
辅助说明（帮理解的）：类比。
“令牌桶像电影院进场，平时匀速放人，但攒了一批票可以一次性放行（突发）。” 这是帮懂令牌桶，不是证令牌桶好。类比放这层正好。
论点标签：主张。
“限流很重要。“——这句话如果独立成句当证据，弱；但如果它是”小标题”，下面垫着数据案例，就只是概括，没问题。
很多人犯的错：把核心论点只配主张（“限流很重要，我们要做”），读者打一折。核心论点必须下沉到数据。
四、反例：三种证据错位
错位一：主张当证据（最普遍）
“我们的架构非常优秀，值得推广。” “优秀”是主张，没证据。读者：凭啥优秀？补数据：“QPS 提升 3 倍，成本降 40%，故障率从月均 3 次到 0。“——主张才有底。
错位二：类比当结论
“微服务像乐高，所以微服务一定好。” 类比（乐高）不能证结论（微服务好）。这是用第三级证据证核心论点，读者不信。该用数据：微服务后部署频率从周级到日级、故障隔离率提升 X%。
错位三：案例孤证推普遍
“我朋友公司用单体，后来崩了，所以单体不行。” 一个孤例（第二级）推普遍结论（第一级才配），逻辑跳。要证”单体不行”，得多个案例或数据对比（单体 vs 微服务故障率统计）。孤例只能”钉教训”，不能”证规律”（第十八章讲过）。
五、怎么给你的论点”找证据”？
写之前，对每个核心论点问：“读者凭什么信这句？” 然后去找对应级别的证据。找不到数据，至少找案例；找不到案例，至少给类比 + 明确说”这是机制推断，待验证”。
找数据的来源：
- 你自己的监控/日志（最硬，因为是你的真实数字）。
- benchmark（压测结果）。
- 业界公开数据（大厂复盘、论文）。
找案例的来源：
- 你踩过的坑（真实，信服度高）。
- 业界知名事故（AWS 宕机、GitLab 误删库等，读者有印象）。
找类比的来源：
- 读者生活里的心智模型（第二十章四步法）。
实在没证据时，诚实降级：
“我认为该限流——机制上，不限流突发会打满连接池（推断），但我们还没实测数据，建议先灰度观察。”
这比硬说”限流很重要”诚实，读者反而更信（因为你承认证据级别）。
六、一个改写示范：从空到实
原稿（主张堆砌）：
“性能优化非常重要。我们要重视缓存。索引也要建好。代码要写得高效。这些都是最佳实践。”
四句主张，零证据。读者打一折，划走。
改写（证据垫底）：
“性能优化不是口号，是钱。
缓存：我们没加缓存前，商品详情页查库 200ms，QPS 到 500 就超时；加 Redis、命中率 92% 后，降到 8ms，QPS 扛到 8000。一个缓存，省了三台数据库服务器。
索引：订单表按
user_id查，没索引时全表扫 300ms；加索引后 B+ 树定位 <1ms。慢查询从日均 2 万条降到 20 条。这两件事，靠的是机制（减少慢源访问），不是玄学。数据摆这，你信不信由你——但数字不会骗人。”
主张（“性能优化重要”）被降级成标题，下面垫满数据 + 机制。读者：信了，而且记得住那几个数字。
七、心法：论点要站住，证据得够硬
这章心法：
你每抛一个主张，读者心里都在称重。你给的证据越硬，他称得越重；你只给主张，他直接扔回给你。
写作不是”把我想的写出来”，是”让读者不得不信”。让读者信，靠的不是你语气多肯定（“非常重要！必须！“反而显得虚），靠的是你垫在下面的证据硬不硬。语气越肯定、证据越空的文字，读者越防备——他分得清”自信”和”有料”。
所以下次写完一段，做个动作：把每个”非常重要/必须/很明显”圈出来，问”这句下面有够级的证据吗？” 没有，要么补证据，要么把语气下调成”我推断/建议”。
反问你：你写东西，是”先有证据再下结论”，还是”先下结论再补（或忘了补）证据”？后者写出来的，就是满篇”非常重要”的空文。
八、思考题
思考题一： 给论点”代码评审能减少线上 bug”，配齐四级证据：一条数据、一个案例、一个类比、一句主张（作标签）。注意各自放对层级。 思考题二： “孤例能不能证规律”？什么情况下案例可以升级到接近数据的可信度？ 思考题三： 为什么”语气越肯定、证据越空”的文字，读者越防备？你有过被这种文字劝退的经历吗？
九、参考答案
思考题一：
主张（标签）：“代码评审值得做。” 类比（帮懂）：“评审像出厂质检，每辆车下线前过一遍，免得路上爆胎。” 案例（次硬）：“我们团队引入评审前，线上 bug 月均 15 个；引入后降到 4 个。其中一次评审拦住了一个会把余额清零的 bug。” 数据（最硬）：“统计半年：评审拦截了 73% 的潜在线上缺陷，人均每周多花 40 分钟评审，换来故障率降 73%。ROI 明显。”
主张当标题，类比帮懂，案例+数据垫底。层级正确。
思考题二：
孤例不能证普遍规律（逻辑上是个例≠规律）。但案例在两种情况下可信度接近数据：① 案例足够典型且读者高频遇到（“你也这样过”→从孤例变”类例”）；② 多个独立案例指向同一结论（三个不同公司都因无评审出过资损 bug→汇成”模式”）。单个案例永远只能”钉教训”，多个案例/数据才能”证规律”。
思考题三：
读者本能区分”自信”和”有料”。语气肯定但无证据，像销售拍胸脯”绝对没问题”——越拍胸脯越像要跑路。有料的人不需要喊，数字自己说话。我被劝退的经历：某技术文通篇”毫无疑问""必然""最佳实践”，翻到底没一个数据，我关了。反过来，一篇只列 benchmark 数字、几乎不评价的文，我反而信。语气是虚的，证据是实的。
十、动手练习
- 找一篇你写过的文档，圈出所有”非常重要/必须/很明显/最佳实践”这类主张，给每句补一个够级的证据（数据或案例）。补不出的，把语气降成”我推断/建议”。
- 给你一个核心论点，按”主张（标签）+ 类比 + 案例 + 数据”四层各写一句，排好顺序，看读者信任刻度怎么爬升。
- 故意写一段”全是主张、零证据”的文字，再改成”数据+案例垫底”版，对比读者体感。
自评标准：
- 核心论点下面垫的是数据或案例，不是只有主张 → 层级过关。
- 类比只出现在”帮理解”层，没越界当结论 → 分工过关。
- 找不到证据的地方，诚实降级成”推断/建议”，不硬撑 → 诚实过关。
十一、小结
- 证据四级：主张 < 类比 < 案例 < 数据。越靠下越客观、越难反驳。
- 核心论点用数据+案例双垫；辅助说明用类比；主张只能当标签，不能当唯一证据。
- 三种错位：主张当证据、类比当结论、孤例推普遍。
- 找不到证据就诚实降级（“我推断，待验证”），比硬撑可信。
- 心法：论点要站住，证据得够硬。读者给主张称重，你垫的证据决定分量。
十二、实战加深：证据自查清单与数据来源
写完一段，拿这张单子过：
- 每个核心论点下面，垫的是数据或案例吗？（不是只有”非常重要”？）
- 类比只出现在”帮理解”层，没越界当结论？
- 孤例有没有标明”这是特例，待更多验证”？
- 主张（“我认为/应该”）有没有降级成”我推断/建议”当证据不足时？
四问全过，你的证据层级就站住了。
数据从哪来（别编，去找）：
- 你自己的监控/日志：最硬。Prometheus、 Grafana 导个数，比”我觉得快了”强一万倍。
- benchmark：你写段压测，
go test -bench，数字说话。 - 业界公开复盘：大厂事故报告、论文数据。读者认。
找不到数据，至少给案例（你踩的坑）；找不到案例，给类比 + 诚实标注”机制推断，待验证”。绝不空抛主张。 空主张是写作里最廉价的，读者一眼识破。
十三、主张密度自检
一个反直觉的指标：一篇文里”非常重要/必须/很明显/毋庸置疑”这类词越多，越空。
这些词是”主张放大器”——你越喊，越暴露底下没证据。自检：圈出全文所有这类词，每个下面如果垫不上数据/案例，就把语气降一档（“非常重要”→“我建议重视”，“必须”→“通常该”）。降完，文章从”喊”变”说”，读者反而更信——因为他感到你在对自己诚实，而不是对读者施压。
记住：语气是虚的，证据是实的。你越肯定越空，读者越防；你越实诚（“我推断，待验证”），读者越信。
十四、附：证据在代码周边文字里
证据层级不只用于长文，你写的报错信息、注释、commit也是证据现场：
- 报错信息：烂报错是”主张”（“error occurred”，零证据）；好报错带数据/案例（“order.Create: user_id empty, got ””）。报错是给未来求救者的”证据”，越具体他越少熬。
- 注释：烂注释”这里处理错误”（主张）；好注释”这里必须返回 error 而非 nil，因为上次吞错导致下游假成功”（带反面案例）。注释里的证据，让接手人懂”为什么这么写”。
- commit：烂 commit “fix bug”（主张）；好 commit “修复连接池耗尽不报错：此前 pool.Exhausted 仍往下走致请求堆积，现改为立即返回 ErrPoolExhausted，并在 Metrics 暴露等待数”（案例+数据）。reviewer 一眼信。
代码周边文字，因为”短”，更容易滑成主张。但越短越该有证据——读者在紧急 debug 时扫一眼，没证据的报错他得自己查半小时。你多写半句证据（哪个字段、什么值），他省半小时。这是证据层级在代码里最实在的回报。
数据诚信警示： 你引数据，必须真。编个”损失 200 万”凑震撼，被懂行读者拆穿，信任归零，且这信任是你整个作者信用的破产。数据宁可保守（“损失数十万”），不可虚高。证据的可信，建立在”你从没编过”上。
证据链：一层托一层（实战加深）
单个证据不够，要成链。最高明的论证不是”甩一个数据砸晕你”，而是让证据像梯子——读者踩着每一级都稳，自然走到你的结论。
看一段只有主张的文字：
微服务很好。它能提升开发效率，增强系统稳定性，还方便团队扩张。所以我们应该把单体拆成微服务。
这句话里四个断言（提升效率/增强稳定/方便扩张/应该拆），没有一条有证据。读者凭什么信？因为这是”行业共识”——但共识不等于论证，写出来仍然是空的。
搭成链：
我们单体应用一次发布要 20 分钟，因为要全量编译和回归（数据）。去年双十一，一次全量发布失误导致核心交易停摆 40 分钟（案例）。如果拆成订单、支付两个服务，故障域就从”整个交易”缩小到”单个服务”（类比：把一间大屋隔成两间，着火只烧一间）。数据 + 案例 + 类比三层托着，结论”值得拆”才立得住。
注意层级顺序：先数据（最硬），再案例（最具体），最后类比（帮理解结构）。不要反过来——拿类比去证明数据，那是本末倒置。
反面改写实战
把这句”应该学 Rust，因为它内存安全又高效”补成证据链：
- 数据：Rust 的借用检查器在编译期拦截了某类漏洞，某报告显示此类漏洞占内存安全问题的 X%；
- 案例：某团队迁移动态语言服务到 Rust 后，生产环境内存相关故障从每月 N 起降到 0；
- 类比：Rust 把”运行时才可能发现的错误”提前到”编译时就拦下”，像质检从出厂抽检变成原料进场全检。
三样齐了，主张才从”我觉得”变成”有理由信”。
证据的”反向”思维（实战加深）
搭证据链时，反向想一步能避坑：你的结论，什么证据能”推翻”它？
如果”引入队列能解耦”——反证是”队列引入后故障域没缩小，反而多了消息丢失风险”。把这个反证主动写出来并回应，你的论证比只摆正面数据硬十倍。读者会想”他料到了我会质疑”。
实战：给你任一主张，先写”什么能推翻它”，再写”我怎么防”。主张 + 反证 + 防御，才是完整证据链，不是单方面吹捧。只摆正面证据的论证，读者潜意识里会觉得”太顺了，像推销”——你主动暴露反例，反而显得客观可信。
证据与密度的关系：证据链每加一层（数据→案例→类比），密度上升，但篇幅也涨。所以只在该”硬”的论断上堆证据，辅助论断一句话带过。全篇都硬 = 全篇都重 = 读者抓不住重点。证据要像盐，关键处够咸，别每句都撒。
综合实战：把”主张裸奔”的段落补成证据链
原段落（只有主张）：
“我们的新架构很稳定，性能也很好，团队开发效率提升了。所以应该全面推广。”
四个断言全裸奔。补证据链：
断言一”稳定” → 补数据 + 案例：“新架构上线半年，P0 故障从每月 3 起降到 0（数据）；去年一次全量发布失误停摆 40 分钟，拆分后故障域缩小到单个服务（案例）。”
断言二”性能好” → 补数据：“核心接口 P99 从 800ms 降到 120ms（数据）。”
断言三”效率高” → 补数据 + 类比：“单次发布从 20 分钟降到 3 分钟（数据）；就像把’全屋装修’改成’单间改造’，影响面小了，速度快了（类比）。”
断言四”应推广” → 这是结论，由前三层托着：三个论断都有证据，结论”值得推广”才立得住。
反向验证：什么能推翻”应推广”？“迁移成本过高”或”旧系统迁移风险大”。主动补一句：“迁移分三批灰度，每批观察一周（防御）。” 主张 + 反证 + 防御 = 完整证据链，不是单方面吹捧。
跑完这遍，原段从”我觉得”变成”有理由信”。你以后写任何论证，都照这模板：断言列出来 → 逐条补证据 → 反向找反证 → 防御。
心法卡：
证据分四级：主张<类比<案例<数据。
核心论点，数据+案例垫底。
类比帮懂，不当结论。
主张只是标签，别当证据。
读者称重量，你垫的证据定分量。
第四卷·素材篇四章讲完：案例选择、故事钩子、类比力度、证据层级。下一卷进入”打磨篇”——开头怎么钓、结尾怎么收、重写怎么动结构。这是把前面所有功夫，在成稿上做最后一遍校阅。