技术写作最怕的不是写得不好，而是写完之后没人能照着做。我给自己定下四个最小习惯：先结论、给场景、留证据、改两遍。它们都很小，但决定了文章半年后还有没有用。
先写结论
读者进文章的第一件事是判断「这跟我有没有关系」。把结论放在第一段，读者扫一眼就能决定继续读还是关闭。
好的开头长这样：
这个网站用纯静态 HTML/CSS/JS 构建，不依赖任何框架。本文讲清楚目录结构、本地预览和部署选项。
坏的开头是铺垫环境、背景和心路历程。结论前置不是文风问题，是尊重读者时间。
给场景，再给步骤
步骤只有在场景里才有意义。写「执行 npm install」之前，先写一句「你正在把项目拉到新机器上」。读者一旦知道自己在哪个环节，步骤就不容易走错。
一个实用的结构：
- 什么情况下会遇到这个问题
- 复现问题的条件
- 解决步骤与预期输出
- 如果失败，最可能错在哪
留下证据
- 命令给出完整可复制版本，不写省略号。
- 代码块标注语言，方便读者复制和高亮。
- 涉及配置的，给出文件路径和生效条件。
- 结论尽量可验证，例如「执行后输出以下内容」。
没有证据的教程是观点。读者无法区分「作者试过」和「作者以为」。
改两遍再发布
第一遍改结构：删掉与主题无关的段落，把长句拆短，确认顺序是从已知到未知。
第二遍改细节：检查命令能否原样执行、链接是否有效、术语是否统一。第二遍最好隔几个小时再做，或者让另一个人读一遍。
把过程变成习惯
不必等灵感。平时遇到值得记的问题，先存三行笔记：现象、原因、结论。写文章时把笔记展开成步骤，比从空白页开始容易得多。
好文章不是一次写完的，是改出来的。先发布，再按反馈修订，比永远停在草稿里更有价值。