一小时出一篇优质技术文，这句话放两年前我自己都不信。那时候一篇技术博客我从打开编辑器到点击发布，平均要耗掉大半个周末——不是不想写，是真卡壳。卡在标题起不来、卡在代码贴进去格式全乱、卡在为了解释一个概念查了半天资料、卡在写到一半发现开头论证的方向根本站不住。更气人的是，最后发出来的文章读者还不一定买账。
后来因为业务需要，我不得不把"写文章"从随缘行为变成固定产出，逼着自己研究了一套从卡壳到流畅的实战方法论。现在我可以负责任地告诉你：一小时出一篇合格甚至优质的技术文，完全能做到，但前提是你得有一套流程、一批工具和一堆提前备好的素材。这篇文章就是把这套方法完整拆给你看，从时间分配到打开编辑器前的准备、从怎么起标题到怎么排代码、从卡壳求救到临阵砍需求，全部是可复制、可落地的经验。适合所有需要定期输出技术内容的人——不管是技术博主、开源作者，还是公司里被要求写技术月报的工程师。
1. 先解决"卡壳"：为什么你写一篇技术文要熬一整天
1.1 卡壳的本质不是文笔差，是决策负担过重
很多人觉得写文章卡壳是语文水平不行，其实大部分技术人卡壳，卡的根本不是措辞，而是"选择太多"。你要写一个主题，脑子里同时冒出来五六个角度：是讲原理还是讲实战？是写入门教程还是写踩坑记录？是先贴代码还是先讲场景？要不要对比几种方案？篇幅控制在多少？这些决策没有模板可依，每想一步都要消耗脑力，脑力耗完了自然就停在原地。
我自己的感受是，文章写到一半卡住，十次里有八次是因为"没有提前想清楚这篇文章到底要解决谁的什么问题"。你在心里把这篇东西当成"关于XX的一切"，那当然无从下手；但如果你把它定义成"教一个刚接触XX两周的同事把环境搭起来"，所有内容的取舍标准瞬间就清晰了。所以我不建议在写作开始时思考太多，而是先用一句话锁死目标读者和目标问题，后面所有决策都往这个方向收。
1.2 我在真实项目里总结出的"时间黑洞"清单
在我开始记录写作耗时之后，发现了几个特别惊人的时间黑洞，不是我没写，是被细节拖死的。
第一个黑洞是"临时查资料"。写到某个知识点，突然觉得不严谨，于是打开搜索引擎，一搜就是二十分钟。解决这个问题的唯一办法是写文章之前就把参考资料备好，并且严格规定写作期间不去搜索——所有不确定的内容先打标记，写完统一补查。这个规则帮我省下的时间非常可观。
第二个黑洞是"调格式"。贴代码、调缩进、弄表格、加链接，这些动作看起来都不起眼，但每一个都在打断思路。尤其是代码块里的缩进和高亮，一旦被格式问题打断，想回到原来的思路状态至少要三五分钟。后来我改用专门的写作工具，用快捷键搞定大部分格式，基本不需要鼠标，思路就不容易断。
第三个黑洞是"反复改开头"。很多人的习惯是先写正文再回头打磨开头，可他们的做法恰恰相反：开头写了删、删了写，耗掉半小时正文还没动笔。正确的做法是先用一个粗糙的临时开头把正文写完，最后再回来润色，一小时出货必须这么干。
2. 一小时出稿的整套流程：五段式管线
2.1 第一段：定靶（0-10分钟）
这一个小时的前十分钟不写任何正文，只做一件事：确定文章靶心。我习惯在一个空文档里写下三个问题，答案写出来，这十分钟就算没白花。
第一，这篇文章给谁看？是给完全零基础的人，还是给有经验的同行？读者水平直接决定你要不要解释基础概念，也决定代码注释写到什么程度。第二，读者看完之后能获得什么？是能自己写出一个功能，还是能理解某个原理，还是能避开某个坑？第三个问题是这篇文章我不写什么？这比前两个问题更重要，因为内容的深度和广度往往是被"取舍"决定的。
这个阶段我还会顺手写一个临时标题，不用多好，能帮自己锁定方向就行。比如想写Promise相关的文章，临时标题就叫"手写Promise.all"，后面所有内容都朝这个方向聚拢，比写"深入理解Promise"要容易把握得多。
2.2 第二段：搭骨架（10-20分钟）
骨架阶段只做目录和核心观点，不写任何完整句子。我的做法是在标题下面列一到两级的小标题，小标题本身就是核心结论或核心动作。
举个例子，如果我写"手写Promise.all"，骨架可能是这样：
- 前言：为什么需要手写，直接调用有什么痛点
- Promise.all的核心行为拆解
- 手写实现第一步：接收可迭代对象并返回Promise
- 手写实现第二步：遍历并保存结果
- 手写实现第三步：空数组与特殊输入的边界处理
- 与真实Promise.all的差异对比
- 总结与延伸
这个过程控制在十分钟内，重点是让文章形成一条可以往下走的结构线，而不是面面俱到。骨架搭好之后，写正文就变成了"往每个格子里填内容"，心理负担小很多。如果你发现某个格子填不满，说明这个骨架节点本身有问题，要么砍掉要么调整角度，趁现在改成本最低。
2.3 第三段：填肉（20-45分钟）
这是整篇文章的核心环节，也是大多数人以为唯一的工作环节。我的经验是，这二十五分钟要像考试做简答题一样，一个节点一个节点地过，每个节点先写完再统一修改，绝不过度修饰。
具体操作是：从骨架的第二个节点开始，往下写每一小段的草稿。把脑子里原生态的想法先倒出来，哪怕句子不够通顺、措辞不够到位，也要逼自己往下走。这个阶段严禁做任何格式调整和措辞推敲，因为那些动作属于另一个脑区，切来切去会浪费大量时间。
如果你在一个节点卡超过三分钟，立刻在文档里加一条TODO标记，然后跳到下一个节点。比如你突然想不起来某个API的准确拼写，不要停下来查，写一个"TODO:确认此处API拼写"然后继续。这招能把"卡壳中断"变成"顺滑跳格"，整个人的写作节奏完全不一样。等全部节点填完之后，再回头处理这些标记。
2.4 第四段：顺稿（45-55分钟）
填肉阶段结束之后，你手里应该是一篇虽然粗糙但结构完整的全文。接下来的十分钟做顺稿，按优先级排序，只改三件事。
第一件事是处理所有TODO标记，把之前临时跳过的信息补上。第二件事是统一语序和衔接，让段落过渡自然一点。第三件事是删减废话，尤其是那些"自行体会"式的内容，它们对读者毫无帮助，只会稀释干货浓度。至于措辞文采，这个阶段不做大改，因为你在一小时内的目标是发布一篇合格文章，而不是提交一份文学作品。
顺稿阶段我建议从后往前读，这样更容易跳出"作者惯性"，因为熟悉的内容倒着看会自动把逻辑关系暴露出来。你可能会发现，某一段内容和它前面的段落根本不在一个话题上，或者一个小标题下的内容其实讲了两件事，这种问题从前往后读很容易漏掉。
2.5 第五段：发布（55-60分钟）
最后五分钟不是点一下发布按钮就完了，还要做三件琐碎但必要的事：检查代码块是否可以正确换行和缩进、检查链接是否能打开、检查标题和小标题的层级是否一致。
我用过的写作工具不少，现在固定下来的一套是"本地Markdown编辑器+剪切板图片床"。写完后我在编辑器里先预览效果，确认格式没有乱；再把标题复制到各种在线工具里看字数，大概心里有数；最后点发布。这套动作熟练之后，五分钟完全够用，甚至可以剩下时间泡杯茶再点发布。
3. 核心细节拆解：从骨架到措辞的实操要点
3.1 标题与开头：前两行决定读者去留
技术文的标题不需要标题党，但要具备"可预期性"。读者看到标题时需要快速知道这篇文章能给他什么，关键词要具体到技术名词或者问题场景，比如"手写Promise.all"比"深入理解Promise"更吸引目标读者，正因为前者给了他明确的收益预期。
开头的任务只有一个：在最短时间内让读者确认"这篇文章和我有关"。所以开头不要写绪论、不要写背景、不要从"随着前端技术的发展"这类废话开场。直接场景切入，比如"接到一个需求，需要并发请求所有接口，但其中一个失败就要整体失败……这时候我就想到了Promise.all"。读者看完这句话就明白了，这篇文章讲的正是他此刻遇到的问题。
我在开头还有一个习惯，就是声音尽量像聊天而不是念稿。技术文最怕端着，你越端读者越觉得有距离。试着想象对面坐着你的同事，你在跟他讲你怎么把这些问题搞清楚的，写出来的语气就自然多了。
3.2 代码块与截图：技术文最耗时的环节怎么提速
技术文和普通文章最大的差别就是代码，而代码恰恰是最容易卡住"一小时出货"的环节。我的提速方法可以总结成三个策略。
第一策略是"能用文字说明就不截图"。截图的流程太过繁琐，切窗口、截选区、保存文件、上传图床，每一步都在打断写作思路。所以能放进代码块的内容尽量放代码块，代码块里写不了的内容才考虑截图，而且截图要批量截、批量传，不要写一句截一张。
第二策略是"代码先精简再入稿"。不要把你项目里一大段两百行的代码原样贴进文章，要切成关键片段外加示意代码。一方面是为了排版美观，另一方面是让读者视线聚焦到核心逻辑上。我在实际写作时会先复制原始代码，然后逐段删掉和核心主题无关的分支与日志输出，再补上必要的空行和注释，这个过程熟练后只需要几分钟。
第三策略是"给代码加注释要用读者的视角"。注释不是写给编译器看的，而是写给读者看的。所以核心逻辑的注释要比平时多一些，甚至可以加上"这一步为什么要这么写"的说明。善意的读者会因为你的注释而少走很多弯路。
3.3 干货密度把控：怎么判断"够不够干"
一小时出一篇文章，最容易被质疑的就是"水"。判断文章干不干，我有一个粗暴的标准：如果把文章里所有代码、命令、路径、报错信息甚至关键参数全删掉，文章还能剩下多少有效信息？如果剩下的内容超过一半，那这篇大概率是水文。
另一种判断方法是看"读者能不能照着操作"。一篇文章发布之后，有没有读者按着步骤走通了？我在评论区经常看见"按你的方法做，成功了"这类反馈，这种反馈就是文章干货的最高评价。为此写技术文时，尽量按"前置条件-操作步骤-预期结果-常见问题"来组织内容，读者可复现的程度越高，干货密度越高。
当然也存在另一种情况：你写的是原理分析类文章，没有可操作的步骤。那就用"提问量"来判断，即文章能不能回答读者大概率会问的问题。能回答的问题越多，文章含金量越高，和操作类的"可复现性"是一个道理。
4. 常见问题与排查技巧实录
4.1 写了半天发现方向跑偏怎么办
说个我自己踩过的坑：有一次我想写一篇关于Node.js流式处理大文件的文章，写到一半发现已经花了大篇幅讲Buffer的底层原理，等到意识到跑偏的时候已经过了半小时，最后只能硬着头皮全篇重写，时间白白浪费。
后来我给自己定了规矩：在写作过程中每十五分钟回头看一眼骨架，检查当前正在写的内容是否对应骨架上的某个节点。如果发现写跑偏了，立刻停手，评估跑偏的内容是应该单独成文还是应该删掉。如果是单独成文，就在文档末尾开一个新章节，把跑偏的内容全部挪过去，等这篇发布后再快速写一篇新文章；如果和主题关联不大，直接删掉不要心疼。
跑偏这件事最好的处理是预防，定时回看骨架是最简单的预防手段，成本低效果好。你甚至可以设置一个十五分钟的计时器，响一下提醒自己回看一次，这样就算偶尔走神最多也就偏两三分钟，很快能拉回来。
4.2 代码跑不通但稿子必须发怎么办
写技术文最怕的就是贴出来的代码自己都没验证过。但一小时出货的压力下，偶尔会遇到"代码写差不多了，测试需要长时间跑但发布不能等"的情况。我的处理策略分三种。
第一种是文章明确告诉你这段代码还没做完整测试，把代码段标注为"示意代码"，并且把已知的边界限制写出来。第二种是回避这段代码，把思路用伪代码或者文字描述清楚，读者照样能理解原理。第三种是紧急情况下先发布，但发布后在文章开头加一句"本文代码需在XX环境下验证，有任何问题欢迎评论区反馈"，然后尽快在后台把问题测通并更新。
这里更重要的其实是"以防为主"。我现在所有文章里的代码在写出之前就已经在项目里跑通过了，会用专门的代码片段文件夹做留存，写文章时直接复制运行记录的代码，这样既保证了正确性，又省了重新敲一遍的时间。
4.3 素材库量级不够时怎么应急
很多我刚接触写文章的人会问我：是不是要有大量的知识储备才能一小时出一篇文章？其实不是。一小时出稿靠的不是储备，而是调用能力。
如果你碰到一个主题，发现自己手头的素材不够，可以做三件事。第一，缩小写作范围。把"写一篇关于Web性能优化的文章"缩小成"写一篇关于首屏时间优化的三个实操技巧"，你需要准备的素材立刻少了一个数量级。第二，反向取材。去搜这个主题下的热门讨论帖，看大家在评论区吐槽什么问题，你把这些问题整合成一篇"避坑清单"，这种文章往往比教程更受欢迎。第三，利用个人经验。你踩过的坑、你解决过的问题就是素材，不需要额外准备什么，只要如实记录过程就能成稿。
说到底，素材库的积累是长期的事。下一篇第二部分我会详细讲怎么建立素材库，但紧急情况下，用缩小范围加反向取材这两招，足以让你在一小时内完成一篇不求全但求准的文章。
5. 一个真实案例：从空白文档到发布的全过程记录
为了把这套方法论讲得更具体，我拿一个真实的写作案例做复盘：一篇"手写Promise.all"的技术博客，从打开编辑器到发布，整一小时。以下是当时的实际操作记录。
打开编辑器那刻是上午十点。第一件事，我在文档顶部的置顶区写下这三行：读者是"工作中用过Promise但不清楚内部实现的前端同学"；目标是"能独立手写出支持核心场景的Promise.all"；不写"Promise的其他API、并发控制、错误重试"。然后是临时标题"手写Promise.all"，一共花了不到十分钟。
接着开始搭骨架。我按时间顺序往下列："背景：业务里多个接口用到all""熟悉用法回顾""核心行为拆解""第一步：返回Promise""第二步：处理入参，拿到迭代器""第三步：遍历收集结果""第四步：处理空数组""边界：非数组输入""对比原生Promise.all的差异""结尾总结"。骨架阶段结束是十点二十，一个附件内容都没写，但整篇文章的结构已经清晰可见。
十点二十到十点四十五，是填肉时间。我按骨架顺序往下填：先写了背景和用法回顾，因为内容熟悉写得最快；然后进入核心行为拆解，把"输入一个可迭代对象、返回一个Promise、所有子Promise都成功才成功、任何一个失败直接失败"这几条列成小点；接着写手写实现部分，每写一小段就紧跟代码块，代码不多但每一步都配了注释。写空数组处理时突然想确认一下空数组时Promise.all的真实行为，本来想查文档，但按规矩先标了TODO，继续往下写。
十点四十五到十点五十五是顺稿时间。我先处理了一个TODO：查了MDN上的说明，确认空数组用手写实现返回一个已经是resolved状态的Promise。然后把正文里两句重复的导语删掉，把"遍历迭代器"和"收集结果"两个节点之间的衔接改顺，最后把临时标题"手写Promise.all"改成"手写Promise.all：核心行为、边界情况与实现"，字数多一点，但读者预期更明确。
十点五十五到十一点是发布阶段。检查了代码块缩进，确认每个代码块不包含排版乱掉的字符；检查了末尾的链接是否可访问；在文章开头加了一段提示，说明本文代码基于Node环境验证，最后点发布。整个过程走完，刚好一小时。
这个案例最能说明的问题是：一小时出稿不是靠写得快，而是靠"流程不会断"。我把时间明确分配给五个阶段，任何环节不掉链子，总时长就能控制住。普通情况下你不需要像我一样精确到分钟，但心里要有个大致的时间账，关键是要阶段分明。
6. 长期打磨：让"一小时出稿"成为可持续能力
6.1 建立个人素材库
一小时出稿本质上是在调用已有库存，库存越多，写作越顺。素材库不需要复杂的工具，我用的是市面上常见的笔记软件，结构非常简单：按技术领域建笔记本，每个笔记记录"知识点+代码片段+参考资料链接+自己的踩坑记录"。写文章时直接进素材库检索，类似的话马上就能搜到，省去回忆和临时查证的时间。
建立素材库的一个关键习惯是"随时捕获"。我通常是工作到一半的时候，遇到一个有意思的问题，或者解决了某个诡异的bug，会立刻把它记进素材库。哪怕只是几句话、一小段代码，都比日后回忆要可靠得多。这种积累方式不需要额外时间，只需要建立条件反射：问题发生时第一反应不是"我记一下"，而是"这个能写成文章"。
素材库维护的另一个要点是定期回顾。我会每周花十分钟把当周的素材看一遍，能成篇的标个"可写"，这个动作虽然短，但能让素材库从"死数据"变成"活选题"。我很多文章的选题就是这么来的，而不是打开编辑器才开始拍脑袋想主题。
6.2 写作节奏与习惯
最后想聊的是习惯层面。一小时出稿需要大量的刻意练习，但练习不等于每天硬写一篇文章。更有效的做法是设定一个最低频率，比如要求自己每周至少发布两篇技术文，用这个频率逼着自己不断走完整套流程。流程走熟了以后才会内化成习惯，习惯有了以后写文章就不需要消耗太多意志力。
另外一个容易被忽视的习惯是"写作时间固定"。我自己的经验是，早上精神最好的时段写技术文，效率最高。如果你只有晚上有整块时间，那也行，但一定要固定下来，让身体和大脑形成条件反射。固定时间加固定流程，写作会变得像喝水一样自然，甚至不需要什么"状态"。
停笔之前，把最后这几条心得留给所有卡在写作门槛上的人：别追求第一篇就完美，先追求第一篇能发出来；别追求每个句子都漂亮，先追求每个节点都讲清楚；别追求覆盖所有读者，先追求瞄准一个具体的场景。按照这套流程试上三次，你一定会发现，一小时出一篇技术文并不是一句口号，而是完全可以量化的个人能力。
