如果你也在做个人技术博客，应该很容易遇到一个尴尬的问题：真正拖慢更新频率的，通常不是没东西可写，而是那条发布链路太重。

WordPress 这条路我很熟，也不是说它不行。相反，它到现在都还是一套非常成熟的方案。你要后台、要主题、要插件、要快速上线一个能工作的内容站，它确实顺手。尤其是企业站、资讯站、多人协作编辑那种场景，WordPress 依旧很能打。

但我后来越来越不想把它当成自己的长期写作主场。原因也不复杂，它对我这种独立开发者来说，慢慢变成了一种“边写文章，边维护一个在线应用”的感觉。你明明只是想更新内容，最后却总要顺手去碰缓存、插件、备份、升级、兼容性，甚至还要担心后台这一层是不是一直稳定。

所以我最后把博客定成了现在这套。前面是 Astro，内容直接写成 Markdown，靠内容集合去约束结构，发布交给 GitHub Actions，服务器只负责挂静态产物。说白了，我想把“写内容”和“维护运行时系统”这两件事拆开。

我不是觉得 WordPress 过时了，我只是更不想继续维护它那套运行时

这篇文章不是要踩 WordPress。它的问题不在于老，而在于它默认把很多事情绑在一起了。

WordPress 官方文档自己其实也讲得很坦白。Hardening WordPress 里直接说，安全不是风险消失，而是风险降低。文件权限、插件来源、备份、主机环境，这些都得一起考虑。另一篇 Updating WordPress 也很实在，讲更新时不会只影响某一个按钮，而是会碰到 wp-admin、wp-includes、插件、FTP、.maintenance 这些一整串东西。

我反而觉得这说明 WordPress 很成熟，因为官方没有假装它很轻。只是这也顺手暴露了一个事实：只要你选了这条路，写文章这件事天然就会和“维护一个运行中的 CMS”绑在一起。

对很多团队来说这没问题，因为他们本来就需要后台、权限、审稿流、插件生态。可对我这种长期写个人技术内容的人来说，真正烦的从来不是写一篇，而是写到三十篇、五十篇、一百篇以后，这套东西还顺不顺手。

很多人一开始做站，都会优先关心首页长什么样、主题漂不漂亮、页面快不快。可你真写久了就会发现，真正决定这个站能不能一直更下去的，其实不是前台，而是后台那条更新链路会不会不断消耗你。

我后来最在意的，其实不是速度，而是内容终于回到了自己手里

很多人一聊 Astro，先想到的是静态站更快、部署更轻、服务器更省。没错，这些都成立。但让我最后下决心换过去的，不是速度，而是文章终于重新变成了仓库里的文件。

现在这个博客里，一篇文章其实就是两份 Markdown，一份中文，一份英文，直接放在内容目录里。这个变化看着很小，实际影响很大。你每次改标题、改描述、改结构、补内链，Git 都会把变化记得清清楚楚。想回滚，直接回到某个 commit 就行，不用再去后台翻版本，也不用碰数据库。

更重要的是，迁移这件事不再可怕。你以后想换主题，想改前端，想把文章展示方式重做一遍，内容本身还是普通文件，不会被某个后台锁死。对独立开发者来说，这一点很值钱。因为你维护的不是一个编辑部，而是一套会长期积累的技术资产。

还有一个体验差别，我觉得只有自己写久了才会特别明显。文章变成文件以后，写作终于和开发习惯接上了。你本地写，本地预览，改完就构建。整个过程是连续的，不会出现“我写完了，现在再切去后台做另一套动作”的割裂感。

这件事说起来很小，但对持续更新真的有用。因为一旦发布动作和你平时工作的手感是统一的，你就没那么容易拖着不发。

内容模型被定住以后，更新会轻很多

我后来越来越觉得，技术博客最怕的不是视觉不够花，而是内容结构慢慢失控。

前期几篇文章看不出来，写多了就会开始出问题。有的文章有 description，有的没有；有的标签写得很随意，过两个月自己都忘了当时为什么这么分；有的双语路径对不上；有的分类后来改名，旧文章却没跟上。到那时候你会发现，自己不是在更新站，而是在不停给过去的混乱补洞。

所以我现在干脆把内容模型定死在项目里，让构建阶段直接校验。Astro 官方在 Content collections 里一直把 schema 和 type safety 当成重点能力，我现在是真正体会到它为什么有用。它最值钱的地方不是“看起来更规范”，而是你以后会少掉很多返工。

对我来说，最舒服的一点是，它不是提醒你“最好写规范一点”，而是更直接一点：写错了就别过 build。文章该有的语言、路径、标题、发布日期、分类、标签、主题这些信息，一开始就被框住了。看着像限制，其实是在帮你省事。后面的 SEO、双语、主题聚合页，也因为这一层约束稳定了很多。

