Claude Code + Stitch 網頁設計：從設計稿到上線工作流

你也許曾看過那種 demo：在 Google Stitch 打一句話，三十秒就跑出一整組漂亮的 UI 畫面；再切到 Claude Code，看它像個聽話的工程夥伴一樣自己改程式碼、跑測試、修 bug。畫面很熱血，但你心裡大概只剩一個問題：這兩個分屬 Google 和 Anthropic 的工具，到底能不能接在一起，真的幫我把一個網站做出來，而且還能被 Google 排名？

我先把答案講在前面。可以，這條「跨生態系」路線能協助非設計背景的人製作網站原型，再把它工程化。前提是把兩個工具的角色切乾淨：Stitch 協助產生與調整介面設計，Claude Code 依專案規範實作與驗證程式碼；兩者都不能取代上線前的產品、內容、效能與安全驗收。

這篇我會帶你走一遍這套工作流：從 Stitch 出圖、把成果餵進 Claude Code 變成正式專案，到怎麼在過程裡守住 Google 真正在乎的行動優先、速度與內容經驗。如果你是行銷人、創業者或接案設計師，想用 AI 把網站從零到一蓋起來又不踩 SEO 的雷，這篇是寫給你的。想先補 Claude Code 的底，可以先讀我寫的 Claude Code 中文教學；想把 Claude 整個生態先看過一遍，Claude 完整使用指南是很好的入口；想看整體 AI 網頁設計的全景，則可以搭著 AI 網頁設計實戰指南 一起看。

先打個預防針：這不是「按一個鈕網站就自己長出來」的流程。Stitch 與 Claude Code 可以減少部分重複工作，但每一階段仍需要人判斷需求、下指令、檢查輸出並測試結果。適合交給工具的是反覆產生與修改的工作，互動、內容、效能與上線決策仍由人負責。若要補充人機分工的背景，可參考生成式 AI 使用指南。

先把兩個工具的角色切清楚：一個管看，一個管做

很多人把 AI 網頁設計想成「一個工具搞定全部」，這是第一個誤會。Stitch 和 Claude Code 解決的是完全不同的問題，硬要它們各自包辦對方擅長的事，只會兩頭都做不好。

Google Stitch 是 Google 在設計這一端的 AI。你給它一句描述、一張參考圖或一份截圖，它能產出一組視覺化的 UI 畫面與元件，並且可以把結果匯出成 HTML、CSS 或 Flutter 格式（見 Google Stitch 官方網站）。它的強項是「視覺品味」與「快速把腦中的畫面具象化」。

Claude Code 則是 Anthropic 那一端的代理人。它住在你的終端機裡，讀得懂整個專案的檔案結構，能寫新檔案、改舊程式碼、跑指令、除錯，而且可以透過 MCP（Model Context Protocol）接上你的 CMS、資料庫或第三方服務。它的強項是「工程執行力」與「在真實 repo 裡長期維護」。

換句話說，就一句話：Stitch 給你「長相」，Claude Code 給你「骨架」。你想像一下裝潢房子，Stitch 是那個幫你畫 3D 透視圖、挑沙發顏色的設計師，Claude Code 則是那個真的去拉水電、砌牆、釘天花板的工班。兩個都很重要，但你絕對不會叫設計師去接電線，也不會叫水電工去配色彩。

Stitch 能交出什麼，又交不出什麼

這一段是期待管理，老實說比任何操作教學都重要。把 Stitch 匯出的前端程式碼直接當成正式成品，可能留下語意、效能、響應式或維護問題。搜尋排名還同時受內容、相關性與許多技術條件影響，不能只憑匯出方式判定。

Stitch 真的能幫你做到的事

Stitch 的核心產出是「畫面等級」的設計資產。你問它「一個極簡風格的 SaaS 落地頁，主視覺放左、報名表單放右」，它給你一組看起來很專業的版面，顏色、間距、字體層級都幫你配好。這對沒有設計底子的人是救命的功能，因為你終於不用再對著空白 Figma 畫布發呆。

