個人網站這件事我前後搞了三次。每一版都不是因為前一版壞了，是因為我對「網站該怎麼存在」的理解變了。三次走下來才搞懂：選工具不難，難的是建立一套讓寫內容變輕的流程。
| 版本 | 技術 | 定位 | 卡在哪 |
|---|---|---|---|
| v1 | Bootstrap 一頁式靜態站 | 履歷連結 | 內容跟結構綁死，改版型要動每張卡片 |
| v2 | Python 腳本生 HTML | 作品集 | 模板難改，圖片壓縮、路由、SEO 都得自己寫 |
| v3 | Astro + React（現役） | 持續累積的內容平台 | — |
第三版的核心轉變不是換工具，是把網站定位從「放作品的單頁名片」改成「持續累積內容的平台」。重點變成——怎麼讓寫內容這件事變得夠輕。這篇就把這套流程從建站、部署、網域、到日常內容管理整個拆給你看，重點放在「我怎麼用 Claude Code 把日常維護壓到最低」。
前置處理：選型、建 repo、初始化專案
選 Astro 主要是因為它剛好踩在「內容驅動」跟「元件化」的交會點——內容用 MDX 寫，靜態部分編譯成純 HTML，真正需要互動的地方再用 React 元件包成 island 嵌進去。
挑框架時我的四個硬需求是：
- 能輕鬆部署到靜態平台（尤其 Cloudflare，因為我網域跟 DNS 都在那）
- 不需要 SSR、不需要 API server
- 能混合 React 互動元件
- 內容能用 MDX 寫
比較過 Next.js（功能太全、重心在 SSR、不想綁 Vercel）、Hugo（不支援 MDX，自訂元件要用 Shortcodes）、Nuxt（我 Vue 不熟），只有 Astro 四點全中。選定之後就照下面三步走，把專案的「家」先架好，後面才開始講部署。
在 GitHub 建立新 repo
我習慣先在 GitHub 開一個空 repo，給專案一個遠端家，後面所有自動化部署都靠這個 repo 串。到 GitHub 個人頁面，右上角點 ① New 開新 repo：
接著填表單：
- ② Repository name：直接照網站定位走，這個站就叫
Personal-OfficialWeb，不用再花時間想代號 - ③ Choose visibility：Public 跟 Private 都行，看你想不想公開原始碼。我自己選 Public 是想順便讓原始碼當履歷一部分；如果你只把這個 repo 當部署用、不打算讓別人看，選 Private 完全沒問題
- README、
.gitignore、license 都先不要勾，等 Astro 初始化會自己生 - ④ 確認沒問題，按 Create repository
Clone 到本地
repo 建好之後 clone 到本地，這份本地副本就是後面所有開發的工作目錄：
git clone git@github.com:你的帳號/你的-repo.git
cd 你的-repoAstro 初始化
在 clone 下來的目錄裡跑 Astro 的官方精靈：
npm create astro@latest .精靈會一路問你要不要 TypeScript、要不要裝範例模板、要不要 git init 等等，按需求挑。我選的是 TypeScript Strict、空白模板（之後自己拼）、git init 跳過（因為已經 clone 過 repo）。跑完之後目錄結構就有了，npm run dev 可以馬上開來看。
跟 Claude Code 討論頁面跟資料格式
初始化跑完之後我不會急著手寫 schema，會先把 Claude Code 開起來討論這個站要長什麼樣。對話的重點放在三件事：
- 要有哪些頁面：首頁、文章、專案、經歷、關於——把資訊架構先列出來
- 每個頁面要做什麼：列表？詳情頁？篩選？互動元件？
- 內容大致長什麼樣：頻繁更新還是穩定？是否雙語？有沒有特殊欄位（
pin、updatedDate、cover）？
把這幾件事先講清楚，schema 才能設計得合身。直接動手寫 schema 的話常常會少欄位，後來才發現「啊我忘了 pin 跟 updatedDate」，然後又要回頭改一輪——浪費時間。
跟 Claude Code 討論的好處是它會主動問「這個欄位要不要選填？」「需要支援雙語嗎？」「列表頁要怎麼排序？」這類我自己會漏掉的問題，等於免費請了一個 reviewer 幫你把資訊架構釐清。
設定 Content Collections schema
頁面跟資料格式釐清之後，就可以動手寫 schema 了。Astro 的 Content Collections 是它讓我留下來的功能之一——每個 collection 都有 Zod schema，寫 MDX 時欄位漏填或格式錯，build 前 IDE 就紅線提醒。以 articles collection 為例：
src/content/config.ts
const articlesCollection = defineCollection({
type: 'content',
schema: z.object({
title: z.string(),
description: z.string(),
date: z.coerce.date(),
category: z.string(),
tags: z.array(z.string()).default([]),
pin: z.boolean().default(false),
cover: z.string().optional(),
})
})date 打成 2024-13-40 這種非法日期、或漏填 category，astro dev 當場就噴錯。以前 v2 的 Python 生成器要等跑完才知道欄位錯了，現在寫的時候就擋下來。
樣式這邊我搭 Tailwind CSS v4 + shadcn/ui，元件靠 React island 寫——這層日常維護後面交給 Claude Code 管，有專門一節談。
自動化部署：Cloudflare Workers 串 GitHub
前兩版都跑在 GitHub Pages，這版改用 Cloudflare 主要是這幾點：
- Workers 生態（D1、KV、R2、Durable Objects）讓未來要加動態功能時資源都現成
- 網域本來就在 Cloudflare，綁網域同一個儀表板點一下，HTTPS 自動發
- 邊緣節點多，台灣延遲比 Vercel、Netlify 更順
Cloudflare 已經把 Pages 收進「Workers 和 Pages」這個統一介面，新建一個應用程式四步搞定：
1. 進 Workers 和 Pages 建立應用程式：左側選單進「運算 → Workers 和 Pages」，右上角 ① 點 建立應用程式。
2. 選方法：在「Ship something new」面板挑 ② Continue with GitHub，授權 Cloudflare 讀你 GitHub 的 repo 列表。
3. 挑 repo：下拉選擇帳號之後，③ 從清單挑剛才建好的 repo（Personal-OfficialWeb），④ 按「下一步」。
4. 填組建跟部署指令：⑤ 組建命令輸入 npm run build，部署命令填 npx wrangler deploy（走 Workers 統一流程）。⑥ 按 部署 就會跑第一次 build，幾秒鐘就好。
綁完之後推 main 分支自動 build、自動部署到 edge，整個流程 1–2 分鐘。沒有 staging、沒有 preview flow，因為這就是我自己的站，有錯就改完再推一次。
網域：在同一個平台買、命名走長期主義
網域我走 Cloudflare Registrar 註冊，理由是「成本價」模式——多少錢就收多少錢，不會有第一年便宜、續費翻倍的陷阱，WHOIS 隱私也免費內建。其他註冊商（GoDaddy、Namecheap）比較下來都有續費漲價、介面雜亂、加購推銷這些扣分項。
命名幾個原則：
- 好念好拼，避免讓人猶豫怎麼拼
- 不要塞職業或領域：
xxx-designer.com換跑道會尷尬 - TLD 選單純的（
.com/.me/.dev），別追新潮 TLD - 長度壓短，避免連字號
實驗性的 side project 走子網域（app.lumakes.com、lab.lumakes.com）——主站是身份，子站是實驗，維護一個品牌樹就夠。
回到部署，網域買好之後綁回 Workers Platform。在剛才那個專案的「自訂網域」分頁，① 點右上角的 設定自訂網域：
接著 ② 把網域填進去（example.com、www.example.com、shop.example.com 都可以），③ 按「繼續」就好。如果這個網域本來就在 Cloudflare 名下，DNS 紀錄會自動寫入；不在的話 Cloudflare 會給你一筆 CNAME 去外部 DNS 設定。HTTPS 憑證 Cloudflare 自己處理，不用碰 Let’s Encrypt。
工作環境：四個角落各管一件事
站建好之後，剩下的就是反覆「寫、預覽、改、再預覽」。這四個動作如果擠在同一個畫面，視窗會疊得到處都是，每次找東西都要先花幾秒挑視窗。第三版開站之後我把螢幕切成田字四格，四個常用視窗各佔一個角落、固定不動，眼睛瞥一下就到，根本不用切換。
四個角落各對應一個動作：
- 左上・Zen Browser： (Preview) 專門開
localhost:4321看本地預覽。Zen 比 Chrome / Safari 多了 Workspace 跟側邊欄分頁分組，順便查資料時不會把預覽分頁洗掉 - 右上・VS Code： (Writing & Coding) MDX 文章跟 Astro / React 程式碼都在這寫。MDX 預覽、Tailwind hint、Git 都在同一個視窗
- 左下・Figma： (Design Image) 文章首圖、APP cover、社群圖都用 Figma 排，同一份檔案放所有素材，要哪張就匯出哪張
- 右下・Claude Code： (Chat for dev & write) 開獨立 Terminal 跑 Claude Code——問問題、改樣式、跑
/new-article、/translate-article都在這。我自己用 Ghostty，其實任何 Terminal 都行，會特別獨立出來是因為 VS Code 內建的 Terminal 在大量文字渲染時會出狀況，尤其中文字常常直接變亂碼
分開放的好處不只是看起來整齊——是眼睛瞥一下就到。寫一行 code 就抬頭看左上預覽、改一張圖就瞥左下 Figma，腦袋不用先決定「我要打開哪個視窗」、手也不用滑切換。寫跟看是同一個畫面的事，反射動作直接接起來。
樣式管理：交給 Claude Code
到了這一版我摸出最舒服的工作分工是——樣式跟結構用 Claude Code 管、內容自己寫。
樣式這條線是 Claude Code 最擅長的地方。它能一次讀完整個專案的上下文，理解我用的是 Tailwind v4 不是 v3、shadcn/ui 的元件放在哪、主題變數怎麼定，改起來的一致性比我自己動手還穩。
關鍵是要寫好 CLAUDE.md。我在專案根目錄放了一份，涵蓋技術棧、資料夾結構、樣式規則、常見地雷、雙語創作流程。每次開新 session，Claude 一啟動就知道這個專案在幹嘛，不用重複解釋。細節我之前寫過一篇 Claude Code 調教筆記，這邊不重複講。
內容流程：從靈感到雙語上線
樣式外包之後，剩下的事——「寫什麼」「怎麼寫」「寫得對不對」——只能自己處理。但這不代表每篇都要從零開始重新跟 Claude 解釋規則。我把這條線拆成五步，每一步都把可重複的部分固化下來：
① 內容發掘：求快不求精
第一步是把想法抓住。這個階段我講求的是快，不是精準——有念頭就要馬上記下來，格式亂、錯字多都無所謂。我挑的工具都是那種打開就能寫的輕量速記軟體：
- Apple 備忘錄：macOS 跟 iOS 內建，iCloud 自動同步（免費）
- Bear：介面乾淨、原生支援 Markdown，從速記到長文大綱都能接（免費使用，進階功能需訂閱）
- SimpleNote：超輕量純文字筆記，開啟速度快、跨平台同步（免費）
這三個共通點都是無摩擦——靈感蒐集最怕的就是「整理感」太重，一旦要決定「這筆記放哪個資料夾」就會卡住，想法也跟著冷掉。
② 大綱規劃：先跟 Claude 對骨架
每次要寫新文章，我會先跟 Claude 討論三件事——主題、slug、H2 結構。這三個確定之後，整篇骨架就定了，剩下就是填肉。
這步看起來瑣碎但很重要——它幫我把模糊的想法逼成具體段落劃分，避免動筆之後才發現結構不對要整篇重組。對話過程通常會碰幾次「這樣切會不會太碎？」「這個 H2 跟那個 H2 有沒有重複？」這類修正。
③ 撰寫跟素材：MDX + new-article Skill
骨架定下來之後就直接開 .mdx 檔寫。文章就是放在 src/content/articles/zh-Hant/ 底下的單一檔案，用 Git 管版本，不接 headless CMS——對只有我一個人寫的個人站來說，CMS 是 overhead，MDX 反而最輕。
我把「動筆寫」這件事包成一個自訂 Skill 叫 new-article。指令裡面預先寫好文章的三種類型（工具推薦型、方法論型、經驗分享型）、每種類型該怎麼結構化、可用的特殊元件（pricing tag、callout、code title）長什麼樣、SOP 順序怎麼走。之後我只要打 /new-article，Claude 就會進入「文章撰寫模式」，按這套規則走一遍。
把這層 SOP 化之後，我每次的產出格式都一致，不用每篇都重新跟 Claude 溝通規則。
④ 內容確認跟品牌意向 MD
寫完之後不是直接發，會先跟 Claude 來回打磨——文字節奏、段落順序、用詞精準度。但「打磨」這件事如果每次的標準都不一樣，文章口吻就會飄。
所以我額外做了一件事：把寫作口吻、用詞偏好、開場結構模式寫成一份獨立檔案，叫 BRAND_VOICE.md，放在專案根目錄。CLAUDE.md 跟所有 skill（包含 new-article 跟下面要講的 translate-article）都引用這份檔案，讓「我希望文章長什麼樣」這件事有一個唯一的真相來源。
裡面大概是這種結構：
BRAND_VOICE.md（節選）
## 寫作口吻
- 第一人稱、口語化、像在跟朋友分享經驗
- 不用 emoji
- 用「跟」不用「與」
- 語尾自然收：「搞定」「方便很多」「用起來很順」
## 用詞偏好
- 避開過時口語：「最殺」改用「最精妙」「最值得留下的」
- 帶選擇脈絡：「因為我同時在用 A 跟 B，所以...」
## 文章開場模式
- 開場列的痛點要對齊維度，能被同一個共同根源解釋
- 第一個 H2 必為底層邏輯
- 原則命名化（例如「先規劃、再動筆」），讀者好記確認文章的時候，我會請 Claude 對照這份檔案 review，挑出不符合的地方建議修。規則固化在檔案裡，每次討論的標準就一致，不用每次都重新解釋「我比較喜歡這樣寫」。
⑤ 雙語翻譯：translate-article Skill
中文版定稿之後才進英文版。這個原則很重要——在中文還在反覆改的階段就建英文版，等於要兩邊同步維護，迭代會變慢。
中文定稿後，我用 translate-article skill 處理英文版。這個 skill 包含：
- 找對應的中文 mdx，建相同 slug 的英文檔
- frontmatter 翻譯（含 category 跟 tags 的固定對照表）
- 保留 imports、images、內部連結路徑（中英共用）
- pricing tag、official-link、callout 等特殊元件的中英對照表
- 翻譯時要對齊
BRAND_VOICE.md的口吻——避免翻譯腔、保留第一人稱、用 em dash 對應「——」
整個流程我只要打 /translate-article 並指定 slug，Claude 就會跑完整套流程，最後跑 build 確認頁數 +1。少數需要我介入的是「這個詞中英差異大、做了取捨」的段落，skill 結尾會主動列給我 confirm。
包成 skill 之前，我每次翻譯都要重新交代規則（不要翻譯腔、保留 class variant、內部連結別動）；包完之後，這些規則對 Claude 來說是預設行為。這就是 skill 真正的價值——把可重複的判斷固化下來。
三次重寫學到的心法
把上面這套流程沉澱下來，可以濃縮成幾條：
一、定位決定一切，不是工具。三次重寫的轉折點都不是「舊工具壞了」，是「我對這個站的定位變了」。先想清楚這個站對自己是什麼，再選工具。
二、把規則固化下來才能可重複。BRAND_VOICE.md、new-article skill、translate-article skill——這三個都是同一個邏輯：把每次討論都會用到的判斷寫成檔案，讓下一次的起點不是零。
三、別自己重造基礎建設。v2 那版我花了一堆時間寫圖片處理、路由、SEO——這些 Astro 都內建了。自造工具看起來自由，每一樣都在消耗寫內容的力氣。
四、小站該有小站的節奏。沒有 staging、沒有 preview flow、push main 就上線。過度工程化反而會讓自己不想寫東西——這個站是為了累積內容存在，不是為了展示架構能力。
這一版我大概能用很久了。卡住的部分不是技術，是我對「網站該怎麼存在」的理解；現在這個架構已經足夠承接「持續寫」這件事，剩下的就是規律地寫下去。
