有一次我把一篇讲 CDN 缓存的文章发给一个做设计的朋友。她读完后的反馈是：“每个字都认识，但不知道你在解决什么问题。”
那句话让我难受了很久。文章的技术内容没有错，命令和配置也都对，但它默认读者已经知道“为什么要缓存”“缓存失效会怎样”。对圈内人这是常识，对圈外人不是。
后来我开始有意识地练习“跨界写作”。目标不是把技术讲浅，而是让不同背景的读者都能理解问题和取舍。
先给场景，再给概念
我以前的开头经常是：“CDN 缓存是一种位于边缘节点的内容副本机制。”这句话准确，但没有画面。
现在的开头更像一个场景：
你更新了博客封面，刷新页面却还是旧图。过了十分钟再打开，它又正常了。这十分钟里发生了什么？
读者先遇到一个具体问题，再看到“缓存”这个词，理解成本会低很多。概念仍然要讲，但它出现在读者需要它的时候。
类比要有边界
类比很好用，但用不好会制造新的误解。比如把缓存比作“便利店库存”，能解释“为什么快”，却解释不了“为什么会过期”。
我现在用类比时会补一句边界：“这个比喻只适用于说明就近取货，实际缓存还有失效和一致性的问题，后面会讲。”这样读者不会把类比当成完整解释。
术语第一次出现时解释
技术文章里最容易出现的句子是“显然，只需要配置一下回源就行”。对作者显然，对读者不一定。
我的做法是：每个术语第一次出现时，用一句话解释它是什么、为什么在这里出现。不追求定义完整，只追求“读者能继续往下读”。
比如：
回源，就是 CDN 自己没有这份内容时，回到源站去取。它决定了缓存没命中时会发生什么。
一句话，够用了。
数字比形容词有用
“加载很慢”不如“首屏 3.2 秒”；“优化效果明显”不如“从 3.2 秒降到 1.1 秒”。数字让读者有自己的判断，也能看出条件是否适用于自己。
但数字也要给条件：什么网络、什么设备、样本多少。没有条件的数字，和形容词差不多。
结论前置，过程放后
技术作者习惯按“背景—方法—结果”写，读者却常常只想知道“这和我有什么关系”。
我现在会在开头用两三句话给出结论和适用条件，再展开过程。想深入的读者可以继续看，只想了解结论的读者也不会被挡在门外。
不牺牲准确性
跨界写作最大的风险，是为了“好懂”而丢掉条件和边界。
我给自己定了两条底线：
- 不省略会影响结论的条件，比如“在静态站点、低并发的前提下”；
- 不把一次经验说成普遍规律，尤其是性能和成本相关的内容。
好懂不等于不严谨。真正好的解释，是让读者知道“这个结论在什么范围内成立”。
找一个人试读
每篇偏解释性的文章，我会找一个不写代码的朋友试读，只问三个问题：
- 这篇文章在解决什么问题？
- 哪一段你跳过了？为什么？
- 有没有哪个词你不知道什么意思？
他们的回答经常指出我完全没意识到的问题。有一次，一位读者卡在“反向代理”上，我原以为上下文已经解释清楚了，实际上并没有。
最后
跨界写作不是为了讨好所有人，而是为了让有价值的技术判断被更多人理解。
技术博客的读者不只有工程师。产品、设计、运营，甚至只是好奇的朋友，都可能读到你的文章。把门槛降低一点，不会让内容变浅，反而会逼自己把问题想得更清楚。
能把一件事讲到外行听懂，通常说明自己真的懂了。