Claude Design 實戰篇 —— 5 個能直接抄的提示詞，外加一套別想偷懶的地基

前兩篇講完 Claude Design 點樣行、提示詞要點寫先唔會出 AI slop 之後，後台有一大堆人留言話："唔好再講原理喇，直接畀幾個可以 copy and paste 嘅提示詞啦。"

行，今日呢篇就硬核少少 —— 將我自己反覆試過嘅五個中文場景提示詞原汁原味貼出嚟，每個後面會跟一段我踩過嘅坑。但有一句說話要講咗先：地基打唔好，幾靚嘅提示詞都係虛浮嘅。所以前面會先廢話兩句「地基」嘅嘢。等唔切嘅同學可以先去下半段抄走啲提示詞，轉頭再返嚟補返，都得。

點解一定要先講地基

我在三間公司主導過設計系統（Design System），其實同我之前喺雲端文件、喺安全審計平台搭統一組件庫嘅路數差唔多。每次都見過同一種死法：頭一個月所有人嘅熱情都喺度，品牌規範、組件庫、Figma 變量（Variables）一應俱全；第三個月開始就散晒；半年後文檔冇人更新，組件庫有一半係殭屍變體，團隊又退返去各畫各嘅狀態。

設計系統嘅敵人從來唔係工具問題，係時間問題。Claude Design 把「做」呢一段壓扁咗，但「建立 + 維護」呢件事嘅總重量係冇變到。工具係新嘅，規律係舊嘅 —— 我呢兩星期喺幾個細團隊試吓行，最差嘅姿勢已經睇到苗頭：有個設計師下晝啱啱開通帳號，即刻整咗個 Hero 區出嚟畀老闆睇，底子一點都冇打就開始堆生成。按過去三輪做設計系統嘅經驗推斷，呢種玩法用唔得幾耐就會走樣 —— 今日 A 整張圖，聽日 B 整張圖，過兩星期擺埋一齊，團隊入面每個人用 Claude Design 做出來嘅嘢都唔係同一個品牌。呢啲嘢你同我講叫「設計系統」，我係唔信嘅。

所以下面呢套打底嘅工夫，聽落可能會有啲笨，但順序千萬唔好亂。

摸清你手頭上有啲咩

第一件事唔係開工，係盤點。Logo 各種格式齊唔齊？字體文件呢？色板（Color Palette）有冇 Hex code？間距（Spacing）有冇規範？語調（Tone of Voice）文檔有冇？寫低你缺啲咩。「缺」本身都係資訊。呢一步同我哋做架構評審（Architecture Review）之前，先將現有嘅微服務（Microservices）、數據庫、上下游依賴盤點清楚係同一個意思 —— 唔盤點清楚，後面每一步都係靠估。

跟住落嚟揀 Source of Truth。如果你團隊已經有生產代碼庫（Production Codebase）連埋組件庫，優先揀代碼。其次先係文檔化咗嘅 Figma 文件，再其次先係品牌手冊 PDF。呢個順序係有講究嘅：Claude Design 從代碼入面提取出嚟嘅嘢最接近「可複用」，從靜態文件入面提煉嘅成日會缺狀態（States）、缺 Hover、缺 Disabled，轉頭你仲要手動補返一次。

最後，將 Onboarding 嘅資產打一個乾淨嘅包：代碼倉庫連結、Figma 導出、品牌手冊、兩三張可以代表你產品視覺嘅真實生產截圖。唔好將成個 Lark（飛書）雲端硬碟、成個企業微信共享資料夾一股腦兒掉上去，要揀過。Claude 同人一樣，你畀佢嘅資訊越亂，佢畀你嘅輸出就越矇。

將品牌「教」畀 Claude

教嘅順序都唔好亂：代碼優先 → 品牌文檔 → 參考截圖。代碼打頭陣，等 Claude 讀到你最真實嘅組件係咩樣；品牌文檔其次，疊加 Token 同語調規則；截圖最後壓陣 —— 截圖係用嚟驗證系統嘅，唔係用嚟定義系統嘅。呢條規則反過嚟用就會翻車。我喺一個金融客嗰度見過同事直接攞截圖當輸入，結果生成出嚟嘅色板比真實代碼入面嘅色板暗咗兩個色階，冇人即場發現，上線半年先畀產品總監指返出嚟。

教完之後，生成任何界面之前先驗證。叫 Claude 將佢讀到嘅色板、字體比例、間距、組件名都列晒出嚟畀你睇一次，即場糾錯。錯嘅原語（Primitives）會順住每一個後續項目流落去 —— 呢個同微服務入面上游服務嘅契約（Contract）錯咗一個道理，下游全線跟住錯，越早 Fix 越慳事。

仲有一條好容易漏：將語調規則明確咁寫入去。設計系統失敗最常見嘅姿勢就係只係記錄咗視覺，唔記得咗記錄「品牌點樣講嘢」。句長、正式程度、使唔使縮寫、帶唔帶幽默感、邊啲詞語絕對唔可以出現 —— 呢啲你唔寫，Claude 默認就會畀一段「賦能、重塑、未來已來」嗰種大陸官腔味你，到時你喊都無謂。

唔好等佢變殭屍 —— 治理呢一步真係唔好慳

如果你品牌視覺同產品視覺本來就唔一樣（大部分 B2B 公司都係咁，營銷網站走酷炫路線，產品後台走克制路線），就老老實實維護兩套 Design System。Claude Design 原生就支援多套，唔好夾硬將一套塞入所有場景。

開放畀團隊之前，行一輪測試衝刺（Test Sprint）。生成你最常做嘅三件套：一個 Landing Page、一個 Pitch Deck 首頁、一個產品後台組件。對住規範逐條 Review。行通咗先至開權限。呢個同新服務上線前要先做灰度測試（Canary Release）係同一個意思 —— 唔做灰度直接全量推行，翻車係遲早嘅事。

按角色將出口鎖死，再釘死一個 Owner

最後兩件事。第一係按團隊角色預設好輸出路徑：營運做物料就行 Canva 協同；工程接需求就行 Claude Code handoff bundle；銷售整 pitch deck 就行 PPTX 匯出。預先配好晒，每個人就唔使每次都諗「我呢件嘢應該行邊條路」。

另一個係 owner —— 呢條係冇得讓步嘅。設計系統一定要有人掛名負責。冇明確 owner 嘅設計系統，六個月內一定會變成「設計建議」。季度 review 係底線，變更流程亦係底線。我做架構咁多年最深嘅體會就係：冇人掛名嘅事，就等於冇呢件事。寫 code 係咁，設計系統都一樣。