它也支援把設計匯出成可讀的前端程式碼，這是它跟純繪圖工具最大的差別。你拿到的是一份「長得像網站」的 HTML 與 CSS，已經超越單純的圖片層次。這份匯出物，就是我們要交給 Claude Code 的起點。

Stitch 明確做不到、也沒打算做的事

Stitch 不會幫你把網站「架起來」。它不處理網址、不處理主機、不處理 sitemap、不處理結構化資料，也不會幫你通過任何 SEO 檢查。它匯出的程式碼是「設計原型等級」，不是「生產環境等級」。

這裡要特別提醒一個容易誤判的地方。Stitch 匯出的 HTML 往往長得很像一份完整的網頁，打開瀏覽器預覽還能看到畫面，這會給人一種「好像可以直接用了」的錯覺。但你只要把它放進真實專案，就會發現它的標記幾乎全是為了還原視覺而存在：大量的行內樣式、為了排版而硬加的空區塊、缺乏語意的包裝層。這些東西在單頁預覽裡無害，一旦要擴充成多頁、要共用樣式、要讓搜尋引擎讀懂結構，就會變成處處絆腳的負債。所以與其說 Stitch 給你「程式碼」，不如說它給你「一份可以餵給工程工具的設計稿」。後續的工程化，才是價值真正落地的地方。

這兩者差多少？我用個比喻：原型等級的程式碼，就像樣品屋，看起來甚麼都有，但你不能搬進去住；生產環境等級的程式碼，是真正接好水電、領到使用執照、能登記戶籍的房子。中間那段「從樣品屋變成實屋」的工程，就是 Claude Code 要補上來的。如果你對「設計原型」和「成品」這層差異有興趣，可以延伸讀 UI 原型設計 和 線框圖設計入門，把腦中的層次拉清楚。

為什麼我會把這兩個跨陣營的工具串在一起

這整篇文章最關鍵的論點在這裡，我先講清楚。目前市面上談 AI 架站，大致有兩條路線，各自有盲點。

第一條是「全 Google 路線」：Stitch 產生介面，再交給 Google 的開發工具處理程式碼。同一生態的匯出與串接較直接；若專案採用其他技術棧，或需要長期維護與複雜測試，仍要用實際需求比較產出品質、版本控制與除錯流程。

第二條是「全 Anthropic 路線」：直接用 Claude Code 從無到有寫程式碼，搭配 Figma 當設計來源。Claude Code 的工程肌肉很強，但設計品味要靠你自己或設計師在 Figma 裡先想好，對非設計背景的人門檻偏高。想看這條路的細節，可以讀 用 Claude Code 搭建專業網站 和 Figma AI 功能解析。

我的主張是：把兩邊最強的那一塊拆出來接在一起。設計品味交給 Stitch，因為那是它最擅長、也是非設計師最缺的；工程執行交給 Claude Code，因為那是它目前最成熟、也最能扛長期維護的。跨生態系聽起來好像多一道手續，但你換來的是「每一關都用最強的工具」，不必從頭到尾將就同一個工具的弱項。

換個方式想：你組一支球隊，不會硬要九個投手去打全場。你會找最會打擊的當打者、最會守備的當游擊手。工具組合的邏輯是一模一樣的。

當然，跨生態系不是沒有成本。你得學會兩套工具的操作邏輯，也得處理它們之間格式轉換的那道手續。但這個學習成本是一次性的，學會之後它就變成你的直覺。而你換來的，是設計端與工程端都站在各自最強的位置上。對一個要把網站當長期資產、會持續新增頁面與迭代內容的人來說，這個前期投資幾乎一定回收。對還在猶豫要不要踏入 AI 架站的人，Vibe Coding 網頁設計實戰 示範了另一條同樣不寫程式就能上路的路線，兩者可以互相對照。

一套 Stitch 到 Claude Code 工作流

底下這套流程不是理論，是做小型形象站和落地頁時實際會跑的順序。這裡不會給你假數字說「這樣做產能提升百分之多少」，因為那種話術本來就不該信。我只告訴你每一步在做什麼、為什麼這樣排。

