> ## Content Index > Fetch the complete content index at: https://growthhackers.tw/llms.txt > Use this file to discover other available public pages before exploring further. # Claude Design 怎麼用？AI 做網站六步驟：從 design.md 到 AI 規格書，一半時間該花在動工前 - URL: https://growthhackers.tw/blog/claude-design-ai-native-workflow/ - Published: 2026-08-08T13:00:00.000Z - Updated: 2026-08-08T13:00:00.000Z - Description: 影片標題寫 25 分鐘，作者自己說花了幾個小時、還有 bug。真正值錢的是那句「至少一半時間要花在規劃上」。本文拆解 Claude Design × Claude Code 的六步驟：design.md、AI 規格書、元件庫、資料 schema。 - Author: Lewis wang - Tags: AI 工具, Claude, 產品開發, AI 應用, 工作流程 Peter Yang 在 7 月 29 日發了一支影片，標題叫〈25 分鐘從構想做出一個 App〉。 你點進去，會看到他用 AI 做網站的完整六步驟：定義問題、寫一份 `design.md`、用 Claude Design 出原型、寫規格書，最後才交給 Claude Code 建置，從零做出一個叫 Tastemaker 的品味策展網站，收藏你喜歡的電影、影集、遊戲。畫面很漂亮，流程很順，看完會有一種「我今晚也來做一個」的衝動。 但整支影片最值錢的一句話，在第 19 分鐘，而且很多人會滑過去： > 「用 AI 開發的時候，你至少要把一半的時間花在前期規劃上。建置那段已經變簡單了。」 然後他在片尾補了一句更誠實的：這個網站「大概花了幾個小時，而且我確定裡面還有 bug」。 切入重點，這支影片真正在講的不是 AI 有多快。 **它在講一件很反直覺的事：執行變便宜了，但「沒想清楚」的代價反而變貴了。** --- ## 先把「25 分鐘」這件事講清楚 我很討厭那種「你也可以 25 分鐘做出一個 App」的說法，所以先把前提攤開來講。 **第一，25 分鐘是影片長度，不是開發時間。** 作者自己說實際花了幾個小時，而且還有 bug 沒修。 **第二，這個人不是素人。** Peter Yang 在 Roblox、Reddit、Amazon（Twitch）、Meta 帶產品和團隊超過十年，他的電子報 [Behind the Craft](https://creatoreconomy.so/?ref=growthhackers.tw) 有 14 萬以上的訂閱者。影片裡他掃一眼就知道評論不該擠成格線、Claude 愛寫的那種文青金句該刪掉，那個判斷力是十年練出來的，不是工具給的。 **第三，題目很簡單。** 一個個人用的收藏頁，沒有金流、沒有多人協作、沒有法遵。 **第四，工具有門檻。** Claude Design 是 Anthropic Labs 在 2026 年 4 月 17 日推出的產品，截至 2026 年 7 月底，官方產品頁上仍標示為 beta，只開放給 Claude Pro、Max、Team、Enterprise 訂閱者（Enterprise 預設是關的，要管理員去組織設定裡開）。免費帳號進不去。而且它跟 chat、Claude Code 共用同一份用量額度，你設計畫得很爽，回頭可能發現額度燒完了。（來源：[Anthropic Labs 公告](https://www.anthropic.com/news/claude-design-anthropic-labs?ref=growthhackers.tw)、[Claude Design 產品頁](https://claude.com/product/design?ref=growthhackers.tw)） **第五，這是一個人的私房流程，不是業界標準。** 作者全程講的是「my AI native design process」。 把這五件事講完，這支影片反而更有價值了。因為當你不再期待魔法，你才會看見他真正在示範的東西：一套把需求想清楚的紀律。 --- ## 為什麼 vibe coding 之後，「規劃」突然變值錢了 我在雨傘產業待了七年。那時候最痛的事情不是打樣做不出來，是打樣做出來「不是我要的」。 早期我很菜，跟工廠溝通就一句「你就照那個感覺做，要有質感一點」。師傅照他的理解做，回來的樣品骨架太重、布面反光、把手的曲線很俗。改？可以，但傘骨的模具已經開下去了，改一個規格幾十萬跑不掉。 那一次我學到的事情是：**真正貴的從來不是工錢，是「等你發現做錯的時候，已經動不了的那個部分」。** 換到 AI 開發上，邏輯一模一樣。這就像裝潢：以前工很貴，你會逼自己先把水電圖木作圖畫清楚；現在 AI 是那種手腳超快、不收加班費、半夜叫他也來的師傅，工變便宜了，你就敢說「先打牆再說」。 但「水電都走完了才發現廚房要移位」的代價，從來沒有變便宜過。 Peter Yang 在影片裡講得很直白：一旦 AI 開始建資料庫和後端架構，要再改核心邏輯或版面，就會變得非常麻煩而且昂貴。他還特別提到，規格書裡一定要先寫資料 schema，因為「資料庫上線之後非常難改」。 而在那之前，你要改的只是兩個 HTML 檔案。 ![修改成本曲線：資料庫上線前改動只要編輯兩個 HTML 檔，上線後改動等於重建](https://growthhackers.tw/content/images/2026/07/inline-cost-curve-v1.png) **以前你的瓶頸是「做不出來」，現在你的瓶頸是「說不清楚」。** 他自己下的結論最狠：這套流程某種程度上就是瀑布式開發（waterfall），只是被 AI 快轉了。 --- ## Claude Design 怎麼用：AI 做網站的六個步驟 以下是他的完整流程。我把每一步後面都接上台灣的實際場景，你不寫 code 也看得懂。 ![AI 做網站的六步驟流程：定義問題、design.md、原型、規格書、所有畫面、建置，前四步佔一半以上時間](https://growthhackers.tw/content/images/2026/07/inline-six-step-flow-v1.png) ### 步驟一：先定義使用者問題，不急著列功能 他的起手式不是「幫我做一個網站」，而是丟給 AI 這樣一段話： > 我是電影、影集、遊戲的重度愛好者，我想要一個頁面能同時展示這三種喜好。可以幫我定義顧客問題、這是為誰做的、以及網路上有沒有證據顯示這個問題存在嗎？先從顧客問題開始，這個主題寫兩小段就好…… 注意他要的是「定義問題」和「找證據」，不是「給我功能列表」。 他也很誠實地說，如果這是要拿來賺錢的產品，他會花多很多時間去研究這個東西到底能不能賺錢或養得起用戶。他還補了一句我覺得很重要的話：現在每個人都能寫程式了，**靠軟體賺錢比以前更難了**。 **台灣場景翻譯**：這一步就是你在提案前該做的事。行銷部門跟 IT 說「我要一個會員專區」，IT 問「為什麼」，你答不出來，這個專案八成會做壞。想更完整拆解怎麼把一個想法逼成可驗證的問題，可以看我之前寫的[問題規格書怎麼寫](https://growthhackers.tw/blog/30-60-90-startup-validation-framework/)。 ### 步驟二：design.md 是什麼？先把視覺方向寫成檔案 這一步是整套流程裡最容易被低估的。 他先講了一個大家都有感的現象：AI 預設產出的設計，不是「一坨很通用的紫色」，就是那種一眼看得出來的 Claude 味。 所以他去找靈感。他推薦 [Mobbin](https://mobbin.com/?ref=growthhackers.tw)（收集各種 App 的 UI 截圖）和 [Dribbble](https://dribbble.com/?ref=growthhackers.tw)（設計師作品集），而他這次的參考對象是一個叫 Monogram 的 App，理由是它「看起來非常乾淨，而且用顏色把注意力帶到內容上，不是帶到介面上」。 然後他把幾張 Monogram 的截圖貼進 **Claude Code**（注意，這一步還沒進 Claude Design），配上這段 prompt： > 這是 Monogram 的幾張截圖。可以幫 Tastemaker 依這個視覺方向做一份 design.md 嗎？這個產品是幫人把喜歡的電影、影集、遊戲放在同一頁分享。介面保持安靜，讓封面圖去帶顏色。 產出的 `design.md` 就是一份 markdown 檔，裡面寫著這個產品的設計原則，加上色彩、字體、間距的具體建議。 他也提醒了一句我覺得該加粗的話：**參考靈感跟直接抄襲是兩回事**。他做的是完全不同品類的產品，所以他覺得借一點沒問題。 **台灣場景翻譯**：你有沒有收過這種需求單？「首頁要質感一點」「弄得跟那個日系品牌一樣」。 這句話交給設計師，會來回改五版。交給 AI，你會拿回一坨紫色。 `design.md` 就是把「質感一點」翻譯成機器和人都能執行的東西：主色碼是什麼、標題用幾級字、卡片間距多少、什麼情況下不能用陰影。寫這份檔案的時間不長，省下的是後面一輪又一輪的「感覺還是怪怪的」。 ### 步驟三：在 Claude Design 裡探索原型，先做兩個核心畫面 到這裡才開始畫圖，而且是先畫「兩個最核心的畫面」，不是全部。 先講一件他很坦白、但轉述時常被略過的事：**他選 Claude Design 的理由是「我本來就有 Claude 訂閱」**，不是評比過一輪之後的結論。他自己還推薦了另外兩個 AI 原生設計工具 Paper 和 pen.dev，並且明講「Figma 現在自己也有很多很好的 AI 功能」。所以下面的流程你用哪個工具跑都成立，重點在順序，不在品牌。 他附上 design.md，要求 AI 產出兩個畫面（公開的品味頁、未登入的著陸頁），**而且每個都要兩種版本**，攤在同一頁方便比較。他的原話是：既然 AI 可以一次做多個版本，那就讓它做，我們再挑。 他也提到，Claude Design 有個他很喜歡的設計：它會先反問你一串釐清問題（範例要放誰的品味？兩個版本要探索什麼差異？要不要明暗兩種？文案要多真實？）。他說他不懂為什麼別的 AI 設計工具不抄這招。 拿到版本之後，他用兩種方式改：**直接在畫布上編輯**（刪掉他討厭的那種「文青金句」、刪掉還沒做的追蹤按鈕），以及**用對話給回饋**（收藏改成一排六個、加上 Netflix 那種左右箭頭、評論改成整列全寬）。 他很誠實地說：「講實話，這中間又跑了好幾輪才到這個狀態。」 然後是我認為全片第二值錢的一句話： > 「垃圾和真正好的東西，差別就在有沒有注意細節。Claude 不會一次就生出完美的設計。」 **台灣場景翻譯**：這一步的重點是「發散再收斂」。他說他不是設計師，但他知道好的設計師會先探索多個方向再收斂。台灣很多團隊的問題剛好相反：第一版就定案，然後花三個月修那一版。 ### 步驟四：AI 規格書怎麼寫？把 PRD、設計、技術合成一份 HTML 這是整套流程的核心，也是跟傳統流程差最多的地方。這種做法現在有個正式名字，叫 **spec-driven development（規格驅動開發）**：先把規格寫成單一事實來源，再讓 AI 照著做。 **傳統流程**：PM 先寫規格 → 交給設計師畫 Figma → 兩份一起交給工程師寫技術文件。三份文件，兩次交接。 **他的流程**：先把關鍵畫面做出來，再回頭寫規格。理由是「先看到幾個關鍵視覺，比較容易搞懂這產品到底是什麼，然後才有辦法把預設狀態和邊界情況一次想清楚」。 而且他把 PRD、設計、技術三份東西，塞進同一個 HTML 檔案，做成三個分頁： - **PRD 分頁**：使用者問題、產品的高層次目標、需求清單（他特別要求 AI 寫得精簡好掃描，並依產品的不同區塊分開列） - **Design 分頁**：等於 design.md 的網頁版，加上樣式指南，**以及一個元件庫（component library）** - **Tech 分頁**：技術選型，加上資料 schema ![三合一 AI 規格書結構：PRD、Design（含元件庫）、Tech（含資料 schema）三個分頁](https://growthhackers.tw/content/images/2026/07/inline-three-tab-spec-v1.png) **元件庫這件事要單獨拉出來講。** 他說他以前做 App 沒有先定元件庫，結果「AI 開始亂造各種奇怪的元件，整個 App 看起來就像一團亂」。而且元件庫要隨著新畫面持續更新。 他強調規格書要做成「人類讀得下去」的樣子，因為**你一定要真的把它讀完並給回饋**，否則後面全是白燒 token。 順帶一提，他用的是自己做的 `/spec` skill，那是他 [behindthecraft.com](https://www.behindthecraft.com/?ref=growthhackers.tw) 付費訂閱的內容。但他也大方講了：你完全可以自己叫 AI 照這三個分頁的架構生一份，不用付錢。 如果你想知道怎麼把這種重複的檢查流程固化成 AI 的技能包，我寫過[把品管檢查變成 Claude Code skill](https://growthhackers.tw/blog/claude-code-skill-verification-loop/) 這篇。 ### 步驟五：把空狀態、邊界情況這些畫面補完 規格寫完，回到 Claude Design，這次叫它「把需求裡的所有核心畫面都做出來」。 重點在他要求的那幾種畫面：**預設狀態、空狀態、邊界情況、完整的 onboarding 流程**。 他舉例：新用戶剛建好品味頁，那頁是空的，這時候必須有一個清楚的行動呼籲叫他去加東西。這種畫面在需求單上永遠不會有人寫，但在真實產品裡天天發生。 **台灣場景翻譯**：這就是台灣電商上線後最常見的災難來源。首頁很美，然後：搜尋沒結果長什麼樣？購物車空的時候？優惠券過期？會員資料還沒填？ 沒人畫，工程師就自己決定，然後你上線後才在會議上吵。 ### 步驟六：Claude Code 怎麼用？最後才動工，先讓 AI 反問模糊點 到這裡他手上有兩個檔案：`spec.html` 是規格書（產品、設計、技術三個分頁），`design.html` 是從 Claude Design 匯出的實際畫面。一份講「為什麼和要什麼」，一份講「長什麼樣」。 他丟給 Claude Code 的第一句話不是「開始做」，而是： > 看過規格和設計後，開始建置之前，告訴我你有沒有任何問題，或任何我該先釐清的模糊地帶。 他說：**永遠假設還有你沒想到的模糊地帶**，讓 AI 在寫第一行 code 之前把它們問出來。 即使前面做了這麼多，他還是強調建置不是一發入魂。他讓 AI 跑起 localhost，然後貼一堆截圖進去給回饋：收藏的愛心要 hover 才出現、個人頁跟設計對不上、評論區跑去哪了。來回非常多次。 最後他串了 [Supabase](https://supabase.com/?ref=growthhackers.tw) 當資料庫和身分驗證，作品上線在 [mytastemaker.vercel.app](https://mytastemaker.vercel.app/?ref=growthhackers.tw)。 還有一個很多人會忘的收尾動作：**當 AI 開始直接改 code 的時候，要求它同步更新規格和設計檔**，不然你的文件跟實作三天就對不上了。 關於怎麼設計這種「來回驗收」的節奏，我之前拆解過 Anthropic 工程師的做法：[用 AI 的高手不寫更長的 prompt，他們設計驗收迴圈](https://growthhackers.tw/blog/ai-agent-verification-workflow/)。 --- ## 不寫程式也能用的 AI 規格書工作法 如果你問我，這支影片對台灣多數讀者最大的價值，不是「學會用 Claude Design」。 而是這個判斷：**AI 時代真正稀缺的能力，不是會下指令，是能把「要做什麼、長什麼樣、什麼叫做好」寫清楚。** 我自己有很深的體會。我用 AI 幫這個部落格做過幾個小工具，第一次我就丟一句「幫我做一個文章資料庫的同步腳本」，它做出來了，能跑，但欄位設計完全不是我要的，我後面所有的分析腳本都得跟著它的爛結構走。第二次我學乖了，先花 40 分鐘把「我要查什麼、輸出長怎樣、失敗的時候要怎樣」寫成一頁規格，才叫它動手。 第二次前面花的時間比較長，但總時間反而更短。 這件事跟你會不會寫 code 完全無關。**它就是「把模糊的期待翻譯成可驗收的條件」這個能力。** 行銷人用它寫 campaign brief，老闆用它寫需求單，接案的用它擋掉無限次修改。台灣接案圈那個經典的死循環，客戶說「再修一下」，你說「這已經第七版了」，本質上就是雙方從來沒有把「什麼叫做好」寫下來過。 所以，你今天可以做的事： ► **先寫 design.md，再叫 AI 動手。** 就算你只是要做一頁活動頁，先蒐集 3 到 5 張你喜歡的參考截圖，叫 AI 幫你整理成一份包含色碼、字級、間距原則的檔案。 ► **把 PRD、設計、技術寫進同一份文件。** 不要分四個檔案。人會讀的東西才會被讀，被讀的東西才會被修正。 ► **一定要有元件庫。** 不管是 AI 做還是人做，先定義「按鈕長怎樣、卡片長怎樣、標題有幾級」。沒有這個，你會得到一個每頁風格都不一樣的網站。 ► **邊界狀態一定要先畫。** 空狀態、錯誤狀態、載入中、沒有結果。這四個畫面決定了你的產品是「有做完」還是「看起來有做完」。 ► **叫 AI 在動手前先問你問題。** 一句「開始之前，告訴我有哪些模糊的地方」，可以省掉後面一大段的返工。 ► **資料結構要最早定、最晚改。** 這是唯一一個「上線後幾乎改不動」的部分，值得你花最多時間。 --- ## 常見問題 **Q：Claude Design 是什麼？要付費嗎？免費帳號可以用嗎？** A：Claude Design 是 Anthropic Labs 在 2026 年 4 月 17 日推出的視覺協作工具，可以做設計稿、原型、簡報。截至 2026 年 7 月底，官方產品頁仍標示為 beta。它開放給 Claude Pro、Max、Team、Enterprise 訂閱者，包含在訂閱裡不另外收費，但**免費帳號無法使用**。Enterprise 方案預設是關閉的，需要管理員在組織設定中開啟。它與 chat、Claude Cowork、Claude Code 共用同一份用量額度，用完可以選擇開啟 extra usage 付費續用。入口可從 [Claude Design 產品頁](https://claude.com/product/design?ref=growthhackers.tw) 進入。 **Q：Claude Design 怎麼用？** A：正確用法不是叫它一次做完整個網站，而是分四個動作：① 先在 Claude Code（或任何 AI 對話工具）產出一份 `design.md` 當視覺系統，再附檔上傳到 Claude Design；② 請它產出「兩個核心畫面」，並且每個畫面各做兩種版本方便比較（它會先反問你一串釐清問題，值得認真回答）；③ 用「直接在畫布上編輯」加「對話給回饋」兩種方式修到滿意；④ 依規格書補齊所有核心畫面與空狀態，再用 share 匯出成 zip 或 HTML，交給 Claude Code 建置。重點是先收斂兩個關鍵畫面，不要一開始就要求它畫全部。 **Q：design.md 是什麼？沒有設計背景怎麼生一份？** A：`design.md` 是一份用 markdown 寫的設計原則檔，內容包含產品的設計原則，以及色彩、字體、間距的具體規範。它的用途是讓 AI 每次產出的視覺風格一致，不會每個畫面都長不一樣。沒有設計背景的做法是：先去 Mobbin、Dribbble 或你欣賞的網站蒐集 3 到 5 張截圖，貼給 AI，請它「依這個視覺方向，為我的產品產出一份 design.md」，並說明產品在做什麼、你想要的調性。 **Q：AI 規格書該寫哪些內容？** A：Peter Yang 的做法是把三件事寫進同一份 HTML 檔的三個分頁：① PRD（使用者問題、產品目標、依功能區塊拆分的需求清單）② 設計（設計原則、樣式指南、**元件庫**）③ 技術（技術選型、**資料 schema**）。其中元件庫和資料 schema 最容易被略過，也最容易在後期害你大改。 **Q：真的能 25 分鐘做出一個 App 嗎？** A：不能，至少不是那個意思。25 分鐘是影片長度。Peter Yang 在他 2026 年 7 月 29 日那支教學影片的片尾明說，實際「大概花了幾個小時，而且我確定還有 bug」。而且他是在 Roblox、Reddit、Amazon、Meta 帶過十年產品的人，題目也相對單純（沒有金流、沒有多人協作）。合理的期待是：**規劃佔一半以上時間，建置階段仍需大量來回修正。** **Q：vibe coding 為什麼做出來的東西都很像、而且越改越亂？** A：vibe coding 指的是不先寫規格、憑感覺丟 prompt、邊做邊改的 AI 開發方式。它會出問題通常有兩個原因。第一，沒有給 AI 視覺方向，它就會回到預設風格，也就是 Peter Yang 說的「通用紫色」或一眼認得出的 Claude 味，解法是先寫一份 `design.md`。第二，沒有先定義元件庫，AI 會在每個新畫面自己造新元件，整個產品就會越長越亂。Peter Yang 的原話是「AI 開始亂造各種奇怪的元件，App 看起來就像一團亂」。 **Q：一定要用 Claude Design 嗎？有沒有別的選擇？** A：不一定。Peter Yang 自己在影片中說，他用 Claude Design 的理由是「我本來就有 Claude 訂閱」，並不是評比後的結論。他同時推薦了另外兩個 AI 原生設計工具 Paper 與 pen.dev，也提到 Figma 目前已內建不少 AI 功能。這套六步驟流程的價值在**順序**（先定義問題、先寫 design.md、先出規格，最後才建置），不在特定工具，換成任何能產出設計稿與規格的工具都成立。 --- ## 最後 寫程式變便宜這件事，我在[程式碼變免費之後，競爭力換成「誰定義得清楚」](https://growthhackers.tw/blog/code-is-free-become-the-driver/)那篇裡談過方向。這支影片等於是把那個方向做成了一份可以照著跑的流程。 有意思的地方在於，這套「AI 原生」的流程，骨子裡是被嫌棄了二十年的瀑布式開發。先想清楚、先畫圖、先寫規格、再動工。作者自己都承認了。 它之所以回來，是因為條件變了。以前規劃很貴、執行更貴，所以大家選擇小步快跑，邊做邊修。現在執行接近免費了，那個天秤就翻過來了：**規劃反而成為唯一還需要人類真正投入的環節。** 你的競爭力不會來自你 prompt 下得多漂亮。 會來自你能不能把「我要什麼」講到連機器都不會誤會。 --- **資料來源**：Peter Yang，〈Full Tutorial: From Idea to App with Claude Design and Claude Code in 25 Minutes〉，2026 年 7 月 29 日發布。[YouTube 原片](https://www.youtube.com/watch?v=G9o8eoHzpxc&ref=growthhackers.tw)。Claude Design 產品資訊來自 [Anthropic Labs 公告](https://www.anthropic.com/news/claude-design-anthropic-labs?ref=growthhackers.tw) 與 [Claude Design 產品頁](https://claude.com/product/design?ref=growthhackers.tw)。作者背景資料來自 [creatoreconomy.so](https://creatoreconomy.so/?ref=growthhackers.tw)。 **協作聲明與免責** 這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 `[來源名稱](URL)` 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。 內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。