地基講完喇，下面係五個場景。先講返個邏輯，費事你讀到一半卡住 ——

頭 4 個場景嘅提示詞入面反覆出現「用我哋嘅 design system」，指嘅都係按前面地基嗰步建好嗰份：色板、字體、組件、語調、間距、無障礙預設值全部都已經餵咗畀 Claude Design 喇。如果未建過嘅話，唔好直接跳去抄提示詞，先翻到最後一個場景（由 GitHub 倉庫反推一套設計系統）—— 嗰一節講嘅就係點樣由你產品嘅 code 倉庫或者公開網站反推一整套 design system 出嚟，係 onboarding 呢一步應該做嘅嘢。做完佢，頭 4 個場景嘅提示詞先至行得通。

下面文章入面攞 resolve.ai、秘塔 AI 搜索呢啲真實產品做案例，對應嘅「design system」就係將佢哋公開嘅前端「扒」落嚟，行一次最後嗰個場景嘅提示詞得到嘅產物 —— 官網、開源組件、字體棧、色板、icon set 都可以由公開渠道反推，唔需要內部授權。真係要幫呢類產品做正式物料嘅話，再將工程團隊內部嘅組件庫疊加埋上去、覆蓋公開版，就係完整嘅喇。

直立式短片 —— 產品 feature 發佈用得最多

視頻號、小紅書都係食呢個尺寸。最難嘅唔係視覺，而係節奏 —— 文案要短、要畀讀者有時間讀完、視覺唔好一睇就知係 AI 做嘅（例如旋轉字、滑入滑出、配嗰啲免費音效庫嘅歡快鋼琴聲）。

下面呢段提示詞我攞 AI on-call 工具 resolve.ai 做案例嚟寫，真實產品、真實場景，直接就行得。你換自己產品嗰陣，將產品名、痛點句、時間數字、目標用戶換成你嘅就得：

做一個 9:16 豎版視頻，30 秒內講清楚 resolve.ai 這個 AI on-call 助手
能幫 SRE 和一線工程師幹什麼。
風格剋制、節奏冷靜，字體和配色走我們 design system。下面這些
"AI 模板化"動效一個都不要：旋轉文字、浮誇滑入、背景粒子、歡快鋼琴配樂。

文案節拍按這個來：
- 0-3 秒："凌晨告警，又值一宿" —— 大字入場，停 2 秒能讀完
- 3-5 秒："以前告警一炸，翻日誌、跳面板、拉指標，定位要四十分鐘" —— 中等力度
- 5-9 秒："現在 resolve.ai 自動串全鏈路上下文，分鐘級給出一份可讀的根因分析" —— 視覺重音，放大或加強調色
- 9-12 秒："專為一線 SRE 和 on-call 工程師打造" —— 回到穩態
- 12-15 秒："resolve.ai · resolve.ai/try" —— CTA 微微呼吸感

畫面主體用我們 design system 裏的真實產品截圖 —— 告警列表、
context timeline、根因分析卡片都要出現，不要簡化成單條 AI chat bubble。
不要用圖庫素材。不要字幕半透明黑條底。不要任何音效。
導出 1080×1920 MP4，30fps。

踩過嘅坑有呢幾個。

「30 秒內」佢成日會理解錯做「啱啱好 30 秒」，第一版塞到滿晒。呢種時候唔使重寫提示詞，直接去右上角 Tweaks 拖一個「每拍時長」滑塊，一拖就鬆返晒，2 分鐘搞掂。

如果呢條片主要投落小紅書，比例要寫 3:4（1242×1660）而唔係 9:16。小紅書直立封面係 3:4 嘅，9:16 傳上去會被平台二次裁切，你精心擺喺底嘅 CTA 會直接被切走咗。

「唔要音效」呢一條一定要講明。我第一次冇寫，佢配咗一段一聽就知係 Canva 免費庫出嚟嘅鋼琴背景音樂，成條片嘅格調即刻冧晒 —— 你如果發落客群度，老細第一句實問「點解咁 low 㗎」。

涉及產品數據（例如呢條入面嘅「分鐘級畀出根因分析」），發之前一定要同官方 marketing 嘅口徑對齊。自己「拍腦袋」填「3 分鐘」、「5 分鐘」睇落好爽，但真實使用時間同事件複雜度有好大關係，官方一般會用「分鐘級」、「比人工快 10 倍」呢類描述。跟返佢哋原話走 —— 唔係嘅話素材一發，即刻會被客或者銷售同事當場 call out。

最後一條係畀 AI 類產品嘅：第一版 Claude Design 好大機會畀個靚但失真嘅「AI 聊天氣泡」介面你，其實 resolve.ai 主介面係告警列表 + context timeline + 根因分析卡片嗰套，資訊密度比普通 SaaS 高好多。唔明確提要求嘅話，出嚟就係陣 AI slop 味嘅假介面 —— 所以提示詞入面嗰句「告警列表、context timeline、根因分析卡片都要出現，唔好簡化成單條 AI chat bubble」係唔慳得嘅。

畀長輩用嘅健康 App 原型

國內 60 歲以上群體換智能手機呢兩年明顯快咗，但大廠 App 嘅互動完全唔照顧呢個群體 —— 字細、全手勢、文案仲帶有羞辱感（例如「今日完成 0/3」）。做敬老向嘅原型，最難嘅唔係「好睇」，而係要守住「唔遊戲化、唔羞辱、唔靠手勢」呢幾條。Claude 預設會一嘢將你拉返去「連續打卡 7 日解鎖成就」嗰種健身 App 範式，要明確切斷佢。

做一個給 65 歲以上用戶的健康 App 原型，四個聯動界面。用我們 design system，
但疊加下面這幾條無障礙硬約束：

- 正文字號最小 18pt
- 點擊區域最小 56 × 56 pt
- 對比度 WCAG AAA 起步（正文 7:1）
- 禁止純手勢，每個操作必須有顯式按鈕
- 語氣温和、不遊戲化：不連續打卡、不成就勳章、不排行榜，
  也不要"今日完成 0/3"這種帶失敗感的進度提示

四個屏：

今日概覽
- 頂部按時間問候 + 用戶暱稱（早上好/下午好/晚上好）
- 三張垂直卡：(a) 今日活動：大圓環進度 + 一句鼓勵話；
  (b) 今日餐食：早午晚三個小縮略圖，點擊跳"餐食推薦"屏；
  (c) 今天感覺如何：三個大按鈕（很好 / 一般 / 不太好）
