Claude Design 系統提示詞泄露，如果把它做成 Skill，能復刻 Claude Design 嗎？

作者：AI 啓蒙小夥伴
日期：2026年4月22日 上午12:05
來源：WeChat 原文

✦整理版優先睇

速讀 5 個重點 高亮

Claude Design 的核心價值不在於單純的提示詞技巧，而是將 AI 模型、設計工作流與 HTML 運行環境深度耦合的生產系統。

  • 角色定位：將 Claude 定義為「執行設計師」而非聊天助手，強調產出可運行、可交互的 HTML Artifacts。
  • 工作流優先：強制執行「先吸收上下文、再提問、後設計」的流程，嚴禁在缺乏品牌資產或 UI Kit 的情況下盲目創作。
  • 設計哲學：提倡系統化探索，要求提供至少 3 種變體（Variations），並透過 Tweak 面板讓用戶進行維度比較與篩選。
  • 技術約束：文檔暴露了大量針對宿主環境的硬性規定（如 React/Babel 版本、禁止 scrollIntoView 等），確保輸出在工程上穩定。
  • 可行動點：透過將洩漏的系統提示詞封裝成 Skill，可以在 Codex 或 Claude Code 等工具中復刻其設計品味與協作邏輯。
值得記低
連結 pan.quark.cn

Claude Design 完整系統提示詞

Anthropic 官方流出的 Claude Design 完整 System Prompt 備份。

開啟
Skill pan.quark.cn

Claude Design 可安裝 Skill 包

將系統提示詞沉澱為可直接在 Codex 等工具使用的 Skill 配置文件。

開啟
工具 github.com

infocard-skills

開源的信息卡製作 Skill，支持多種比例 HTML 轉圖片生成。

開啟
整理重點

不只是 Prompt，是一套「設計生產系統」

Claude Design 的強大並非源於抽象的設計理論，而是源於它與宿主環境（Runtime）的緊密結合。這份洩漏的提示詞揭示了它如何處理項目文件、預覽窗口、DOM 映射以及驗證代理。

整理重點

從失敗經驗中長出來的硬性規矩

文檔中包含許多具體到瑣碎的規定，這些往往是從真實交互事故中總結出來的生產規則，而非理想化的說明書。

Claude Design 具體約束示例 markdown 
- 不要用 scrollIntoView
- 不要把 slide label 按 0 開始編號
- 沒有真實 icon 時，用 placeholder 比拙劣仿製更好
- 儘早將文件展示給用戶（Show file early），不要悶頭做完
- 在 HTML 開頭寫下 assumptions 與 design reasoning，像個初級設計師向主管匯報
整理重點

如何復刻 Claude Design 的設計能力？

要復刻這種體驗，關鍵在於將這些規則「Skill 化」。透過將長篇的系統提示詞拆解為觸發條件（SKILL.md）與規則手冊（Playbook），可以讓 AI 在特定場景下自動進入設計模式。

這是一種成熟的方向：把 Prompt、設計方法、宿主工具鏈和驗證機制進行一體化設計。

Claude Design 系統提示詞

Anthropic 最新推出 Claude Design 幾天後，完整的系統提示詞就被扒出來了，我把它放在國內可正常訪問的地址：

https://pan.quark.cn/s/a98fdeb6f5ba[1]

今天咱們一起拆解學習 Claude Design，看看它到底好在哪，為什麼能做出這麼好的設計交互產品，以及，拿到了這篇完整的系統提示詞，做成 Skill，咱們能復刻 Claude Design 的設計品味品質嗎？

系統提示詞深度拆解

系統提示詞構成

  1. 角色定義：把 Claude Design 定義成“替用戶產出設計成果的設計師”，而不是聊天助手。
  2. 工作流程：從提問、找上下文、搭文件、預覽、交付到驗證，給出一套固定順序。
  3. 平台契約：它假定背後有一整套宿主能力，比如項目文件系統、預覽窗口、DOM 映射、Tweak 面板、驗證子代理。
  4. 故障經驗總結：很多細節不像抽象原則，更像從真實失敗里長出來的規矩。

