Claude Code 架站實戰：Skills + MCP 工作流

Claude Code 可以在終端機裡讀寫檔案、跑指令，並依專案檔案與對話脈絡協助開發。把「架一個專業網站」交給它，到底能走多遠？先說結論：它能明顯縮短從雛形到上線的時間，但前提是你把範圍、規範、品質閘這三條線都顧到，不然它只會幫你很快地生出一個很快垮掉的網站。

核心重點：Claude Code 搭網站的真正價值在 Skills 加上 MCP 這兩個齒輪，它們把「重複動作」與「對外連接」標準化，讓每一次開工都從對的地方開始。這篇給你一份從範圍界定、CLAUDE.md、Skills、MCP、品質檢查到部署上線的完整工作流。

為什麼「用 Claude Code 蓋網站」跟「用聊天機器人寫 HTML」是兩件事

很多人把 Claude Code 想成「升級版的聊天框」，這是第一個會讓你走冤枉路的誤解。聊天機器人給你一段程式碼，你要自己複製貼上、自己存檔、自己測試；Claude Code 是一個跑在你終端機裡的AI 代理，它能直接讀你的整個專案資料夾、改檔案、跑 build、看報錯、再回頭修（見 Claude Code 官方概述）。換句話說，它不是「幫你寫一行字」，它是「坐在你旁邊、看得見你螢幕的工程夥伴」。

這個差別為什麼關鍵？因為網站從來不是一個檔案，而是一整個資料夾的相依結構：HTML、CSS、JS、圖片、設定檔、部署腳本。你給聊天機器人「幫我做一個首頁」，它回你的永遠是一塊漂浮的片段；你給 Claude Code 同樣一句話，它能先掃過你現有的版型、複用你已經寫好的元件、然後把新頁面接上正確的路由。想把它的定位跟安裝一次看清楚，可以搭配我寫的 Claude Code 中文教學。

換句話說，Claude Code 架站的價值，關鍵在它能記住專案先前做過的決定。這個記憶來自兩個地方：一是每次開工都會讀取的專案設定檔，二是對外連接器；前者靠 CLAUDE.md 與 Skills，後者靠 MCP。接下來會把這兩條線分開說明。

先對齊一下「專業網站」這四個字的定義，免得我們想的不是同一件事。我說的專業，跟視覺炫不炫的關係其實不大，它指的是三個條件同時成立：能在手機上順順地開完、能被搜尋引擎正確讀懂、能穩定地交給原作者以外的人接手維護。一個網站就算畫面再漂亮，只要手機開起來卡頓、或 Google 收錄不出來、或只有原作者自己會改，那它離「專業」還有一段距離。這篇文章所有環節的最終目的，都是為了讓這三個條件成立，AI 只是手段，這三個條件才是目的。

開工前三件事釘死：範圍、技術棧、內容來源

我最常看到踩雷的狀況是：興沖沖打開 Claude Code，下了「幫我做一個咖啡館網站」這種指令，兩小時後你得到一個又一個彼此打架的版本，因為每一輪它都會把方向往不同地方拉。這不是工具的問題，是你沒有給它邊界。

開工前我一定先釘死三件事，缺一不可：

• 範圍：這個網站有幾頁、每一頁的目的是什麼。形象官網五頁跟電商二十頁是兩個世界，不要混在一起講。
• 技術棧：純靜態 HTML、Astro、Next.js、還是 WordPress？這個決定會回頭決定你能用哪些 MCP、哪些 Skills。
• 內容來源：文案誰寫、圖片哪裡來、品牌資產在哪。AI 生圖可以，但商用授權要搞清楚。

底下這張表是我用來跟客戶對焦的對照表，把「沒準備就開工」跟「釘死再開工」的差別攤開來看：

面向	沒準備就直接開工	釘死三件事再開工
範圍	每輪對話都在重新定義網站長什麼樣	每頁目的明確，AI 只在邊界內發揮
技術棧	改一個功能要砍掉重練	路由、元件、部署方式從頭一致
內容	文案與圖片臨時生，版權與品質失控	文案有來源、圖片有授權清單
成本	來回修正吃掉大量 token	每輪迴圈短，token 花在刀口上

這個範圍界定的動作我稱為「範圍契約」。你可以在契約裡明確寫「不做會員系統、不做多語系、不做金流」，這幾個「不做」往往比「要做什麼」更能防止專案失速，因為 AI 不會自己畫底線，底線永遠是你給的。

