如何写好一篇技术文章？

文字是我们感知世界的方式。

今天分享一下关于如何写好一篇技术播客的文章，这位作者总结的还是非常全面和到位的。

为何要写技术博客

关于这个问题，已经有很多大佬给过建议了。对于我个人来说，写技术博客主要有以下几个出发点。

加深知识理解和掌握

程序员群体很多都挺爱学习，大家经常在工作之余看些技术书籍，刷一些公开课来开拓视野，提升技术水平。不过仅仅有“输入”其实是很难真正掌握一些知识的，我们需要结合各种方式的“输出”来验证自己所学的知识，比如动手实现一些原型，在公司项目中进行应用，或者做一个分享，写一篇博客来将这个新知识讲述给别人。当你在撰写技术博客时，会更加立体地去思考技术点背后的“What，Why，How”，很多读书过程中没有想到的细节，或者背后潜藏的发展历程故事，都会在撰写过程中去不断挖掘完善。所以很多时候我们也会说，做分享其实收益最大的并不是听分享的人，而是做分享的。

完善个人“技术地图”

大家在工作几年后，逐渐会进入到某些特定的领域进行深入的发展，在这个领域中可能有许多相关的技术内容，背后有千丝万缕的联系，而一系列的技术博客也是帮助我们整理，完善这些技术点，进行更高层次的思考和融会贯通的一种途径。一个比较有意思的例子是大数据和分布式系统领域的神书《数据密集型应用系统设计^[2]》，书中附带了很多关于这个领域的“技术地图”，非常的高屋建瓴。后续有新技术的出现，我们也可以“映射”到这幅地图上去做整体性的思考，利用已有的积累和框架去快速理解新事物的差异点和创新之处。持续积累了一定数量的高质量博客后，我们还可以考虑出一本书，进一步扩大影响力 :)

提升写作与沟通能力

这方面的能力对于技术人员的职业发展也是相当有帮助，之前在我的 资深工程师之路系列^[3] 中也有所介绍。做项目不光光是架构设计，代码实现，测试，发布运维这些偏技术的内容，也非常需要项目意义的阐述，业务需求的沟通，架构设计的讨论与宣导，项目应用的推广与运营等跟沟通紧密相关的重要环节。无论你想成为独当一面的技术大牛，还是带领团队的 tech lead，写作沟通都是非常重要的技能，需要持续投入，刻意练习。

拓展人脉圈

个人的力量总是非常有限的，而如今的技术发展又是日新月异，高速迭代。很多时候与其他专家的交流探讨能大大提升你对某些技术领域的理解，甚至在公司急需某个方向专业人才的时候还有机会可以直接邀请大佬的加入，一起干一些大事 :) 运营优秀的个人/公司技术博客或开源项目，是一种非常好的打造技术品牌的方式，大佬肯定是更喜欢跟高水平的同僚探讨合作的嘛。

生活记录

当然也有很多技术人也会写一些生活化的博客文章，比如 pluskid 大佬的博客^[4] 里就有很多旅行，绘画，读书等方面的内容，读起来也是精彩纷呈。平时写写博客记录生活，抒发情感也是一种很好的消遣方式，说不定以后我也可以尝试一下 :)

如何写一篇技术博客

这个部分，我们主要来介绍一下写一篇技术博客的整体流程一般是怎么样的。

明确主题

比较常见的技术博客选题方式有几种：

