如果你也在做個人技術部落格，應該很容易遇到一個尷尬的問題：真正拖慢更新頻率的，通常不是沒東西可寫，而是那條釋出鏈路太重。

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 更對我的胃口。