CLAUDE.md 是整個專案的大腦，先寫它再寫任何程式碼

CLAUDE.md 是 Claude Code 每次啟動都會自動讀進來的專案說明檔。多數人把它當裝飾，隨便丟兩行就開工。老實說，這是整個流程裡 CP 值最高的一個動作：你花三十分鐘寫一份清楚的 CLAUDE.md，接下來每一次對話都幫你省下重新解釋的時間。

對一個網站專案，我會把 CLAUDE.md 拆成這幾個區塊，缺一個都會漏訊號：

• 專案一句話：這是給誰的網站、解決什麼問題、用什麼技術棧。一行字，但這行字會貫穿整個專案。
• 資料夾結構：哪個資料夾放元件、哪個放頁面、哪個放圖片。標清楚它就不會亂塞檔案。
• 設計規範：主色、字體、斷點、按鈕樣式。給它 token 名稱，例如 primary-color，別只跟它說「用藍色」。
• 內容規範：語言 zh-TW、品牌語氣、禁止出現的字詞清單。網站是要面對讀者的，語氣不一致馬上被看穿。
• 品質閘：build 指令是什麼、有哪些 lint 規則、部署前要過什麼檢查。這些寫下來，它才知道什麼叫「做完了」。

把它想成你交辦新人時會寫的 onboarding 文件。寫得越具體，它越不需要自行猜測。如果你還沒摸過這個檔案，先看 官方快速入門，會更清楚哪些指令值得記下、哪些只是雜訊。

光講原則有點抽象，底下是一份給五頁形象官網用的 CLAUDE.md 長什麼樣子，你可以拿去當模板再改：

專案：某咖啡館形象官網，共五頁（首頁、關於、菜單、分店、聯絡）
技術棧：Astro 加 Tailwind，部署到 Netlify
資料夾：src/pages 放頁面、src/components 放共用元件、public/img 放圖片
設計 token：主色 #1a4d8f、輔色 #f5f5f5、字體思源黑體、斷點 768 與 1024
內容規範：繁體中文，語氣親切但不油膩，禁止使用「全台第一」「業界首選」這類無法證實的極端用詞
品質閘：npm run build 必須過、SEO 健檢 Skill 結果無紅字、行動版三個斷點截圖不破版才准部署

注意這份範例裡每一行都是「可被驗證」的：技術棧可對應到實際指令、設計 token 可對應到程式碼變數、品質閘可對應到一個會回傳成功或失敗的檢查。最怕的是寫一堆形容詞，例如「設計要現代感、要有質感」，這種描述對 AI 來說等於沒寫，因為它沒有一個客觀的對錯可以對齊。把形容詞換成可量測的條件，是寫好 CLAUDE.md 最關鍵的一個動作。

Skills 怎麼把重複工作收斂成一個指令

Skill 是 Claude Code 裡可以把「一套步驟」打包成「一個指令」的機制。它的本質就是把你腦袋裡那套 SOP 外掛出來，讓代理每次都用同一個方法做事，省下每次重新發明輪子的力氣。完整的入門觀念可以看 Claude Skills 完整指南。

蓋網站時我會固定準備這幾個 Skill，每一個都是被血淚教訓逼出來的：

• 新增頁面：給它頁面標題與段落大綱，它自動套版型、填 meta、建路由、更新 sitemap。一個指令掉一頁。
• 圖片最佳化：一個指令把資料夾裡所有圖片壓縮、轉 WebP、補上 alt 文字與寬高。手機載入速度就是這顧下來的。
• 連結檢查：掃整站，列出所有斷掉的內部連結與漏掉的 alt。網站越長越大，這個 Skill 越值錢。
• SEO 健檢：跑一次 meta、標題層級、canonical、OG tag 的盤點，輸出一份待辦清單給你判讀。

這四個 Skill 的共通點是：它們都是「你不想每次都手動做、但每次都得做」的事。把它們打包成 Skill 之後，你下的是「幫我跑一次 seo-check」，省下十分鐘跟它解釋要檢查哪些欄位的力氣。這就是 Skills 對網站專案最實際的回報：把紀律變成預設值。AI 最大的問題從來都在一致性不夠，能力它早就夠了，Skill 就是用來補一致性這一塊。