在開始之前，先講一個我認為很重要的前置動作：開一個資料夾，把這個專案用到的所有 Stitch 產出、截圖、以及你最終寫好的 CLAUDE.md 一起放進去，並用版本控制管起來。這個習慣看似不起眼，卻能幫你解決兩個未來一定會遇到的麻煩。第一個是回溯，當你改了某個頁面卻發現效果變差，你需要能回到上一個穩定的版本；第二個是交接，當你把這個專案交給別人或是回頭自己接手時，一份清楚的設計來源與規矩紀錄，會幫你省下大量重新理解的時間。AI 工具會讓產出變快，但快不代表可以不管紀錄，反而因為迭代次數變多，版本紀律比以前更重要。

第一步：用 Stitch 把版面與元件集先定下來

我先在 Stitch 裡用自然語言描述這個網站要長怎樣：是形象站還是落地頁、主視覺放哪、有哪些區塊、配色偏向哪種產業氛圍。我不會一次要它做完整個網站，而是拆成「首頁」「關於我們」「服務列表」「聯絡頁」這種頁面等級的單位，一次做一頁，品質穩得多。

這一步的重點不是程式碼，是「把腦中模糊的畫面變成具體的視覺決策」。顏色怎麼選、字體層級怎麼排，可以回頭參考 網頁配色實戰指南 和 排版設計實戰技巧，讓你給 Stitch 的 prompt 更精準。Prompt 寫得越具體，它吐出來的東西越能用。

第二步：把 Stitch 的匯出物截圖存下來

這一步很多人會跳過，直接把 HTML 丟給 Claude Code，結果 Claude Code 看得到原始碼、卻看不到「畫面到底長怎樣」，重做出來的版面常常走鐘。我的習慣是兩樣都留：Stitch 匯出的 HTML 與 CSS 留一份，同時把設計畫面截圖也存一份。截圖是給 Claude Code 的「視覺真相」，HTML 是給它的「結構參考」。

第三步：在 Claude Code 裡先把規矩寫進 CLAUDE.md

這是整條流程裡最關鍵、也最容易被放過的一步。在把任何 Stitch 的東西餵進去之前，我會先在專案根目錄寫一份 CLAUDE.md，明確告訴 Claude Code 這個專案的規矩：用什麼框架（Astro、WordPress 主題、或純靜態）、行動優先、不可以產生內聯樣式氾濫的標記、必須符合語意化 HTML、要預留結構化資料的位置。

為什麼這份檔案這麼重要？因為 AI 工具不會自己長出品味，也不會自己記住你的 SEO 底線。你把規矩寫死在 CLAUDE.md，它每次動手前都會讀一遍，等於幫你的專案裝上一套「不會越界的護欄」。正因如此，我常提醒：工具可以替你動手，但判斷標準永遠要握在你自己手裡。想深入了解這層思維，可以看 Claude Skills 完整指南 和官方的 Agent Skills 說明。

第四步：把截圖加原始碼一起餵進去，讓 Claude Code 起骨架

接著我才把截圖和 Stitch 的匯出原始碼一起丟給 Claude Code，並用一句明確的指令定調：「以這份設計為視覺依據，用我指定的框架重寫成符合 CLAUDE.md 規範的可上線程式碼。」注意我用的是「重寫」這個動作，刻意避開直接「套用」。因為 Stitch 的程式碼是原型等級，直接套只會把它的包袱一起帶進來；重寫才能讓 Claude Code 用你的技術棧、你的規範，重新長出一份乾淨的成品。

第五步：用 MCP 把成品接上你的 CMS 或資料來源

網站很少是純靜態就完事，尤其形象站常要接 WordPress、接表單、接分析工具。這時候我會用 Claude Code 搭配 MCP，把內容管理系統或第三方服務接上來，讓它能在你的真實環境裡操作，不必只停在本地端寫死字串。走 WordPress 路線的人，Claude Code 搭配 WordPress MCP 那篇有完整步驟；想把更多重複工作自動化的，則可以看 Claude Code Plugins 指南。

把設計意圖講清楚：餵給 Claude Code 的指令該怎麼寫

