從一個想法到正式上線：我們如何打造「JB 的部落格」

一切從「我想要一個自己的地方」開始

建立「JB 的部落格」時，我們最先討論的不是版型、動畫，也不是該用哪一套熱門框架，而是一個更根本的問題：這個網站為什麼存在？

我希望它是一個真正屬於自己的地方，可以長期保存工作筆記與思想札記，書寫 Linux、伺服器、網路、程式設計與人工智慧，也容得下投資、健康、文學、哲學和人生。它不只是作品集，也不只是技術文章的集合，而是「我思，故我在；我 PO，故我在」這句話的延伸。

這也決定了網站最重要的幾個原則：內容要容易閱讀、資料要握在自己手上、維護方式要能長久，而且即使日後沒有任何 AI 工具協助，已經發布的文章仍然可以正常存在。

先做減法，再選技術

個人網站很容易在一開始就塞進會員、留言、搜尋、分析工具和內容管理後台，但每多一項功能，就多一個需要更新、備份與防護的地方。

因此，第一版刻意不使用 CMS、資料庫、會員系統、留言服務或常駐的 Node.js 程序。我們選擇 Astro 產生靜態 HTML，以 Markdown 保存文章，並讓 Apache 直接提供建置完成的檔案。

這個選擇並不是為了追逐技術潮流，反而是為了讓技術退到內容後面。靜態網站的攻擊面較小、載入速度快，也容易備份與搬遷。讀者即使停用 JavaScript，仍然可以閱讀文章和使用主要導覽；瀏覽器端的 JavaScript 只負責明暗主題切換等必要互動。

程式碼與文章則一起放進 Git。每一次排版調整、內容更新和部署，都有清楚的版本紀錄，也能知道正式網站對應到哪一個 commit。

把模糊的想法變成可驗收的計畫

專案沒有直接進入寫程式，而是先盤點開發主機 JB66 與正式主機 S224 的環境，確認 Node.js、npm、Git、Playwright、Apache、HTTPS、磁碟空間與網站目錄狀態，再整理出完整的網站規劃。

我們把工作拆成幾個階段：

確認需求、基礎環境與安全邊界；
建立 Astro 專案、內容模型與核心路由；
完成視覺、響應式版面及主要頁面；
放入正式內容、品牌素材與 SEO metadata；
建立部署、備份、smoke test 和 rollback；
正式上線，並在 production 再做一次完整驗收。

MapleClaw 與 Codex 在這個過程中協助整理需求、檢查現況、撰寫程式、製作內容初稿和執行測試；但個人經歷、公開素材、文章觀點與正式發布，仍由我確認。AI 是協作者，不是網站的擁有者，也不是自動發布的最後一關。

從功能正確，到長得像「我的網站」

第一個可運作版本先建立首頁、文章列表、文章頁、標籤、封存、About、RSS 與 404。接著才逐步形成現在的視覺語言：青綠與萊姆綠、溫暖的米白底色、深墨色文字，以及帶一點手作感的色塊。

設計的方向是「理性技術內容 × 溫暖編輯感」。它不能像制式的企業 landing page，也不能因為追求個性而犧牲長文閱讀。正文寬度、標題比例、行距、鍵盤焦點、深色模式與手機版留白，都在實際畫面中反覆調整。

個人頭像成為網站識別的一部分，Maple Logo 則使用經確認的原始 SVG。圖片在放進網站前轉成適合網頁的格式與大小，並補上替代文字。這些看似細小的處理，最後共同決定了網站是否像一個有人居住、而不是套用模板後就離開的地方。

內容不只是 Markdown 檔案

文章正文雖然使用 Markdown，但每篇文章還包含標題、摘要、發布與更新日期、標籤、語言、草稿狀態等結構化資料。Astro Content Collections 會在建置時檢查這些欄位；有封面圖片卻沒有替代文字，或摘要不符合規則，建置就不應悄悄通過。

同一份內容資料還會被用來產生文章列表、標籤頁、RSS、sitemap、canonical URL、Open Graph、Twitter Card 與 BlogPosting JSON-LD。草稿則會從正式路由、RSS 和 sitemap 中一起排除，避免尚未完成的文章意外曝光。

首批內容包括個人介紹、〈我思，故我在；我 PO，故我在〉、MapleClaw 個人 AI 助理，以及記錄本站製作方式的文章。AI 可以協助組織大綱與潤飾文字，但遇到硬體規格、日期、人物或個人經歷時，沒有資料就不補寫；讀起來流暢，從來不等於事實正確。

測試不是上線前才按一次的按鈕

每次重要修改都要通過固定的品質閘門，包括格式檢查、ESLint、Astro 與 TypeScript 檢查、Vitest 單元測試、production build，以及 Playwright 瀏覽器測試。

我們在 360、768 與 1440 像素三種 viewport 檢查首頁、文章列表、文章頁、About 與 404，同時進行 axe 無障礙掃描與視覺基線比較。上線前的 Phase 3 驗收共有 60 項 Playwright 測試全數通過，沒有 serious 或 critical 等級的無障礙問題；依賴套件的 production audit 也沒有發現漏洞。

測試還涵蓋 RSS、sitemap、canonical、社群分享資訊與結構化資料。建置輸出也經過檢查，確認沒有把原始碼、Markdown 原稿、環境檔、套件清單或秘密資訊一起送到正式主機。

自動化負責守住可以明確判定的底線，人工則負責閱讀節奏、圖片感受、文字語氣，以及最重要的問題：這個結果是否真的值得公開。

真正困難的不是部署，而是安全地失敗

正式上線前，我們先設計失敗時要怎麼回來。

網站採用版本化的 release 目錄。每次部署都先建立一個新版本，完成上傳與檢查後，再把 Apache 使用的 current symbolic link 原子切換到新版。正式主機只接收 Astro 產生的 dist/，不需要安裝 npm 套件，也不需要執行 Astro、OpenClaw、Codex 或任何 AI runtime。

部署腳本會檢查遠端 hostname、固定的絕對路徑與 release id；預設只做 dry-run，正式切換必須明確確認。每次部署後執行 production smoke test，一旦失敗，就切回上一個可用版本。

2026 年 7 月 24 日，網站正式上線於 jb.maplecloud.org。Apache 設定完成 HTTP 到 HTTPS 的永久轉址、自訂 404、安全標頭、快取政策與獨立的 log rotation。首頁、文章、標籤、封存、RSS 和 sitemap 都在 production 通過驗證。

我們也沒有把「可以 rollback」只留在文件裡，而是真的把正式網站切回前一個 release，確認服務正常，再切回新版並重新執行 smoke test。只有實際走過一次，rollback 才算是一項能力，而不是一句安慰。

上線之後，網站才真正開始

從規劃到正式上線，這個專案最重要的成果不只是一組頁面，而是一套自己看得懂、可以驗證、能夠回復，也願意長期維護的方法。

網站未來仍會繼續調整。標題大小會修，圖片會換，文章會增加，舊內容也可能更新；但內容自主、簡單耐用、人工把關與可回復的核心原則不需要跟著流行改變。

這次協作也讓我更確定，AI 最實際的價值不是「一鍵做完一個網站」，而是協助人把模糊的想法整理成選擇，把重複的檢查變成可靠的流程，再把有限的時間留給真正重要的判斷與創作。

「JB 的部落格」已經上線，但它不是一件完成後就封存的作品。它會隨著我讀過的東西、做過的工作與思考過的問題，繼續長成自己的樣子。