一個 Skill 在檔案裡長得像一份給代理看的說明書，大致包含三個部分：觸發時機（什麼時候要用它）、執行步驟（按什麼順序做哪些事）、輸出格式（做完要回報什麼）。以「圖片最佳化」為例，觸發時機寫「當我新增圖片到 public/img 時」，執行步驟寫「把原圖壓縮到寬度不超過 1600px、轉成 WebP、補上與圖片同名的 alt 文字草稿、回報每張圖的壓縮前後大小」，輸出格式寫「一張清單，列出檔名、原大小、新大小、節省比例」。你看，整份 Skill 沒有任何抽象的「請最佳化圖片」，每一句都是具體到可以驗收的動作。寫 Skill 的訣竅跟寫 CLAUDE.md 一模一樣：把形容詞換成動詞，把「大概做一下」換成「做完回報這幾欄」。

MCP 是對外的那隻手：檔案、瀏覽器、Figma、WordPress

如果 Skills 是把「內部步驟」標準化，那 MCP（Model Context Protocol）就是把「對外連接」標準化。MCP 是一個讓模型跟外部資源溝通的協議，你可以把它想成幫 Claude Code 裝上一堆可插拔的手，每隻手抓一種工具。完整的協議介紹看 MCP 入門指南。

蓋網站時，這幾隻手特別好用，我列成表格讓你直接挑：

MCP server	用途	為什麼省時間
Filesystem	讀寫整個專案資料夾	不必手動貼檔案內容給模型
Browser / Playwright	開真實瀏覽器測試與截圖	RWD 與互動 bug 它自己看自己修
Figma	讀設計稿圖層與設計 token	設計還原成程式碼不必人工翻譯
Fetch	抓參考網站的結構當研究	分析版型不必開一堆分頁

表中的 Figma MCP 處理的是「已經畫好的設計稿」；若連設計本身都想用 AI 先生成、再交給 Claude Code 工程化，這條路線我整理在〈Stitch 與 Claude Code 跨生態架站〉。若設計方向還很模糊，想先跟 Claude 把配色、字體與版面結構這些取捨想清楚再動工，可以看〈用 Claude 把設計決策想清楚〉。另一條常見的組合是用 Midjourney 先生成視覺方向、再交給 Claude Code 落地成頁面，完整流程可以參考〈從定位走到上線的 Claude 與 Midjourney 工作流〉。

特別想點出 Browser MCP，因為它是「你自己看」跟「它自己看」之間的橋樑。以前要請它改一個手機版的 bug，你得自己截圖貼給它、自己描述怎麼重現；現在它能自己開 DevTools、自己看 console 報錯、自己改完再驗證。這個迴圈一建立起來，效率是量級上的差距，不是一點點。

更具體地說，Browser MCP 把「除錯」從一段你來我往的對話，變成代理可以自己閉環的循環：它開頁面、看到東西歪了、讀 console、改 CSS、再重新整理確認。你只要給它一個夠清楚的驗收條件，例如「手機寬度下，首頁的 hero 區塊不能出現水平捲軸」，它就能自己跑到滿足條件為止。這也帶出一個重要的使用觀念：你給 AI 的指令越靠近「可觀察的結果」，它就越幫得上忙；你給的越靠近「主觀的感覺」（例如「讓它看起來更專業」），它就越容易原地打轉。把驗收條件寫成眼睛看得到的事實，是善用 MCP 的基本功。

如果你的網站是跑在 WordPress 上，還有專門的 WordPress MCP 能讓它直接寫文章、改外掛設定、批次處理媒體庫，這條路線我寫在 Claude Code 搭配 WordPress MCP。選靜態站還是 WordPress，關鍵是看你的內容更新頻率跟誰來維護，不是看哪個看起來比較潮。

技術棧怎麼選：給一張決策表，別再憑感覺

「技術棧要選哪一個」是整個專案最早、也最容易被低估的決定。選錯了，後面 Skills 與 MCP 都要跟著重練，已經寫好的頁面也要搬家。我把最常被問到的四個選項整理成一張決策表，照你的實際狀況對號入座，會比憑感覺選準得多：

