Hello，欢迎你来到主题为「技术写作」的线上圆桌活动，我先来介绍下自己：我是沸点运营 -- 清蒸，本次活动邀请了掘金社区最有代表性的 7 位作者来谈谈他们对「技术写作」的看法，本次圆桌的初衷不在于帮你获得一篇 1k+ 赞 or 10w+ 阅读的文章而是让你知道这个社区高赞高阅读高粉丝的作者们是如何看待「技术写作」，而他们在当中的哪些小技巧使他们在社区内获得技术写作“成功”。

本次圆桌活动嘉宾均为社区高粉丝、高阅读、高赞作者，作为社区内容生产核心，这些作者们更了解这个社区基调，知道什么内容更适合社区，如果你想在掘金和他们一样获得技术“成功”，不妨听听他们怎么看待这些问题。

先来看下他们的合影

*注：按昵称首字母排序，下同

嘉宾介绍

来和掘金小伙伙伴们介绍下自己 😊

超人汪小建：Hi，我是超人汪小建，已写作 5 年，文章包括算法、人工智能、大数据、各种开发等类型文章，已出版《Tomcat 内核设计剖析》，即将出版一本算法书籍，同时也陆陆续续在写 AI 相关的书。

Hollis_公众号Hollis：我是 Hollis，一个个人技术博主，微信公众号Hollis（ID：hollischuang）负责人，个人博客技术博文阅读量数百万，技术文章写作 3 年多。

J_Knight_：大家好，我是一名刚满三年的非科班 iOS 开发者，从事写技术博客已经有两年多了，在掘金积累了 11000+ 名粉丝。

刘志军：大家好，我叫刘志军，一名 Python 开发者，从大学开始一直有记笔记、写博客的习惯，坚持了七年多，写作成为了我生活中一部分。

刘望舒：从 2011 年开始在 CSDN 写博客，顺理成章的成为了 CSDN 博客专家，然后通过 CSDN 吸引了出版社编辑，出了两本畅销书《Android 进阶之光》和《Android 进阶解密》，同时也开通自己的公众号[刘望舒]，平均阅读量在 2000+。

守候i：大家好，我是守候，前端开发者，三年工作经验，写作应该是有一年半了。

冴羽：我是冴羽，一个优秀的高冷的帅气的优雅的 Web 前端攻城狮，一个靠 JavaScript 系列、JavaScript 专题系列、underscore 系列、ES6 系列没有发家也没有致富的掘金用户。

圆桌开始

通过写作，你获得了什么呢？

超人汪小建：提升探索能力、思维能力、表达能力、毅力吧。

Hollis_公众号Hollis：和超人汪小建类似，除了提升表达能力，我还提升了自己的技术能力，同时也收获了了很多粉丝的认可。

J_Knight_：我从写作中收获的不仅仅是平台的粉丝以及影响力，更多的是学习能力，语言描述的能力以及力求把事情做到最好的品质。详情请看我最新的一篇文章：我从写技术博客中收获到了什么？- J_Knight_

刘志军：写作给我带来不少收获，它能帮我重新整理思路，通过对外分享获得更多关注和交流机会，还有工作机会和一些出版社的邀请等，同时，因为赶上了好时代，通过写作还能获得一些额外的收入。

刘望舒：正如我自我介绍的一样，出版两本 Android 畅销书的我通过畅销书，受邀出席了很多技术大会并发表了演讲，认识了很多 Android 界的知名大咖和技术专家，也让很多 Android 开发者知道了我。可以看出，通过写作我得到的不仅仅的技术上的提高，也产生很多积极的、质变的化学反应，更帮助了很多开发者。

守候i：和他们相比，我的写作时间有些短，但我在写作的这一段时间，最大的收获就是和其他的前端开发者交流学习；以及自己的对各个知识点的一个学习，整理，总结。往后也会坚持写作，希望大家多多支持。

看来各位写作收获颇多，你们的写作初衷又是什么呢？

超人汪小建：发表个人见解，建立个人品牌。

Hollis_公众号Hollis：知识记录与分享，提升个人影响力。

J_Knight_：我的写作初衷只是单纯地记录一些学习笔记和读书笔记。到现在也还是这个目的，只不过随着粉丝数增多，对博客质量上的要求越来越高了。

