论好文章和烂文章

简介：我们为何写作？对于许多技术同学来说，写作是一件比写代码困难许多的事情，和电脑相顾无言数小时，发现自己写不出什么像样的东西来，着实不是一种很好的体验。

作者 | 许晓斌
来源 | 阿里巴巴云原生公众号

写作动机

我们为何写作？对于许多技术同学来说，写作是一件比写代码困难许多的事情，和电脑相顾无言数小时，发现自己写不出什么像样的东西来，着实不是一种很好的体验。即便对于有些经验的人来说，写四千字质量尚可的文章，我估计也要花 6 小时以上的时间，这还不算平时素材积累的时间消耗。

这么费事费力的事情，为什么要去做呢？我认为此事有着极大的价值，这个价值分两层，我暂且称之为表层价值和深层价值。

表层价值是极其功利的，例如有同学想晋升，而晋升的一项指标是个人影响力，那么写文章就能提升个人影响力；例如有团队 Team Leader 想招聘，那怎么让别人了解你及你的团队呢，写文章也是个不错的方法；再有一些就是冲着上级或者利益相关方写的文章，以类似项目汇报的方式写的文章。表层价值的核心关注点其实并不在文章本身，而在于文章背后的人，作者对读者的期望往往不在于读者认可文章内容，也不期望读者参与对内容的讨论，而仅仅是期望读者快速地认可作者这个人。

只关注表层价值去写文章，非常的本末倒置。就好比写一篇讨论 PM 2.5 的科普文章，如果你一上来就冲着推销自己的空气净化器这个动机去写，其恶臭很快会从字里行间流露出来。

与表层价值相对的，我认为任何一篇文章都应该从深层价值出发。这个所谓深层价值就是文章的内容，文章的观点，文章需要尽可能地客观，要向学术真理的态度逼近。写一篇文章是因为对一个问题有着自己的思考，并且去详细了解了很多人的思考，发现了一些观点的冲突，并且不会为了政治正确去迎合别人的观点；尽我所能把那些我认为有价值的想法，总结下来，用清晰、有趣的方法传播给他人；我能体会到写作的热情，这种热情来自于思维的乐趣，来自于观点的碰撞。这个写作的过程，自己的思维有成长，通过大量的逻辑思考，我的思维得到提升；其次写出来的文章，对读者有着很高的价值，因为有价值的知识得到了传播。

还有一种写作动机就是想要传播有价值的技术，例如 Pivatal 公司的布道师 Josh Long 就写了大量的技术介绍文章，也有很多精彩的演讲。我曾问他为什么能够做的如此出色，以致于多年被评为全球 Java 领域最有影响力的 20 人之一。他的回答是这样的：

I think that people don’t trust technology, they trust people. So, while it is possible that the spring team could just publish good documentation and leave it for the world to find, it’s far more compelling when u feel u can ask questions of someone. And u can see that they’re having fun.I love Spring because it has made millions of lives easier. It makes me happy to think about its application, to see people happy with its possibilities.

一篇文章写出来，是因为作者喜爱一项技术，从内心认可技术的价值，相信技术的潜力；还是因为作者想兜售什么东西。这两者动机的差异，稍微细心的读者很快就能发现。当然，上述动机经常混合在一起，但是如果写作的主要动机都在表层，那么基本上这样的文章也就没什么价值了。

影响力

Josh 是 Java 领域在全世界有影响力的人，他通过演讲，写书，博客，影响着全世界数百万的 Java 程序员，帮助了 Spring 等优秀的技术在全世界的推广。我写了一本关于 Maven 的书，这本书也得以卖书了几万册，再加上盗版 PDF 的数量，那是影响了全国十多万的 Java 程序员了，帮助了 Maven 这一技术在中国的推广。我加入阿里 8 年多，在内部技术社区 ATA 发表了 60 多篇文章，累计的阅读数大概也有五万以上，我相信这些文章也给阿里的技术带来了一些微小的正面改变。从这些角度看，写优质的文章虽然耗费很大的精力，但是由于其非常便于分享传播，因此能够快速地影响许多人，而且这种影响能够持续的存在。

当然时代在改变，以前由于网络技术的限制，文字的传播比较方便，视频的制作及传播成本比较高，因此演讲的实际影响力相比文章和书籍会弱很多。而今天的网络和视频技术已经非常成熟，制作高质量的视频也许更容易传播了。

