先说结论：我这次搭的不是一个站，而是一套长期表达基础设施

如果只看结果，这像是一个普通的个人博客站：有首页、有文章页、有域名，也能上线发布。

但对我来说，真正重要的不是“终于有个网站”，而是终于有了一个属于自己的写作母站。以后文章先在这里长成完整版本，再决定怎么发到公众号、小红书、知乎或 X。顺序一变，写作心态也会跟着变。

我想要的不是多一个入口，而是一个能长期承接内容的地方。它要能归档、能分发、能被搜索，也能保留我自己的写作边界。网站只是外壳，真正搭起来的是一套长期表达的基础设施。

为什么我还要在 2026 年做一个个人博客站

今天再做个人博客站，当然不是为了追求短期流量。单看分发效率，新站大概率比不过现成平台。

但平台和母站本来就不是一回事。平台负责触达，母站负责沉淀。平台让更多人先看到你，母站让你的内容别散在四处。

我越来越不想只有一堆“发过的内容”，却没有一个完整的表达场。这个站就是为了解决这个问题。

这 48 小时到底在做什么：我把它拆成了四段

这 48 小时做的事，其实可以很简单地拆成四段：

• 先想清楚这不是“做个页面”，而是“搭一套长期写作底座”。
• 再把首页、列表页、详情页这些最基本的展示层搭起来。
• 接着把内容入口统一到 content/drafts/*.md，再编译成发布用的 JSON。
• 最后补齐 Staging、部署、校验、RSS、llms.txt 和互动功能。

写代码本身并不是最难的。真正决定后面能不能继续写下去的，是这些基础问题有没有在一开始就处理掉。

从零到一的技术路线：我为什么没有先做一个 CMS

这次我故意没有先做 CMS，也没有先做后台。我想要的是轻一点、稳一点、能马上写，而不是一上来先维护一套复杂系统。个人站最容易犯的错，就是把自己困进“先搭完整平台再开始写”的陷阱里，最后网站还没成熟，人已经先疲了。

我给自己定的原则很朴素：写作入口要轻，内容结构要可控，部署流程要简单，后续维护要低成本，页面可以慢慢迭代，但内容格式不要来回折腾。顺着这几条往下推，最后做出来的技术路线也就很自然：草稿写在 Markdown 里，编译脚本把草稿转成 content/articles/*.json，页面运行时只读结构化 JSON，服务层继续保持轻量，用 Gunicorn 和 Caddy 承接部署。

这条路不花哨，但特别适合一个人长期维护。它把最重的复杂度挡在写作体验之外，也把“以后要不要换皮、加页、补渠道”这些问题留到了更后面，而不是从第一天就绑死。

我最看重的，不是页面长什么样，而是内容系统怎么长久运转

做完以后我更确定，站点最重要的不是样式，而是内容流程。

如果流程不稳，站再好看也撑不久。最常见的混乱无非这几种：

• 草稿在哪里写，没人说得清。
• 发布稿到底以哪个版本为准，没人说得清。
• 标题、摘要、导语怎么分工，没人说得清。
• 代码块、列表、时间格式有没有统一规范，没人说得清。
• 发布前到底要看什么页面、跑什么命令，没人说得清。

所以这次我没有把这些事留到以后，而是顺手把它们写成仓库里的真实规则。

比如发布最小规则，现在就是明明白白写在文件里的：

## 内容格式与发布校验规则
- 所有文章正文一律在 `content/drafts/*.md` 中编辑
- 发布前必须先编译，再运行 `python scripts/validate_content.py`
- `published_at` 必须使用真实北京时间，不能写未来时间
- 发布前必须肉眼检查 `/writing` 列表页和文章详情页首屏

这个站和微信公众号、传统博客站、小红书、知乎、X，到底有什么不同

我现在对它的定位很简单：平台还是要用，但它们是渠道，不是母站。

公众号适合维护熟悉读者，知乎适合借问题找到新读者，小红书和 X 适合把观点切成更容易传播的版本。它们都重要，但都不适合替你保存完整版本。

这个站的作用就是承接原稿、归档关系和长期目录。以后无论我去哪里发，先有母站，再谈分发。

48 小时里最难的，其实不是代码，而是重新确认“我为什么要写”

最难的地方不是技术，而是把“为什么要做”想清楚。

如果只是为了看起来更专业，做一个站很快就会失去后劲。只有当它真的服务写作，很多细节才会有意义。

我这次最大的变化是，不再把自己的内容当成随手发发的东西，而是当成值得认真归档、认真整理、认真发布的作品。

如果你也想在 48 小时里做一个自己的站，我最真诚的建议是什么

如果你也想做，我最真诚的建议不是模仿技术栈，而是先想清楚三件事：

• 你做这个站，最想承接的到底是什么，是文章、作品、项目，还是职业身份。
• 你打算长期更新的最小单位是什么，是短评、长文、研究笔记，还是专题系列。
• 你愿不愿意从第一天就把规则写下来，而不是把所有流程都留给未来的自己收拾。

想清楚这些以后，技术可以很克制。先把最小闭环做出来就够了：

• 一个自己的域名。
• 一套稳定的首页、列表页和详情页。
• 一个明确的草稿目录。
• 一条能重复执行的编译和校验流程。
• 一份未来的自己也看得懂的部署说明。

做到这里，就已经够用了。

最后想说的，是对读者、朋友和后来者的感谢

写到最后，我最想说的还是感谢。感谢一直在看的人，也感谢认真挑问题、提建议的人。没有这些反馈，这个站不会这么快长出样子。

如果这篇文章最后只留下一个判断，我希望是这个：平台当然重要，但最好别让平台成为你唯一的表达现场。哪怕只是一个很小的母站，只要它真正属于你，它就值得慢慢搭起来。

更新附注

• 版本：v1.1

更新日期：2026-03-31 更新原因：重写开头和技术路线段，压掉“搭站教程”式模板口吻，把重点收回到母站、流程与长期表达边界。