1. 针对工作领域体系性的技术介绍。例如作为算法工程师，可以系统性地介绍所在业务领域的常见模型，他们的发展历程，背后的关联，优缺点等。后端开发也可以从各类框架工具，架构设计，系统组件等方面来选择相关的主题。这些选题可以和你个人的工作规划紧密的结合起来，例如这个季度打算做系统的云原生改造，那么就可以集中火力调研一系列这个方向的技术话题，并总结成文章。对于自己熟悉的技术，可以做深入剖析，或者做更高维度的提炼总结；对于一些不熟悉的新技术，也可以边学习，边记笔记，后续整理成博客文章。
2. 实战中碰到的疑难杂症的记录。个人还挺喜欢看这类 debug 相关的文章，尤其是那些隐藏很深，难以复现的复杂问题，可以通过高超的工具和技术层层抽丝剥茧，定位到根因并加以解决的经历过程。如果说技术介绍的文章读起来像说明文的话，那么这种类型的文章就很像引人入胜的小说了。这类文章如果解决的是一类大家经常碰到的问题，被搜索访问的点击量也会比较高。
3. 技术史话，人物传记，技术圈八卦的故事型文章。比较典型的代表有吴军老师写的《浪潮之巅》，飞总早年写的 大数据那些事^[5]，还有最近看到的 OneFlow 的专栏 科技星辰^[6] 等。这种类型的文章要写的好，一般都是大佬级选手了，需要在行业积累了足够的经验和视野，经历了技术发展的跌宕起伏，才能把控得游刃有余，读起来也是非常引人入胜。
4. 还有一类很受欢迎的文章是“导航型”或者“经验分享型”的。例如我之前写的 算法工程师技术路线图^[7]，可能因为大家都或多或少有点“收藏就等于看过”，“看了一堆目录就等于全都看过”了的心态吧 :) 这种类型的文章受众也会比较广，很容易获得高点击量，不过对于写作者自身来说提升帮助并没有那么大。
5. 外文资料的翻译和解读。有很多优秀的一手技术资料都是以英文形式出现在互联网上，例如顶级的学术会议，开源项目或者大公司组织的开发者大会，推特，HackerNews 上的一些新的文章和讨论，高质量的外文播客等等。我们也可以结合自身的一些经验，将这些内容翻译，搬运到国内的博客平台上。

大家可以根据自身喜好来进行选择，平时工作中也可以多留意可以总结提炼的知识点，后续汇聚成文。

调研学习

个人习惯在确定主题之后，先做一番已有相关文章的调研学习。比如在知乎，Google 上搜索一下中文世界中已有的相关文章，看看他们已经覆盖了哪些内容，深度和广度如何，是否有一些我们独有的认知没有被提到，读者有一些什么样的反馈建议等。如果发现已经有写的非常完善的文章了，个人无法作出多少额外的新贡献，我就会选择暂且搁置这个主题。无论是否继续撰写文章，整个调研过程也可以让我们学到不少新的东西。

素材积累

确定主题后，我们就可以开始着手做相关素材的积累，其中上一步的调研学习过程中，就可以把一些看到的比较好的资料记录下来。对于一些新的知识，这个素材积累的过程可能会持续一段时间，需要看更多的书，文章，视频等来不断丰富自己的理解。以我之前写的 走马观花 AutoML^[8] 为例，光看各种论文参考断断续续就花了 3 个月。养成了写博客的习惯后，我们就可以持续做这类的素材收集工作，对于平时的阅读学习来说也会更有目标性一些。

确定大纲

开始正式进入到撰写阶段，我们可以整体浏览一遍之前积累的素材内容，做一些区分归类，然后把文章大致的框架脉络确定下来，比如可以把各层级标题先写下来，或者画个思维导图。对于现代读者来说，大段的文字很容易让人失去耐心，所以逻辑条理清晰的分段分层非常重要。这其实跟写代码时做一些模块划分的设计类似，个人比较习惯这种 top-down 的方式，后续写具体内容也会非常自然流畅。写好大纲之后可以从初学者的角度带入来体会一下整体的阐述思路是否清晰易懂，避免后期的较大的返工修改。

完成具体内容

如果前面准备工作做的比较充分，这部分的工作总体来说会比较顺利，比小时候写 800 字的作文要轻松得多了有没有。而且这部分可以有很多的自由发挥空间，比如有些人喜欢通过讲故事的方式来做串联，有些人会穿插很多精美的插图来帮助理解，有些人相对平铺直叙，就会看起来比较“干”（比如我）。这里有个小建议是除非文章的主题跟代码或数学讲解强相关，否则不要在文中加入比例过高的代码和公式，尽量以具体的例子，配图等方式来简化一些复杂的概念，能更好的帮助读者理解核心思想。这里比较好的范例是专门讲解数学的视频博主 3B1B^[9]，用很多可视化的方式把很多复杂的数学问题都讲得十分清晰透彻。