- 底部四宮格導航：今天 / 活動 / 餐食 / 進度

活動詳情
- 左上返回
- 標題"今日推薦活動"
- 頂部示意圖或視頻佔位（大面積）
- 分步驟卡片：每步編號 + 簡筆圖 + 一句話指令
- 底部一個全寬大按鈕"開始"

餐食推薦
- 左上返回
- 三張餐食卡（早/午/晚），每張：菜名、4-6 樣食材、
  一句話推薦理由（AI 生成）、一個"換一個"按鈕
- 底部小字："根據您的健康檔案每天早上更新"

進度
- 三塊垂直堆疊：(a) 活動：近 7 天柱狀圖，座標軸字號要大；
  (b) 餐食："本週按推薦吃了 5 天"配友善插畫；
  (c) 感受：近 7 天表情行
- 底部一句支持性總結，不打分、不排行：
  "這一週你動了 6 天，已經很實在的進步了。"

四屏底部導航互通。今日概覽的餐食縮略圖點擊跳"餐食推薦"。
移動端豎屏，iOS / Android 視覺語言都接受，
人像插畫優先用中國面孔。

第一版畀你嘅嘢多數仲係「健身 App 浸味」 —— 元素密度高、字號偏細、字體太有「科技感」。呢種時候唔好話「再適老啲」，直接講「元素密度降 40%、所有字體大一級、攞走晒所有運動化詞彙」，立竿見影。「適老」呢啲模糊詞 Claude 會往「更大更圓」嗰種刻板印象度走，其實 65 歲以上用戶要嘅唔係被照顧得過頭，而係節奏慢啲、唔好催佢。

人像插畫如果唔明確指定族裔，佢預設會畀白人面孔。要寫「中國面孔」。

最後仲要提醒一句：原型唔係可以上線嘅產品。真係要做產品，健康數據要行《個保法》同《健康醫療數據安全指南》，涉及醫療建議仲要過藥監相關規範。Claude Design 畀你嘅係一個可以點擊嘅概念，唔係合規嘅 code。合規呢條線要交畀工程團隊 —— 我前面嗰篇講 Claude Code + Claude Design handoff 嘅文章入面傾過呢條鏈路點行，有興趣可以翻睇吓。

AI 工具產品嘅中文落地頁 + 可點擊 demo

喺國內做 AI 工具產品，最大嘅轉化阻力其實唔係用戶唔信你，而係佢哋懶得註冊。一段 demo 片永遠唔及畀佢哋真係點兩下掣。Claude Design 可以將縮細版產品介面直接嵌落落地頁，訪客唔使登入就可以試一次。

下面呢段攞秘塔 AI 搜索嚟做例子 —— 呢類產品做 landing page demo 天生就係好合適：用戶入一個問題、頁面即場出答案，一個閉環就講完。你套用落自己產品嗰陣，將核心動作換返做你產品嘅主要互動就得（API 調用、code 補全、agent 拖拽，乜都得）：

做一箇中文落地頁，針對秘塔 AI 搜索。用我們 design system，整體走剋制簡潔，
不要紫色漸變背景，不要 AI slop 三件套。

結構從上到下：
- Hero：主標題"搜答案，不是搜頁面"，副標題"一款給你直接答案、
  帶原文出處的 AI 搜索引擎"。主 CTA 按鈕"免費試用"，
  右側一張真實產品截圖（搜索結果頁 + 結構化答案 + 引用卡）
- 三列能力展示：
    全網檢索 + AI 重排 —— 引用公開信源，不是大模型憑空說
    結構化答案 —— 分段、帶小標題、每條結論標出引用號
    多模態 + 學術模式 —— 可切換文獻、學術論文、視頻源檢索
- 交互式 demo 區塊：嵌入一個縮小版搜索框，預置三個示例問題
  （比如 "Claude Code 的 MCP 是什麼"、"上週 ICLR 最好的 agent 論文"），
  訪客點任意一條，頁面原地展示預生成的分段答案 + 引用號卡片，
  按鈕必須真的可點擊，不要做成靜態截圖。
  走完跳一個"看起來不錯？正式試用"的 CTA
- 定價三檔（免費版 / 進階版 / 研究員版），中間檔視覺加重
- 客戶評價三段，留佔位文案我來填（研究員、開發者、學生各一段）
- 底部：產品連結、公司連結、合規連結
  （用戶協議、隱私政策、ICP 備案號佔位 "滬ICP備 XXXXXXXX 號"）

中文排版幾條硬規則：
- 正文行高 1.75
- 標題字體從這幾個裏挑一個有風格的：思源宋體、霞鶩文楷、Alibaba Sans、
  站酷高端黑。避開 PingFang 和系統默認，一眼就是 AI 做的
- 段落首行不縮進
- 數字、英文、中文之間加半角空格

文案保持克制。每一句要麼說產品做啥，要麼給事實證據。
"賦能""重塑""一站式解決方案""未來已來"這些詞一律不出現。

導出 standalone HTML，前端能直接接。

「唔要 AI slop」呢條指令 Claude 執行得唔係咁穩定。最後一版我成日發現紫色漸變背景又被佢偷偷地加返入去 —— 解決方案係去 Tweaks 面板將主色鎖死做你嘅品牌色，佢就冇得擅自改喇。

中英文混排佢成日漏咗空格。叫佢喺 Tweaks 入面加一個「中英文空格」掣，強制開咗佢，好過每次手動檢查咁煩。

Demo 區塊嘅第一版十成九都係一張「睇落似產品」嘅死圖，啲掣點唔郁。要明明白白同佢講：「demo 區塊入面嘅掣一定要真係撳得，撳完之後要觸發區塊內部畫面變化，唔好跳去外鏈。」唔寫呢句，你攞到嘅就只係一張靜態截圖，完全冇用。

最後一條係當你攞人哋產品做案例時嘅提醒：上面秘塔嗰段，我係按佢公開定位順手寫嘅樣例文案，真係要發布之前一定要對住產品官方嘅 marketing 口徑執一次 —— 定價級別嘅叫法、功能點描述、引用機制，呢啲細節唔啱，識行嘅用戶一眼就睇得出係外行人寫嘅。呢條道理推廣到任何「用 A 產品做案例幫 B 團隊整頁面」嘅場景都一樣 —— 案例可以抄，定位唔可以靠估。

一個活動出三個平台嘅視覺包

喺國內做一個活動，成日要喺小紅書、公眾號、視頻號、朋友圈九宮格入面全部露面。規格完全唔同，字體大細、留白、視覺重心全部都要重新調校。人手做嘅話每張圖重做一次，一個營運同事一個下晝就咁廢咗。