所以，這份文本真正重要的地方，不只是“Claude Design 會怎麼做設計”，是它暴露了一種產品思路：把模型、設計工作流和交互式 HTML 運行環境 tightly coupled 成一個設計生產系統。

它到底在塑造什麼樣的 Claude Design

開頭幾句就把角色釘得很死：模型是“expert designer”，用戶是“manager”，產物以 HTML 為核心媒介，而不是把 HTML 僅僅當網頁代碼。這一點很關鍵。它實際上在把 HTML 提升成一種通用設計承載層：

  • 可以做頁面，也可以做 PPT、原型、動畫、視頻式 artifact。
  • 重點不是“網頁開發”，而是“可預覽、可交互、可迭代的設計交付物”。
  • 因為目標是 artifact，所以它反覆強調預覽、持久化狀態、評論定位、變體切換、交付後驗證。

這意味着它對“設計”的理解，不是 Figma 式靜態出圖，也不是單純的前端編碼，而是“能跑起來的設計表達”。

這份系統提示詞最核心的設計哲學

第一 設計不能憑空生成，必須先吸收上下文。
文本反覆要求先讀 design system、UI kit、現有代碼、截圖、Figma、品牌資產，並明確說“從零 mock 整個產品是 last resort”。這說明它把“理解既有視覺語言”放在“創造新方案”之前。

第二 設計交付不是找一個標準答案，而是做系統化探索。
它要求給出 3+ variations，用 slides 或 tweaks 暴露差異，還鼓勵從保守到激進逐步展開。這不是一次性給一個“最好看”的方案，而是讓用戶在多個維度裏比較、拼裝、篩選。

第三 儘早把東西給用戶看。
prompt 明確要求“show file to the user early”，而不是悶頭做完。說明它把設計看成連續反饋過程，而不是封閉創作。

第四 模型要像一個有執行力但仍需管理的初中級設計師。
有一處非常值得注意：它要求模型在 HTML 文件開頭寫 assumptions、context、design reasoning，“as if you are a junior designer and the user is your manager”。這很能說明它的產品定位：不是讓模型裝成全知全能的創意總監，而是進入一種更可管理、更可 review 的協作姿態。

它不是抽象原則，而是帶着強烈平台痕跡

這份文本里大量內容其實不是“設計理論”，而是“這個 Claude 設計環境應該怎麼用”：

  • 固定 React/Babel 版本和腳本寫法
  • 多個 text/babel 腳本不共享作用域，要掛到 window
  • 禁止寫通用名 const styles = {}
  • deck/video 要把播放位置寫入 localStorage
  • 用戶評論時會帶 DOM block，用來反推源代碼節點
  • 高層 screen 要打 data-screen-label
  • 通過 window.parent.postMessage(...) 接 edit mode / tweaks
  • 最後用 done 交付，再交給 fork_verifier_agent

這些要求說明，這不是普通意義上的 prompt engineering，而是“prompt + runtime API contract”。文本本身只是表層，真正的系統是提示詞背後的宿主產品。

最有價值的部分在那些具體到有點瑣碎的規定

真正讓我覺得這份 prompt 很重要的，不是“要問很多問題”“要尊重設計系統”這些常見原則，而是那些很具體、很像從事故里總結出來的條目。例如：

  • 不要用 scrollIntoView
  • 不要把 slide label 按 0 開始編號
  • 不要默認加 speaker notes
  • 不要輕易加 title screen
  • 不要自己先做驗證，先 done 再交給 verifier
  • 不要直接引用別的項目資源，要複製進當前項目
  • 不要 bulk-copy 大量資源
  • 沒有真實 icon 時，placeholder 比拙劣仿製更好

這類規則的信號很強：它不是一份理想化說明書，而是一份經歷過大量真實交互、被持續打磨過的生產規則集合。換句話說，它體現的不是“設計師怎麼想”，而是“一個可用的設計代理系統在真實環境裏會怎麼出錯，因此必須如何約束”。

從產品角度看，它想解決的是什麼問題