很多人以為工具強，就可以隨便下指令，這是另一個常見的誤會。你給 Claude Code 的指令越模糊，它就越只能用自己的預設判斷去補洞，而它的預設判斷不會自動對齊你的品牌、你的產業、你對速度的要求。我自己的原則是：每一次把 Stitch 的成果交出去，都附上三樣東西，缺一不可。

第一樣是剛剛說的截圖，給它視覺真相。第二樣是 Stitch 的匯出原始碼，給它結構參考。第三樣、也是最多人漏掉的，是一段明確的文字描述，把你這一頁「想解決什麼問題、給誰看、希望讀者看完做什麼」講清楚。這段描述就是你的搜尋意圖與轉換目標。你越能把這層意圖寫進指令，Claude Code 產出的標記、文案結構與 CTA 擺放位置，才會越貼近一個能排名又能轉換的頁面。

還有一個小技巧會大幅提升穩定度：在 CLAUDE.md 裡定義一套你的「設計語言」。這套語言包含主要色票、字體層級、間距規則、按鈕樣式與元件命名慣例。你等於是先幫 Claude Code 準備好一組詞彙表，讓它在重寫每一頁時都從同一套詞彙裡挑字，結果才會前後一致，不會首頁一套配色、關於頁又跳一套。這對品牌一致性與後續維護都是基本功。想把這套設計語言建立在 WordPress 上的人，品牌官網設計全攻略 有一整套從色彩到元件的落地方法可以參考。

談到色彩，有一個常見的陷阱順帶提醒。很多人在 Stitch 裡看到漂亮的漸層與高彩度配色就直接採用，卻沒有考慮到這些顏色在真實內容頁面上的可讀性，以及它們對品牌辨識度的長期影響。我會建議你在交給 Claude Code 之前，先回頭用品牌色的邏輯過濾一遍 Stitch 的產出，把主色、輔色、強調色定下來。色彩怎麼挑才會兼顧美感、心理暗示與無障礙對比，品牌色彩挑選指南 和 色彩心理學設計攻略 寫得很完整，值得在這一步對照著看。中文字體的選擇同理，中文字體設計指南 能幫你避開很多排版的雷。

行動優先不是口號，是這套工作流的第一條規則

走到這裡，我要把話題從「怎麼做」轉到「怎麼讓 Google 願意收錄並排名你做出來的東西」。因為做出一個漂亮的網站，跟做出一個 Google 看得上眼的網站，是兩件事。而其中最根本的一條，就是行動優先。

Google 從 2020 年 3 月在 Google Search Central 部落格宣布全面走向行動優先索引，並在 2023 年 10 月以〈Mobile-first is here〉宣告轉換完成。意思是 Google 主要使用行動版內容進行檢索與索引，不是另設一個「手機版排名加分」。再加上 Statista 的統計顯示，全球網頁流量長期有超過一半來自行動裝置，手機體驗本來就是產品基本功。

這對 Stitch 加 Claude Code 的工作流有兩個具體影響。第一，你在 Stitch 出圖時，就要先想手機版的層級，再回頭想桌面版，順序絕對不能顛倒。很多 AI 設計工具預設先畫桌面版，畫得漂漂亮亮，結果手機版整個擠成一團，這在行動優先的世界裡是本末倒置。第二，你在寫 CLAUDE.md 時，要把「行動優先」明定成一條硬規則，要求 Claude Code 產出的標記與樣式，必須先以小螢幕為基準再往上擴展。

這件事不難，但它不會自己發生。你得主動設定。響應式設計的完整觀念，我寫在 響應式網頁設計 RWD，搭配 網頁版面設計攻略 一起讀，你會更清楚為什麼「先小後大」是這套工作流不能省的順序。

速度是功能，不是事後補丁

第二個容易踩雷的點是速度。Google 在 2018 年 1 月把網頁速度列為行動搜尋的排名因素之一（見 Google Search Central 部落格的〈Using page speed in mobile search〉），之後也在 2020 年 5 月把 Core Web Vitals 納入頁面體驗考量（〈Evaluating page experience〉）。這是眾多訊號中的一小部分，相關性更高、內容更有幫助的頁面仍可能排名較好；速度優化的直接價值在於使用體驗，可對照 web.dev 的研究。