刘志军：最早写作没想太多，就是把它当作一个备忘工具，早期我是把东西记在本地，但是放本地不方便在其它地方查看，后来就把内容直接放在了网上，成为了一名 blogger，一开始写的东西其实很烂，隔段时间回过头来看的时候甚至自己也看不懂，这也是很多人刚开始写作时存在的问题，因为我们没有考虑读者的感受，自嗨型创作。现在写作除了备忘之外，还是一个思考的过程。

刘望舒：每次看到网上的文章时，看的别扭，就自己写了，看自己写的是最舒服的，而且还能不断改进。

守候i：本来这个只是当做个人笔记使用的，但是后来想着把笔记分享出去，和别人交流学习下，以及有一个技术博客，简历也加分，就开始写文章了。

冴羽：希望我做前端的几年里(未来无论是做后端、还是做管理、还是摆个铁板烧小摊都是对前端的一种远离)，能给业界留下一点微小的东西。

小结：看来，大家的写作初衷比较类似，都是分享整理内容和打造个人品牌😊

在清蒸看来文章分系列文章和和单篇文章，写单篇文章的话，你是如何进行选题呢？

延伸下，大家都在写《用 Vue 做一个仿 xx 》、《关于 Javascript 闭包你该知道的一切》等常见话题文章时，随着文章基数的增多后来的文章如果没有新的切入点很难获得高阅读和高点赞，所以如何一个切入某个点进行单篇技术写作是一个难点。

超人汪小建：除了写书之外，我写单篇文章选题主要来源有三个：

工作相关，平时在工作中负责的事情，觉得有价值的东西我会提炼出来写成一篇文章。

零碎的灵感，平时灵感一来想到一些主题或感想，就会我会给自己的微信发要点记录下来，后面有空时就会看自己给自己发了那些idea，进行写作。

读书畅想，因为我每年都要求自己看三四十本书以上（书房已经塞了几百本书），所以看了很多书后自己会有很多个人见解或者总结，于是可以写成一篇文章。

清蒸：嗯，和工作相关的内容不容易“撞题” ，内容的独特性来源于工作和书籍。

Hollis_公众号Hollis：工作中遇到的问题，学习中的总结，读者粉丝们提的问题等。

清蒸：看来将工作中遇到的问题文字化是文章的一大来源。来看看 J_Knight_ 怎么看这个问题 🎙️

J_Knight_：我的博客除了一些源码解析的文章之外，都是和当时的业务方面的学习相关的。有些突如其来的业务需求涉及到的技术点可能非常陌生，这个时候就可以选择和这一方面相关的主题来学习。所以我的很多博客都不是从零开始写的，都是源于自己平时的一些学习笔记。学习笔记成型之后再不断修改和添加自己的思考之后，博客差不多就成型了。

清蒸：正如 J_Knight_ 说的，读书笔记是一个很好的切入点，可以慢慢学会去总结和整理知识点。

刘志军：没有刻意去选题，因为我不是职业写作者，我的文章素材一般源自于工作或者通过平时阅读习惯积累，逐渐形成自己的素材库，有空了就从素材中挑一个主题写。

清蒸：志军老师和小建大佬的来源类似呀，听听守候对此有啥看法？

守候i：我觉得得知道自己目前对什么技术主题有兴趣，以及掌握了或者学习过的一些技术主题，再进行写作。切忌选择一些不熟悉的主题。至于是不是系列文章，个人觉得没太多的关系，但需要注意的一点就是选题不适合太广泛，太广泛可能会导致文章过长，读者会累，写得也累，也会乱。

清蒸：守候说了一些选题的禁忌点，冴羽有啥补充呢？

冴羽：虽然我从来不写单篇，但我觉得要写文章就写自己想写的东西、或者最近学习的东西、或者从项目中思考和实践的东西，这些课题不需要你想，他们就自动冒出来了。

小结：比较一致的看法，文章的选题来自于工作点滴和平时的书籍阅读

如何处理技术文章正文部分题外话--问题来自之前问题收集中「却把清梅嗅」的提问