Claude Design 嘅「共享視覺概念 + 多規格聯動」就係為咗呢種場景而設 —— 你對個概念做一次迭代，四個資產就會同步更新。本質上同我哋做微服務入面嘅共享配置中心係同一回事，資訊源只可以有一個。

為 [活動名] 做一個四件套視覺包，全部共享同一個視覺概念 ——
一樣的字體處理、一樣的強調色、一樣的佈局邏輯 —— 讓用戶在四個平台
刷到時能識別出是同一個活動。

四個資產：
- 小紅書封面（1242 × 1660，3:4）：主標題 + 一個視覺鈎子
  （圖像、插畫、幾何圖形都接受）
- 公眾號頂部圖（900 × 383，≈2.35:1）：同一主標題，橫向重排
- 視頻號封面（1080 × 1440，3:4）：主標題 + 副標題，中間偏上構圖
- 朋友圈九宮格（9 張 1080 × 1080 單圖，拼起來是一張大圖）：
  主標題分佈在對角線或中心三張，其餘六張是視覺延展

主標題：[4-8 字，突出結果或懸念]
副標題（只在視頻號出現）：[10-15 字補充]
主色：design system 裏的 [強調色名]
字體：標題走 design system 裏的 display 字體，正文不出現

四個資產放在同一個項目下，讓我對視覺概念做一次迭代四個能同步更新。
導出為文件夾。

Claude 預設會將四個資產做得好似「同一張圖換尺寸」咁。但小紅書嘅讀者同公眾號嘅讀者係兩撥人 —— 要明確補多句：「小紅書嗰張要後生啲、情緒外放啲；公眾號嗰張資訊要密集啲、CTA 要明顯啲；視頻號嗰張用戶係掃過嘅，視覺要更搶眼、用大啲嘅色塊；九宮格拼埋一齊嗰陣，中心視覺重心要喺中間嗰張。」

九宮格呢種需求外國係冇嘅，Claude 第一反應會俾一張 3240 × 3240 嘅合成大圖你。要反覆強調「每一格都係獨立嘅 1080 × 1080 檔案，要 9 個檔案，唔係一張合成圖」。

視頻號封面係 3:4（1080 × 1440），唔係抖音嗰種 9:16。傳錯咗俾平台裁切，底部 CTA 係重災區。

由 GitHub repo 反推一套設計系統

如果你團隊已經寫緊 code —— 就算只係攞 shadcn/ui 或者 Ant Design 起咗個後台 —— 你嘅「設計系統」其實已經收埋咗喺 code 入面。Tailwind 配置、組件 props、CSS 變數、icon set，全部喺晒度。手動整理成可以 reuse 嘅文檔，三個月都做唔完。

Claude Design 可以反向將 code 入面嘅管束提煉成一套明確嘅 design system，之後非技術同事都可以套用呢個系統嚟整物料，整出嚟嘅嘢同 code 入面嘅原語係同一套。呢個用法對工程團隊嚟講特別正 —— 我自己第一次睇到生成結果嗰陣，真係覺得「呢樣嘢幫我慳咗起碼兩星期」。

呢條係 onboarding Claude Design 嗰陣用嘅提示詞，唔係每個 project 都用：

基於以下資產建立 [公司/產品名] 的完整 design system：
- 代碼倉庫：[GitHub URL 或本地目錄]
- 品牌資料：[上傳的文件名]
- 三張參考截圖：[附件]

提取並明文記錄下面這些原語：

色板 —— 主色、次級色、強調色、語義色（成功/警告/錯誤/提示）、
中性灰階。每一個給 hex 值 + 用法說明

字體比例 —— Display / Headline / Body / Caption 四級。
每級給：字體家族（中英文各一套 fallback 棧）、字號、字重、行高、字間距

間距比例 —— 一套命名的數列（比如 4、8、12、16、24、32、48、64 px），
每一步給名字

組件原語 —— 按鈕（主要/次要/第三級/破壞性）、輸入框、卡片、
彈窗、導航、圖標。每個列出 props、狀態、尺寸

佈局模式 —— 常用柵格、斷點、容器最大寬

語調規則 —— 句長、正式度、該用的詞、不該用的詞、
是否用縮寫、是否帶專業術語、是否帶幽默

無障礙默認值 —— 最低對比度、焦點狀態、動畫減弱降級

提完之後，給下面四個上下文各生成一個樣例產物讓我驗證：
- 落地頁 hero
- 產品後台一張卡片
- 一張社交媒體封面
- Pitch deck 標題頁

重要：哪一項在我提供的資產裏推導不出來，明確 flag "缺失"讓我補。
不要自己編一個值填進去。

「唔好自己編一個值」呢條一定要寫。唔寫嘅話 Claude 會「幫你補全」，三個月後你先發現團隊一直用緊佢當初亂編嘅中性灰，到時呢個值已經生晒喺每一份物料入面，改死你。

Code repo 如果係大 monorepo，Chrome 會窒。提前揀出相關嘅 sub-package 放喺一個乾淨嘅目錄俾佢，唔好直接貼 repo root。

第一版 design system 大概會有 10-15% 嘅項目需要人手糾正。重點複查兩處：語義色（primary 同 secondary 佢成日會幫你掉轉）、間距命名（prefix 容易唔統一，一陣間 space- 一陣間又 spacing-）。

中文字體 fallback 棧一定要明確要求分開列出嚟 —— 佢預設只會列英文，「PingFang SC」之類一定要叫佢補返。Frontend 打包嗰陣 fallback 順序會影響 loading 策略，呢一忽交俾非技術同事好容易會漏咗。

幾條跨場景嘅小小體會

CLAUDE.md 入面一定要埋定啲審美提示詞。之前嗰篇寫過「避開 AI slop」嗰段，直接 copy 入去 project 嘅 CLAUDE.md，Claude Design 每次都會自動讀一遍，唔使你每個 prompt 都人肉加多次。

用 Tweak 嚟迭代，比起重寫 prompt 慳好多時間。一份 80 分嘅稿用 Tweaks 滑桿調到 90 分只需 2 分鐘，重寫 prompt 等佢由頭生過要 10 分鐘，仲成日會將原本好嘅部分都整走埋。卡住嗰陣，第一反應應該係諗「Tweaks 邊個滑桿未用啱」，而唔係「提示詞點解寫得唔好」。

