JB 的部落格

工作筆記 · 思想札記

利用 MapleClaw 架設、維護個人部落格網站及協助製作網頁內容

以這個網站的實作為例，整理 MapleClaw 如何協助規劃、開發、內容製作、測試、部署與長期維護，同時保留人的審核責任。

先決定網站要解決什麼問題

製作個人部落格很容易從挑選版型開始，但版型只是表面。真正應該先回答的是：我要寫什麼、給誰看、誰來維護，以及網站在幾年後是否仍然能運作。

我希望這個網站同時是工作筆記與思想札記。主要內容使用繁體中文，讀者不必登入，也不應因為瀏覽器停用 JavaScript 就看不到文章。網站需要快速、容易備份，並且不把日常發布綁在複雜的資料庫或訂閱服務上。

MapleClaw 在這個階段協助我把想法整理成可以驗收的條件，而不只是列出一長串功能。

選擇簡單而耐用的架構

最後採用的核心架構是：

  • 使用 Astro 在建置時產生靜態 HTML；
  • 文章以 Markdown／MDX 保存；
  • 程式與內容一起納入 Git 版本控制；
  • production 主機只提供建置完成的靜態檔案；
  • 第一版不加入 CMS、資料庫、留言、會員或第三方分析；
  • 只有主題切換需要少量瀏覽器 JavaScript。

這不是因為其他做法不好，而是靜態網站很符合目前的需求：攻擊面小、速度快、備份直觀，也不需要在伺服器上長期運行 Node.js。

一個重要原則是：AI 可以參與開發流程，但不成為網站 runtime 的必要條件。即使 MapleClaw 或任何模型暫時無法使用，已發布的網站仍應完整運作。

把內容當成結構化資料管理

每篇文章除了正文，還需要標題、摘要、日期、標籤、語言與發布狀態。這些資料會同時影響文章列表、RSS、sitemap、分享卡片與搜尋引擎理解。

網站使用內容 schema 在建置時檢查 frontmatter。例如，摘要必須有合理長度；有封面圖片時一定要提供替代文字；草稿不得進入正式路由、RSS 與 sitemap。

這類規則很適合交給自動化工具守住。人不必每次憑記憶檢查所有欄位，但仍要負責判斷標題是否準確、摘要有沒有誤導，以及內容是否真的適合公開。

MapleClaw 如何協助寫作

AI 協作並不是輸入標題後直接發布一篇文章。比較可靠的流程是：

  1. 我先提供主題、目的、經驗與希望保留的觀點；
  2. MapleClaw 整理大綱，指出資料不足或可能需要查證的地方；
  3. 產生初稿或協助重寫難以表達的段落；
  4. 檢查用詞一致性、連結、metadata 與格式；
  5. 我核對事實、補充經驗、調整語氣並決定是否發布。

尤其是涉及硬體規格、日期、版本、人物或外部事件時，不能因為文字讀起來順就當成正確。資料不足時，寧可清楚保留範圍，也不要讓 AI 補出一個看似完整的答案。

品質不是最後才做的檢查

網站每次修改後都會經過固定的品質閘門：

  • 格式與 lint；
  • TypeScript 與 Astro 內容檢查；
  • 單元測試；
  • production build；
  • Chromium 三種 viewport 的功能測試；
  • axe 無障礙掃描；
  • 視覺基線比較；
  • RSS、sitemap、canonical、Open Graph 與 JSON-LD 驗證。

自動測試不能取代人工閱讀，但可以守住容易重複犯錯的底線。人工驗收則負責手機上的閱讀節奏、圖片是否合適、文字是否像我，以及整體是否值得公開。

部署要先設計 rollback

很多部署流程只描述如何把新版放上去，卻沒有先回答失敗時怎麼回來。這個網站採用具版本的 release 目錄與 current symbolic link：

site-root/
├── current -> releases/<release-id>
└── releases/
    ├── <older-release-id>/
    └── <new-release-id>/

新版先上傳到新的目錄，確認檔案完整後才原子切換 current。如果 smoke test 失敗，就把 symbolic link 切回上一版。production 不接收原始碼、測試、.git、套件或秘密資訊，只接收 dist/。

部署 script 還必須確認遠端 hostname 與絕對路徑，避免 rsync --delete 因目標寫錯而造成破壞。正式切換、Apache 設定與對外發布仍需明確授權，不能因為工具「可以做」就自動執行。

維護工作也要留下方法

網站上線不是結束。長期維護至少包括：

  • 更新文章並保留修訂日期；
  • 檢查失效連結與 404；
  • 定期更新 dependencies，並在更新後跑完整測試；
  • 保存 Git remote 與多個 production releases；
  • 檢查 HTTPS、憑證、RSS 與 sitemap；
  • 定期演練從 clone、build 到 rollback 的完整流程。

MapleClaw 可以把這些工作整理成清單、執行唯讀檢查、產生差異與測試報告；但涉及公開、刪除、權限或 production 變更時，仍由我做最後決定。

網站也是協作過程的紀錄

這個部落格不只用 MapleClaw 製作，也會記錄 MapleClaw 如何參與製作。哪些工作適合交給 AI，哪些地方仍需要人的經驗，哪一種規則能避免錯誤，這些都是值得持續觀察的實作問題。

我的目標不是追求一個「完全自動」的網站，而是建立一套自己看得懂、可以驗證、能夠回復，也願意長期維護的工作方式。

如果 AI 能讓這個過程更清楚、更可靠，並把我有限的時間留給真正想寫與想思考的內容，那就是它最實際的價值。