很多技术博客中不可避免会加入一些写作者本人的情感（或者叫题外话），这些文字有时会被说 “废话多”、“啰嗦”，但是有时作为过度的段落，它能够让读者更有代入感转接到下一个知识点，这个度如何把握？

Hollis_公众号Hollis：控制字数和段落。不超过两段，不超过 500 字。

清蒸：控制篇幅好像是个不错的方法，但是具体到文章，大概是要控制占比了。不过，J_Knight_ 好像有不同的看法 🎙️

J_Knight_：首先我觉得题外话，或者带有本人情感的话应该是越少越好，甚至是应该完全没有的，这类话会显得作者不够专业，而且会影响文章整体的专业性，让整篇文章的质量大打折扣。一篇内容专业的文章被一些带有情感色彩的话和题外话拖累是很让人痛心的。而且并不是说一定要用这类话来作为过度或者让读者有代入感。相反，用客观的，专业的文字作为过度也是完全可以的。

清蒸：志军老师也有不同的意见，🎙️

刘志军：没必要刻意把握，文章的背后是一个真人，不是 AI，人是有温度的，有情感的，如果你在写作过程中那些所谓的“啰嗦”是发自内心的，那么读者是能感受到文字中流露出的情感，读你的文章就感觉是在和作者交流。如果你是给文章刻意加戏，读者就显得你啰嗦了。

清蒸：🤔理解为文章要出自真心不知恰当否，听听望舒对这个问题的看法。

刘望舒：我认为技术文章还是少参杂一些个人的情感，就如同写书一样，尽量要言简意赅，能一笔带过的，绝不拖拖拉拉。

清蒸：好像守候也是和望舒、J_Knight_ 一样的看法？

守候i：是的，关于个人情感，个人建议是：能避免则避免，无法避免就一句话说完，并且著名是个人的建议，看法等。情感观点也切勿过于偏激，个人主义。比如就如同火锅汤底可辣可不辣，喜欢辣汤底火锅的可以表达自己的喜好，但是不建议对不辣汤底的火锅起批斗性的言论。

清蒸：冴羽，你怎么看待题外话这个问题？

冴羽：emm，我从来不写。

小结：对于个人情感抒发类的题外话，大部分的作者选择的是能不写就不写。

写源码解读或者理论性比较强的文章时，如何兼顾生动有趣呢？-- 问题来之前问题收集中「弗兰克的猫」& 「RecoReco」的提问

Hollis_公众号Hollis：讲故事，比喻，画图

清蒸：画图的确是一个非常棒的方式，图解类的文章一直都是很受大家欢迎的，图片相对文字更直观、形象，阅读者能更好地理解到你讲的意思，同理比喻也是。J_Knight_ 有话要补充 🎙️

J_Knight_：这两类文章的写法差别蛮大的，我在这里分别说一下。

一. 源码解读类的文章：这一类文章一定避免不了对大段代码的分析和解读，所以要注意为了避免让读者感受到枯燥乏味，需要在讲解源码的之前先大致介绍一下这个源码或框架的用途和使用方法，让读者对它的功能有一个初步的认识。然后最好可以提供一个该框架的架构图，再分别介绍一下架构里面每个成员或模块的作用。这是为了让读者了解一下源码的结构。而且在解读源码的时候，最好还要用图或者日至输出来让读者真正用眼睛看到这段代码的执行效果是什么。最后，如果再能说出框架作者为什么这么设计的理由的话（这么设计好处在哪里，如果不这样设计的话会有什么问题），博客的质量就会明显上升一个档次。我觉得如果做到这几点的话就可以避免读者感觉枯燥乏味了。各位可以参考我写过的一篇源码解读：MJRefresh 源码解析。这篇文章在讲解代码的同时，还提供了很多形象的截图来配合代码的解析。

二. 理论性比较强的文章：这类要避免枯燥乏味的话相对容易一些，简单说就一句话：理论结合实际，抽象转为具体。不能单单地长篇大论你的理论，还应该用真是可用的 Demo 或者一段代码来验证这些观点，而且最好是可视化的，也就是有图或者日至输出，让读者真切体会到这个理论有什么用途，这个理论的意义在哪里。各位可以参考我写的一篇关于设计原则的文章：面向对象设计的六大设计原则。这篇文章除了介绍这六大原则之外，还针对这些原则提供了 Demo 和 UML 类图；而且还对比了遵循和不遵循这些原则的区别在哪里。