技術棧	適合場景	與 Claude Code 配合度	最大地雷
純靜態 HTML/CSS/JS	一頁式、活動登陸頁、極簡作品集	高，檔案少、好讀好改	頁面一多就難維護，沒有版型可複用
Astro 等靜態站產生器	內容站、形象官網、部落格	很高，元件化、部署最省事	需要會員或頻繁互動會卡關
WordPress	要常更新內容、業主自己維護、需要外掛生態	中，要靠 WordPress MCP 才順	速度與資安要長期顧，外掛會互相打架
Next.js / React	需要複雜互動、會員系統、客製後台	高，但複雜度也最高	過早最佳化，把簡單網站越蓋越重

這張表有三個補充我會反覆跟讀者講。第一，純靜態不等於陽春，Astro 這類框架可以做出非常精緻的互動與動畫，關鍵差別在於你需不需要「頻繁由非技術人員更新內容」。如果每週都要行銷同事登入改文案、發新文章，WordPress 那條路會輕鬆很多；如果內容一年才動兩次，靜態站反而更乾淨。第二，會寫 React 不代表就該選 Next.js，很多形象官網用純靜態就綽綽有餘，把複雜度往自己身上攬不會有任何回報，只會讓部署與維護變得更痛苦。

第三，也是最實際的一點：技術棧這件事沒有標準答案，但有最差答案，那個最差答案就是「聽說某個框架很紅所以用某個框架」。你選的依據應該是「這個網站未來三年主要由誰維護、多久更新一次、需不需要複雜互動」，憑這幾個條件去挑，會比看工程論壇的流行度排行榜準得多。範圍契約裡那一行技術棧，值得你花一整個晚上想清楚。

一份從零到上線的七步實戰流程

把前面講的東西串起來，底下是我實際在用的七步流程。它不是唯一解，但它把我踩過的坑都吸收進去了，照著走可以少繞很多路。

這七步的順序是有邏輯的：先界定、再立規、然後才動手。很多人一拿到工具就想跳到第三步直接蓋骨架，結果蓋到一半才發現技術棧選錯、內容還沒生，於是整個砍掉重來。把前兩步當成可以慢、但不能省的投資，後面五步才會跑得順。你也可以把這七步想成一個不斷內縮的漏斗，從最寬的「這個網站到底要做什麼」，一路收斂到最窄的「這一頁的這個按鈕要不要改」，每一次收斂都建築在前一次的決定上。

1. 寫範圍契約：一頁 A4，寫清楚要做幾頁、技術棧、內容來源、三個明確的「不做」。
2. 寫 CLAUDE.md：把上面那份契約落成專案大腦，加上資料夾結構與設計 token。
3. 建立骨架：請它用你選的技術棧搭一個最小可跑的版本，首頁加一個關於頁就夠，不要一次蓋十頁。
4. 打包 Skills：至少先做「新增頁面」與「圖片最佳化」這兩個，之後再補 SEO 健檢與連結檢查。
5. 接外部工具：Claude Code 已能處理工作目錄中的檔案；有需要時再接瀏覽器測試、Figma 或其他 MCP 服務。
6. 逐頁擴充：一次做一頁，每做完一頁就跑一次 build 與 SEO 健檢 Skill，確認沒退化再做下一頁。
7. 部署前品質閘：跑速度、行動版、SEO 三條線的檢查，全過才推上線。

這個流程最關鍵的不是任何一步本身，而是「每一次迴圈都很短」。我寧可你一個晚上跑十次小迴圈，也不要你悶著頭做完二十頁才回頭看。AI 代理的好處是它可以陪你高頻率迭代，前提是你真的迭代，別把它當許願池，丟一句大願望就放著等。

用五頁形象官網拆解決策的實際長相

講再多原則，不如看一個具體決策是怎麼長出來的。底下我用一個五頁形象官網（首頁、關於、服務、案例、聯絡）當尺度，把幾個關鍵判斷點攤開來，這是一般化的流程形狀，不牽涉任何特定客戶的數字，你可以直接把它套到自己手上那個專案。

第一個判斷：這個網站交給業主之後誰來改？如果答案是「業主自己每個月會發一篇新文章」，那直接選 WordPress 配 WordPress MCP，讓業主之後能在後台自己更新，你不必每次都被叫回來改一個錯字。如果答案是「上線之後基本不會動，要動也是找我」，那 Astro 這類靜態站產生器是更乾淨的選擇，部署一條線、速度也最快。這個判斷會回頭決定你後面所有 Skills 的寫法，所以它必須最早做。