文章也好，视频也好，影响力应该是被用来做正确的事情。今天控制影响力的很多流量入口，已然形成了一种新的权力，他们能控制什么声音容易被大家听见，什么画面容易被大家看见，什么文字容易被大家阅读，什么态度容易被大家感受。权力的形成进而演变成了权力寻租，然后这个事情就往往和所谓“正确的事情”无关了。

通过影响力做正确的事情，我觉得最好的例子就是张瓅玶（花名：谷朴）的这两篇文章了，第一篇是「API 设计最佳实践的思考」，第二篇是「警惕复杂度困局：关于软件复杂度的思考」。文章的内容都是工程师喜闻乐见的关于软件设计的深度分析和思考，但我觉得在这个例子中，比内容更重要的是这两篇文章中传递了一个非常重要的信息，那就是，“在阿里巴巴，即便是研究员级别，也是有人在仔仔细细认认真真看技术的，那些层级更低的却早已脱离一线的，张口闭口都说技术只是细节的管理者，见鬼去吧。”（当然，这个信息只是我个人观点，不能代表谷朴）

写作方法

我们的基础教育似乎在写作的培养方面很有问题，我印象中市面上常见的那些优秀作文选，往往都是注重形式和套路，往往缺乏逻辑和观点，用一个成语总结就是“无病呻吟”，什么事情都要拔高抒情，以小见大，最终的结果就是假大空成灾。大家整体的基础已经薄弱了，而从事技术工作的同学，往往在读书的时候语文还是个弱项，那么结果就可想而知了。写出来的东西，要逻辑逻辑不严密，要形式形式乱糟糟，基本的分段、标点、用词更是问题颇多。好在写作这个能力不是只在学校才能训练的，工作中也可以训练，而且明显有章可循。

1. 阅读量

郑子颖（花名：南门）在他的文章中强调了“多看”的重要性，他用豆瓣记录了年均 50 本以上的阅读量，这相当于平均每周至少一本书，这是一个比较非常惊人的数字。我回顾了一下自己的豆瓣记录，阅读量大概是他的一半，也就是年均 25 本的样子。阅读的益处自不必说，我这里想强调的一点是，不断阅读优质图书能提升自己的文字鉴赏力，书读多了，拿起一本翻翻目录，其中找几个段落读一下，对于此书的质量，心里大概就有个谱了。自己写作的时候，其实大多数时间也是在参考现有例子的结构和方法，如果你照着大量优秀的案例学习，那么自然也不会差到哪里去。

我在写《Maven 实战》之前，阅读了大量的 O‘Reilly，Pragmatic Bookshelf，和 Manning 的计算机图书，这些公司出版的图书大都有非常高的质量保证，在介绍技术的时候，有清晰的由浅入深的结构，辅以大小适中的案例，以及不枯燥的理论分析。可以说，我就是参考着那些优秀的书籍的写作结构和写作方法，写了自己的书，最终我的书也得到了整体不错的评价。

除了写作方法上的受益，阅读更重要的是从内容受益。再举例来说，我在「如何做好技术 TL」这篇文章中，提到了自己在做 TL 的这些年阅读了好多本讲管理的书籍，包括《赢》、《驱动力》、《门后的秘密》、《非暴力沟通》等等，这些书籍极大程度上帮助我补充了自己的思考脉络。写作即思考，而思考不是凭空出现的，思考需要原料，常见的原料就是我们实际的工作经验，然而一个人的体验毕竟是非常有限的，而阅读他人的体验及思考，以谦卑的态度为自己的思考提供更多原料，显然是明智的做法。

「如何做好技术 TL」收到过一条很有意思的评论，评论是这样的：

个人认为管理相关的书籍都是鸡汤，不必看，如果需要靠着“教你怎么做管理”的书才能做管理，那么说明这个人不适合做管理。

这句话隐含的意思是，有些知识，例如管理的知识，是无法传承的，只能靠自己天性领悟。对于此评论，我只能说无知者无畏了，我们写文章必不可持有这种心态，即便自己的想法有多么独特、多么原创，也一定不能自建藩篱，坐井观天。

2. 素材

