這個網站的程式碼一個小時就寫完了。從需求文件到能寫、能發、能收信，花了一個晚上。中間那段時間，沒有一分鐘是在寫程式。

全部都在接縫上。

需求一頁，決定先做

需求文件只有一頁，最重要的一段是「不做什麼」。這件事我在上一篇講過，這裡不重複。這篇講的是選了什麼、為什麼，以及卡在哪裡。

技術選用，每一項一個理由

  • Astro。 靜態輸出，Markdown 原生支援，不需要為了一個部落格背一個前端框架。
  • GitHub。 所有內容是 Markdown 檔，Git 就是唯一真相來源。網站可以壞，後台可以換，repo 在內容就在。
  • Cloudflare Pages。 免費，頻寬不計費，不用顧任何一台機器。原本打算自架在家裡的 Mac mini，被「能不能更少維護」這個問題砍掉。
  • Sveltia CMS。 它不是系統，只是一層介面。在後台按儲存，它做的事情就是往 repo 送一個 commit。
  • Cloudflare 自家的分析。 免 cookie，所以不用同意橫幅。

部署只有一條 workflow

一個 GitHub Actions 檔案做三件事：push 到 main 就建置上正式站；push 到其他 branch 就給一個預覽網址；每天早上九點自動重建一次。

第三件事是排程發布的全部實作。文章的發布時間寫在 frontmatter，建置時把未來的過濾掉，每天重建一次，時間到的文章就出現。沒有伺服器，沒有排程器，沒有資料庫。

卡住的五個地方

權限少了兩項。 GitHub 的存取權杖一開始只給了讀寫內容，推送時被拒絕，因為建立 workflow 檔案需要另一個權限。補了之後，自動部署又失敗兩次，因為寫入 secrets 又是另一個權限。教訓很單純：接兩個系統之前，先把需要的權限列成清單，一次給齊。

帳號 ID 貼錯。 Cloudflare 的每一個 API 都回認證錯誤，權杖明明是有效的。最後發現是帳號 ID 貼成了另一個值。解法是不信手貼的東西，從網域反查它所屬的帳號。這種錯誤沒有任何錯誤訊息會告訴你。

網域上有幾年前的殘留。 這個網域以前掛過別家的郵件服務，紀錄還在。開 Cloudflare 的信箱轉寄時直接被擋：有衝突的紀錄，先清掉。清掉之後，轉寄一分鐘就開好了。舊東西不會自己消失，它只會在你需要那個位置的時候擋在那裡。

CMS 只看 main。 我給 AI 的規則是所有修改只進 branch，我看過 diff 才合併。結果 AI 寫好的草稿，我在後台看不到，因為後台只讀 main。這不是工具的問題，是我的規則套錯了對象。草稿本來就不會公開，發布的閘門是 draft 這個欄位，不是 branch。規則改成：草稿直接進 main，只有已發布文章的修改才走 branch。

測試信寄給自己。 轉寄開好之後寄了一封測試信，沒收到。查了半天，轉寄規則是對的，伺服器也接受這個地址。問題是我用同一個 Gmail 寄給轉寄地址，信轉回同一個信箱，Gmail 把它當成我自己寄出的那封，收件匣不顯示。換一個帳號寄，秒到。

所以

五個問題，沒有一個跟架構有關。全是把兩個系統接起來時，其中一邊的預設假設跟另一邊不一樣。

接縫是常態。架構簡單的價值不是沒有接縫，而是接縫只有幾條，而且只需要處理一次。