很多人觉得写第一篇文章最难的是文笔但我这几年回头看发现真正卡住大多数人的是那个不知道该写什么的空白期。我自己第一篇正式发出来的技术文章前后改了七版从两千字憋到五千字又删回三千字最后发布时手都在抖。现在回头看那篇文章有很多幼稚的地方但它确确实实把我推上了持续输出这条路。这篇文章不聊虚的就聊我从零到一写完第一篇文章的全过程怎么定选题、怎么搭骨架、怎么写初稿、怎么改到能见人、怎么面对发布后的冷清和反馈。如果你也正卡在想写但还没动笔的状态这篇文章应该能给你一些能直接用的思路。1. 第一篇文章的选题别追热点先翻自己的记录1.1 一个反直觉的结论好选题往往藏在你过去三个月的聊天记录里我一开始犯的最大错误是想写一个看起来厉害的话题。当时市面上流行容器化、微服务我也跟风列了一堆宏大的标题结果坐在电脑前两个小时一个自然段都没憋出来。原因很简单我对那些话题的了解仅限于看过几篇博客没有真正动手解决过问题没有踩过坑写出来全是教科书式复读。后来我换了个思路把自己过去三个月在团队群里的提问、在Stack Overflow上的收藏、在笔记本上记录的报错信息全部翻了出来。我发现一个规律那些我反反复复跟同事解释过的问题——比如某个配置项为什么这样写、某个报错到底是怎么触发的——恰恰是我最有资格写的话题。因为跟别人解释过意味着你已经把这件事从头到尾想明白了你清楚别人会在哪里卡住。所以选题的第一原则不是这个话题热不热而是这件事我是不是真的亲手解决过。第一篇文章不需要惊艳四座它需要的是你能完整地讲清楚一个闭环遇到了什么问题、怎么一步步排查、最后怎么解决、解决了之后有什么反思。这种文章哪怕选题再小读起来也是有血有肉的。1.2 把想写的和能写的分开列两张清单具体的操作方法我建议你拿张纸或者开个文档左边列出我觉得这个话题很酷的清单右边列出我最近真的做过、踩过坑的清单。然后优先从右边清单里挑选。为什么这个动作很关键因为左列的选题会让你产生我必须写得很专业的心理压力而右列的选题天然自带叙事素材。举例来说容器化改造实践这种题目听起来大而空但记一次Docker容器内时区问题的排查就是你真正遇到过、查过资料、最终解决的真实经历——两者写出来的质感完全不同。做完清单对比之后还有一个判断标准你能不能只用三句话向一个外行说清楚这篇讲什么。说不清楚说明这个选题在你脑子里还没成型硬写必翻车。我当时定下来的第一篇选题是离线环境下的依赖包安装踩坑记录三句话就能讲明白你装包的时候没有外网怎么办、有哪些绕过去的办法、每种办法有什么坑。这就够了。1.3 第一篇文章的边界感第一篇文章最容易犯的毛病是想把一个小问题写成一本书。我见过不少人写第一篇就列了二十个小节从背景讲到原理从原理讲到架构最后实操只占一小段——这种文章注定烂尾。给第一篇文章做一个范围限定其实是在保护你自己。我当时给自己立了三个规矩第一只写一个场景离线环境的包安装第二只覆盖两个核心方案本地源镜像和离线包导出第三每一节都要有一个我当时就是这么做的的具体步骤。这样写起来节奏感很强你不需要为了填字数去水内容反而能把核心部分写得有肉。2. 动笔前先搭骨架素材是砖结构是混凝土2.1 先攒素材而不是先写正文我第二版之所以废掉就是因为我在没有任何素材积累的情况下硬写。写到中间发现这个细节我记得不太清那个命令的完整路径得查一下于是频繁切出去搜资料思路断了十几次最后一篇好好的回忆录写成了信息碎片集。正确的做法是先花一到两天只做素材收集绝不碰正文。把你能想到的所有相关信息——聊天记录、截图、代码片段、报错日志、当时查过的文档链接——全部丢进一个素材文档里不用管顺序和条理只需要有。我当时的素材来源有这么几类技术类复现问题时的命令历史history命令直接导出、改过的配置文件前后对比、报错信息的完整文本。心路类当时排查的思路尤其是我一开始错误地以为……后来才意识到……这类转折点这是文章的宝贵素材。教训类哪些地方浪费了时间、哪些方案试着试着就放弃了以及放弃的原因。这些素材在写作阶段就是你的弹药库。没有弹药你写什么都虚。2.2 给素材分类技术事实、经验判断、采坑教训素材收集完之后我建议你按三个类别做一次标注这个动作会在你动笔时省下大量力气。第一类是技术事实比如执行A命令报B错误C版本之后默认开启了D功能这类内容负责支撑你的操作描述必须准确不能含糊。第二类是经验判断比如遇到这个报错先检查配置文件比重启服务更快这类内容是你的观点输出也是读者最想要的东西。第三类是采坑教训比如不要直接在生产环境执行那条清理命令这类内容是文章的避雷针让读者避免重蹈覆辙。我当时用三种颜色的高亮笔给素材做标记写作时一眼就能看到手上有什么资源。如果你用的是文档工具建三个二级标题分门别类放进去也是一样的效果。2.3 骨架怎么搭结论先行然后按你来经历一遍的顺序组织素材齐了之后千万不要急着写正文。先花半小时把骨架列出来——只列H2和H3标题每个标题下面用一个句子说明这一节打算讲什么。这里有个很重要的组织原则要按读者的认知顺序而不是你当时的时间顺序来组织文章。你排查问题可能是东一榔头西一棒子的但写文章不能这样。我当时排查的过程中至少走了三次弯路但写出来的时候我按的是为什么会有这个问题——最常见的错误做法——当时我尝试过的三种方案——最终可行的方案——这类问题的通用排查思路这个顺序。这样的顺序让读者看完能带走一个可复用的方法论而不是只吃到一个瓜。骨架搭好之后你还要做一个动作把骨架拿给一个同事或者朋友看一眼让他判断只看标题你想不想读这篇。他如果说不清楚你想讲什么说明你的H2标题取得太抽象了。好标题的标准是读标题就能知道这一节的内容和分量。比如## 环境准备这种标题就抽象## 在无外网机器上装包两类核心工具的区别就具体得多。3. 初稿写作先完成再完美3.1 不要边写边改初稿的任务只是把话说出来我前两版之所以写不下去很大一部分原因是开了边写边改模式。写一段觉得用词不好调写一段觉得段落太长拆写到三分之一又回头改前面的章节标题……最后整个下午就在原地打转。后来我学到一个方法初稿阶段关掉所有审美判断告诉自己这个版本只有我自己能看到我的任务只是把脑子里所有想法倒出来。用词的准确、句子的节奏、段落的分配全都是修改阶段的事。你只需要确保一点今天的写作时段内你写完了一个完整链条没有半途停在一个你没想清楚的地方。如果写到某个环节发现自己讲不清楚怎么办我当时直接在文档里留一个标注[这里需要补一个当时测试的截图xxx] 或者 [这段要查一下A命令和B命令的准确参数]。不要停下来去查先跳过去往后写。因为一旦停下来去查你又会陷入素材收集的无限循环文章永远写不完。3.2 新手最容易忽略的以读者能看到什么为视角写操作步骤说人话这件事在写技术文章的操作步骤时尤其重要。很多新手容易写成执行命令A得到结果B看起来很清晰但读者没法跟着做——因为你看似告诉了他步骤实际省略了大量隐含前提。我举一个最简单的例子。如果我要写在离线环境安装tensorflow错误的写法是使用pip install tensorflow-2.8.0-cp38-cp38-linux_x86_64.whl然后完事。正确的写法至少要包含我是在哪台机器上、什么系统版本下执行的这个whl文件是从哪个来源拿到的官网朋友机器内网共享安装之前是否需要先装依赖的依赖如果装有conda是否要先切换到目标环境。这些废话恰恰是新手最需要的信息。我写作时给自己提了一个要求假设读者就坐在我旁边他能看到我的屏幕我要把他需要看到和操作的东西一个字一个字地讲给他。这个视角的转变能让你的文章实用性大幅提升。3.3 代码和报错信息要原样呈现不要美化第一篇文章的代码块最常见的通病有两种。一是代码片断不完整只贴了关键几行前后文缺失读者根本没法复现二是报错信息只贴了最后一行实际上排查问题最重要的恰恰是那几行完整上下文。我当时写离线安装那篇把完整的报错堆栈全部贴了出来甚至包括中间那些看起来没什么用的Warning。因为我知道读者去搜索一段报错时他是拿着完整的报错去搜的我的文章如果能和那个报错匹配上他就能快速找到问题根源。而如果你只贴一个主错误他搜到你的文章也未必敢确认这就是我的问题。这个细节还有一个作用它让你的文章显得很真。一个完整的、带着奇怪路径和具体版本的报错信息是编造不出来的。这种真实感在新手期尤其值钱它能帮你建立读者信任。3.4 在一口气写完和分多天写完之间找自己的节奏我知道很多人会推荐一鼓作气写完初稿但实际执行起来一鼓作气在纯下班后的业余时间里几乎不可能。我自己的经验是把初稿拆成连续三天的写作任务Day1写背景问题重述Day2写排查过程和方案Day3写总结和复盘每天保持同一个节奏不要在中间间隔太久。间隔的度很关键。如果每天写你的思路是连续的不需要花太多时间回顾前一天的内容如果间隔一周那你重新进入状态的成本就很高甚至想推翻重来。第一篇文章不是学术论文你不需要把它当作一个周末大工程来完成拆成小块反而更容易坚持。4. 修改打磨从能看到能发至少要过三道关4.1 第一道关趁热修改把初稿当成别人的代码来评审写完初稿后的第二天我推荐你做一次趁热修改。所谓趁热是趁着你对自己的素材还有记忆的时候赶紧把那些初稿里标注的待补充信息补上把语无伦次的段落理顺。我把这一步比喻成给自己的文章做一次代码评审。你在公司Review别人的代码时一定会问这些问题这个函数为什么这样命名这个边界条件有没有处理这个注释有没有意义同理你读自己的初稿时也要用读者视角来审视读者看到他需要执行的命令他能不能看清楚命令在哪个目录下操作我有没有解释为什么需要先做这一步而不是直接把步骤丢出来我是不是默认读者知道某个概念了比如我默认他知道conda环境是什么那要不要给个一句话说明这个阶段不要吝啬删减。凡是和主线无关的素材一律砍掉或者留到附注/扩展阅读里。我当时删掉了大概三分之一的素材比如中间一次失败的方案试验、一些历史背景的介绍这些东西放到文章里会让读者的注意力从主线上飘走。第一篇文章的通病是全都想要作者希望把每一个踩过的坑都讲一遍结果每个坑都只讲了一句话读者哪一段都觉得不够深入。砍素材其实是在保护你真正的核心内容让它们的密度更高、更可观。4.2 第二道关隔一天再改让创造模式切换到批判模式趁热修改之后我强烈建议你把文章放一天第二天再回来改。这个冷却期的作用是让你从作者身份切换到编辑身份。写文章的时候你会不自觉地护着自己的内容觉得每一句都有存在的理由。但隔了一天之后你再看那篇文章它就变成了一个陌生文本你更容易发现它哪里逻辑不顺、哪里例子突兀、哪里废话连篇。我第二次大改的时候发现了好几处问题有一个段落我明明想表达方案B效率低但前面花了大段文字讲方案B的原理读者很有可能误解成作者很推崇方案B还有一张截图是旧版本的界面和新版操作对不上。这些问题当天我是看不出来的。这一轮改稿我建议你把注意力放在两个维度。第一检查每一段的主题句确保每段都在讲一个明确的事情第二检查所有过渡句确保从上一段到下一段读者不会觉得跳。我经常用所以呢和然后呢来检查过渡。读完一段后问一下所以呢如果答案接不上下一段说明过渡出了问题需要补一句连接。4.3 第三道关发布前的朗读检查和技术准确性核对上一轮改完之后就到了发布前的最终检查。这一步我推荐你做两件事。第一朗读一遍全文。不用出声在脑子里默读也行关键是要注意那些读起来别扭的句子。技术文章经常出现的通病是英文术语和中文连接词混合导致的语感断裂比如我们可以通过这个配置项来enable该功能读起来就不如我们可以通过这个配置项来开启该功能顺畅。朗读能很敏锐地暴露出这类问题。第二核对你引用的每一条命令、每一个参数、每一个版本号。哪怕你有九成把握是对的也建议在真实环境里再跑一遍或者对照官方文档确认一次。我写第三篇文章的时候引用了一个Python包的API参数结果自己写错了发布后被读者指出来那感觉真的非常尴尬。第一篇文章是你的门面技术准确性上一旦出问题读者对你的信任会打很大折扣。如果你是技术类文章这一轮还要检查你贴的代码块是否完整、缩进是否正确、有没有把敏感信息比如IP地址、密码、token忘记打码。我见过有人把生产环境的数据库连接串直接贴在文章里的那是真的社死级别的错误。发布前一定要通读一遍所有代码块和截图确认没有泄露任何不该泄露的信息。4.4 需要一个外部视角找人做一次预读如果条件允许在发布前找一个目标读者帮你预读一遍。这个人最好不是你的同行而是和你目标读者水平相近的人或者至少是一个愿意说真话的朋友。你请对方帮的不是纠错而是回答三个问题能不能看懂主线哪一段开始走神了哪一段你会跳过去不看这三个问题的答案能告诉你文章结构上的真实问题比你自己反复改十遍都有效。我当时找我老婆做了一次预读她完全不懂技术但在读离线环境下装包那篇时她唯一的问题是为什么要离线——这让我意识到我缺了一段背景交代我默认所有读者都知道生产环境往往不能上外网这个前提但对纯新手来说这个前提恰恰是需要解释的。后来我补了一段两句话的背景说明文章的适用读者群一下子就变宽了。5. 发布之后冷清、反馈与心态调整5.1 第一篇发出后没有人看很正常你可能满怀期待地等着第一篇发布后马上有人点赞收藏评论但实际的情况往往是发布后的前48小时阅读量屈指可数收藏和评论更是为零。我当时的心理落差非常大一度怀疑是不是文章质量太差了。但后来我想明白了一个事实你的文章在平台上的曝光取决于平台分配给你的初始流量这个初始流量和文章的话题性高度相关。作为纯新人没有粉丝、没有历史互动记录哪怕文章质量不错初始推荐也少得可怜。这和你文章好不好没有直接关系纯粹是冷启动的客观规律。我能给的建议是发布后的第一周尽量不要频繁刷新数据页面。把这个时间用来写第二篇文章。因为数据焦虑会严重干扰你的创作节奏而创作节奏是新手期唯一需要死守的东西。5.2 哪怕只有一条评论也要认真对待冷清归冷清但万一真的有读者留言了一定要认真对待。哪怕对方只是说了一句我也遇到过这个问题原来是这样解决的那也是一次真实的反馈说明你的文章确实触达了目标读者。我记得我的第一篇文章收到的最有营养的一条评论是追问如果在离线环境下没有局域网源怎么办我当时只写了两种方案没想到这个边界场景。这个评论直接帮我孕育了第二篇文章的选题。你看读者的反馈能帮你发现自己的盲区这是纯靠自己想很难获得的信息。5.3 用数据校准而不是用数据评价自己发布一周之后我会去看一次后台数据看的是两个指标平均阅读进度和跳出率。如果阅读进度普遍在50%以下说明文章的前半部分有问题要么引入太慢要么背景铺垫过长读者没有等到精彩的部分就划走了。但这里必须有一个心态建设这些数据是给你的下一篇文章用的不是给你上一篇文章下判决的。每一篇文章都是一个实验你通过数据知道哪个开头更抓人、哪种段落节奏更舒服、哪个长度更合适然后把这些经验用到下一篇。新手期的核心任务是建立写作的正循环而不是写出第一篇爆款。6. 把第一篇文章变成持续写作的起点6.1 建立一个最低限度的写作节奏第一篇文章发出去之后最重要的事情不是庆祝而是趁热打铁确立一个可持续的写作节奏。我见过太多人发完第一篇就陷入下一篇什么时候写的迷茫一拖就是两个月最后热情彻底凉了。我的建议是第一篇文章发布后的一周内就启动第二篇的选题。上一篇的某个边界场景、某条读者的评论、你当时砍掉的素材里那块最亮的碎片都可以成为下一篇的起点。写作节奏不需要很密集每周或者每两周一篇关键是稳定。稳定输出的价值远远大于偶发的高质量长文。你想想读者关注的不是你某一篇写得多好而是他能预期你每到周三就会更新这种预期本身就是影响力。我自己当时定的节奏是一周一更周日写周一改周二发布。这个节奏坚持了大约半年那时我才敢说自己勉强养成了一个写作的习惯。为什么这么强调节奏因为写作能力本质上是持续性产出的能力而不是灵感的爆发。你写得越多就越能感觉到自己从一个靠状态写作的人变成了靠系统写作的人。6.2 建立自己的写作素材池第一篇写作过程中你一定会发现那些随时可能用到但又不适合塞进这篇文章的信息。我建议你从第一天开始就建一个专门的素材池把你平时在工作里遇到的小问题、灵光一闪的解决方案、甚至一句来自同事的有意思的总结都扔进去。素材池不需要结构化一个备忘录就够了。它的作用是你下一个不知道写什么的夜晚打开它就能找到三五个可以写的选题。写作最怕的不是写不出来而是打开编辑器却不知道写什么——素材池恰恰是为这个场景准备的。我自己的素材池里大概常年躺着三四十个未展开的草稿条目有的话题已经放了一年了但当我某天就是想写点轻松的东西时翻一翻总能找到合适的。6.3 第一篇不是终点它是你的最低可行产品用产品思维来看第一篇文章它其实是你作为创作者的最低可行产品。它不需要完美不需要面面俱到甚至不需要很大影响。它只需要做到一件事证明你能把一个想法完整地写出来并发布出去。这个完成闭环的动作比任何事情都重要。因为一旦你完成了第一篇文章你就不再是那个想写但一直没写的人了。你会开始积累自己的写作方法论你会在写第二篇、第三篇时感受到明显的进步你会逐渐形成稳定的表达风格。这些都是从第一篇这个起点慢慢长出来的。我自己的体会是第一篇最大的意义不在于它吸引多少流量而在于它让我发现了写作这个动作对我思考的帮助。当我发现自己写出来的东西比脑子里想的更清晰我就知道这个习惯值得长期做下去。如果你也准备写下你的第一篇文章那就从今天开始攒素材吧。不要等准备好了再写你永远不会完全准备好——但你可以先写出一堆素材再搭出一个骨架然后跌跌撞撞地完成初稿最后让它面目一新地出现在读者面前。 
长河君 · 2026/9/9 21:46:49 · 阅读 1.2k 从零开始写第一篇技术博客：选题、写作与发布全流程指南
很多人觉得写第一篇文章最难的是文笔但我这几年回头看发现真正卡住大多数人的是那个不知道该写什么的空白期。我自己第一篇正式发出来的技术文章前后改了七版从两千字憋到五千字又删回三千字最后发布时手都在抖。现在回头看那篇文章有很多幼稚的地方但它确确实实把我推上了持续输出这条路。这篇文章不聊虚的就聊我从零到一写完第一篇文章的全过程怎么定选题、怎么搭骨架、怎么写初稿、怎么改到能见人、怎么面对发布后的冷清和反馈。如果你也正卡在想写但还没动笔的状态这篇文章应该能给你一些能直接用的思路。1. 第一篇文章的选题别追热点先翻自己的记录1.1 一个反直觉的结论好选题往往藏在你过去三个月的聊天记录里我一开始犯的最大错误是想写一个看起来厉害的话题。当时市面上流行容器化、微服务我也跟风列了一堆宏大的标题结果坐在电脑前两个小时一个自然段都没憋出来。原因很简单我对那些话题的了解仅限于看过几篇博客没有真正动手解决过问题没有踩过坑写出来全是教科书式复读。后来我换了个思路把自己过去三个月在团队群里的提问、在Stack Overflow上的收藏、在笔记本上记录的报错信息全部翻了出来。我发现一个规律那些我反反复复跟同事解释过的问题——比如某个配置项为什么这样写、某个报错到底是怎么触发的——恰恰是我最有资格写的话题。因为跟别人解释过意味着你已经把这件事从头到尾想明白了你清楚别人会在哪里卡住。所以选题的第一原则不是这个话题热不热而是这件事我是不是真的亲手解决过。第一篇文章不需要惊艳四座它需要的是你能完整地讲清楚一个闭环遇到了什么问题、怎么一步步排查、最后怎么解决、解决了之后有什么反思。这种文章哪怕选题再小读起来也是有血有肉的。1.2 把想写的和能写的分开列两张清单具体的操作方法我建议你拿张纸或者开个文档左边列出我觉得这个话题很酷的清单右边列出我最近真的做过、踩过坑的清单。然后优先从右边清单里挑选。为什么这个动作很关键因为左列的选题会让你产生我必须写得很专业的心理压力而右列的选题天然自带叙事素材。举例来说容器化改造实践这种题目听起来大而空但记一次Docker容器内时区问题的排查就是你真正遇到过、查过资料、最终解决的真实经历——两者写出来的质感完全不同。做完清单对比之后还有一个判断标准你能不能只用三句话向一个外行说清楚这篇讲什么。说不清楚说明这个选题在你脑子里还没成型硬写必翻车。我当时定下来的第一篇选题是离线环境下的依赖包安装踩坑记录三句话就能讲明白你装包的时候没有外网怎么办、有哪些绕过去的办法、每种办法有什么坑。这就够了。1.3 第一篇文章的边界感第一篇文章最容易犯的毛病是想把一个小问题写成一本书。我见过不少人写第一篇就列了二十个小节从背景讲到原理从原理讲到架构最后实操只占一小段——这种文章注定烂尾。给第一篇文章做一个范围限定其实是在保护你自己。我当时给自己立了三个规矩第一只写一个场景离线环境的包安装第二只覆盖两个核心方案本地源镜像和离线包导出第三每一节都要有一个我当时就是这么做的的具体步骤。这样写起来节奏感很强你不需要为了填字数去水内容反而能把核心部分写得有肉。2. 动笔前先搭骨架素材是砖结构是混凝土2.1 先攒素材而不是先写正文我第二版之所以废掉就是因为我在没有任何素材积累的情况下硬写。写到中间发现这个细节我记得不太清那个命令的完整路径得查一下于是频繁切出去搜资料思路断了十几次最后一篇好好的回忆录写成了信息碎片集。正确的做法是先花一到两天只做素材收集绝不碰正文。把你能想到的所有相关信息——聊天记录、截图、代码片段、报错日志、当时查过的文档链接——全部丢进一个素材文档里不用管顺序和条理只需要有。我当时的素材来源有这么几类技术类复现问题时的命令历史history命令直接导出、改过的配置文件前后对比、报错信息的完整文本。心路类当时排查的思路尤其是我一开始错误地以为……后来才意识到……这类转折点这是文章的宝贵素材。教训类哪些地方浪费了时间、哪些方案试着试着就放弃了以及放弃的原因。这些素材在写作阶段就是你的弹药库。没有弹药你写什么都虚。2.2 给素材分类技术事实、经验判断、采坑教训素材收集完之后我建议你按三个类别做一次标注这个动作会在你动笔时省下大量力气。第一类是技术事实比如执行A命令报B错误C版本之后默认开启了D功能这类内容负责支撑你的操作描述必须准确不能含糊。第二类是经验判断比如遇到这个报错先检查配置文件比重启服务更快这类内容是你的观点输出也是读者最想要的东西。第三类是采坑教训比如不要直接在生产环境执行那条清理命令这类内容是文章的避雷针让读者避免重蹈覆辙。我当时用三种颜色的高亮笔给素材做标记写作时一眼就能看到手上有什么资源。如果你用的是文档工具建三个二级标题分门别类放进去也是一样的效果。2.3 骨架怎么搭结论先行然后按你来经历一遍的顺序组织素材齐了之后千万不要急着写正文。先花半小时把骨架列出来——只列H2和H3标题每个标题下面用一个句子说明这一节打算讲什么。这里有个很重要的组织原则要按读者的认知顺序而不是你当时的时间顺序来组织文章。你排查问题可能是东一榔头西一棒子的但写文章不能这样。我当时排查的过程中至少走了三次弯路但写出来的时候我按的是为什么会有这个问题——最常见的错误做法——当时我尝试过的三种方案——最终可行的方案——这类问题的通用排查思路这个顺序。这样的顺序让读者看完能带走一个可复用的方法论而不是只吃到一个瓜。骨架搭好之后你还要做一个动作把骨架拿给一个同事或者朋友看一眼让他判断只看标题你想不想读这篇。他如果说不清楚你想讲什么说明你的H2标题取得太抽象了。好标题的标准是读标题就能知道这一节的内容和分量。比如## 环境准备这种标题就抽象## 在无外网机器上装包两类核心工具的区别就具体得多。3. 初稿写作先完成再完美3.1 不要边写边改初稿的任务只是把话说出来我前两版之所以写不下去很大一部分原因是开了边写边改模式。写一段觉得用词不好调写一段觉得段落太长拆写到三分之一又回头改前面的章节标题……最后整个下午就在原地打转。后来我学到一个方法初稿阶段关掉所有审美判断告诉自己这个版本只有我自己能看到我的任务只是把脑子里所有想法倒出来。用词的准确、句子的节奏、段落的分配全都是修改阶段的事。你只需要确保一点今天的写作时段内你写完了一个完整链条没有半途停在一个你没想清楚的地方。如果写到某个环节发现自己讲不清楚怎么办我当时直接在文档里留一个标注[这里需要补一个当时测试的截图xxx] 或者 [这段要查一下A命令和B命令的准确参数]。不要停下来去查先跳过去往后写。因为一旦停下来去查你又会陷入素材收集的无限循环文章永远写不完。3.2 新手最容易忽略的以读者能看到什么为视角写操作步骤说人话这件事在写技术文章的操作步骤时尤其重要。很多新手容易写成执行命令A得到结果B看起来很清晰但读者没法跟着做——因为你看似告诉了他步骤实际省略了大量隐含前提。我举一个最简单的例子。如果我要写在离线环境安装tensorflow错误的写法是使用pip install tensorflow-2.8.0-cp38-cp38-linux_x86_64.whl然后完事。正确的写法至少要包含我是在哪台机器上、什么系统版本下执行的这个whl文件是从哪个来源拿到的官网朋友机器内网共享安装之前是否需要先装依赖的依赖如果装有conda是否要先切换到目标环境。这些废话恰恰是新手最需要的信息。我写作时给自己提了一个要求假设读者就坐在我旁边他能看到我的屏幕我要把他需要看到和操作的东西一个字一个字地讲给他。这个视角的转变能让你的文章实用性大幅提升。3.3 代码和报错信息要原样呈现不要美化第一篇文章的代码块最常见的通病有两种。一是代码片断不完整只贴了关键几行前后文缺失读者根本没法复现二是报错信息只贴了最后一行实际上排查问题最重要的恰恰是那几行完整上下文。我当时写离线安装那篇把完整的报错堆栈全部贴了出来甚至包括中间那些看起来没什么用的Warning。因为我知道读者去搜索一段报错时他是拿着完整的报错去搜的我的文章如果能和那个报错匹配上他就能快速找到问题根源。而如果你只贴一个主错误他搜到你的文章也未必敢确认这就是我的问题。这个细节还有一个作用它让你的文章显得很真。一个完整的、带着奇怪路径和具体版本的报错信息是编造不出来的。这种真实感在新手期尤其值钱它能帮你建立读者信任。3.4 在一口气写完和分多天写完之间找自己的节奏我知道很多人会推荐一鼓作气写完初稿但实际执行起来一鼓作气在纯下班后的业余时间里几乎不可能。我自己的经验是把初稿拆成连续三天的写作任务Day1写背景问题重述Day2写排查过程和方案Day3写总结和复盘每天保持同一个节奏不要在中间间隔太久。间隔的度很关键。如果每天写你的思路是连续的不需要花太多时间回顾前一天的内容如果间隔一周那你重新进入状态的成本就很高甚至想推翻重来。第一篇文章不是学术论文你不需要把它当作一个周末大工程来完成拆成小块反而更容易坚持。4. 修改打磨从能看到能发至少要过三道关4.1 第一道关趁热修改把初稿当成别人的代码来评审写完初稿后的第二天我推荐你做一次趁热修改。所谓趁热是趁着你对自己的素材还有记忆的时候赶紧把那些初稿里标注的待补充信息补上把语无伦次的段落理顺。我把这一步比喻成给自己的文章做一次代码评审。你在公司Review别人的代码时一定会问这些问题这个函数为什么这样命名这个边界条件有没有处理这个注释有没有意义同理你读自己的初稿时也要用读者视角来审视读者看到他需要执行的命令他能不能看清楚命令在哪个目录下操作我有没有解释为什么需要先做这一步而不是直接把步骤丢出来我是不是默认读者知道某个概念了比如我默认他知道conda环境是什么那要不要给个一句话说明这个阶段不要吝啬删减。凡是和主线无关的素材一律砍掉或者留到附注/扩展阅读里。我当时删掉了大概三分之一的素材比如中间一次失败的方案试验、一些历史背景的介绍这些东西放到文章里会让读者的注意力从主线上飘走。第一篇文章的通病是全都想要作者希望把每一个踩过的坑都讲一遍结果每个坑都只讲了一句话读者哪一段都觉得不够深入。砍素材其实是在保护你真正的核心内容让它们的密度更高、更可观。4.2 第二道关隔一天再改让创造模式切换到批判模式趁热修改之后我强烈建议你把文章放一天第二天再回来改。这个冷却期的作用是让你从作者身份切换到编辑身份。写文章的时候你会不自觉地护着自己的内容觉得每一句都有存在的理由。但隔了一天之后你再看那篇文章它就变成了一个陌生文本你更容易发现它哪里逻辑不顺、哪里例子突兀、哪里废话连篇。我第二次大改的时候发现了好几处问题有一个段落我明明想表达方案B效率低但前面花了大段文字讲方案B的原理读者很有可能误解成作者很推崇方案B还有一张截图是旧版本的界面和新版操作对不上。这些问题当天我是看不出来的。这一轮改稿我建议你把注意力放在两个维度。第一检查每一段的主题句确保每段都在讲一个明确的事情第二检查所有过渡句确保从上一段到下一段读者不会觉得跳。我经常用所以呢和然后呢来检查过渡。读完一段后问一下所以呢如果答案接不上下一段说明过渡出了问题需要补一句连接。4.3 第三道关发布前的朗读检查和技术准确性核对上一轮改完之后就到了发布前的最终检查。这一步我推荐你做两件事。第一朗读一遍全文。不用出声在脑子里默读也行关键是要注意那些读起来别扭的句子。技术文章经常出现的通病是英文术语和中文连接词混合导致的语感断裂比如我们可以通过这个配置项来enable该功能读起来就不如我们可以通过这个配置项来开启该功能顺畅。朗读能很敏锐地暴露出这类问题。第二核对你引用的每一条命令、每一个参数、每一个版本号。哪怕你有九成把握是对的也建议在真实环境里再跑一遍或者对照官方文档确认一次。我写第三篇文章的时候引用了一个Python包的API参数结果自己写错了发布后被读者指出来那感觉真的非常尴尬。第一篇文章是你的门面技术准确性上一旦出问题读者对你的信任会打很大折扣。如果你是技术类文章这一轮还要检查你贴的代码块是否完整、缩进是否正确、有没有把敏感信息比如IP地址、密码、token忘记打码。我见过有人把生产环境的数据库连接串直接贴在文章里的那是真的社死级别的错误。发布前一定要通读一遍所有代码块和截图确认没有泄露任何不该泄露的信息。4.4 需要一个外部视角找人做一次预读如果条件允许在发布前找一个目标读者帮你预读一遍。这个人最好不是你的同行而是和你目标读者水平相近的人或者至少是一个愿意说真话的朋友。你请对方帮的不是纠错而是回答三个问题能不能看懂主线哪一段开始走神了哪一段你会跳过去不看这三个问题的答案能告诉你文章结构上的真实问题比你自己反复改十遍都有效。我当时找我老婆做了一次预读她完全不懂技术但在读离线环境下装包那篇时她唯一的问题是为什么要离线——这让我意识到我缺了一段背景交代我默认所有读者都知道生产环境往往不能上外网这个前提但对纯新手来说这个前提恰恰是需要解释的。后来我补了一段两句话的背景说明文章的适用读者群一下子就变宽了。5. 发布之后冷清、反馈与心态调整5.1 第一篇发出后没有人看很正常你可能满怀期待地等着第一篇发布后马上有人点赞收藏评论但实际的情况往往是发布后的前48小时阅读量屈指可数收藏和评论更是为零。我当时的心理落差非常大一度怀疑是不是文章质量太差了。但后来我想明白了一个事实你的文章在平台上的曝光取决于平台分配给你的初始流量这个初始流量和文章的话题性高度相关。作为纯新人没有粉丝、没有历史互动记录哪怕文章质量不错初始推荐也少得可怜。这和你文章好不好没有直接关系纯粹是冷启动的客观规律。我能给的建议是发布后的第一周尽量不要频繁刷新数据页面。把这个时间用来写第二篇文章。因为数据焦虑会严重干扰你的创作节奏而创作节奏是新手期唯一需要死守的东西。5.2 哪怕只有一条评论也要认真对待冷清归冷清但万一真的有读者留言了一定要认真对待。哪怕对方只是说了一句我也遇到过这个问题原来是这样解决的那也是一次真实的反馈说明你的文章确实触达了目标读者。我记得我的第一篇文章收到的最有营养的一条评论是追问如果在离线环境下没有局域网源怎么办我当时只写了两种方案没想到这个边界场景。这个评论直接帮我孕育了第二篇文章的选题。你看读者的反馈能帮你发现自己的盲区这是纯靠自己想很难获得的信息。5.3 用数据校准而不是用数据评价自己发布一周之后我会去看一次后台数据看的是两个指标平均阅读进度和跳出率。如果阅读进度普遍在50%以下说明文章的前半部分有问题要么引入太慢要么背景铺垫过长读者没有等到精彩的部分就划走了。但这里必须有一个心态建设这些数据是给你的下一篇文章用的不是给你上一篇文章下判决的。每一篇文章都是一个实验你通过数据知道哪个开头更抓人、哪种段落节奏更舒服、哪个长度更合适然后把这些经验用到下一篇。新手期的核心任务是建立写作的正循环而不是写出第一篇爆款。6. 把第一篇文章变成持续写作的起点6.1 建立一个最低限度的写作节奏第一篇文章发出去之后最重要的事情不是庆祝而是趁热打铁确立一个可持续的写作节奏。我见过太多人发完第一篇就陷入下一篇什么时候写的迷茫一拖就是两个月最后热情彻底凉了。我的建议是第一篇文章发布后的一周内就启动第二篇的选题。上一篇的某个边界场景、某条读者的评论、你当时砍掉的素材里那块最亮的碎片都可以成为下一篇的起点。写作节奏不需要很密集每周或者每两周一篇关键是稳定。稳定输出的价值远远大于偶发的高质量长文。你想想读者关注的不是你某一篇写得多好而是他能预期你每到周三就会更新这种预期本身就是影响力。我自己当时定的节奏是一周一更周日写周一改周二发布。这个节奏坚持了大约半年那时我才敢说自己勉强养成了一个写作的习惯。为什么这么强调节奏因为写作能力本质上是持续性产出的能力而不是灵感的爆发。你写得越多就越能感觉到自己从一个靠状态写作的人变成了靠系统写作的人。6.2 建立自己的写作素材池第一篇写作过程中你一定会发现那些随时可能用到但又不适合塞进这篇文章的信息。我建议你从第一天开始就建一个专门的素材池把你平时在工作里遇到的小问题、灵光一闪的解决方案、甚至一句来自同事的有意思的总结都扔进去。素材池不需要结构化一个备忘录就够了。它的作用是你下一个不知道写什么的夜晚打开它就能找到三五个可以写的选题。写作最怕的不是写不出来而是打开编辑器却不知道写什么——素材池恰恰是为这个场景准备的。我自己的素材池里大概常年躺着三四十个未展开的草稿条目有的话题已经放了一年了但当我某天就是想写点轻松的东西时翻一翻总能找到合适的。6.3 第一篇不是终点它是你的最低可行产品用产品思维来看第一篇文章它其实是你作为创作者的最低可行产品。它不需要完美不需要面面俱到甚至不需要很大影响。它只需要做到一件事证明你能把一个想法完整地写出来并发布出去。这个完成闭环的动作比任何事情都重要。因为一旦你完成了第一篇文章你就不再是那个想写但一直没写的人了。你会开始积累自己的写作方法论你会在写第二篇、第三篇时感受到明显的进步你会逐渐形成稳定的表达风格。这些都是从第一篇这个起点慢慢长出来的。我自己的体会是第一篇最大的意义不在于它吸引多少流量而在于它让我发现了写作这个动作对我思考的帮助。当我发现自己写出来的东西比脑子里想的更清晰我就知道这个习惯值得长期做下去。如果你也准备写下你的第一篇文章那就从今天开始攒素材吧。不要等准备好了再写你永远不会完全准备好——但你可以先写出一堆素材再搭出一个骨架然后跌跌撞撞地完成初稿最后让它面目一新地出现在读者面前。