如何搭建文章结构——常见技术文章的逻辑框架

开场白

输出倒逼输入

作为一个技术人，我们往往都沉浸于技术的海洋中学习。在学习技术的过程中，我们不断的在输入知识，同时我们也需要关注输出。输出是也一种学习的过程，无论是写博客、写文章、写书，还是做分享、做演讲，都是一种输出的过程。有时输出是你坚持学习的动力，有时是你巩固和总结学习的过程，有时是你向别人传递知识的方式。"费曼学习法" 其实就是输出的一种形式，它的核心思想是：如果你想要学习一件事，那么你就需要把这件事教给别人。

说到输出，其中一个非常重要的技能就是写作，写作是一种思考的过程，也是一种沟通的方式。在写作的过程中，我们需要考虑的问题有很多，比如如何取标题、封面配图、如何搭建文章结构等等。

我也是一个技术博主，在写博客的 6 年时间里面，我也不断地在积累和思考，如何去更好的写作。今天，就围绕着如何搭建文章结构，如何进行取标题、封面配图等等，我将一个开发的视角分享一些我自己的经验和思考，希望能够帮助到你。

当然，下面的分享针对与文章、博客类型，对于书籍或是论文的写作有着更加专业的要求，这里就不做过多的讨论。由于本人对于后端的知识更加熟悉一些，所以文章中具体的案例会偏向底层一些，但不用过多担心，你只需理解抽象的概念，具体的案例我相信你也就能理解了。

为什么要写好？

我相信，你既然看到了这里，一定已经解决了第一个问题，为什么要写。我觉得无论写作的内容是什么，只要你踏出第一步，那么我就觉得你比许多人要成功了，因为你已经开始了，而不是一直在想要开始。那么我主要来讨论为什么要写好。

虽然说技术文章，不像写散文、记叙文，需要华丽的词藻或者是一些倒序插叙的写作手法，所以我们常常看到的就是非平铺直叙。但并非说它的行文就可以没有章法。

有人可能会说：技术文章的重点不应该是内容吗？

没错，当然！技术文章的内容往往是吸引人的关键，作为一篇技术文章，别人想要读的前提就是他对你说的这个知识不了解，或者是对于你说的这个问题没有答案。所以我一开始就觉得，只要我的文章中有你想要的答案，就可以了。

但是当我拜读了许多的文章之后才发现，原来不是这样的。厉害技术文章不仅仅是内容，逻辑框架非常的重要。逻辑框架清晰的文章能让读者迅速理清思路获得知识，同时还有以下几个好处：

好处 1：方便回顾

技术写作的其中一个目的，应该是自己对于一个技术或者知识的当下理解，它很多时候承载了你的笔记这样一个功能。所以，当几个月或者是几年后，当你想要查询当时的解决问题的思路时，一个好的逻辑框架能非常快速的帮回忆起你当时的想法并找到答案。

好处 2：建立正向循环

写作写好的另一个巨大好处，就是能够获得读者的认可，当你的文章容易被别人阅读的时候，别人才会给你更多的意见和建议，这样的建议往往能促使你更好的写作，从而形成一个正向循环。写作 -> 建议 -> 写的更好。

好处 3：快速创作

有时候，当你想要写作时，往往只是一个念头或者想法，想要成文，还需要花费很多的时间。你需要围绕你想要写的主题，来构思整个文章的前因后果。而一个好的逻辑框架能够帮助你快速的把想法转化为文字，从而快速的创作。有了一个好的骨架之后，你只需要不断填充，一篇逻辑清晰的文章就能迅速成型。

我经常会使用的一种创作思路就是，积累+总结。比如，当我对于一个新的认识有自己的看法时，我马上将它在笔记上记录下来，然后再一周内不断地积累相关联的知识、背景、资料等等，最后再周末的时候将它们整合到一起，从而形成一篇文章。因为很多时候当前你对某个知识的理解是片面的，不完整的，在寻找相关资料的过程中能让你对它有更加深刻的理解。