第二個判斷：首頁要傳達的唯一一件事是什麼？五頁網站最怕的是首頁什麼都想講，結果什麼都講不清楚。我會強迫自己在範圍契約裡寫一行：「首頁要讓訪客在十秒內知道我們做什麼、為誰做、怎麼聯絡」。這一行字會變成 Claude Code 改首頁時的北極星，每當它想把版面塞滿，你就拿這行字把它拉回來。

第三個判斷：哪一頁最值得花力氣？五頁裡一定有一頁是轉換的關鍵，形象官網通常是「服務」或「案例」，電商是產品頁，作品集是作品本身。把那一頁設定為品質基準，其他頁面用同一個版型衍生。Claude Code 很適合這種「先打磨一個範本，再批量衍生」的模式，你只要把基準頁調到九十分，剩下幾頁的衍生幾乎是免費的。

第四個判斷：上線條件是什麼？在範圍契約裡寫可於上線前驗證的條件，例如「五頁能在指定手機與網路條件下正常載入、無斷鏈、頁面可抓取，sitemap 已提交」。Search Console 的索引狀態要在上線後持續觀察，不能當成上線當下的完成條件。

這趟流程走下來，你會發現真正花時間的環節是寫範圍契約與盤內容，寫程式反而是整個過程裡最快的一段。這也是我用 Claude Code 搭網站最深的體會：工具把「實作」這一段壓到最短，所以你的時間分配會整個倒過來，從「花最多時間寫碼」變成「花最多時間想清楚到底要什麼」。這個轉變一開始會讓習慣寫碼的人很不適應，但它才是產出高品質網站的真正關鍵。AI 沒有讓想清楚這件事變便宜，它只是讓沒想清楚的成本更早就暴露出來。

也要提醒，五頁是這套流程最舒服的尺度，但網站很少永遠停在五頁。當它長到二十頁、五十頁，真正的考驗會從「能不能蓋出來」變成「能不能不亂掉」。這時候前面投資的 CLAUDE.md、設計 token、Skills 與品質閘會開始回本，因為它們就是讓網站可以長大而不崩塌的鷹架。反過來說，如果你在五頁的階段就偷懶跳過這些基本功，等網站長大再回頭補，成本會是當初的數倍。把每一個小專案都當成未來大專案的練習場，這是我會給每一個剛開始用 Claude Code 蓋網站的人，最誠懇的一句話。

網站品質不是跑得起來就算數：速度、行動版、SEO 三條線

很多人把「網站做好了」等同於「在我的電腦上打得開」。這是業餘的定義。一個專業網站要同時過三條線：載入速度、行動版體驗、SEO 結構。這三條線顧不好，你的網站就算長得再漂亮，Google 不會推、訪客不會留。

速度本質上是使用者體驗問題，也屬於 Google 排名系統眾多考量之一（見 2018 年的 行動搜尋速度說明）。Google 將 Core Web Vitals 納入更廣的頁面體驗訊號，但良好體驗不會凌駕內容相關性（見 web.dev 的說明與 Search Central Blog 的頁面體驗文章）。

行動版這條線，看一個數字就懂：全球網站流量已經有超過六成來自行動裝置，而且這個比例還在逐季成長（Statista 的逐季統計，2026 年 4 月）。你的網站在桌機上再美，手機上一團亂就是直接出局。完整的對應做法我整理在 RWD 響應式網頁設計 與 網站速度這條線的細節，這兩篇是搭配這套流程看的基本功。

SEO 這條線，要檢查的欄位我習慣列成一張表，把「SEO」這個嚇人的大詞拆成幾件具體可勾掉的事：

項目	為什麼重要	誰來檢查
每頁一個 H1、標題層級正確	讓搜尋引擎看懂頁面結構	Skill 掃、真人複核
title 與 meta description	影響搜尋結果呈現與點擊；Google 可能改寫顯示文字	真人寫
canonical 與主要網址一致	協助搜尋引擎辨識代表網址並整合重複網址訊號	Skill 自動、人工確認
圖片有 alt 與寬高	無障礙與載入穩定度	Skill 自動、真人審 alt
內部連結指向有效且錨文字自然	協助使用者與搜尋引擎理解相關頁面	Skill 掃、真人複核
sitemap 與 robots.txt	sitemap 協助發現網址；robots.txt 管理爬取，不是存取控制	Skill 自動、人工確認
OG 與社群 tag	分享時的預覽長相	真人看
行動版斷點不破版	確保手機使用者能正常閱讀與操作	瀏覽器截圖與互動測試