AI 生成或設計工具匯出的程式碼，可能包含內聯樣式、重複 CSS 或較多包裝層；實際情況會隨提示、版本與匯出格式而變。這在單頁 demo 裡不一定明顯，但網站開始共用元件與樣式後，就要檢查重複、未使用資源與維護成本。Stitch 匯出物應視為起點，是否符合正式專案標準仍要逐案驗證。

Claude Code 可以協助把畫面重寫成專案框架，也能在過程中做 refactoring：抽出重複樣式、整理標記並移除確認無用的程式碼。不過 Core Web Vitals 仍要以實際頁面測量，會受圖片、字體、第三方程式、主機與使用者裝置等因素影響，不能只靠一次重構判定。完整手法可參考網站速度優化指南。

具體來說，我會在這一關要求 Claude Code 做幾件固定的事：把所有裝飾用的 span 與 div 改成語意標籤、把重複出現的按鈕與卡片樣式收進共用的 CSS 類別、確認圖片都有壓縮並補上寬高與替代文字、把會擋住首次繪製的字型與腳本往後挪。這幾個動作單獨看都不花俏，但加起來對 Largest Contentful Paint 和 Cumulative Layout Shift 這兩個指標的影響非常直接。你不需要自己一行行改，把這份清單寫進 CLAUDE.md，Claude Code 每次重寫都會順手做完。

內容與經驗，是 AI 工具補不上的那一塊

工具再強，有一塊它永遠做不來，那就是「真人寫出來、有第一手經驗的內容」。這也是在 SEO 領域最常被強調的一句話，更是 Google 在 E-E-A-T 評估裡特別看重的「Experience」那一項。Stitch 能幫你把版面排好看，Claude Code 能幫你把程式碼寫乾淨，但沒有任何一個工具能幫你寫出「你這一行做了十年才會知道的那個洞見」。

所以當你用這套工作流把網站骨架搭起來之後，真正決定它能不能排名、能不能留下讀者的，是你放進去的內容。我自己的原則是：結構與樣式可以大量依賴 AI，但每一頁的開頭兩百字、每一個我提出的判斷、每一個我給的具體建議，都要是我自己想清楚才寫下來的。這不是固執，這是護城河。

還有一段 SEO 實作要人工盯：每頁標題與描述、麵包屑、適用的結構化資料、網址結構，以及整站的 sitemap 與 robots.txt。Claude Code 能依規格寫入標記，但不能替你決定每頁的搜尋意圖；robots.txt 只管理爬取，不是存取控制，也不保證網址不被索引。這些決策應由懂品牌與內容的人確認，再寫回 CLAUDE.md。網址與主機可參考網域申請購買全攻略；網站架構則可搭配網站架構圖 AI 工具規劃。

AI Overviews 與 AI Mode 沒有特殊 Schema 或固定字數門檻，Google 在 Search Central 的「AI features and your website」說明中仍建議遵循一般搜尋基礎、確保頁面可索引並提供有幫助的內容。延伸可讀AI 搜尋時代的 SEO 全攻略與Google AI Overviews 完全指南。

做完不是結束：迭代、審查與驗收的迴圈

很多教學停在「程式碼生成完就收工」這一步，但真實世界裡，第一版產出幾乎不會是終點。我把這套工作流的收尾階段看得很重，因為一個網站會不會出問題，往往就決定在你有沒有認真跑這幾圈迭代。

我的習慣是每完成一個頁面，就立刻做三件事。第一件是肉眼審查，把頁面在手機和桌面各開一遍，看視覺層級、按鈕可點擊範圍、文字斷行有沒有走樣。第二件是看 Claude Code 改動的 diff，確認它沒有為了還原畫面而塞進一堆無意義的包裝層或行內樣式，這一步是你守住程式碼品質的關鍵。第三件是跑基本的速度與可及性檢查，確認這一頁沒有明顯拖慢載入、也沒有漏掉圖片的替代文字與語意標籤。

