为什么我要重新开始写博客

我删过三次博客。

第一次是学生时代的技术社区账号，写的是「某数据库安装踩坑记录」；第二次是工作后自建的 WordPress，主题换了七八个，文章停在两篇；第三次是某个周末用 Next.js 搭的站点，部署完当晚就再没打开过。

三次停更的直接原因都不一样，但根子是同一个：我把博客当成了作品，而不是工具。

一、搭站的时间，永远多于写作的时间

回头看这三次失败，有个共同点：我在「搭博客」上花的时间，远远超过「写博客」。

• 主题要好看，CSS 改了三晚
• 评论系统要选型，Disqus、Valine、Giscus 试了个遍
• 图床要自建，对象存储、CDN、防盗链配齐
• 然后就没有然后了

这是一条很舒适的拖延路径。调样式有即时反馈，而写文章要面对一个残酷得多的事实：我脑子里那些「我懂了」的东西，大多经不起写下来的检验。

写作是思维的编译器。编译不过的地方，就是没想清楚的地方。

二、发布摩擦比写作技巧更能决定产出

我以前一直以为，写不出来是因为文笔不行，于是去看「技术写作技巧」。看完之后产出依旧是零。后来我才意识到，真正卡住我的不是写作能力，而是从「想写」到「已发布」之间的步骤数。

我数过一次：旧流程需要登录后台、在富文本编辑器里粘 Markdown、手动传图、选分类、点发布，中间还会因为网络丢一次草稿。九步。任何一步出问题，这篇就永远躺在草稿箱里。

现在的流程只剩三步：新建文件、写、提交。

摩擦来源	旧做法	现在的做法
写作环境	浏览器后台编辑器	本地编辑器直接写 .md
图片	手动上传图床再贴链接	放在仓库 public/ 下，随构建发布
发布	登录后台点按钮	git push 触发构建
草稿管理	存在数据库里，看不见	draft: true，或干脆不建文件
找灵感	翻聊天记录	在仓库里搜关键词

判断标准很简单：如果某一步让我产生「等有空再弄」的念头，这一步就该被砍掉。

还有一个容易被忽略的摩擦来源：选题的心理负担。以前我总觉得一篇文章必须「成体系」——有背景、有原理、有对比、有结论，最好再配张架构图。这个标准一立，一个下午就没了。现在的做法是把一篇文章当成一条笔记的延长线：先写下那个让我卡住十分钟的具体问题，解决过程就是正文。写不成长文的，就让它停在八百字，也没什么损失。

三、Markdown + Git + 静态站点，不折腾

技术选型上我只保留一个原则：内容必须是纯文本，且能脱离平台存在。

博客/
├── src/content/posts/      # 文章，一个主题一个文件
│   ├── why-i-blog-again.md
│   └── frontend-to-nodejs.md
├── public/images/          # 图片，跟文章一起版本化
└── src/config.ts           # 站点配置，唯一需要改的地方

发布就是一条命令。构建产物是纯静态文件，扔到任何一台机器上都能跑，没有数据库、没有后台、没有登录——因为这些都会变成「今天不想写」的借口。

pnpm build      # 生成 dist/
pnpm deploy     # rsync 到服务器，Caddy 直接托管

写文章的时候，我还会跑一个小脚本检查草稿状态和字数。字数不是 KPI，只是提醒自己「这篇是不是还没展开」：

# scripts/post_stats.py
from pathlib import Path
import re, sys

POSTS = Path("src/content/posts")
CJK = re.compile(r"[\u4e00-\u9fff]")

for path in sorted(POSTS.glob("*.md")):
    raw = path.read_text(encoding="utf-8")
    _, _, body = raw.split("---", 2)
    count = len(CJK.findall(body))
    draft = "draft: true" in raw
    flag = "草稿" if draft else "已发布"
    if count < 800:
        flag += " · 偏短"
    print(f"{path.name:<34} {count:>5} 字  {flag}")

跑起来是这样：

$ python scripts/post_stats.py
frontend-to-nodejs.md              2140 字  已发布
nodejs-backend-patterns.md         1980 字  已发布
why-i-blog-again.md                 760 字  草稿 · 偏短

这个脚本是三天前写的，本来只想看看自己写作的字数分布，结果发现偏短的那几篇确实都是「感觉没什么可写」的主题。字数是个很粗糙的指标，但它能诚实地指出哪里在敷衍。

四、备考期间，用输出倒逼输入

真正让我这次下定决心重启的，是软考高级的备考。

系统架构设计师要背的东西不少：质量属性、架构风格、ATAM、设计模式，还有一大套描述架构的语言。我一开始的方法是划重点、抄笔记、反复看。看了两遍之后做案例题，发现自己写出来的答案还是「大白话」——知道意思，但用不出考试要求的那套术语。

后来我改了做法：每梳理完一个知识点，就用它写一篇给自己看的短文，要求是「假设读者是个没学过这个考点的工程师，我要把他讲明白」。写了大概十篇之后，案例题明显顺了。

举个具体的例子。可用性这个质量属性，我原本只记得「心跳、冗余、集群」这几个词。为了写清楚它，我被迫去回答几个更细的问题：心跳的检测周期和误判率是什么关系、主备切换时的数据丢失窗口怎么描述、双机热备和集群互为备份的区别在哪。这些问题的答案，恰好就是案例题里「请说明该方案如何提高系统可用性」想看到的内容。写一遍，比抄五遍管用。

原因不复杂：

1. 写的时候必须把术语用对，用错自己就会发现
2. 必须举出具体例子，举不出来说明只是背下来了
3. 必须组织成结构，而案例题和论文恰恰是按结构给分的

这件事让我重新理解了博客的定位：它首先是我的学习工具，其次才是给别人看的内容。 顺序反了，就会不停地想「这个话题别人是不是已经写过了」，然后一篇都写不出来。

五、我给自己定的三条规则

1. 先发布，再打磨。 初稿粗糙没关系，发布之后再改，改动记录本身也是内容。
2. 只写三个月后的自己需要的东西。 官方文档写得更全的主题不写，除非我有非我不可的实践细节。
3. 不追热点，不追流量。 这里是我的工作台，不是内容农场。

小结

如果你也在犹豫要不要开始写，我的建议是：不要先搭博客，先写一篇 500 字的笔记，扔在随便哪个平台上。能连着写十篇，再考虑自己的站点。

工具解决的是「怎么发布」，解决不了「写什么」。而后者才是真正难的部分，也是唯一有价值的部分。