這張表把抽象的 SEO 拆成可檢查任務。Claude Code 配合 Skill 能自動檢查部分機械性項目；標題、描述、alt 與結構化資料是否準確，仍要真人判讀。想進一步把這些檢查項目交給代理、排進固定的優化流程，可以參考把 Claude Code 接進 SEO 工作流。

這裡要特別提醒一件容易被分數綁架的事：Lighthouse 那個零到一百的分數是參考用的，不是成績單。一百分不代表你的網站就好，可能只是那個頁面剛好沒什麼內容；六十分也不代表世界末日，可能只是少了一張圖的寬高。我看分數的習慣是看「趨勢」，盯著單次絕對值意義不大；而且我寧可相信來自真實訪客的欄位資料（field data），也勝過只信在實驗室跑出來的模擬資料（lab data）。模擬跑出來的分數可以高分但難用，真實訪客的載入時間不會騙你，這也是為什麼部署完我一定會拿自己的手機親自點一遍，光盯著儀表板慶祝是會出事的。

什麼時候 Claude Code 會帶你走歪

我不想把這套流程講得好像萬能。Claude Code 在蓋網站時有幾個明確的極限，先把這些講清楚你才不會用錯地方。

第一個是範圍失速。當你沒有範圍契約，它很容易一路加功能、加頁面、加互動效果，每一個都「聽起來不錯」，加起來就是一個失去重點的網站。第二個是使用額度與 API token 成本。Claude Code 可透過訂閱方案的使用額度，或 API 的 token 計費方式使用；複雜改版若反覆重做，兩種方式都會增加資源消耗（計價方式見 Anthropic 定價頁）。要壓住消耗，先減少無謂來回，把範圍契約與 CLAUDE.md 寫清楚。想搞懂 token 怎麼計算，看 AI Token 完全解析。

第三個是「vibe coding 的幻覺」。看 AI 一直吐出能跑的程式碼，你會誤以為自己掌握了整個系統，其實你只是掌握了「它現在跑得起來」。等它跑到一個你沒看過的報錯，你才發現自己根本沒讀過它寫進去的那一堆相依套件。這不是我反對 vibe coding，這是提醒你它在哪條線上很強、哪條線上要踩煞車，相關的實戰討論可以參考 Vibe Coding 完整入門與 Vibe Coding 網頁設計實戰。

底線是：Claude Code 適合蓋中小型、範圍清楚、能快速迭代的網站；如果你的需求牽涉複雜的金流邏輯、高安全性、或龐大的既有系統整合，那你要的不是更強的 AI，而是一個真正的工程團隊。把它當成「把八十分的事做到九十五分」的工具最划算，期待它無中生有蓋出一個大型電商平台，只會換來失望。

還有一個容易被放過的盲點要講清楚：AI 很會在它熟悉的瀏覽器與環境裡把網站跑到完美，但真實世界的訪客用的是各種你沒想過的裝置與瀏覽器。跨瀏覽器相容、舊版 Safari 的怪脾氣、慢速網路下的載入行為，這些邊界條件 Claude Code 不會主動幫你測，你最好自己排一份測試清單，至少涵蓋一款 iPhone、一款 Android、再加上一個桌機瀏覽器。這份清單不用很長，但它存在的本身，就會逼你從「在我的電腦上能跑」升級到「在真實訪客手上也能跑」。

部署上線：把靜態站推到 Netlify

如果你選的是純靜態或 Astro 這類技術棧，部署是最爽的一段。Claude Code 跑出來的就是一堆檔案，把這些檔案推到靜態託管平台就完事。我自己常用 Netlify，因為它接上 Git 之後就是一條提交後自動部署的生產線，每次推送都觸發一次全新 build（見 Netlify 官方入門文件）。如果你對 repo、commit、分支這些詞還很陌生，先看〈GitHub Repo 是什麼〉把基礎補起來，底下的部署邏輯會更好懂。