清蒸：很详实地介绍了下源码和理论性文章的撰写方法，志军老师对理论性的文章有啥看法？

刘志军：对于理论性的东西，最好用比喻手法，用一些来自于某些生活场景的比喻，好的比喻能让读者秒懂，我曾经写过几个例子，关于代理和反向代理，还有 Python 装饰器的概念，在知乎有超过 1000 赞。另外，一图胜千言，日本的很多技术图书能把高深的内容用图解的方式呈现，就是很好的例子

清蒸：和 Hollis 的看法一致，望舒好像有不同的看法？🎙️

刘望舒：拿 Android 系统源码来说，其实我也想写的生动有趣，但是事实上这种理论和生动有趣完全的不搭边，硬凑只会让文章失去原有的光彩。

清蒸：看来生动有趣不是所有的内容都可以做到的，😊，听听守候怎么看生动有趣？

守候i：兼顾生动有趣给我感觉，第一要避免一大段文字。第二要时不时的出现些图片，让文章生动些。兼顾这两点，给我印象深刻的就是《码农翻身》了，里面的文章，引用了大量的动画，图片，让文章变得更加的有趣。记得还记得有看过一篇文章是师生问答形式，但是文章貌似删除，找不到了。这两种形式可以参考下。也是我学习的一种方式。

清蒸：《码农翻身》一本很不错的书，阅读本文的小伙伴有机会可以阅读下，看看冴羽对源码解读怎么看 🎙️

冴羽：源码解读本身就是读者难以通过一遍阅读就能理解的东西，我只能做到源码理解过程中，读者可能遇到的问题，可能会想到的问题都写上自己的理解，然后……然后我就不管了……

清蒸：🤔Get 到的点是，分享自己的看法帮助他人理解

小结：生动有趣可以通过图来完成，但是有时候难以避免的要“枯燥”地讲解源码和理论，将自己的理解呈现给阅读者以作参考便于他们理解即可。

有深度的技术文章受众少，如何兼顾技术深度和高阅读呢？-- 问题来之前问题收集中「wujunze」& 「闵仙森」&「sea_ljf」的提问

Hollis_公众号Hollis：尽量用通俗的话语把高难的技术表述清楚，循序渐进的介绍，配合代码，图片，甚至动画，音频等。

清蒸：辅助图、音频形式，循序渐进由浅入深地来讲解。

J_Knight_：“阳春白雪，下里巴人”，有深度的技术文章受众少是一个非常正常的现象，我个人没有写过非常有技术深度的文章，但是对于这类文章如何提高阅读，在这里说一下我自己的看法。其实高阅读无非源于两点：

标题看上去比较吸引人，容易让人点进去看

很多人可以在文章里面有所收获，愿意去分享这篇文章

分别说一下上面两点：

标题看上去比较吸引人标题看上去吸引人有两个原因：

主题不偏离现在的热门主题太远

用一些修饰性的辞藻加以修饰（标题党除外）首先就是主题应该不能太偏。如果太偏，可能多数人都不会去点击，比如一个.NET的主题和Flutter的主题的热门程度肯定是不一样的。其次是适当加一些引人入胜的辞藻，但是不建议太过，因为会影响整体的专业性。

很多人可以在文章里面有所收获所以到这里就是既要有技术深度，也要让人有所收获。我认为是最难的一个部分：将晦涩难懂的理论知识让大部分人容易理解是很能体现出作者写作功力的。我这里有两个技巧：

提供足够的背景知识

善于利用比喻和联想提供足够的背景知识：你需要将读者想象成一个完全外行的人，你需要提供TA需要先了解的一切背景知识，用于构建你后面所讲解的知识体系。善于利用比喻和联想：即使是有了背景知识可以让读者在理论层面理解，但是这还不够。因为这个时候读者可能还是不会应用这些理论。所以最好使用现实中的例子或者也可以想象出一个生动的例子去模拟这个理论模型，让读者可以对这个理论有更形象的认识。