開到口要求變體數量。雖然系統提示詞入面 Claude 係被要求「畀 3 個以上變體」，但如果你唔出聲，佢預設只會畀一個。每個新 project 第一句都加埋「畀三種唔同風格嘅方向我」，花多一秒鐘，少跑兩次返工。

生成之前先驗證 design system。新開 project 第一條 message 唔好一嚟就話「幫我做一個 XX」，先問下「你讀到嘅 design system 係邊一套？主色 hex 係幾多？間距基本單位係幾多？」等佢確認完你再落 requirement —— 咁樣行錯路嘅機會就會明顯下降。呢個同生產部署前先 dry-run 一次係同一個道理。

最後

五個提示詞、打地基嗰啲嘢、幾條小心得，睇完十分鐘，認真試一次要一個下晝。但下次你做 design 嘅時間，可以由「鐘頭計」減到去「分鐘計」 —— 呢個投資回報相當划算。

我做咗技術十幾年，最大嘅體會係咁：工具越聰明，「準備工作」呢一步反而越重要。地基紮實咗，佢可以幫你孭重擔嘅比例就越高；乜都唔準備就直接開波，佢就只能夠將你推返去最大公約數 —— 即係嗰種一眼就認得出係 AI 做、但你又講唔出邊度唔太對路嘅嘢。

Claude Design 唔係幫你由無到有做設計，而係將你已經諗清諗楚嘅品牌風格，放大到每一個產物上面。你諗得越清楚，佢就越好用。

前兩篇聊完 Claude Design 怎麼跑、提示詞寫成什麼樣才不出 AI slop，後台一堆人留言說："別講原理了，直接給幾個能複製粘貼的提示詞。"

行，今天這篇就硬核一點 —— 把我自己反覆跑過的五個中文場景的提示詞原樣貼出來，每個後面跟一段我踩過的坑。但有句話得放最前面：地基沒打好，再漂亮的提示詞都是浮的。所以前面會先嘮兩句"地基"那點事。等不及的同學可以先翻到下半段把提示詞抄走，回頭再回來補，也行。

為啥非要先講地基

我在三家公司主導過設計系統，其實跟我之前在雲文檔、在安全審計平台搭統一組件庫的路數差不多。每次都見過同一種死法：頭一個月所有人熱情都在線，品牌規範、組件庫、Figma 變量一應俱全；第三個月開始七零八碎；半年後文檔沒人更新，組件庫一半是殭屍變體，團隊又退回到各畫各的狀態。

設計系統的敵人從來不是工具問題，是時間問題。Claude Design 把"做"這一段壓扁了，但"建立 + 維護"這件事的總重量沒變。工具是新的，規律是老的 —— 我這兩週在幾個小團隊裏試着跑，最糟糕的姿勢已經能看出苗頭：一個設計師下午剛開通賬號，立馬拉一個 Hero 區出來給老闆看，底子一點沒打就開始堆生成。按過去三輪做設計系統的經驗推一推，這種玩法用不了多久就會漂移 —— 今天 A 拉一張圖，明天 B 拉一張圖，過兩週一擺，團隊裏每個人用 Claude Design 做出來的東西就不是同一個品牌了。這玩意兒你跟我說叫"設計系統"，我是不信的。

所以下面這套打底子的活兒，聽着可能有點笨，但順序千萬別亂。

摸清你手裏有什麼

第一件事不是開工，是盤點。logo 各種格式有沒有齊？字體文件呢？色板有沒有 hex 碼？間距有沒有規範？語調文檔有沒有？寫下來你缺啥。缺本身也是信息。這一步跟我們做架構評審之前先把現有微服務、數據庫、上下游依賴盤清楚是一個意思 —— 不盤清楚，後面每一步都是猜。

接下來選 source of truth。要是你團隊已經有生產代碼庫帶組件庫了，優先選代碼。其次才是文檔化過的 Figma 文件，再次才是品牌手冊 PDF。這個順序有講究：Claude Design 從代碼裏提取出來的東西最接近"可複用"，從靜態文件裏提的常常缺狀態、缺 hover、缺 disabled，回頭你還得手動補一遍。

最後，把 onboarding 的資產打一個乾淨的包：代碼倉庫連結、Figma 導出、品牌手冊、兩三張能代表你產品視覺的真實生產截圖。別把整個飛書雲盤、整個企業微信共享文件夾一股腦兒丟上去，挑。Claude 跟人一樣，你給它的信息越亂，它給你的輸出越糊。

把品牌"教"給 Claude

教的順序也別亂：代碼先 → 品牌文檔 → 參考截圖。代碼打頭陣，讓 Claude 讀到你最真實的組件長啥樣；品牌文檔其次，疊加 token 和語調規則；截圖最後壓陣 —— 截圖是用來驗證系統的，不是定義系統的。這條規則反過來用就翻車。我在一個金融客戶那兒見過同事直接拿截圖當輸入，結果生成出來的色板比真實代碼裏的色板暗了兩個色階，沒人當場發現，上線半年才被產品總監指出來。

教完之後，生成任何界面之前先驗證。讓 Claude 把它讀到的色板、字體比例、間距、組件名都列出來給你看一遍，當場糾錯。錯的原語會順着每一個後續項目流下去 —— 這跟微服務裏上游服務的契約錯了一個道理，下游全跟着錯，越早 fix 越省事。

還有一條容易漏：把語調規則顯式寫進去。設計系統失敗最常見的姿勢就是隻記錄了視覺，忘了記錄"品牌怎麼說話"。句長、正式度、是否用縮寫、是否帶幽默、哪些詞堅決不能出現 —— 這些你不寫，Claude 默認就給你來一段"賦能、重塑、未來已來"的味兒，到時候你哭都沒地方哭。

別讓它變殭屍 —— 治理這一步真的別省

如果你品牌視覺和產品視覺本來就不一樣（大部分 B2B 公司就是這樣的，營銷站走酷炫，產品後台走剋制），就老老實實維護兩套 design system。Claude Design 原生就支持多套，別硬把一套塞所有場景。

開放給團隊前，跑一輪測試衝刺。生成你最常做的三件套：一個落地頁、一個 pitch deck 首頁、一個產品後台組件。對着規範逐條 review。跑通了再開權限。這跟新服務上線前要先做灰度是一個意思 —— 不灰度直接全量，翻車是遲早的。

按角色把出口配死，再釘一個 owner

最後兩件事。一個是按團隊角色把出口路徑預設好：運營做物料走 Canva 協同；工程接需求走 Claude Code handoff bundle；銷售拉 pitch deck 走 PPTX 出口。默認配好，每個人不用每次再想"我這個該走哪條路"。