而在最后整合和总结的过程中，就需要用到我们下面要讲的逻辑框架了。

问题提示

提出问题不仅仅是为了吸引读者

第一个框架，也是我最常用的一个行文思路，就是提出问题。许多的技术文章并非写的不好，而是没有一个好的逻辑框架，导致读者在阅读的过程中很难理解作者的思路，从而导致文章的阅读完成率很低。

而针对与技术文章，特别是一些困难的技术分析文章，往往就会有一个问题，就是我看着看着，就没有办法理解这个知识了，或者说我看完就看完了，但好像又没学到什么东西。

那么，或许使用问题提示法就能帮助你解决这个问题。

框架

提出问题
解决/回答问题过程
总结和提升

你肯定会说，这么简单？这不就和我现在写的事故分析报告差不多吗？先列举问题，然后分析问题产生的原因，如何解决防止下次出现。

没错，很多时候简单的东西往往容易被人忽略使用。最关键的是它能用在何处？

举例：源码分析

如果，你对技术比较喜欢，对于一些开源的技术实现，学习源码往往能让你快速理解这个项目，并且能学到很多编码设计上的技巧。所以源码分析类的文章也挺常见，但是许多文章有一个一致的问题，他们的文章大多数就是将代码的跳转路线告诉你了：

入口在哪？从那个方法进来，到那个方法去，这个方法是做什么的.... 等等，当你看完之后，你就会发现，你剩下的几乎没有，回过头你发现你等于没看。或者是当整个项目非常复杂的时候，往往方法和类的扩展很多，导致你看到最后，你都不知道在哪里了。还不如自己运行代码，跟着断点调试来的方便。

那么，文章的问题出在哪里呢？我们要如何使用这个框架改进呢？没错，合理的设计问题，也是在考验你对于整个技术实现的理解。比如你可以这样设计问题：

在阅读源码之前，你可以思考一下，如果是你，你将会如何实现它？

再比如：

为什么这个技术能处理的如此迅速？原因是什么？

然后，当你在叙述整个源码实现的过程的时候，你就可以时时刻刻围绕这个重点去阐述：

比如：这里数据结构的设计对于整个实现是有很大帮助的，如果我设计，可能无法想到用这个结构，以后可以用到
比如：你可以写，不要忘记我们的问题，关键在于如何迅速处理，没错，这里就是问题的关键，由于这里用了....技术...能帮助它更快的处理...

最后，不要忘记，在总结的时候再次回答这个问题，让读者一定产生：哦，原来是这样的感觉。

优势

那么使用这个框架所构建的文章就很明显，让你原本平铺直叙的文章有了一个主心骨，原本无依无靠的零散的知识点，都是为了这个主心骨服务的。

这样，读者在阅读的过程中就会时时刻刻围绕着这个问题去思考。即使当我们有很多很复杂的项目时，我们的问题也有有多个，只要围绕着问题去写，读者就能迅速将思维更上，从而不乱。

并且，就像前面说的，当你很长一段时间回过头来复习的时候，你不需要看整个文章，你只需要口述回答你最前面提出的问题，你就能迅速回忆起来整个知识点。

扩展

当然这样的框架并非只能用在源码分析的文章中，还有类似的还有分析框架、分析中间实现等等，都可以尝试用这样的框架去构建，会让文章更加清晰。

开门见山

即使直接上结论，读者也不会逃跑

在学校的时候，老师总是会告诉我们，写作的时候要有一个开门见山的思路，也就是说，你的文章要有一个明确的主题，而不是一上来就开始写，然后到最后才说，这篇文章是关于什么的。

而在当下，厉害技术太多了，很多人都喊着学不动了，躺平了。并且在短视频，这样短频快的节奏之下，已经很少有人能耐心仔细的看完你的文章了。