清蒸：很棒的写作技巧提点，志军老师对这问题有另外的解读 🎙️

刘志军：人更愿意接收不需要思考的东西，这也是深度技术文不那么受关注的原因。如果想获得更高的阅读，还是取决于于作者对技术的理解程度，你对某个技术的理解越深，你就越有可能用浅显易懂的语言来表达。

清蒸：志军老师说的挺对的，结合我自身，有些深度内容巴不得被人分解成零零碎碎我不用思考去阅读，💦我的个人阅读习惯不好，好在我这样的读者有对知识点理解深刻的人来输出内容 😊看看望舒看待这个问题的。

刘望舒：我想作为写作者，肯定是希望高阅读。当写作者技术的不断提高时，大部分还是希望会去写一些有深度的文章，随着越来越多的人进入高级开发，这些有深度的文章也会有这良好的阅读量。另外，一些新技术的入门深度不高，但是会得到高阅读，可以写一写，毕竟技术不仅仅要追求深度，同样也要兼顾广度。

清蒸：酒香不怕巷子深，时间会给好的内容带来流量，这话不假，虽然缓慢但终归会被人接收、传播。冴羽好像有不同的看法。

冴羽：很难做到，所以不要想了。我学习自己想学的，我写自己想写的，然后我分享出来，如果能对阅读这篇文章的人能有所帮助，我很开心，阅读量什么的，就顺其自然吧

清蒸：顺其自然也不错，守候怎么看？。

守候i：曲高和寡，既然文章是有技术深度，那么看得懂文章的人就少，阅读数会受到影响。要兼顾技术深度和高阅读，这个似乎很难做到。可以的就是尽可能做到在一篇文章里面，用生动有趣的方式，把深度的技术通俗易懂的表达出来，让更多的读者容易读懂，阅读数就会有一个提升，这个就似乎又回到上一个问题了（如何兼顾生动有趣呢？）。

清蒸：确实，深度内容对人的理解要求高，对应的受众基数小，阅读量也就不如普及性文章来的高。

小结：对于高阅读和深度的平衡，嘉宾的看法并完全相同，清蒸的看法偏向望舒、冴羽，个人觉得摆正心态，专注写作便好，时间会分好坏。

有什么写作用的工具安利吗？

冴羽：我也想知道看看其他嘉宾怎么说？

超人汪小建：写文章主要还是内容吧，工具只是提升效率，markdown 效率就很高，展示代码和排版都方便，而且多数网站都支持。所以只需要有道云笔记 + chrome 的微博图床插件就能很高效了。

Hollis_公众号Hollis：mweb--「Mweb」是一款 Mac Markdown 应用，因其丰富的功能和强大易用性俘获大批忠实用户，通过「Mweb」，你可以完成写作、记笔记、静态博客生成等工作。官网地址：传送门

J_Knight_：写作用的工具我主要使用下面几个：
- Markdown 笔记：Evernote 或有道笔记。这两个笔记都是支持多平台的，更新非常方便，不受电脑的限制，用手机就可以；而且也没有电脑客户端的限制，因为可以用 web 服务。
- 图床：图床我最初使用的是七牛，但是后来域名被回收了，就改为用阿里云的 OSS 服务了。这个服务是按照流量收费的，不过我的流量还不是很高，半个月只用了几分钱，感觉还好。
- 动图制作：有的时候展示 Demo 的时候会需要用动图。我使用的是 PicGif 软件（Mac 平台）。首先是用 Mac 自带的 QuickTime 把 Demo 的操作录下来，然后再用 PicGif 编辑即可。

刘志军：我没有用太多的工具，就用 sublime 在本地写，存在 GitHub 的私有仓库，文章都是基于 markdown 写的，这样我不需要花太多时间在排版上。工具越简单越好，我是 markdown 重度使用者。

刘望舒：时序图推荐用 visio 2013 ,其他的图推荐使用 ProcessOn。

写作有什么注意的事项同大家分享的吗？例如：排版、代码展示？

Hollis_公众号Hollis：参考一定要原文地址，尊重别人的知识产权。

清蒸：嗯，产权这个很重要，清蒸在这里呼吁下：如果你发现别人的文章非原创，来源于他人且未标注转载出现在他的专栏下，记得告诉官方~ 感恩 ❤️