這三件事構成一個小迴圈：產出、審查、修正、再產出。你不需要每一頁都做到完美才往下走，但每一頁至少要過完這個迴圈一次。把這個紀律建立起來，你的網站才會在十幾頁、幾十頁的規模下還保持一致的品質，而不會做到後面發現前面全是要回頭收拾的爛攤子。這層迭代觀念，跟做 SEO 是一樣的道理，最佳化從來都不是一次做完就結束的動作，它本身就是一個持續校正的過程。

三種工作流的取捨：單用 Stitch、單用 Claude Code、兩者串接

我把三種常見選擇攤開來比，你自己評估哪一種最適合你的情境。沒有絕對的最佳，只有最適合。

工作流	最適合誰	最大優勢	最大風險
單用 Stitch	只需要快速視覺提案、做 demo 給客戶看的人	出圖最快，視覺品質高，門檻最低	產出是原型等級，直接上線會卡在速度與 SEO
單用 Claude Code	有設計稿、只需要工程實作的開發者	工程執行力強，能維護長期專案	設計品味要自己扛，非設計師門檻偏高
Stitch 串接 Claude Code	非設計背景、想從零做到可上線網站的行銷人與創業者	設計與工程都用最強的工具，各司其職	流程多一步轉換，要先學會把規矩寫進 CLAUDE.md

從這張表看得出來，第三種的代價是「你要學會當那個定規矩的人」。但這個代價，換來的是你不再被任何一個工具的弱點綁住。對想把網站當長期資產累積的人，這筆投資是值得的。如果你想看其他「不寫程式也能架站」的選項來對照，AI 網站建立工具實測 介紹了幾條不同的路線。

我再補一個判斷上的提醒。很多人選工作流時，只看「哪個工具現在最紅」，這其實是錯的切入點。你該問的是：我這個專案最弱的環節在哪裡，哪個工具能補上它。如果你是工程底子強、設計薄弱，把力氣花在 Stitch 上回報最高；如果你設計 sense 不錯、但不想碰程式碼，Claude Code 才是你該投資時間學會的工具。工具是手段，補你的短板才是目的。把這個先後順序想清楚，你才不會陷在「到底要學哪個」的焦慮裡，而是清楚地知道每一個工具在你手上的位置。對想先把網頁設計整體觀念補起來的人，網頁設計完整指南 和 UIUX 設計差異解析 是很好的起點。

什麼樣的網站適合這套工作流，什麼樣的要再想想

工具組合再漂亮，也有它吃得下與吃不下的範圍。我不想給你一種「這套流程萬能」的錯覺，那跟保證排名第一一樣不誠實。底下是我對適用範圍的判斷，給你做決策參考。

特別適合的，是頁面數量在個位數到十幾頁之間、結構相對單純的網站。典型代表包括：創業初期的品牌形象站、單一產品的落地頁、服務介紹頁、個人作品集、活動報名頁、一頁式的銷售頁。這類網站的設計決策集中、內容版式重複性高，Stitch 出圖加 Claude Code 重寫的效率優勢會最明顯。落地頁的轉換邏輯我整理在 Landing Page 轉換率優化全攻略，一頁式的設計手法則可以看 一頁式網頁設計攻略，兩篇都能幫你把 Stitch 產出的版面對接到正確的轉換目標。

需要謹慎評估的，是牽涉複雜交易邏輯或大量動態資料的網站。例如有完整結帳流程與庫存系統的 WooCommerce 大型商城、會員訂閱與權限分級的社群平台、即時報價與預約排程交錯的服務系統。這類網站的瓶頸往往落在後端的狀態管理與資料流，跟前端設計的關係不大，Stitch 幫不上太多忙，Claude Code 雖然能寫，但你得有能力審查它產出的邏輯是否正確、是否安全。對這類需求，我會建議把 AI 工具放在「快速起骨架」這一關，真正的核心邏輯還是要有懂工程的人把關。

講白了，判斷標準只有一條：這個網站的複雜度，主要落在「看得見的畫面」還是「看不見的邏輯」。落在前者的，這套工作流如魚得水；落在後者的，它只能幫你加速前期，後期仍要回歸紮實的工程。誠實面對你的專案落在哪一邊，才不會對工具產生錯誤的期待。

