写分享文章这件事我断断续续做了快十年。前三年基本是在自嗨写出来的东西自己觉得挺满意发出去之后阅读量惨淡评论区除了几个朋友捧场几乎没有陌生人说话。后来我把过去几十篇分享文章翻出来逐篇拆解对比那些数据好的和没人看的发现了一个规律大家不是不想看分享而是大部分分享根本没说清楚这篇文章关我什么事。从那时候起我开始认真研究分享文章怎么写才有人看、看得完、看完有收获。这篇内容就是我对这件事的完整复盘适合每一个想把自己的经验、技能、踩坑经历写成文章分享出去的人。1. 先泼一盆冷水分享文章的本质是信息差不是自我表达很多人写分享文章的第一反应是我把我会的写出来就行了。这个想法听起来没毛病但恰恰是大多数分享文章没人看的根源。你要明白读者点开你的文章不是来了解你的是来获取他自己不知道、但想知道的信息。你写出来的东西如果只是我知道的而不是他不知道且需要的那这篇文章对他来说就是噪音。1.1 读者凭什么花十分钟读你的文章我刚开始写技术分享的时候特别喜欢事无巨细地记录自己做了什么背景铺垫写一大段中间过程流水账一样记下来最后加上一句成功了分享给大家。这种文章现在的我一眼就能看出问题它从头到尾只回答了一个问题——我经历了什么而读者真正关心的问题是——我能得到什么。后来我给自己定了一个规矩动笔之前必须用一句话回答这篇文章能让读者拿走什么。这句话如果说不出来或者说出来之后发现是了解了一些背景知道了一个人的经历这种空话那这篇文章就别写了写出来也是浪费彼此时间。信息差这个事想清楚就很简单读者知道的东西和你知道的东西之间存在差距你的文章就是在填这个差距。差距越大文章越有分享价值。差距越小文章就越像闲聊。1.2 三种最常见的分享类型对应三种不同的读者预期根据我这些年的观察分享文章大致分三类每类读者看文章时的心理状态完全不一样。第一类是技能教程型比如教你用Python批量重命名文件三分钟搭一个个人博客。这类文章的读者预期非常明确我照着做能不能做成。他要的是步骤、命令、参数、验证方法他不在乎你当时的心情也不在乎你走了多少弯路他只在乎结果。第二类是经验复盘型比如我在生产环境踩了一个内存泄漏的坑这个活动方案为什么失败了。这类读者的预期是我想知道你是怎么栽的、怎么爬出来的这样我遇到类似问题能少走弯路。他要的是背景、过程、原因分析、排查链路而不是干巴巴的结论。第三类是观点洞察型比如为什么很多工具用的人越多越难用深度学习框架选型的底层逻辑。这类读者想看的是你的思考过程是你的分析框架是你得出这个结论的依据而不是结论本身。很多分享文章扑街不是因为内容差而是因为类型没分清。你用教程型的写法去写经验复盘用复盘型的节奏去写观点洞察读者预期落空自然看不下去。1.3 写之前问自己三个问题省掉一半无用功我现在每写一篇分享文章之前都会在文档最上面写三句话这篇分享的核心信息是什么用一句话说清楚。谁最需要这个信息越具体越好比如刚转行做前端、第一次接触构建工具的开发者而不是所有人。他看到这个信息之后会做什么会照做会避开一个坑会改变一个认知这三个问题回答不上来文章就先放着。这个习惯帮我过滤掉了至少一半的选题冲动。你想分享的心情可以理解但读者不欠你阅读时间你得靠内容把时间挣回来。2. 选题定生死选题没选对写再多技巧都救不回来这是我在拆解自己文章数据时感触最深的一点。同样是认真写、认真排版有的文章发出去一周还陆续有点赞有的文章发出去两小时就沉底了。差别不在字数、不在标题、不在文笔在选题。2.1 自嗨式选题和需求式选题差距比想象中大自嗨式选题的特征是这件事我特别有感触所以我要写一写。需求式选题的特征是这件事很多人反复遇到且没有好的解决方案我写一个出来应该能帮到人。举两个我自己的例子。我以前写过一篇关于某个旧代码重构心得的分享写的时候觉得自己提炼得特别到位发出去之后阅读量不到一百。后来我写了一篇两个常用命令搞坏数据库后怎么恢复的文章素材来自一次线上事故处理发出去当天阅读量过了三千评论区全是问细节的。区别在哪里重构心得这件事读者得先对你的项目背景有兴趣才会关心你的重构过程这是一个非常窄的需求场景。而命令搞坏了数据库怎么办几乎所有写代码的人都可能遇到这是刚需。阅历丰富的人都知道内容是雪中送炭还是锦上添花读者心里分得很清楚。2.2 三个屡试不爽的高价值选题方向这些年我总结下来有三类选题方向几乎是长盛不衰的。第一类是坑复盘。人在遇到问题的时候是最饥渴的他要的是一个明确的解决方案或者一条完整的排查思路。你要做的就是把一个坑从出现到解决的全过程整理出来重点放在我是怎么定位到这个原因的而不是我用了什么工具。第二类是对比选型。工具选A还是选B、方案用C还是用D这种问题永远有人问、永远没人能一次答全。你只要真实对比过把边界条件、成本、指标、坑都列出来文章就有长尾价值。第三类是原理拆解。很多人会用某样东西但是不懂背后原理你把这个原理讲透讲明白讲得让一个新手能听懂这就是高质量分享。我后来慢慢形成习惯灵感来的时候先不急着写先记到备忘录里过三天再回来看如果还是觉得很值得写再动手。冲动期写的东西大多是自嗨式选题。2.3 验证选题别闭门造车出去看大家在问什么一个人拍脑袋想的选题很容易偏离真实需求。我现在写之前会花二十分钟做一轮快速验证。技术类的选题就去搜索引擎和相关社区搜关键词看看有多少人在问类似的问题问题下面有多少条回复回复质量怎么样。如果一个问题被反复问了很多遍但现有答案都很零散、不完整这就是一个很好的分享切入点。生活类、职场类的选题就去社交平台看话题讨论观察评论区里人们的情绪和困惑点那些点赞高的问题就是需求信号。还有一种办法特别简单把自己在实操中觉得这个东西当时如果有人告诉我我能少花很多时间的小经验记下来。这种瞬间是你最真实的选题来源因为它意味着这件事确实存在信息差。3. 结构是隐形骨架读者不关心你的顺序但会被顺序影响选题选好了接下来就是怎么组织内容。分享文章的结构和论文、报告不一样论文允许你先铺垫背景再抛出观点读者为了学术目的能忍。分享文章不行读者是用碎片时间在刷手机他给你十秒钟的耐心这十秒钟内没有看到想看的东西手指一滑就划走了。3.1 开头一百字的任务不是铺垫是承诺我复盘过自己数据最好的几篇文章它们的开头有一个共性前一百字之内读者一定知道这篇文章能给他什么。比如我写数据库恢复那篇文章开头第一句就是如果你不小心在生产环境执行了一个带条件的删除命令然后发现条件写错了不要慌下面讲的这套流程能救你大半的数据。这句话没有自我介绍没有背景铺垫没有心情描写直接给承诺读者瞬间就明白了这篇文章解决我的问题我值得往下看。反过来很多分享文章开头先写做这个项目的初衷是……不知不觉工作已经五年了……这些内容不是不能写但不能放在最前面。放在最前面等于逼着读者先看你无关紧要的前戏他大概率会直接走人。我个人的经验是开头一百字里把读者是谁、会解决什么问题、他能得到什么至少说清楚两样。剩下那些情绪化的、背景性的内容如果一定要写放在后面也来得及。3.2 一个H2只讲一件事章节之间要有递进感有人写分享文章喜欢把内容一股脑倒出来从头讲到尾中间不划分章节。这种文章在移动端看起来就是一堵厚厚的文字墙读者很快就失去耐心了。我写长文一定会划分章节而且我给自己定的规矩是一个二级标题只讲一件事这一件事必须在标题里直白地说清楚。比如配置文件里的字段冲突是怎么一步步定位到的读者只看目录就知道这一节在讲什么不用猜。章节之间的顺序我一般遵循看清问题 → 拆解原因 → 给解决方案 → 回顾预防这个链路。这样读者跟着文章走下来心里是顺畅的先和你一起确认问题是什么再跟着你的思路看原因然后拿到可执行的方案最后知道以后怎么避免。千万不要小看这个顺序。读者阅读的时候脑子里其实是跟着你的章节目录在建一个物理模型他每读完一节就有一部分模型被填上。如果章节顺序乱了这个模型就会被反复推翻阅读成本急剧上升。3.3 段落越短越友好长段落是阅读热情的杀手我之前有个坏毛病喜欢写超长段落一段写二三百字觉得这样才叫思路连贯。后来看后台的阅读完成率数据发现文章后半部分的完成率断崖式下跌。从那以后我刻意训练自己一个段落只表达一个核心意思一般控制在四到六行之内。手机上看起来大概两三屏这个长度读者不会觉得喘不过气。还有一个排版技巧很实用段落之间的小标题不要怕多该用就用。小标题相当于给读者设置一个又一个小的阅读目标每读完一个就会产生一点成就感支撑着他继续往下读。但是小标题一定要言之有物别用为什么要这样做核心细节解析这种放在哪篇文章里都成立的套话。4. 干货的密度决定收藏率把我知道变成你能用分享文章最容易被人收藏的从来不是感想而是那种我拿过去就能用下次遇到我会了的实感。干货不是你知识的堆砌而是你经验的浓缩和转化。4.1 干货的定义可迁移、可复用、有边界我在判断一个内容算不算干货的时候会用三个标准第一可迁移性。这个东西能不能从我的场景平移到读者的场景比如这种排查思路可以应用到所有带缓存组件的系统里就比我改了一个参数系统就恢复了有干货属性。第二可复用性。读者看完之后下次遇到同类问题是不是能拿出一个可以照做的流程哪怕这个流程粗糙一点也比没有强。第三有边界。你有没有说清楚这个方案在什么条件下成立、什么条件下不成立很多文章被人吐槽照做了没用多数原因是作者没写边界条件。你要在文章里明确写出来这个做法只适用于MySQL 8.0及以后的版本这个方法在数据量超过一千万行的时候需要额外优化读者才能安全地应用。4.2 把隐性经验显性化是分享文章最核心的能力大多数从业者有一个通病自己觉得理所当然的东西就不写了。但那是你觉得理所当然对读者来说可能就是最大的障碍。举个例子你做一道菜菜谱上写盐少许、大火收汁你可能觉得这不是废话吗但对一个新手来说少许是多少、大火是多大完全没概念。分享文章的价值就在于把这种含混的经验转成可执行的量盐两克左右、中大火焖五分钟。技术文章也一样。你写出数据库连接池设置成20太大会导致连接浪费读者可能就看看但如果你写出我对比过50并发和200并发下的表现20个连接的时候延迟上升明显10个连接的时候明显不够用最后设在15各项指标最均衡这就成了实打实的干货。我每次写完初稿都会做一件事把文里的每一段经验描述都过一遍凡是出现应该、大概、一般而言这种模糊词的地方就问自己能不能写得更精确。能加数据加数据能加条件加条件能加对比加对比。这个操作能直接把文章的干货密度拉高一截。4.3 失败经验和边界条件同样重要甚至更重要很多分享文章只写成功路径对失败部分一笔带过这种做法很可惜。真实场景里失败才是最有教学价值的部分。我写文章时会专门留一部分讲我试过但没成功的方法以及为什么没成功。比如我那个数据库恢复的文章里就写了尝试过直接重放二进制日志但失败了因为删除语句也记录在里面重放会再次执行删除。这个失败经验反而帮很多读者理解了为什么不能直接重放日志这个底层逻辑。边界条件我会单独拎出来写成一节哪怕只有三四行字也绝不省略。我的经验是一个读者如果因为没看见边界条件而照做失败他不仅不会再看你的下一篇文章还可能专门回来骂你。边界写清楚是保护读者的也是保护自己的。5. 语言和排版是礼貌再好的内容也需要被读下去文章内容和结构都排好了最后这道工序是语言和排版。我不认为文笔好等于辞藻华丽对分享文章来说文笔好的定义是表达准确、阅读流畅、不费力就能理解意思。5.1 说人话把专业术语翻译成读者能懂的表达写分享文章久了你会渐渐发现自己开始说行话这没问题但如果全文都是行话读者门槛就被抬高了。我的原则是核心术语第一次出现时用一句话做通俗解释不需要刻意绕开术语但要让外行能往下读。比如写内存泄漏我用生活类比补了一句可以理解成有一个程序从系统总内存里借了一块空间用完不还系统可用内存越来越小最后其他程序都没地方住了。这个类比不严谨但它让零基础读者快速建立起一个大致的概念对往下读是有帮助的。相反有些文章喜欢用术语展示专业度写完复盘工具用KubernetesService MeshgRPC一类的名词一个接一个往外抛读起来压力很大。你是在分享不是在做技术答辩。5.2 排版本身就是阅读引导我排版的时候有几个固定动作正文里的代码块、命令行、文件路径一律用代码格式标注正文里的关键结论或者重点提示用加粗单独拎出来重要的操作步骤用有序列表一项一项列出来涉及对比的信息用表格整理。表格在分享文章里特别好用。比如你在对比两个方案的优缺点与其写两三段话来回比较不如做成一个两栏或三栏的表格读者扫一眼就抓住了差异。同样的信息表格能省读者一半的时间。还有一个细节容易忽略图片。如果是技术类分享核心的界面截图、运行结果截图、报错信息截图该放就放。特别是报错信息你直接把真实报错贴出来读者搜索时才能搜到你的文章。搜索引擎是按字符串抓的你手打一个系统提示参数错误和真实报错ORA-00933: SQL command not properly ended带来的流量差距是十几倍。5.3 发出去之前用读者的视角通读一遍每次写完初稿我会把文章搁置至少几个小时最好是隔夜。隔一段时间再读很容易发现自己当时没意识到的问题哪一段铺垫太长、哪个步骤没写清楚、哪个术语没解释。通读的时候我会做两件事第一件把自己当成一个完全不了解这篇文章主题的读者从头到尾读一遍所有卡住的地方做标记回头修改——这个过程中我通常会删掉三分之一的内容第二件拿手机打开预览检查排版效果。手机上显示的状态和电脑上完全不一样很多人在电脑上看着段落很舒服一上手机就成了一堵墙。现在的编辑器基本都有手机端预览功能发布前过一遍这个流程能避免很多看起来不专业的问题。6. 发布之后才是真正的开始数据、评论和下一篇文章写完发出去了很多人觉得任务完成其实分享文章的闭环有一大半在发布之后。6.1 发布渠道怎么选取决于你分享的类型和读者在哪里技术类分享主流的垂直社区是首选这些平台的用户搜索意图很强长尾流量能给文章带来持续曝光。观点类、经验类的分享社交平台和问答社区更合适这类内容靠的是话题讨论的连带传播。我的习惯是一文多发但每个平台做一点适配。技术社区的文章把代码块和命令写全社交平台把开头一百字改得更口语、更有钩子问答社区则把核心结论前置到第一段。同一个内容在不同平台上的呈现方式完全不同这不是偷懒是基本礼貌。还有一个不算新的新趋势是现在很多平台的推荐算法对看完率非常敏感。文章越长被看完的难度越大但算法恰恰会把看完率高的长文推荐给更多用户。所以与其担心长文没人看不如把功夫下在结构和节奏上让读者愿意看到最后。我发现结构清晰、有小标题的文章看完率明显高于同等长度的纯文字墙。6.2 评论区是干货的富矿别错过很多人发完文章就不看评论区了我觉得这是巨大的浪费。评论区里藏着读者最真实的需求——他觉得哪里没看明白、想让你补充什么、他自己在这个问题上有没有其他解法。我有好几篇文章的续篇就是从评论区的提问里酝酿出来的。比如一开始发命令恢复数据的文章读者在评论区问如果误删了整张表怎么办如果数据库没有开二进制日志怎么办这些问题比我自己闭门造车想出来的选题精准得多因为它们背后是真实的场景。我处理评论区的习惯是所有技术性的提问尽量在评论里直接回答如果回答比较长就把回答补充到原文里在文末加一句根据评论区补充了xx情况下的处理方案。这样文章内容越来越厚后来者能看到的信息也越来越多。6.3 用数据反馈调整下一篇而不是用数据否定自己刚发文章的时候我几乎每分钟都要刷一次数据看到阅读量不涨就焦虑。后来我想明白一个道理这篇文章的数据已经定格了与其盯着它看不如思考下一篇怎么写。我现在会看三个核心指标。第一是阅读完成率如果很多人在文章中间某个位置退出说明那段内容要么太无聊要么太长第二是收藏和点赞的比例如果收藏量明显高于点赞量说明内容有实用价值但可能读起来有点吃力第三是评论区的提问内容问得最多的那个点就是下一篇可以展开深入的主题。这些数据不直接说明你写得好不好但它们能告诉你读者对什么感兴趣、在什么地方有困惑。带着这些信息去看下一篇的选题和结构写出来的文章质量会越来越稳定。一些平台后台还能看到用户搜索进入文章的关键词这些词是很好的选题素材我曾经靠这个方法确认了一个冷门但需求旺盛的方向后来那篇文章给网站带来了好几个月的稳定流量。写分享文章这几年我最大的体会是表面上看你是在帮别人省时间、避坑、学东西实际上最大的受益者是你自己。为了把一件事讲清楚你必须逼自己想明白很多细节那些以往你习以为常、从没深究过的细节都会在这时候浮出水面。我很多关于自己项目的深入理解不是在做项目的时候想通的而是在写分享文章的时候想通的。从这个角度说哪怕你的文章没人看只要认真写了这笔账也是赚的。当然如果用了上面这些方法大概率还是有人看的。