J_Knight_：我认为写作的注意事项有一下几点：

大标题的层级最好不要超过 3 层，不然会增加读者的阅读成本

如果有并列的事项最好用 1，2，3 或者原点开头竖着排列起来，而不是横着写。

解释性的语言最好用 markdown 的引用语法来标注，方便用户直接区分哪些是正文，哪些是辅助性的语句。

代码块和针对该代码的讲解的高度加起来不能超过一个屏幕的高度。这是一个阅读体验的问题：如果代码块很长，超出了一个屏幕的高度，读者可能就会来回上下滚动屏幕，很影响阅读体验。而且这个时候读者也不方便看到代码的讲解，也可能会来回上下滚动屏幕，也是比较糟糕的体验。因此我建议的是将代码段和这段代码的讲解可以在一个屏幕的高度下完全展示出来，这样的话读者只需要移动眼球就可以同时看代码和其对应的讲解了。

如果文章的理论性知识过多，最好需要提供 Demo 展示或者日志输出，让读者对理论有更加直观的认识。

段与段，尤其是每个部分之间要有承上启下的过渡语句，不然读者会有一种很突兀的感觉，影响阅读体验。

文字的描述要经得起推敲，切忌生搬硬套，最好是用自己的话将资料或者其他文献里的文字表述出来。也就是说你需要真的理解了你所写的才可以。

清蒸：很棒的一些写作小总结，划重点，记下记下 📒

冴羽：我会遵守中文技术文档的写作规范，其他的我就不管了。

清蒸：阮老师的这个写作规范挺完整的。

最后一问，如何对抗自己不想坚持写作的惰性？-- 问题来之前问题收集中「豌豆花下猫」的提问

超人汪小建：

培养习惯：培养写作习惯，习惯培养起来了几天不写文浑身难受。

制定计划：可以给自己制定短期、中期、长期目标，比如要求自己一个月写满五篇文章，半年写出某个领域的系列文，两年完成一本书籍的编写。

预留固定时间：一篇质量较高的文章写完其实平均得四个小时，所以写作时间必须有保证。比如可以预留一三五晚 8 点到 10 点为写作固定时间，周末每天预留 3 个小时。

持续输出：找一个平台，比如掘金、CSDN、公众号等，保证起码周更频率，有了粉丝和读者的反馈鼓励，也能让自己更有动力。

Hollis_公众号Hollis：逼自己，比如我在做公众号，给自己定了一个目标：每周都要有原创。这样就可以逼迫自己要进行不断的原创输出。

J_Knight_：我认为产生惰性或者拖延的根本原因是：觉得这件事的执行成本非常大，同时做这件事的收效无法预期。

回到写博客这方面上来，很多人不想写博客或者是无法坚持的原因也是类似的：

没有主题，方向，无从下手

觉得写博客需要花费太多的时间，而且就算写了，如果想写好也是需要费大量的时间和精力

博客写出来质量上怕保证不了，怕被吐槽。

其实上面这三点在我看来都不是问题：

没有主题方向，无从下手上面的问题中我也提到过：我所写的博客其实大部分都来自于我平时的学习笔记。所以只要是我一直在学习，在记笔记，那么只要是有时间的话，我都会不断去提炼，去完善，最后形成博客。

觉得写博客需要花费太多的时间和精力其实从一份笔记到博客的最终形成所花费的时间并不是很长，无非就是添加一些写给读者的过度性的话，可能还需要加一些配图，而且排版方面不会太花费时间，因为 markdown 语法已经很完善了，熟练的话可以马上理出一篇博客出来。这里面需要提一个时间管理方面的问题，很多朋友喜欢利用多个大块时间来写博客，或者是一篇博客想一气呵成。其实这些想法大可不必：首先大块时间非常宝贵，应该拿来去学习，去思考。另外，一篇博客写出来以后，可能第二天你看了之后还会觉得有可以优化的地方。所以我个人建议使用碎片时间来写博客：可以用跨平台的笔记软件（现在的有道笔记和 evernote 都支持 markdown 语法）来写博客，有时间的时候可以打开电脑或者手机来看笔记，想修改的话及时修改，提高时间的使用效率。