这也是我现在和 WordPress 最大的体感差别之一。WordPress 当然也能把结构做出来，只是它更像后台里的一层能力；而我现在这套，是把规则直接钉在仓库里。前者灵活，后者更稳。对长期写技术内容的人，我现在更偏后者。

发布动作被压成一次 push 以后，整个人会轻松很多

我觉得很多人低估了发布摩擦这件事。

如果一篇文章从写完到上线，中间还要切后台、点发布、清缓存、查插件、备份、再去确认线上有没有抽风，那久而久之，你就会本能地拖延更新。不是没内容，而是嫌这整套动作烦。

我现在的流程就短很多。本地写 Markdown，跑一次构建确认没问题，然后直接 push，后面的事情交给 GitHub Actions。官方在 Events that trigger workflows 里本来就把 push、schedule、workflow_dispatch 这些触发方式定义成标准能力，所以这不是自己硬拼的野路子，而是一条很正常的工程化发布链路。

落到我这个博客里，实际体验也很简单。先用脚手架把中英双语文章骨架起出来，本地构建时顺手把 frontmatter 和内容模型先校验掉，GitHub Actions 再去构建产物、上传服务器、切换 release，最后由 Nginx 指向当前版本。

这里面最舒服的其实不是少点了几个按钮，而是发布终于变成了一件低情绪负担的事。写完就是 push，不需要再切换脑子，不需要再进入“现在开始运维”的模式。

我自己现在最明显的变化就是，发文不再需要攒劲。以前总觉得“晚点再发吧，等我有空把后面的事一起处理”。现在因为后链路已经标准化了，反而更容易保持更新频率。

服务器终于像服务器了，不再像事故现场

以前我不喜欢 WordPress，还有一个很实际的原因，就是服务器承担的角色太多了。

它既是内容后台，也是运行时，也是插件容器，也是缓存现场，很多时候还是排障现场。你本来只是想更新一篇文章，最后却可能要去关心 PHP、数据库、插件兼容、后台登录面、升级后的连锁反应。

现在这套博客里，服务器的工作简单得多。构建在本地或者 CI 做完，线上只负责接收静态产物、保留多个 release、切换 current，然后稳定提供 HTTPS 和静态访问。这个变化听起来很朴素，但真的会让人省心很多。线上不再像一个你要经常进去“修”的应用，而更像一个稳定的发布目标。

这对 SEO 其实也有帮助。因为你的注意力会更自然地回到内容本身，回到主题页、内链、代表作、更新节奏，而不是不断被后台和运行时问题打断。

真正让我觉得这套东西更像“现在进行时”的，是 AI 很容易接进来

如果只是把博客从 WordPress 换成 Astro，还谈不上多新。真正让我觉得这套架构更适合继续往前扩的，是 AI 能很自然地接进整条内容链路，而不是只停留在一个编辑器里的“帮我润色一下”按钮。

现在这个项目里，AI skill 已经可以直接处理一整条动作。它能读 Markdown 文档，也能接 Notion 页面；能把原始材料改成更像博客文章的正文，再顺手生成双语版本；发布前还能先做一轮脱敏，避免把密码、私有路径、IP、口令之类的东西直接带出去。后面再补标题、description、slug、分类和标签，最后接到 build、commit、push、部署验证这一串动作上。

这就是我觉得现在这类 Git-first 博客和传统 WordPress 很不一样的地方。WordPress 的核心体验，还是在线后台管理内容；我现在这套，更像是把内容当代码、当资产、当可编排对象。对独立开发者来说，这种模型会越用越顺，因为你后面想补的那些能力，比如文章模板、SEO 检查、敏感信息过滤、双语发布、自动部署，本来就和文件流、Git 流更贴。

你会明显感觉到，AI 在这里不是额外贴上的一个小玩具，而是天然就能插进流程里。这个体感差别，其实比“页面是不是更快”还大。

所以最后不是谁更先进，而是谁更适合你接下来几年怎么写

如果你的站需要非技术成员直接在线写作，很依赖后台权限和审稿流，或者要快速拼会员、表单、商城、营销页，那 WordPress 很可能还是更省事。这一点没什么好硬拗的。

但如果你的目标更像我现在这个站，长期写个人技术内容，重点吃搜索流量，文章最好能版本化和回滚，双语维护别太费劲，而且以后还想把 AI 真正接进更新流程，那我现在还是会更推荐这套 Astro + Markdown + GitHub Actions 的架构。

因为最后决定你能不能持续写下去的，很多时候不是主题够不够炫，而是这条更新链路够不够轻，够不够稳，够不够像你本来就熟悉的工作方式。

说白了，我现在更在意的不是“今天发一篇是不是方便”，而是“半年后我还愿不愿意继续更”。在这一点上，这套方式确实比传统 WordPress 更对我的胃口。