我最近一年一直在做云原生相关的工作，期间我一直在思考，到底什么才是云原生架构，目前行业里对这个词有非常多的解释，但是所有这些解释都没法给让我满意，它们都过于偏重技术和云厂商的视角，而缺乏应用架构的视角。对于这个状况，我想基于过去一年，以及未来的相关工作，对云原生架构这个概念写一些东西，对其概念做一些补充阐述，帮助大家更好的使用技术，文章还没写出来，但是动机就这样形成了。

有了这个动机，再结合我自己个人的一些兴趣，过去一年我一直在积累素材，这些素材非常有意思。例如，我直接深入参与了国际化中台和考拉的项目，他们的架构基于云原生的技术，以及许多阿里云的产品，做了非常大的升级；我也详细了解了菜鸟如何在云上构建平台服务他的合作方公司；学习了解钉钉、IoT 这些本身在公有云上售卖服务的部门，自身是如何在云上架构。我通过 IM，电话或者面对面的方式和相关的同学沟通，他们都非常友好地知无不言，然后我整理相关的材料，再从中分析相同的模式。人脑非常喜欢模式识别的刺激，我在做这些事情的过程中也是乐在其中。除了实际的案例，行业资深人员的观点也是我平时收集素材的来源，例如林昊（花名：毕玄）最近写了一篇名为「云原生的进一步具象化」的文章，他们的文章通常不会人云亦云，仔细阅读会发现一些比较原创的观点。

除了上述和目标主题关联度非常大的素材外，我还发现跨学科的阅读也往往会给自己带来意向不到的收获。还是以云原生为例，虽然我在这个领域工作，但是最近一两年我一直在断断续续的阅读一些经济学的书籍，包括曼昆的《经济学原理》等（我估计好多人买了这套书了，但是真正认真读完的非专业人士还是比较少的）。在学习经济学的思维方式时，我就想从经济学的视角去解释云原生这个事情，原本自建的技术基础设施，在云的时代在逐渐演变的基于云的基础设施，这背后的选择对于业务来说，从经济学的角度应该怎样去分析？自建的成本和效用是什么？购买的成本和效用是什么？将复杂的业务技术架构拆分成一层一层之后，或许可以逐层分析，在每一层做一个从经济学角度最优的选择。

3. 思维导图

我最早了解思维导图是因为读了「Pragmatic Thinking and Learning」这本书，书中介绍思维导图的核心用途是把一个主题相关的所有内容，无论重要次要，都在一个图中写出来，那些不断拓展延伸的线，不是为了构成一个清晰的结构，而是为了给大脑显示什么地方思维可以进一步拓展。因此画思维导图的方式应该是尽量开放自由，目标是把主题相关的内容全部展现出来，思维导图的目的不是建立清晰的逻辑结构。因此，当我看到很多画的思维导图实际上是一个目录的时候，我觉得他们基本都用错了。

写文章（做演讲也是类似的），都是一个先开放后收敛的过程，在前期不断积累素材，使用思维导图拓展思维，建立材料的关联，就是开放的阶段。这个阶段中可以适当让逻辑思维退到幕后，把目光打开，不要过多评价（建立结构，分主次其实就是一种评价），用一种类似空杯的心态去倾听和观察现实世界及他人想法。我在做演讲或者做文章之前，总会先找个安静的地方，准备好咖啡，打开 MindNode，或者直接找拿出 A4 白纸和笔，给自己半小时到一小时的时间，把主题相关的思维导图画一画。安静免打扰的环境、没有时间的压力、富有精力的大脑，这些条件放在一起，才能够让自己从手头事务的聚焦中移开，让大脑中平时得不到关注的意识浮现出来，然后落到纸上。

4. 结构

将大量的材料胡乱堆砌在一起作成文章自然是不行的，作品必然要有一个清晰的结果。在建筑中，我们耳熟能详的有古希腊建筑的柱式结构，也有哥特式建筑以尖拱券、肋拱、飞扶壁等要素为核心的结构；在程序中，常见的 MVC、分层、微内核等模式也是清晰的结构。文章的结构能帮助作者把自己的观点清晰地表达，引导读者在清晰的路径中阅读。在有了思维导图之后，我通常会从那些纷繁复杂的材料中提取出一个最合适的结构，然后再基于这个结构组织材料。