我會主動避開的五個地雷

這套工作流有幾個常見的坑，直接幫你列出來。這些不是理論上的風險，而是實際在網站健檢時反覆會出現的問題。每一條都附上判斷方式，讓你下次遇到類似狀況時，知道該從哪裡檢查、怎麼修正。

1. 把 Stitch 的匯出程式碼當成品上線。它的原始碼是設計原型，不是生產環境等級。直接套用，速度、語意化標記、結構化資料幾乎都會出問題。永遠先讓 Claude Code 重寫一輪。
2. 沒有寫 CLAUDE.md 就開始做。沒有規矩，AI 就會用它自己的預設值做事，而它的預設值通常不包含你的 SEO 底線。這份檔案是你把判斷標準寫進流程的唯一入口。
3. 先做桌面版再做手機版。在行動優先的世界裡這是本末倒置。從 Stitch 出圖到 Claude Code 實作，全程都要以手機為基準再往上擴展。
4. 放任 AI 生成的樣式膨脹。內聯樣式、重複 CSS、多餘的包裝層，這些是 AI 程式碼的通病。一定要在流程裡安排一輪 refactoring，否則速度會被拖垮。
5. 未經審查就量產內容。Google 看的是內容是否有幫助，不會因為使用 AI 就自動降權；真正的風險是大量產生缺少原創價值、只為操弄排名的內容。第一手經驗不能靠標籤假裝，引用、案例與判斷都要能驗證。對 AI 內容判讀有疑問，可參考AI 內容檢測工具。

開始動手：六步行動方案

講了這麼多，我給你一組可以直接照著做的行動清單。不用一次做完，但照這個順序走，你會少踩很多別人踩過的坑。這份清單的設計邏輯是「先小後大、先骨架後內容」，每一階段都確認穩定了再往下走，寧可慢一點扎實，也不要圖快而留下一堆回頭才發現的債。

1. 挑一個小範圍先試。不要第一個專案就挑整個官網。先拿一個落地頁或一個服務介紹頁來跑完整流程，把 Stitch 到 Claude Code 的手感建立起來。
2. 在 Stitch 裡先想手機版。用頁面等級的單位一次做一頁，prompt 裡明確指定配色、字體層級與主視覺位置，產出後截圖存檔。
3. 把 CLAUDE.md 先寫好。在餵任何東西給 Claude Code 之前，先寫清楚框架、行動優先、語意化 HTML、與速度底線這幾條規矩。
4. 用「重寫」的方式，避免直接「套用」。把截圖和 Stitch 原始碼一起交給 Claude Code，要求它以你的框架和 CLAUDE.md 為準重新實作。
5. 做一輪 refactoring 與速度檢查。把重複樣式抽乾淨，再拿速度優化指南當清單跑一遍 Core Web Vitals。
6. 把內容的開頭兩百字自己寫。每一頁最重要的判斷與經驗，由你親自下筆。這是 AI 工具取代不了、也是你最堅實的護城河。

AI 把「做出一個網站」的門檻壓到了前所未有的低，但它從來沒有、也不會把「做出一個值得被 Google 排名、值得被讀者信任的網站」的門檻壓低。後面那一半，還是得靠你把品味、規矩和真人經驗放進流程裡。把 Stitch 和 Claude Code 當成你手上的兩把好工具，而不是兩個會替你做決定的代理人，這套工作流才會真的幫到你。當你哪天回頭看自己用這套方法累積出來的網站，你會發現真正值錢的不是那些自動產生的程式碼，而是你在每一個關卡留下的判斷。

如果你讀完想更進一步，把整套 AI 架站與行銷的思維串起來，Vibe Coding 入門 和 Vibe Coding 網頁設計實戰會給你更全景的視野。我們 Whoops SEO 也有提供從網站健檢到內容策略的顧問服務，你把它當成一個選項就好，不是義務。先把上面那六步走一遍，你自己就會感受到這套流程值不值得繼續深耕。