Claude Code 新增 /design skill:一張截圖或一句話,變成可編輯的設計稿

/design 跟過去在 Claude Code 裡貼截圖、請 Claude 照著改介面,有什麼不同?

過去的做法(貼截圖到終端機、口頭描述要改哪裡)本質上是把截圖當成「參考圖片」,Claude 讀取圖片內容後直接生成或修改程式碼,中間沒有一個獨立、可编輯的設計檔案存在——你看到的成果就是程式碼本身跑起來的樣子。/design 不一樣的地方在於,它的輸出是一份真正的設計檔案(收在 Claude Design 裡的畫布),不是直接寫死的程式碼。這代表你可以在還沒有任何程式碼的階段,先在設計檔案上調整、比較、甚至讓其他人(在 Team/Enterprise 方案裡)一起編輯,確定版本之後才請 Claude 把這份設計轉譯成程式碼。

簡單說,舊做法是「圖片進、程式碼出」,/design 是「想法或截圖進、可編輯設計檔案出,設計檔案再轉成程式碼」——多了一個獨立、可反覆修改的中間產物。

為什麼 Anthropic 要特別做一個「設計」Skill,而不是繼續強化 Claude Code 直接生成程式碼的能力?

最直接的原因,是設計跟實作原本就是兩個不同性質的決策——設計階段在意的是「這個畫面該長什麼樣子、資訊該怎麼排列」,實作階段在意的是「怎麼用程式碼把這個畫面做出來」。如果每次調整畫面都要透過修改程式碼來實現,等於是用成本更高的方式(改程式碼、重新編譯、重新查看結果)去解決一個成本應該更低的問題(單純比較幾個版面選項)。

把設計獨立成一個可編輯的檔案,還有另一層意義:設計檔案可以被分享跟共同編輯,但程式碼的修改權限跟審核流程通常更嚴謹。讓非工程背景的人(例如產品經理、設計師)也能直接在 Claude Design 裡調整畫面、不需要碰觸程式碼本身,某種程度上是把「畫面決策」跟「程式碼實作」這兩件事的權限邊界重新劃分開來。

實際使用起來,從輸入到拿到程式碼的完整流程是什麼樣子?

第一步是輸入,可以是三種形式其中之一:純文字描述你想要的畫面(例如「一個訂閱方案的比較表,三欄,中間欄要突出顯示」)、一張現有介面的截圖、或是你手上已經有的設計稿。第二步,/design 會根據輸入回傳一份可編輯的畫布,收在 Claude Design 裡——這個階段建議做的是生成多個版本並排比較,而不是直接接受第一個結果。

第三步是調整跟確認,你可以在畫布上直接修改細節(顏色、間距、文字),如果是 Team 或 Enterprise 方案,也可以邀請其他人一起編輯、發布新版本。等到畫面確定,第四步才是請 Claude 把這份設計檔案轉譯成實際的程式碼——因為前三步都不涉及寫程式碼,修改成本相對低,真正進入寫程式碼階段時,要調整的通常已經是定案的設計,而不是還在猜測的草案。

現在就想試用 /design,要注意什麼?這個功能適合什麼樣的使用情境?

先要知道的是它目前是研究預覽階段,代表操作細節、輸出品質跟功能範圍都還可能持續調整,不建議把它當成已經穩定成熟的正式功能來依賴,尤其是關鍵、對外發布的產品設計。比較適合的定位是「內部功能的早期草案階段」——例如快速拉出一個內部工具的介面草稿、或是產品經理想在會議前先給工程團隊看幾個畫面選項,這類場景可以直接感受到「不用等設計師先做出來」的效率提升。

如果你的團隊已經有既定的設計系統或品牌規範,實際使用時要留意 /design 生成的初版通常需要對照既有規範做調整,不會自動套用你公司的視覺規範——比較實際的做法是把它當成「快速生成幾個方向的草案」,而不是「一步到位的最終稿」。目前這個功能只在 Claude Code 的 CLI 跟桌面應用裡,還沒有開放到其他介面。