写技术文章还是有一些常见的结构的，以下是几种范式：

• 解决问题型结构。这种范式通常围绕解决一个具体问题出发，常见逻辑是：背景介绍 -> 提出问题 -> 讨论解决问题的思路 -> 解决问题 -> 价值总结。这种结构可能是工程师最熟悉的了，因为大家都擅于解决具体问题。
• 知识介绍型结构。这种范式通常用于新技术的介绍，常见逻辑是：行业背景 -> 技术提出 -> 简单 Demo -> Core Conecpts -> 概念深入及 Demo （1-N次）-> 前景分析。大家平时看到的很多技术介绍文章通常使用的是这样的结构，这样的结构的好处是可以由浅入深地介绍新技术和新概念。
• 观点输出型结构。这种范式相较于前面的两种会更有挑战，常见的逻辑是：总体观点 -> 子观点 1 -> 子观点 1 阐述 -> 子观点 2 -> 子观点 2 阐述 … -> 总结。这种结构的文章写好了力度是非常强的，但是写起来非常有挑战，因为观点的阐述需要丰富的素材以及严密的逻辑推导，稍有不慎就有胡扯之嫌。

当然，我们在写作的时候不必拘泥于这些范式，也可以琢磨自己的范式，但不论何种范式，背后总是存在一个有逻辑关系的结构的。有一本书叫「金字塔原理」，我听到很多人推崇（尤其是在绩效季的时候），我看了下介绍和评价，讲的就是如何用高效地方式让对方理解你，我没读过这本书，但应该就是讲行文的结构和逻辑的，有兴趣的同学可以买来看看。

5. 观点

不是所有的文章都有观点的，例如你写文章总结自己如何解决一个性能问题，不一定需要有观点；介绍一项技术，如 Rust，不是非要表达观点。但是能够表达自己观点的文章通常会更有吸引力，例如解决性能问题的时候强调理解排队论的重要性，这就是一个观点，容易让人印象深刻；介绍 Rust 的时候，断言其在性能敏感的场景未来会占据统治地位，也更容易让这门技术吸引人的目光。当然，观点是需要论证的，其坚固性和你论证的投入度成正比，逻辑推导、数据支撑、案例分析都是非常好的论证手段。

我们也看到有一些文章满篇观点，但基本都是引用，一会是乔布斯，一会是张小龙，一会是马云等等；当然，更常见的是引用公司高管的话，谁谁谁在什么时候说过什么等等，然后用这些内容来支持自己的材料。我觉得偶有引用无伤大雅，总是引用就只能说明自己没有观点，或者观点无力，需要强力给自己支撑。

更有勇气，能体现自己素材丰富，思考深度的观点，反而是那些敢于说出皇帝的新衣的文字。技术文章应该是具备科学精神的，科学是基于对过去不断的 say no 发展出来的，技术文章也应该敢于表达 say no 的观点，不用怕得罪人，我们应该明白，正确的技术/架构/方案，应该是经得起质疑的，因为如果技术是错误的，即便当下环境没人敢质疑，时间长了，现实会让错误需要付出的代价呈指数倍上升。因此，相比于通篇正确的废话，敢于对现状 say no 并提出自己反面观点的文章，更值得推崇。

6. 故事

严格来说，给自己的内容添油加醋的整故事，对于逻辑论证没有任何帮助。然而要让自己的文章/演讲有吸引力，故事的元素是必不可少的。人类进化到今天，大脑对逻辑的反应是非常慢的，而且需要经过训练后才能理解逻辑，但是对于故事的反应，三四岁的小孩就有，人类早期流传下来的精神，例如希腊神话和圣经，都充满了精彩的故事。直至今天，无论公司内网，还是微博，大家对吃瓜的热情之高，岂是逻辑论证能点燃的。故事很容易引起人的共情，让人设身处地联想，然后大脑皮层就容易嗨了，神经网络被激活，各种激素开始分泌……

这是人类生理的现实，所以我们写文章的时候要尊重（利用）这个现实。要讲一下程序性能不好导致身边的同事半夜 3:20 分电话惊醒了；出了故障导致超市收银机被砸了，介绍新编程语言的时候要秀一段代码，顺便搞个对比说 Java 不行；介绍 Mesh 的时候就要说你原来升级中间件得这么干这么干，以后不需要了，等等……

