第2355篇：技术写作对工程师的复利效应——用文字建立影响力的方法论
第2355篇：技术写作对工程师的复利效应——用文字建立影响力的方法论
适读人群：有意愿建立个人技术影响力的工程师 | 阅读时长：约12分钟 | 核心价值：技术写作的真实价值，以及如何从零开始建立写作习惯
2022年初，我在公众号发了第一篇技术文章。当时的想法很简单：整理一下我自己学的东西，方便以后回看。
那篇文章发出去一周，阅读量87，其中可能有三十个是我自己反复看的。
我没有想到的是，两年半后，这个公众号成了我职业发展最重要的资产之一——不是因为流量，而是因为它带来的东西：陌生人因为一篇文章找到我讨论技术问题，某家公司的技术总监说他看了我的系列文章决定联系我，我在一个会议上介绍自己时不需要说很多话，因为对方可能已经看过我写的东西。
这就是复利。
为什么大多数工程师不写作
我问过很多工程师为什么不写技术文章，得到的答案集中在几类：
"我写的东西没什么价值，都是基础的。"
这是最常见的误区。你认为"基础的"东西，对于刚踩到这个坑的人来说，可能是救星。我写过一篇《Spring Boot接入向量数据库时遇到的五个坑》，在我看来只是工作中的记录，但这篇文章的搜索流量持续了一年多，因为踩这些坑的人太多了。
你不需要写出"前沿研究综述"或者"深度架构设计"才叫有价值。你解决了一个真实问题，把过程写下来，就是价值。
"我文笔不好，写出来不好看。"
技术写作不是文学写作。技术文章的评判标准是：信息是否准确，结构是否清晰，读者能不能快速找到他需要的东西。文采是加分项，不是前提条件。
"我没有时间写。"
这个理由其实是在说"我还没有把写作视为对自己的投资"。一篇2000字的技术文章，认真写需要2-3小时，但它能在接下来的一两年持续产生价值。时间投入是一次性的，收益是持续的。
技术写作的真实价值
写技术文章到底有什么好处？我来讲几个具体的。
帮助自己真正理解一件事
费曼学习法说的是：如果你不能把一件事解释给别人听，你其实没有真正理解它。
我有很多次的经历是：我以为自己理解了某个概念，开始写文章，写到一半发现我其实没搞清楚其中一个细节，然后去补了这个细节，理解才真正闭环。
写作是最好的"理解检验器"。
建立可搜索的技术档案
你现在写的每一篇技术文章，都是在帮未来的自己。一年后你可能会遇到同样的问题，你直接搜自己的公众号就能找到答案。我用这个方法"救"了自己好几次。
建立技术信誉
在互联网上，文章是你的名片。当你在某个技术领域持续输出内容，你会被这个领域的人看到。这种被看到，往往会带来意想不到的机会：合作邀请、工作机会、演讲邀请。
不要小看这种"被动曝光"的价值。人脉不只靠主动维护，还靠内容沉淀。
获得读者反馈，拓展视野
读者的评论是非常好的学习资源。每次我发了技术文章，都会有读者在评论区指出我没考虑到的情况，或者分享他们不同的解决方案。这些反馈让我的认知持续扩展。
从零开始：如何找到写作题材
这是工程师最常问我的问题。
方法一：写你今天解决的问题
你今天花了三个小时排查了一个诡异的bug，最后找到原因了——这就是一篇文章。
题目就是：《[描述问题的一句话]——排查过程和解决方案》
把问题描述清楚，排查过程记录下来（越详细越好），最后是根本原因和解决方案。不需要很长，1500字就够。
方法二：写你学到的一个新概念
你最近在研究RAG，今天搞清楚了HNSW索引是怎么工作的——这就是一篇文章。
题目就是：《HNSW索引是什么——用直觉理解向量搜索的核心算法》
把你理解这个概念的过程写出来，用你自己的语言解释，加上代码示例。
方法三：写你踩过的坑
你用LangChain开发时踩了三个大坑，花了不少时间才解决——这就是一篇文章。
题目就是：《LangChain开发的三个常见坑和解决方案》
这类文章搜索流量往往很好，因为踩坑的人多，搜索"xxx坑"的人多。
方法四：写你的工作流
你有一套处理AI项目评估的工作流，你觉得比较有效——这就是一篇文章。
题目就是：《我用来评估RAG系统效果的评估框架》
把你的方法论写出来，有步骤、有例子。
好文章的结构
我总结了一个对我有效的技术文章结构：
技术文章结构模板
├── 开头（引出问题）
│ └── 一个真实的、读者会有共鸣的情景
├── 为什么这个问题值得关注
│ └── 说清楚重要性，让读者有继续读的动力
├── 核心内容（由浅入深）
│ ├── 基本概念（读者的起点）
│ ├── 核心知识（文章的主体）
│ └── 深层细节（给想深入的读者）
├── 实际应用
│ └── 代码示例或实战场景
└── 总结和延伸
└── 关键点提炼，以及下一步可以去哪里深入关于文章开头
技术文章最忌讳的开头是"本文将介绍XXX的原理和应用"。这句话让读者知道这篇文章是教科书，而不是一个工程师的真实经历。
好的开头从一个场景出发：
"上周我在生产环境排查一个延迟问题，发现P99延迟突然从200ms跳到了1500ms，但P50没有变化。这种现象通常意味着……"
这样的开头，有场景，有数字，有问题，读者会想知道后面发生了什么。
关于代码示例
能加代码就加代码，而且要加真实能跑的代码，不是伪代码。
真实代码有两个好处：一是读者可以直接用，二是说明你真的做过这件事，不是在复述别人的内容。
持续写作的系统
写了一篇两篇容易，难的是持续写。
建立选题库
我有一个简单的Notion页面，专门记录选题。每次遇到一个值得写的话题，马上记进去。这个列表现在有几十个选题，不缺东西写。
设定写作时间
不要等"有时间了再写"。有时间了也不会写的，因为总有更紧急的事。
我的习惯是每周固定一个下午（2-3小时）用来写作。这个时间块是预约的，不被其他事情打断。
降低发布门槛
不要追求每篇文章都是精品。写够一定质量就发，发了之后读者的反馈会帮你进一步打磨。等到觉得"完美了"再发，很多文章会永远躺在草稿箱里。
复盘和迭代
每隔一段时间，看一下哪些文章阅读量高、反馈好，思考为什么。这能帮你校准写作方向——什么样的内容对读者最有价值。
写给还在犹豫的工程师
我见过很多工程师，技术能力很强，但在外部几乎没有任何可见度。当他们需要换工作、拓展机会的时候，只能靠简历，而简历上写的东西，怎么说都不如一篇被很多人认可的技术文章有说服力。
技术写作是一种杠杆。你花在上面的时间，会通过多种渠道持续给你回报——学习深度、人脉、机会、影响力。
但这个杠杆是有时间延迟的。你写了六个月，可能没什么人看；写了一年，可能开始有一些读者；写了两年，回头看，你会发现已经积累了一个别人没有的东西。
复利的本质就是：前期看不出来，时间足够长了才知道有多值。
开始吧。今天就开始。第一篇文章不需要好，只需要存在。