Figma Make 省 credit 七招：寫對 prompt 勝過寫長 prompt

所有人都在討論怎麼把 prompt 塞滿、把 token 榨乾——Figma 團隊管這股風氣叫 tokenmaxxing。但他們回看 Make 上線一年的使用資料，浮出一個反直覺的 pattern：把 Make 用得最省的那群人，prompt 往往寫得很節制。

寫最長 prompt 的，常常也是來回修最多次、燒最多 credit 的。真正高效的人，懂得先把工作擺好、把每次修改框得很小、把脈絡留給需要協作的地方。Figma 這篇整理了七個官方做法，與其問「怎麼下更多指令」，他們要你先想清楚「哪些事根本不該丟給 prompt」。

Figma 觀察到的核心很簡單：能把 Make 用得最好的團隊，靠的是三種習慣——把開頭設定好、把修改範圍框緊、把脈絡擴散給整個團隊複用。這三件事決定了你會在來回修改上燒掉多少 credit。

七個做法可以濃縮成一句操作守則：把第一個 prompt 當成整份 brief，之後的每一次跟進都只是一個 delta。下面從這條守則往外展開。

你的第一個 prompt 會定下整個專案的結構與限制，這個起點越完整，後面要回頭修的就越少。官方建議第一個 prompt 至少包含四件事：目標、脈絡、所有關鍵元件與行為和限制、以及「完成」最後長什麼樣。把它寫成一份 brief，而非一句模糊的開場。

之後的跟進 prompt 就能小很多，好的跟進只交代三件事：改什麼、會怎麼改、什麼維持不動。大型專案則拆成幾個階段——先把結構做對（結構是深入後最難改的），再加行為與互動，最後才細修內容與打磨。最關鍵的是框緊範圍：「更新 calendar 元件」「在這個畫面加一個新狀態」「改 tokens.ts 這個檔」都比「不太對，可以重做嗎」省 credit，因為模糊的指令會逼 Make 先猜你的意圖，那一猜就是成本。

很多跟進 prompt 其實沒在解新的設計問題，只是想推一下那個已經大致正確的東西。改間距、刪元素、調文字這類小事，Edit 工具往往最快，它讓你做精準微調、不用把整個問題重新打開一次。

程式碼那端也一樣。有些最省的改動，是直接跳到 source 改值——用 ⌘F 在 code 裡搜某個 tag 或餵內容進來的資料，從 App.tsx 找起，找不到再翻 component 資料夾裡其他 .tsx。你不必是工程師也能用，Make 的 code 可讀性夠高，知道要找哪個元件就能定位。較大的視覺調整，官方建議乾脆用 Copy design 把 Make 預覽複製回 Figma Design 畫布，用你熟的工具改完，再一句 prompt 送回去。Designer Advocate Miggi Cardona 就這樣做：Make 生出來的音訊 App 是深色模式，他複製到畫布做了淺色版，再把結果當脈絡帶回 Make——一個 prompt，零猜測。

發現自己一直交代同一件事，就該把它從 prompt 裡抽出來。guidelines.md 是隨身的專案記憶：寫下 design system 有什麼、命名規範、偏好的 pattern、品質標準、常見決策的真正出處。Make 不必每次重學，省下重複的同時也讓第一版結果更好。檔案結構也有講究——一份主 guidelines 配上 components、motion、tokens 等小檔，比一份巨大的 markdown 更好讀，模型讀得越順越有用。

skills.md 則是下一步：當你重複的東西，已經從一段脈絡長成一整套完整流程。兩者都是純文字指令，差別在角色——guidelines 是隨時在背景跑的環境記憶，skills 是特定任務才喚起的隨選流程。一句話分辨：guidelines 告訴 Make 要知道什麼，skills 告訴 Make 要做什麼。

餵外部脈絡時要克制。把 Make 指向一個沒指定重點的大型來源——一整頁 Notion、一個範圍很廣的 Jira 查詢、connector 上一次開放式搜尋——都是在加噪音，模型得先搞清楚哪些脈絡才相關。正確做法是把檢索範圍縮緊：指到那份確切的文件、連到那張確切的票、點名那個檔案或元件。若需要的只有一段話或一組需求，直接貼上去比讓它去搜更有效率。手上已有的檔案（研究 PDF、CSV 資料集、媒體素材）直接附上，比叫它上線去找更省。

最快的做法，是避免每次都從白紙重畫同一套 UI。Make kits 像共用的系統食材——把 foundation、token、component、guidelines.md 甚至 production 用的 npm 套件帶進專案，從 0→1 時直接站在真實元件上，而非從零近似。Templates 則給團隊可複用的起點：產品殼、慣用版面、起手 prompt。Laura Fehre 的開源 SAP template 就把固定的 header、navigation 鎖住，配上嚴格 guidelines，還內建一鍵複製的「recipes」prompt，讓人邊用邊學會怎麼用好它。

選模型也要按任務分流，沒有單一模型適合所有情境。例行小修、單純迭代，Gemini Flash 這類輕量模型通常更划算；遇到模糊、難 debug、需要強推理或保留大量視覺精度的硬活，Claude Opus 這種強模型雖然貴，卻能少走很多冤枉路。前期多投資一點，常比用弱模型來回糾正更省。專案聊久了會變重——chat history 一長，每一輪都得吃更多脈絡、成本疊加，這時清掉 chat context 就能換個乾淨起點。

第七個做法把前面六個收束起來：拿到最多價值的團隊，會一起決定 Make 該插在工作流的哪裡、又該避開哪裡。也許是把 Make 留給「讓既有設計動起來」，而把充滿模糊與探索價值的 0→1 留給人；也許是用它加速原型，但在團隊本來就快又有把握的地方保留手工。每個任務從自動化得到的好處並不一樣，強的團隊知道 Make 在哪裡放大槓桿、哪裡仍需人的精準、哪裡前期多花一點設定能省下後面一大段力氣。

最划算的投資，常常是前期多花一點心思：好一點的 template、清楚的 guidelines、乾淨的 prompt、一份共用的團隊 playbook。那之後的每個專案，都從更穩的地方起跑。本文作者 Alexia Danton 是 Figma 駐巴黎的 Designer Advocate，在設計各領域累積超過十年經驗。