我介绍自己「Maven 实战」的时候喜欢讲一个真实的故事：

在我书出版的前些年，因为虚荣心作祟，我特别喜欢去各大售书的网站刷评论，什么亚马逊，豆瓣，京东啊等等，一条条的去看，看到 5 星评价就喜滋滋，看到低1星或者 2 星的就很生气，当然，大部分评价都是很正面的。直到有一天，我在京东刷到一条 1 星的评论，我就一边难过一边打开评论，但读罢我就乐了，那个读者打 1 星的原因是这样的“让你们老板泡奶茶，差评！”原来是因为那阵子刘强东奶茶爆出了恋爱的新闻，伤了这位读者的心了，然后我就躺枪了。

这个故事其实和我在书中介绍的技术没有任何关系，但是我却喜欢讲这个故事，因为他会让听众会心一笑，然后记住我写过一本关于 Maven 的书。

烂文章是怎样的

讲了那么多怎么写好文章的方法，我也想说一下烂文章都长什么样。所谓烂文章，就是指那些对于读者来说，几乎没什么任何正面价值的文章，更有甚之，不仅没有正面价值，还存在负面价值。以下我稍作总结：

• 个人笔记成文章。自己解决了一个技术问题，做了一些记录，然后写成文章发出来了。这类文章充其量只能称之为素材，因为没有总结提炼，而且完全是从一个人的视角出发写的，读者读起来，不仅感觉不到体系，有价值的部分更通常是少的可怜。
• PPT 贴成文章。作者在某个地方作了一次演讲，因为想传播给更多的人，因此就用贴图的方式整理成了文章，好心点的，在图片的中间在补充一些解释文字，就这么成文了。我先假设这个演讲本身的质量是不错的，有逻辑，有观点，有案例，但是即便如此，这样的所谓文章，其阅读体验也是非常差的。在演讲中，PPT 是辅助“讲”的，如果只有 PPT，那真正核心的“讲”的部分就丢失了，因此，更负责任的做法，应该是演讲者用丰富的文字把所讲，用清晰的方式写下来，而不仅仅是那几页干瘪的 PPT。
• 用宣传战功的方式写文章。组织内部此类文章屡见不鲜，标题会带着很多常见的如“总结”，“年度”，“体系”，“反思”，“展望”等词，通常这类文章既没有体系，也罕见反思，其主要的目的是邀功。基本套路就是，写在在一年中做了很多事情，结果非常好，配几个看起来差不多的框框“架构”图，再直白点，就要上合影了。这类文章后面通常会有很多赞，但基本没有讨论，讨论个啥嘛？作者来邀功了，莫非你说他做的不好得罪人？从知识传播，促进思考的角度来看，这类文章价值几乎为零。
• 各类贴图成文章。相比用 PPT 贴图，还有用各种其他图贴成文章的，思维导图直接贴，设计图直接贴，流程图直接贴，监控图直接贴，一顿看下来就是没见几行字。好的图，的确是一图胜千言，但是那也仅仅应该是点睛之笔采用，如果篇所谓文章全是图，就完全看不出重点，也看不到体系。文字是非常有力量的，文字可以把读者拉入到作者的思考体系中，用逻辑和修辞去引导读者的思考。或归纳，或推导，让原本隐蔽的知识展现；或雄辩，或幽默，让作者的观点闪光。写作应该充分发挥文字的力量，不是只有图才有架构，不是只有图才能体现思考，相反，图往往因为其不精确性，成为很多人掩饰其思考不足的工具。
• 正确的废话成文章。官话套话，动辄抽象到极高的高度，从公司战略说起，洋洋洒洒一顿分析，满眼就是最近被抨击得厉害的那类字眼，什么“顶层设计”，“底层逻辑”，“赋能”，“抓手”之类；如果找不到清晰的逻辑，就来个 1.0，2.0，3.0，4.0，5.0，6.0，反正主版本号加 1 就是比前面牛逼了，至于为什么小版本号从来没人用，不知道，反正 N.0 就对了，直接 N 是不行的，直接 N.0.0 也是不行的。读罢这类文章你说不清楚哪里是错的，你唯一明白的就是这文章啥价值都没有，你又浪费了几分钟生命。

原文链接：https://developer.aliyun.com/article/783986?

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。