另一個是 owner —— 這是不能讓步的一條。設計系統得有人掛名負責。沒明確 owner 的設計系統，六個月內必變成"設計建議"。季度 review 是底線，變更流程是底線。我做架構這麼多年最深的體會就是：沒人掛名的事情，等於沒有這事。代碼如此，設計系統也一樣。

地基講完了，下面是五個場景。先說一句邏輯，免得讀到一半卡住 ——

前 4 個場景的提示詞裏反覆出現"用我們 design system"，指的都是按前面地基那一步建好的那份：色板、字體、組件、語調、間距、無障礙默認值全都已經餵給 Claude Design 了。沒建過的話，別直接跳去抄提示詞，先翻到最後一個場景（從 GitHub 倉庫反推一套設計系統）——那一節講的就是怎麼從你產品的代碼倉庫或公開網站反推一整套 design system 出來，是 onboarding 這一步該乾的事。做完它，前 4 個場景的提示詞才跑得動。

下面文章裏拿 resolve.ai、秘塔 AI 搜索這種真實產品當案例，對應的"design system"就是把他們公開的前端扒下來，跑一遍最後那個場景的提示詞得到的產物 —— 官網、開源組件、字體棧、色板、icon set 都能從公開渠道反推，不需要內部授權。真要給這類產品做正式物料，再把工程團隊內部的組件庫疊加上去、覆蓋公開版，就是完整的了。

豎版短視頻 —— 產品 feature 發佈用得最多

視頻號、小紅書都吃這個尺寸。最難的不是視覺，是節奏 —— 文案要短、要給讀者讀完的時間、視覺別一看就是 AI 做的（旋轉字、滑入滑出、配那種免費音效庫的歡快鋼琴）。

下面這段提示詞我拿 AI on-call 工具 resolve.ai 當案例寫的，真實產品、真實場景，直接能跑。你換自己產品的時候，把產品名、痛點句、時間數字、目標用戶換成你的就行：

做一個 9:16 豎版視頻，30 秒內講清楚 resolve.ai 這個 AI on-call 助手
能幫 SRE 和一線工程師幹什麼。
風格剋制、節奏冷靜，字體和配色走我們 design system。下面這些
"AI 模板化"動效一個都不要：旋轉文字、浮誇滑入、背景粒子、歡快鋼琴配樂。

文案節拍按這個來：
- 0-3 秒："凌晨告警，又值一宿" —— 大字入場，停 2 秒能讀完
- 3-5 秒："以前告警一炸，翻日誌、跳面板、拉指標，定位要四十分鐘" —— 中等力度
- 5-9 秒："現在 resolve.ai 自動串全鏈路上下文，分鐘級給出一份可讀的根因分析" —— 視覺重音，放大或加強調色
- 9-12 秒："專為一線 SRE 和 on-call 工程師打造" —— 回到穩態
- 12-15 秒："resolve.ai · resolve.ai/try" —— CTA 微微呼吸感

畫面主體用我們 design system 裏的真實產品截圖 —— 告警列表、
context timeline、根因分析卡片都要出現，不要簡化成單條 AI chat bubble。
不要用圖庫素材。不要字幕半透明黑條底。不要任何音效。
導出 1080×1920 MP4，30fps。

踩過的坑有這麼幾個。

"30 秒內"它經常理解成"剛好 30 秒"，第一版塞得滿當當。這種時候別重寫提示詞，直接去右上角 Tweaks 拖一個"每拍時長"滑塊，一拖就鬆下來，2 分鐘搞定。

如果這條視頻主投小紅書，比例要寫 3:4（1242×1660）而不是 9:16。小紅書豎版封面是 3:4 的，9:16 傳上去會被平台二次裁切，你精心放在底部的 CTA 直接被切沒。

"不要音效"這一條一定要明說。我第一次沒寫，它給配了一段一聽就是 Canva 免費庫出來的鋼琴背景音，整個視頻的調性當場塌方 —— 你要是發到客戶羣裏，老闆第一句話就是"這怎麼這麼 low"。

涉及產品數據（比如這條裏的"分鐘級給出根因分析"），發之前一定要跟官方 marketing 的口徑對齊。自己拍腦袋填"3 分鐘""5 分鐘"看着挺爽，但真實使用時間跟事件複雜度強相關，官方一般用"分鐘級""比人工快 10 倍"這類描述。照他們原話走 —— 不然素材一發，馬上就會被客戶或銷售同事當場 call out。

最後一條是給 AI 類產品的：第一版 Claude Design 很可能給你拉一個漂亮但失真的"AI 聊天氣泡"界面，其實 resolve.ai 主界面是告警列表 + context timeline + 根因分析卡片那套，信息密度比普通 SaaS 高不少。不顯式提要求，出來就是 AI slop 味兒的假界面 —— 所以提示詞裏那句"告警列表、context timeline、根因分析卡片都要出現，不要簡化成單條 AI chat bubble"是不能省的。

給長輩用的健康 App 原型

國內 60+ 人羣換智能機這兩年明顯加快了，但大廠 App 的交互完全不照顧這個羣體 —— 字小、純手勢、文案帶羞辱感（"今日完成 0/3"）。做敬老向的原型，最難的不是"好看"，是把"不遊戲化、不羞辱、不靠手勢"這幾條守住。Claude 默認會一把把你拉回"連續打卡 7 天解鎖成就"那個健身 App 範式，要顯式切斷。

做一個給 65 歲以上用戶的健康 App 原型，四個聯動界面。用我們 design system，
但疊加下面這幾條無障礙硬約束：

- 正文字號最小 18pt
- 點擊區域最小 56 × 56 pt
- 對比度 WCAG AAA 起步（正文 7:1）
- 禁止純手勢，每個操作必須有顯式按鈕
- 語氣温和、不遊戲化：不連續打卡、不成就勳章、不排行榜，
  也不要"今日完成 0/3"這種帶失敗感的進度提示

四個屏：

今日概覽
- 頂部按時間問候 + 用戶暱稱（早上好/下午好/晚上好）
- 三張垂直卡：(a) 今日活動：大圓環進度 + 一句鼓勵話；
  (b) 今日餐食：早午晚三個小縮略圖，點擊跳"餐食推薦"屏；
  (c) 今天感覺如何：三個大按鈕（很好 / 一般 / 不太好）
- 底部四宮格導航：今天 / 活動 / 餐食 / 進度