除了正文内容，我们也可以在其中穿插一些思考题，小故事等，保持读者的注意力，增加互动机会。比如王喆大佬之前写的一系列推荐系统的文章中每篇最后都会提一些问题来引发大家的思考和讨论，效果也非常不错。

审阅优化

完成撰写后，先别急着发布，可以以读者的视角再从头到尾读几遍文章，或者找一些朋友帮忙先预览一下。一方面确认整体的阐述上没有明显的纰漏或者表达不清的地方，另一方面也对于各种错别字，排版样式等进行最后的复核检查。很多时候我都会把文章在草稿箱里搁置个几天，看看过程中有没有出现一些新的修改完善想法，可以及时做补充，毕竟很多平台发布之后就不允许大幅度的修改了。

发布与运营

最后就是把博客文章进行发布了，我们可以选择的发布平台也有很多，例如微信公众号，知乎，掘金，SegmentFault，简书，语雀，CSDN，博客园等，也可以利用 Github 或者自建站的形式。由于目前平台选项的繁多，所以我们一般不会直接在这些平台进行撰写，而是把撰写和发布“解耦”，在本地撰写文章，然后再选择不同的平台去导入发布，具体的操作会在后面的工具栈环节进行描述。目前我个人选择的平台是公众号和知乎，前者方便在朋友圈做做推广和在手机上阅读，后者相对来说社区质量还算比较高，可以与大家一同交流学习，另外阅读体验上来说也比较清爽。如果读者规模到了一定量级，自建站也是一种不错的选择。

另外就是对博客的推广运营了，这方面说实话我并不擅长，所以整体的关注者和阅读量都一直比较低迷。一些比较通用的运营方法包括在文章中添加版权信息，历史文章的索引，在不同的社群和论坛做文章宣传，选择合适的时间段进行发布等。另外对于各个平台也有自己专门的推广方式，例如知乎上可以选择关注量较大的问题来回答，相比写文章来说天然流量会更大些。此外知乎也提供了内容自荐等创作推广功能。而微信公众号则可以设置一系列的自动回复，自定义菜单，话题标签等，提升关注者的互动体验。

工具栈

最后一个部分，我们结合上面的写作流程来介绍一下个人感觉比较舒服的一套工具栈。

选题与素材管理

这部分的工作，我一般采用待办任务和笔记的方式来进行，主要使用的工具是 Notion。

对于选题，可以创建相关的任务来做管理。我对于自己的要求比较低，工作之余一个月能产出一篇差不多就可以了……

素材方面，可以利用一些 Notion 模板来将看过的东西做分类记录，后续在写作时通过 tag 过滤来统一浏览。一些零碎的点也可以直接记录在待办任务页面里。

文章撰写

主编辑器

为了在多平台进行发布，我们可以选择相对通用的文本格式，如 markdown 来进行具体的内容撰写。早期尝试过一些专用的 markdown 编辑器，如 Typora 等，但后来发现在文章比较长，链接和图片比较多的时候，Typora 的性能出现了很多问题，非常影响写作体验。后续经过一番调研，选择了 vscode^[10] 作为主要的编辑器。Vscode 的整体性能还是比较优秀的，几万字的文章编辑起来也完全不会有任何卡顿。另外 vscode 的插件体系也很强大，有一系列帮助提高我们撰写效率的工具，例如我个人比较喜欢的 Markdown Image 来支持图片的插入和自动图床同步，Pangu-Markdown 来做中文文本的自动格式化等。

云端同步