從文本本身可以比較明確地讀出，它要解決至少四類問題：

  1. 避免模型脱離上下文亂設計。
    所以強制先問、先讀、先找現有組件。

  2. 避免一次性交付太單一。
    所以要求變體、tweaks、可切換版本。

  3. 避免 artifact 只好看但不好協作。
    所以要可評論、可定位、可持久化、可驗證。

  4. 避免模型輸出在工程上不穩定。
    所以對腳本結構、作用域、命名、交付順序寫得非常死。

這說明它追求的不是“Claude Design 能不能設計”，而是“Claude 產出的設計成果能不能在一個團隊協作環境裏穩定流轉”。

它的邊界和侷限

這份 prompt 也有明顯偏向。

一是它非常偏 HTML artifact 世界。
這會讓它在原型、deck、交互展示上很強，但未必適合所有設計任務。某些真正依賴設計工具原生能力的工作，不一定適合被壓進單個 HTML 文件。

二是它對“先找上下文”的強調非常強。
優點是更穩，缺點是對真正從零開始的探索性創作可能會有保守傾向。

三是它把很多策略寫成硬規範。
例如“至少問 10 個問題”，在某些場景下會顯得偏重。這是生產系統常見取捨：犧牲一點靈活度，換更高的穩定性。

四是它把驗證外包給 verifier agent。
這很像一種平台內分工優化，但也說明主代理被限制得比較明顯，它不鼓勵自己做太多末端檢查。

一句話概括這份 prompt 的意義

如果要我用一句話概括，這份 Claude Design System Prompt 的真正價值是：

它不是在教模型“如何做漂亮設計”，而是在把模型訓練成一個能嵌入設計生產流程、能理解上下文、能生成可運行 artifact、能配合平台協作機制工作的設計執行體。

這也是它為什麼重要。它展示的不是單個提示詞技巧，而是一種更成熟的方向：把 prompt、設計方法、宿主工具鏈和驗證機制一起設計。

把這份系統提示詞沉澱成 Skill

Claude Design Skill 創建過程

如果你在使用 Codex 或 Claude Code，它們都有默認的 Skill-Creator，負責按照你的指令把內容沉澱創建為 Skill。

我在使用 Codex App，輸入的指令是：

請使用 @ Skill Creator 把下面內容為我生成 Skill 並安裝:
https://pan.quark.cn/s/a98fdeb6f5ba

執行後我得到的 Skill 是這樣：

/Users/admin/.codex/skills/claude-design/Users/admin/.codex/skills/claude-design/SKILL.md/Users/admin/.codex/skills/claude-design/references/design-playbook.md

簡要說明：

claude-design 是一個面向 HTML 設計產物的 skill，適合生成落地頁、交互原型、演示 deck、動效頁面和設計探索稿。

SKILL.md 負責觸發條件和主工作流，儘量短，便於實際觸發。

references/design-playbook.md 放的是詳細設計規則，比如提問方式、原型與 deck 的選擇、React/Babel 約束、tweaks、驗證要求和內容邊界。

這個可直接安裝使用的 Skill 我也分享出來，可以直接使用：https://pan.quark.cn/s/f3f3ffb50534[2]

圖片

Claude Design Skill 使用效果

可以用最簡單的提示詞來測試：

請使用 Claude Design Skill 為我創建一個網頁展示設計和交互能力

得到的頁面效果在這：

最後推薦我的信息卡 Skill

我一直在用的信息卡製作完整方法我做成了 Skill「infocard-skills」，開源在這裏了：

https://github.com/shaom/infocard-skills[3]]

圖片

支持 16/9、4/3、1/1、3/4、9/16 幾種常見比例信息卡，和 2.35/1、3/1 等常見比例封面的適配性針對設計。 輸入需要生成的內容和比例要求（默認 4/3），AI Agent 使用 這個 Skill 生成 HTML 並截圖輸出 PNG。

下面是這個 Skill 生成的樣例！大家可以在使用中調整成最適合你的樣式風格，並沉澱更新到 Skill 裏。

圖片