活動詳情
- 左上返回
- 標題"今日推薦活動"
- 頂部示意圖或視頻佔位（大面積）
- 分步驟卡片：每步編號 + 簡筆圖 + 一句話指令
- 底部一個全寬大按鈕"開始"

餐食推薦
- 左上返回
- 三張餐食卡（早/午/晚），每張：菜名、4-6 樣食材、
  一句話推薦理由（AI 生成）、一個"換一個"按鈕
- 底部小字："根據您的健康檔案每天早上更新"

進度
- 三塊垂直堆疊：(a) 活動：近 7 天柱狀圖，座標軸字號要大；
  (b) 餐食："本週按推薦吃了 5 天"配友善插畫；
  (c) 感受：近 7 天表情行
- 底部一句支持性總結，不打分、不排行：
  "這一週你動了 6 天，已經很實在的進步了。"

四屏底部導航互通。今日概覽的餐食縮略圖點擊跳"餐食推薦"。
移動端豎屏，iOS / Android 視覺語言都接受，
人像插畫優先用中國面孔。

第一版給你的東西多半還是"健身 App 氣息" —— 元素密度高、字號偏小、字體太"科技感"。這種時候別說"再適老一點"，直接說"元素密度降 40%、所有字體上浮一級、去掉所有運動化詞彙"，立竿見影。"適老"這種模糊詞 Claude 會往"更大更圓"那種刻板印象上走，其實 65+ 用戶要的不是被照顧得過頭，是節奏慢一點、不催你。

人像插畫不顯式指定族裔的話，它默認給你白人面孔。寫"中國面孔"。

最後還得提醒一句：原型不是可上線產品。真要做產品，健康數據要走《個保法》和《健康醫療數據安全指南》，涉及醫療建議還得過藥監相關規範。Claude Design 給你的是一個能點的概念，不是合規代碼。合規這條線得交給工程團隊 —— 我前面那篇講 Claude Code + Claude Design handoff 的文章裏聊過這條鏈路怎麼走，感興趣可以翻翻。

AI 工具產品的中文落地頁 + 可點擊 demo

國內做 AI 工具產品，最大的轉化阻力其實不是用戶不信你，是他們懶得註冊。一段 demo 視頻永遠不如讓他們真的點兩下按鈕。Claude Design 能把縮小版產品界面直接嵌進落地頁，訪客不登錄就能試一遍。

下面這段拿秘塔 AI 搜索當例子 —— 這個品類做 landing page demo 天生合適：用戶輸一個問題、頁面原地出答案，一個閉環就講完了。你套自己產品的時候，把核心動作替換成你產品的主交互就行（API 調用、代碼補全、agent 拖拽、什麼都行）：

做一箇中文落地頁，針對秘塔 AI 搜索。用我們 design system，整體走剋制簡潔，
不要紫色漸變背景，不要 AI slop 三件套。

結構從上到下：
- Hero：主標題"搜答案，不是搜頁面"，副標題"一款給你直接答案、
  帶原文出處的 AI 搜索引擎"。主 CTA 按鈕"免費試用"，
  右側一張真實產品截圖（搜索結果頁 + 結構化答案 + 引用卡）
- 三列能力展示：
    全網檢索 + AI 重排 —— 引用公開信源，不是大模型憑空說
    結構化答案 —— 分段、帶小標題、每條結論標出引用號
    多模態 + 學術模式 —— 可切換文獻、學術論文、視頻源檢索
- 交互式 demo 區塊：嵌入一個縮小版搜索框，預置三個示例問題
  （比如 "Claude Code 的 MCP 是什麼"、"上週 ICLR 最好的 agent 論文"），
  訪客點任意一條，頁面原地展示預生成的分段答案 + 引用號卡片，
  按鈕必須真的可點擊，不要做成靜態截圖。
  走完跳一個"看起來不錯？正式試用"的 CTA
- 定價三檔（免費版 / 進階版 / 研究員版），中間檔視覺加重
- 客戶評價三段，留佔位文案我來填（研究員、開發者、學生各一段）
- 底部：產品連結、公司連結、合規連結
  （用戶協議、隱私政策、ICP 備案號佔位 "滬ICP備 XXXXXXXX 號"）

中文排版幾條硬規則：
- 正文行高 1.75
- 標題字體從這幾個裏挑一個有風格的：思源宋體、霞鶩文楷、Alibaba Sans、
  站酷高端黑。避開 PingFang 和系統默認，一眼就是 AI 做的
- 段落首行不縮進
- 數字、英文、中文之間加半角空格

文案保持克制。每一句要麼說產品做啥，要麼給事實證據。
"賦能""重塑""一站式解決方案""未來已來"這些詞一律不出現。

導出 standalone HTML，前端能直接接。

"不要 AI slop"這條 Claude 執行得不穩定。最後一版我經常發現紫色漸變背景又被它偷偷加回來了 —— 解決方案是去 Tweaks 面板把主色鎖死成你的品牌色，它就沒法擅自改了。

中英文混排它經常漏空格。讓它在 Tweaks 里加一個"中英文空格"開關，強制開啓，比每次手動檢查省心。

Demo 區塊的第一版十有八九是一張"看起來像產品"的死圖，按鈕點不動。顯式跟它說："demo 區塊裏的按鈕必須真的可點擊，點擊後觸發區塊內部畫面變化，不要跳外鏈。"不寫這一句，你拿到的就是一張靜態截圖，白搭。

最後一條是給你拿別人產品當案例時的提醒：上面秘塔那段，我是按它公開定位順手寫的樣例文案，真要發佈之前一定要對着產品官方的 marketing 口徑校一遍 —— 定價檔位叫法、能力點描述、引用號機制，這些細節不對，懂行的用戶一眼就能看出是外人寫的。這條推廣到任何"用 A 產品當案例給 B 團隊做頁面"的場景都一樣 —— 案例可以抄，定位不能猜。

一個活動出三個平台的視覺包

國內一個活動經常要在小紅書、公眾號、視頻號、朋友圈九宮格里都露臉。規格完全不同，字號、留白、視覺重心都得重調。人肉做的話每張圖重做一遍，一個運營同事一下午就廢了。

Claude Design 的"共享視覺概念 + 多規格聯動"就是給這種場景設計的 —— 你對概念做一次迭代，四個資產同步更新。本質上跟我們做微服務裏共享配置中心是一回事，信息源只能有一個。

為 [活動名] 做一個四件套視覺包，全部共享同一個視覺概念 ——
一樣的字體處理、一樣的強調色、一樣的佈局邏輯 —— 讓用戶在四個平台
刷到時能識別出是同一個活動。