這條自動部署線最值得善用的，是它為每一次提交產生的預覽網址。你不必把每個改動都推到正式站，可以先推到一個預覽分支，拿到一條只有你看得到的臨時連結，在那上面驗收完再合進主線。這個習慣搭配 Browser MCP 特別順：請代理在預覽網址上自己跑一輪行動版截圖與連結檢查，全過了才合併。把驗收往前推到預覽階段，別等到推上正式站才發現問題，你的正式站會一直維持在乾淨可信任的狀態，訪客永遠不會替你看到第一手的 bug。

上線前最後一哩路的檢查我會做這幾件事：先把自訂網域的 DNS 指好（DNS 設定的細節我寫在 DNS 設定教學那篇），確認 SSL 憑證由平台自動簽好、不用自己手動續約；推一個 commit 觸發部署，等它跑完，再拿自己的手機實際點一遍每一頁。這個「手機實際點一遍」的動作，比任何 Lighthouse 分數都誠實，分數可以高分但難用，你的手指不會騙人。

部署完成不等於專案完成。網站上線那一刻，才是 SEO 馬拉松的起點：接上 Google Search Console 觀察實際收錄狀況、定期看核心版面體驗指標、每加一頁就重跑一次 SEO 健檢 Skill。把這些收進同一條流程，網站才會越養越壯，別讓上線那天變成它的巔峰。

給非工程師：你不必讀懂每行程式碼，但這三件事要親自顧

whoops 的讀者很多是行銷人、品牌主、接案設計師，不是軟體工程師。你完全不必讀懂 Claude Code 寫出來的每一行程式碼，但有三件事你必須親自顧，不能外包給 AI 之後就放生。這三件事恰好也是 AI 最幫不了你的地方，因為它們靠的是判斷，不是產出。

第一件，版型是合約，不是裝飾。設計 token、元件命名、斷點這些看似工程的事，其實決定了你的網站未來長得像一個品牌，還是一堆拼湊頁面。你要親自跟 Claude Code 確認「所有按鈕都叫 button-primary、所有標題都用同一個字級」，這個一致性一旦建立，未來加新頁面都不會走樣。放任 AI 每頁重新發明樣式，最後你會得到一個精神分裂的網站。

第二件，部署是一條生產線，不是一個按鈕。你要搞懂「推一個 commit 會觸發什麼、失敗了在哪裡看 log、怎麼退回上一版」。這些不用會寫程式也能學會，但你必須自己走過一次完整的「改一個字、推上線、看到它上線、退回上一版」的迴圈。沒走過這一輪，你的網站就永遠處在「上線即失火」的狀態，每次更新都是一次賭博。

第三件，品質閘是紀律，不是建議。速度、行動版、SEO 三條線的檢查，是你給自己立的規矩。Claude Code 很樂於幫你跳過這些檢查直接交付，因為它的目標是「完成你這次的請求」，不是「守護網站長期品質」。長期品質是你這個人的責任，每次想偷懶跳過品質閘的時候，提醒自己一句：上線五分鐘的爽感，通常換來五個月的善後。

把這三件事顧好，你就能放心把產出交給 Claude Code，自己守住判斷這一關。AI 是你的副駕，但這台車的方向盤一直在你手上，這個定位想清楚，你才會用得安心、也用得久。

你現在就能做的五個下一步

看完一整套觀念，真正會產生差別的還是你下線之後做的第一個動作。底下這五步是我會建議你今天、最遲這個週末就動手的順序，每一步都不超過半小時，但串起來就是一個完整的起手式。

1. 挑一個你最想做的網站類型，形象官網、作品集、或一頁式銷售頁都行，寫一頁範圍契約，連三個「不做」一起寫下來。
2. 在專案根目錄開一個 CLAUDE.md，把範圍契約落成專案大腦，先填滿那五個區塊再開始動工。
3. 先做「新增頁面」與「圖片最佳化」這兩個 Skill，其他 Skill 等你實際遇到痛點再補，不要一次想全做。
4. 在明確的工作目錄中跑一輪最小可上線版本；需要畫面驗收時，再接瀏覽器測試工具。
5. 部署前用速度、行動版、SEO 三條線跑一次品質閘，全過才推上線，任何一條沒過就回頭修。

把 AI 當產出的引擎，把範圍契約與品質閘握在自己手上。流程走順後，從想法到可驗收版本的距離會縮短。真正的競爭力不只在「會不會寫程式」，而是能不能想清楚要做什麼、能不能守住品質底線。重點不是工具多強，而是你有沒有先把邊界畫清楚。