使用很多在线平台都可以支持自动的云端同步，这样我们就可以在不同的电脑上进行文章的撰写，也不用担心电脑 down 机导致的内容丢失问题。不过 vscode 本身并没有这样的能力，所以我们需要结合云盘来实现类似的功能。因为我购买了 Office 365 的订阅，所以也顺理成章用了 OneDrive 来作为我们的云同步服务。使用起来也非常的简单，只要把相关 markdown 等文件存在电脑的 OneDrive 目录下即可，撰写过程中一旦有文件新增或保存，都会做自动同步。

此外，如果需要多人合作写一篇文章，也可以在此基础上再引入 git 来做代码同步。当然这个方案从实时性上来说还是比不上很多在线协同文档软件，但对于创作周期较长的文章来说基本还可以接受。

图床

前面有提到 vscode 的 Markdown Image 插件，其中就支持很多不同的图床。使用图床而不是本地文件的好处在于，我们后续上传到不同平台时，不会出现 markdown 中的图像链接解析不出来的问题，否则的话就得一张一张图片重新上传，工作量还是比较大的。图床服务本来想用七牛，但注册审核方面貌似比较麻烦，最后还是采用了更简单一些的 CODING^[11] 来进行托管，然后在插件中配置一下 access token 基本就可以了，后续有任何想要插入的图片，复制后使用快捷键 alt + shift + v 即可。当然图片本身我还是会在 OneDrive 的同目录下也保存一份，以免后续有云服务失效图片找不回来的问题。

备注：很多在线笔记平台可以做到上面三个工具的全功能，比如语雀，Notion 等，所以直接使用这些平台理论上也是可行的。但需要注意评估一下 markdown 导出之类的功能是否完善，比如链接，代码，公式，图片，各种格式信息的导出是否完整且符合通用标准，避免后续出现难以迁移发布的困难。

绘图

很多时候我们还需要自己绘制一些结构图来更好的阐述相关内容，之前我一般用 ProcessOn^[12] 或者 draw.io^[13] 这类相对正式一些的在线绘图工具。后来一个偶然的机会接触到了 excalidraw^[14] 这个手绘风格的工具，就立刻被吸引住了。虽然提供的图形很少，但基本够用，而且效果也很有“个性”，挺适合博客这类非正式场合的配图的。另外它还有个优势是可以使用快捷键，下面这个示意配图基本可以在 2 分钟之内快速搞定。

有时候绘图中我们还希望加一些不同色彩的区分，一般来说各种网站预置的色板都比较丑，我们也可以从一些工具网站参考更现代美观的配色方案，例如 coolors^[15]：

如果代码内容不多，又对字体，排版有比较高的要求，还可以试试这个生成代码图片的 carbon^[16]：

发布

Markdown 排版

由于微信公众号有一些限制，比如不能带外链等，一般在导入到公众号草稿前我们还需要做一些排版工作。目前我用的网站是 markdown.com.cn^[17]，可以选择一系列模板，并做一些 css 格式上的微调。这个网站还可以一键把外链转成备注信息，这点尤其实用。如果你正在微信公众号上读这篇文章，拉到最后就能看到效果 :)

值得一提的是，微信公众号的文章编辑页面自带了错别字检测功能，我在发布到其它平台之前也会用这个功能先做一下大致的检查。

题图资源

不同网站在做发布时可能还需要一些额外的操作，标题，简介这些常规的还是比较好搞定的，不过题图这个就稍微有些难度了。我目前一般会直接在正文配图中挑选一张，或者去 Unsplash^[18] 上搜索相关的图片来作为题图。也有很多作者会按照一定的风格来进行自制，也是不错的选择。

自建站框架

如果打算自建博客，那么可以用类似 hexo^[19] 之类的博客框架来帮助直接生成整个静态站，然后就可以直接部署在 Github Pages 上，连买服务器之类的都省了，相当方便。更复杂一些的 wordpress 之类的我个人就没有尝试过了。

写在最后

写技术博客还是一个需要长期坚持的事情，工作之后断断续续写了这么些年，还是个技术小号。不过持续下来对于个人的技术积累，沟通表达能力的提升还是相当明显的。

参考资料