那么，反应到技术文章，大多数人追求的是什么？答案，他们只需要一个结论，其他的全部略过，知道结论仿佛就知道了全部，如果在文章中，无法迅速找到结论，那么他们会迅速切换下一个搜索结果。

这也是为什么很多时候在搜索英文报错的时候，很多人看着英文文章无法找到答案，无法解决问题，其实答案就在其中。那么此时，我们就需要用到这个框架。

框架

直接上结论
理论论证
总结原因

直接上结论，会不会导致读者就看个结论然后就走了呢？让我们慢慢往下说

举例：技术选型

很多时候，在实现一个功能或者一个需求的时候，有很多的方案供我们选择。常见的就是两个开源项目的是实现，或者两种技术方案的对比。当我们在做选择的时候，往往就会去详细调研两种不同技术的优势和劣势。又或者是只有一种技术，用与不用也是一种选择。用是因为什么，不用是有什么原因。

那么对于这样的文章，我们就可以尝试运用这样的框架去写。

首先，我们可以上来就直接说明，我认为：应该选择使用这个技术，并且我已经将之实践了。

然后，你就开始从各个维度进行论证，为什么：

比如从使用角度
从代码的实现角度
从维护成本出发
...

在论证中，最能给到用户肯定的就是数据，如果你能拿出你的实际测试数据来说话，会更加有说服力。

最终，你是在什么样的场景下，做出了什么样的选择。并且可以总结很多实践过程中，出现的问题。

优势

这样的写作框架与说明文的写作有着类似的道理，优势在于：

快速让读者知道你的观点
清晰的论证让你有足够的靠山
最终让读者清晰的明白你选择的场景，是否他有参考的意义

原因

很多人就会说，别人肯定会看了开头就走了。但其实实际并非如此：很多人其实在看文章的时候一开始都是大致扫一眼，去搜索他们想要的信息，而当他们无法找到信息的时候就会走。

而看了这个开头的用户往往反馈就两个：

同意你的观点
不同意你的观点

对于同意你观点的人，无非就两种，一种是已经对这个知识非常熟悉了，这样的人其实并不是你的受众，你这样做非常可以节约别人的时间。还有一种就是他同意你的观点，但是，只是他的一个个人想法，并没有人支持，那么他会继续看下去，找到你这样说的理由。

同样的不同意你的人也是类似的道理。抓住了用户的第一眼，很多时候就能绑住用户。

扩展

当然技术分析、项目分析、优势分析，等等文章都可以使用这样的方式去写作。

铺垫基础

让你的文章满足更多受众

对于特别难得知识点或者问题，我们往往需要一些前置的知识来做铺垫，铺垫的好与坏直接就决定了文章的阅读体验。

我也经常在看一些底层技术的文章，对于同一个内容，有的文章阅读很顺，从头到尾，读完就学会了；而有点文章就很难，看完之后你还需要去找别的文章，最终拼凑出你想要的结果。

于是乎，有时，对于特别困难的技术说明类型的文章，我就会尝试采用这样的写作框架来帮助我。

框架

前置逻辑/知识储备
推导中间状态
最终得出结论
引用各类观点

举例：难点技术

这里的案例我实在是找不到合适所有读者的说辞，只能以具体的一个案例进行说明，我会尽可能用大家都懂的语言来解释。

“IO 多路复用 ”是一个非常复杂的技术难点，如果直接上来就告诉读者，它是怎么做的，如何实现的，然后贴一贴代码，这样很难让人明白。或者说不太友好

那么，如何去做铺垫呢？你可以从以下几个方面着手：

用户空间和内核空间
进程切换与阻塞
文件描述符是什么
标准 I/O 怎样的
然后，你就可以顺理成章的推导出 IO 多路复用的实现原理，以及和标准 IO 相比它的优势在哪？为什么要用它。

当然，在得出结论之后，我的建议，这样类型的文章，你想要提升，一定要给一些文章站稳脚跟的链接，并且对于一些知识点，你可以引用你之前写过的博客链接，这样不仅能缩短用户的寻找时间，还能帮助你其他博客的引流，也算是一个小技巧吧。

