关于写作
莱斯利·兰波特有一句话被反复引用：”If you’re thinking without writing, you only think you’re thinking.”
这句话的重量，我在管理开源社区和 AI 基础设施项目的过程中，感受越来越深。
我见过很多工程师，代码写得非常好，方案设计得相当精妙，但一旦要把想法落成文字，就开始模糊、绕圈、或者干脆写不下去。这不是表达能力的问题，而是思考还没有完成。
写作是思考的外化过程，不是结果的搬运工。你以为已经想清楚的东西，写下来的那一刻才知道有多少漏洞。
在 RFC 评审和设计文档拉通的场景里，我见过太多这样的情况：方案当面聊得头头是道，文档写出来却破绽百出。不是因为工程师能力不够，而是口头沟通有太多隐性补丁——对方的点头、追问、语境共识，都在填补逻辑空洞，而文字必须自洽。
在开源社区里，写作的重要性还有另一个维度：影响力的延伸。
一个 issue 写得清不清晰，决定了社区成员是否愿意跟进。一篇 ADR（Architecture Decision Record）写得好不好，决定了三年后的维护者能不能理解当年为什么做这个决定。代码会被重构，文档才是组织记忆的载体。
维护开源项目的时间越长，我越觉得：写作能力是工程师职业天花板的核心变量之一。能把方案想清楚的人，都能写清楚——不是说写得多么文学，而是逻辑完备、边界清晰、把读者当成第一次接触这个系统的陌生人来对待。
近一年主导 AI Agent 基础设施建设，我发现写作还有一个更隐蔽的价值：它是控制 AI 协作质量的锚点。
给 Agent 写 prompt、写 harness 配置、写工具调用规范，你会发现——你写得越清楚，Agent 的行为越可预测；你写得越模糊，Agent 的输出就越像薛定谔的猫。AI 时代不是减少了对写作的需求，而是把写作的精度要求拉高了一个数量级。
我自己写博客没有固定计划，也不追求更新频率。写是因为有东西想说，或者有什么没想清楚、想借写来想清楚。不会为了”保持输出”而硬写，那种文章对自己是负担，对读者也是噪音。
如果你刚开始写技术博客，我只有一个建议：不要从”分享知识”出发，先从”把自己弄懂”出发。写清楚一件你刚刚搞懂的事，比写一篇你”都懂”的综述，对自己的成长有用得多。