四個資產：
- 小紅書封面（1242 × 1660，3:4）：主標題 + 一個視覺鈎子
  （圖像、插畫、幾何圖形都接受）
- 公眾號頂部圖（900 × 383，≈2.35:1）：同一主標題，橫向重排
- 視頻號封面（1080 × 1440，3:4）：主標題 + 副標題，中間偏上構圖
- 朋友圈九宮格（9 張 1080 × 1080 單圖，拼起來是一張大圖）：
  主標題分佈在對角線或中心三張，其餘六張是視覺延展

主標題：[4-8 字，突出結果或懸念]
副標題（只在視頻號出現）：[10-15 字補充]
主色：design system 裏的 [強調色名]
字體：標題走 design system 裏的 display 字體，正文不出現

四個資產放在同一個項目下，讓我對視覺概念做一次迭代四個能同步更新。
導出為文件夾。

Claude 默認會把四個資產做得跟"同一張圖換尺寸"似的。但小紅書的讀者跟公眾號的讀者不是一撥人 —— 顯式補一句："小紅書那張更年輕、情緒外放；公眾號那張更信息密集、CTA 更明顯；視頻號那張用戶是劃過的，視覺要更奪目、用更大色塊；九宮格拼起來時中心視覺重心要在中間那張。"

九宮格這個需求國外沒有，Claude 第一反應給你來一張 3240 × 3240 的合成大圖。要反覆強調"每一格是獨立的 1080 × 1080 文件，9 張文件，不是一張合成圖"。

視頻號封面是 3:4（1080 × 1440），不是抖音那種 9:16。傳錯了被平台裁切，底部 CTA 是重災區。

從 GitHub 倉庫反推一套設計系統

如果你團隊已經在寫代碼了 —— 哪怕只是拿 shadcn/ui 或者 Ant Design 起了個後台 —— 你的"設計系統"其實已經藏在代碼裏了。Tailwind 配置、組件 props、CSS 變量、圖標集，全在那兒。手動整理成可複用的文檔，三個月都做不完。

Claude Design 能反向把代碼裏的約束提煉成一套顯式的 design system，之後非技術同事也能套這個系統做物料，做出來的東西跟代碼裏的原語是一套。這個用法對工程團隊尤其香 —— 我自己第一次看到生成結果的時候真有種"這玩意兒替我省了至少兩週"的感覺。

這條是 onboarding Claude Design 的時候用的提示詞，不是每個項目都用：

基於以下資產建立 [公司/產品名] 的完整 design system：
- 代碼倉庫：[GitHub URL 或本地目錄]
- 品牌資料：[上傳的文件名]
- 三張參考截圖：[附件]

提取並明文記錄下面這些原語：

色板 —— 主色、次級色、強調色、語義色（成功/警告/錯誤/提示）、
中性灰階。每一個給 hex 值 + 用法說明

字體比例 —— Display / Headline / Body / Caption 四級。
每級給：字體家族（中英文各一套 fallback 棧）、字號、字重、行高、字間距

間距比例 —— 一套命名的數列（比如 4、8、12、16、24、32、48、64 px），
每一步給名字

組件原語 —— 按鈕（主要/次要/第三級/破壞性）、輸入框、卡片、
彈窗、導航、圖標。每個列出 props、狀態、尺寸

佈局模式 —— 常用柵格、斷點、容器最大寬

語調規則 —— 句長、正式度、該用的詞、不該用的詞、
是否用縮寫、是否帶專業術語、是否帶幽默

無障礙默認值 —— 最低對比度、焦點狀態、動畫減弱降級

提完之後，給下面四個上下文各生成一個樣例產物讓我驗證：
- 落地頁 hero
- 產品後台一張卡片
- 一張社交媒體封面
- Pitch deck 標題頁

重要：哪一項在我提供的資產裏推導不出來，明確 flag "缺失"讓我補。
不要自己編一個值填進去。

"不要自己編一個值"這一條必須寫。不寫的話 Claude 會"幫你補全"，三個月後你才發現團隊一直在用它當初瞎編的中性灰，那時候這個值已經長進每一份物料裏，改起來要命。

代碼倉庫要是大 monorepo，Chrome 會卡。提前挑出相關子包放一個乾淨目錄給它，別直接貼倉庫根。

第一版 design system 大概會有 10-15% 的項需要人工糾正。重點複查兩處：語義色（primary 和 secondary 它經常給你倒過來）、間距命名（前綴容易不統一，一會兒 space- 一會兒 spacing-）。

中文字體 fallback 棧一定要顯式要求單獨列出來 —— 它默認只列英文，"PingFang SC"之類得讓它補上。前端打包的時候 fallback 順序會影響加載策略，這一塊交給非技術同事很容易漏。

幾條跨場景的小心得

CLAUDE.md 裏一定要埋審美提示詞。前面那篇寫過的"避開 AI slop"那段，直接貼進項目 CLAUDE.md，Claude Design 每次都會自動讀一遍，不用你每個 prompt 都人肉追加。

Tweak 迭代比重寫 prompt 省太多。80 分的稿用 Tweaks 滑塊調到 90 分花 2 分鐘，重寫 prompt 讓它從頭生成花 10 分鐘，而且經常把原本好的部分一併丟掉。卡住的時候第一反應該是"Tweaks 哪個滑塊沒用對"，不是"提示詞怎麼沒寫好"。

顯式要求變體數量。系統提示詞裏 Claude 是被要求"給 3 個以上變體"的，但你不開口它默認只給一個。每個新項目第一句話都加上"給我三種不同風格的方向"，多花一秒鐘，少跑兩次返工。

生成前先驗證 design system。新開項目第一條消息別上來就"幫我做一個 XX"，先問"你讀到的 design system 是哪一套？主色 hex 是多少？間距基本單位是多少？"它確認完你再下需求 —— 跑偏的概率會明顯下降。這跟生產部署前先 dry-run 一遍是一個意思。

最後

五個提示詞、地基那點事、幾條小心得，看完十分鐘，認真跑一遍要一個下午。但下次你做設計的時間，能從小時級降到分鐘級 —— 這投入回報相當合算。

我做技術十幾年，最大的體感是這樣的：工具越聰明，"準備工作"這一步反而越重要。地基紮實了，它能替你扛活的比例就越高；什麼都不準備直接開大，它就只能把你推回最大公約數 —— 那個一眼能認出是 AI 做的、但你又說不出哪裏不對的東西。

Claude Design 不是幫你從無到有做設計，是把你已經想清楚的品牌放大到每一個產物上。想清楚的越多，它越好用。