原因

对于困难的知识，很多人其实难以理解的原因往往是由于前因后果没有搞清楚，前置的基础知识没有掌握，你直接告诉它最终的结论，往往会很难让人明白。

优势

这个框架对于读者来说非常的友好，相当于新手和一知半解都能真正在你的文章中 “顺理成章” 。
而这个框架我特别喜欢的还有一个原因是：在写作的过程中，它帮助我去回忆起之前很多的知识点，帮助我在不经意间构建了整个知识网络，让我明白这个知识点在我的整个网络中处于哪一个节点，与之相邻的问题是什么。

扩展

这样的框架不仅适用于较难知识或技术的说明，我还发现在一些框架和开源项目的说明中有所体现，他们会直接引用一开始别人基础的实现逻辑，然后说明其中的问题，推导到他们升级的原因，从而说明他们新技术或者新设计的优势，整体下来一气呵成。

容易被忽略的注意事项

在搭建文章结构，还有一些别的注意事项，我想做一些提醒

不同平台内容量各不同

首先在搭建文章结构之前，你应该确定这个文章想要发布在什么地方。在不同地方发布的时候，内容量是不一样的。我经常能在一些公众号的推文标题看到 “万文长字，分析 xxx 技术” 又或者是 “看这一篇就够了 xxxx” 然后点进去哗啦哗啦非常的长，在手机上观看极为不友好。

所以，针对与不同的平台，你在设计的时候需要考虑内容的不同，当内容过长时进行拆分。比如，针对一个特别系统的设计分析，你可以拆分成专栏的形式进行谋篇布局，将原本的内容拆分成为几个小部分，然后在前后增加衔接的内容，从而形成一个体系。

我在写博客的过程中，也经常会分析一些成体系的内容，将他们拆分后归类到一起，对于读者来说更加友好，每次看的不多，理解没有负担，而又在一起，相互只有有联系。

代码如何展示更优雅

不要截图！不要截图！不要截图！

重要的事情说三遍。我一开始写博客并且到后面有很长一段时间都是在截图，特别是对于一些源码分析。当时的想法是，截图一张图片能放下大段大段的代码，不用占用很多篇幅。直到有读者向我反馈问题：图片看起来有时候不清晰，太小或太大，最大的问题是无法复制粘贴，没有办法进行搜索。所以，从那之后我就基本告别截图了。

开源有外链

如果是对于开源的代码分析，记得加上外链，能方便用户迅速定位到代码段，找到原始方法进行追踪。

可运行的教程要完整

如果你给出的是一个教程或者一个可以运行的完整示例，请一定要保证完整性。我无数次会发现从网上拷贝过来的代码无法使用，而一些博客没有留言功能，最后一点点写才发现，哦，原来对方忘记上传了其中某个方法的实现，而这个方法非常关键....

开源代码分析可缩量

针对于开源的代码，没必要整段整段的拷贝，一方面确实篇幅太长了，占用了文章大量的资源。并且读者不好阅读，其实我们在分析代码的时候往往抓住的是主线，所以其中没有围绕主线的部分你可以手动删除并做注释，缩量之后会让整个结构更加清晰。

总结

当然，说了这么多，对于写作的框架还有很多，这里只是列举出我现在常用的一些，希望对你有所帮助。当然，写作框架固然非常重要，但是它需要你慢慢去总结和摸索。所以对于不同的人来说，我给出以下的建议：

刚开始写作的同学：无论是什么，只要你去写就好，尽量追求易懂。
写作了一段时间的同学：请尝试运用一些技巧和框架去让你的行文更加流畅，让你的文章能被更多人点赞。
写作了很久的的同学：慢慢积累自己的写作思路，建立起成熟的体系，形成自己的风格，能快速建立你形象，从而收获越来越多的粉丝。