怕质量达不到要求其实这一点更不用怕，质量不高或者有错误的文章写出来是有两个好处的：

可能会有人过来纠正你的错误

可以让自己其他人看到你自己的成长

可能会有人过来纠正你的错误：而且可能还会有人看到你文中出错的时候会耐心教导你，纠正你的错误。但是如果你不把你的理解写出来，可能很长时间都不知道自己理解的是错误的，做学问最怕的是不知道自己不知道，所以把问题尽早暴露出来不见得就一定是一件坏事。

可以让自己和其他人看到你自己的成长：其实博客写出来之后，也算是对自己学习和成长的记录。作为读者，看到不断成长的博客就能够感受到博主的成长和细心耕耘。不是所有人都是在能力很强的时候才开始写博客的，很多人都是从零开始，一点一滴积累，随着时间的推移，博客质量不断提高。因为写作也是一种技能，只要多坚持，多思考的话，能力自然越来越好。重要的不是开始的时候怎么样，而是你后来的成长了多少。所以不要怕自己博客的质量不够好，不敢写。

清蒸：嗯，三点原因分析的挺到位的，也有相应的应对方法，看看写作 7 年的志军老师是怎么处理的 🎙️

刘志军：执行力是关键，先设置一个可实现的目标，例如保证每周写一篇文章，写完后把自己当成读者，多读几遍，直到修改成自己能理解的样子。发布到网上后如果效果不错，可以尝试给网站或者给公众号投稿，获得更多的曝光机会，这也是一个正向激励的过程。一旦有了正向激励，你就有了动力投入更多时间在上面，逐渐形成一种习惯。

清蒸：持续输出也要有一点的激励才行，作为平台方我们会努力为优质的作者和内容提供曝光和流量的，听守候是怎么看待这个问题的 🎙️

守候i：我自己的经历就是，开始写作了，写了几篇，只要有内容可写，只要有学习到新的知识，或者研究出一些小技巧甚至黑科技类的内容，自己就会做笔记，做了笔记，整理下一篇文章也不会太遥远了，应该不会出现因为懒而不想坚持写作的情况。在习惯写作了，又有内容写的情况下，如果不写，反而会觉得自己有点事情没做，浑身会有点不自在。为什么会出现不想坚持写作的情况，个人觉得原因有三：

工作太忙，没多余时间写

文章被阅读太少，失去兴趣

暂时没内容可以写。针对前两个原因，主要还是看自己的行动吧，因为时间是可以挤出来的，文章一开始被阅读太少也正常，写的多了，人气就会提升，如果没有，可能要思考自己写的文章是不是哪里出了问题。最后一个应该是大多数人会遇到的一个问题，也是我现在遇到的问题，没东西可以写了，就可能是因为自己学习遇到了瓶颈，或者是自己的学习的知识点一成不变。这个情况就只能靠自己克服，学到到了新的知识，应该就会有内容可写了。就我个人而言，之所以不会要求自己一个月要写多少篇，一年多少篇这些目标，就是因为写作会受时间，内容而影响。如果强制写，质量内容一般，反而觉得还不如再等久写，写好些。

清蒸：看来守候和 J_Knight_看法类似，看看一直很佛系的冴羽怎么看待这个问题的。

冴羽：无为而治，想写就写，不写算了。写作热情本身就是一个此起彼伏的过程，想写的时候多写几篇，不想写的时候就好好休息，刻意要求自己只会增加对写作本身的恐惧和厌恶，倒不如随心所欲，无为而治。

圆桌结束

本期的圆桌「技术写作」话题就此就结束啦，别忙走:

这边还邀请了一些大家常见的作者谈谈他们对技术写作什么看法

在 2019.01.09 - 2018.01.18 留意评论区的评论哟

如果你的文章得不到曝光也欢迎在评论区贴上地址，让社区里的小伙伴帮你分析分析原因~

只有和阅读者接触才知道，才知道什么是他们想看到的，以及你的文章哪里需要改进❤️。

延伸阅读

收录了社区小伙伴对「技术写作」的看法

《[译]如何撰写精彩的技术博客文》 by：幸运儿
《写技术博客那点事》 by：浪里行舟