Prototype 變成新的 PRD：Figma 拆解 4 家公司用 AI 把點子送到產線

Affirm 想加一組 badge 到 checkout——標一下哪個方案 0% 利率、哪個最快繳完。版本要跑：哪個 badge、給誰看、出在哪個結帳頁、跑在哪個裝置。這種「同一個元件、N 種組合」的需求，過去從點子到產線常常要走六週。這次 PM 把所有變體塞進 Figma Make，兩天做完原型；設計師在畫布上收斂方向，再用 MCP 把 component 和 token 餵進 Cursor，AI agent 直接從真的 design system 寫起前端。六週收成兩天。

Figma 這篇拿 FloQast、Merkle、Accor、Affirm 四家公司現場拆給你看——他們把 code、canvas、prototype、design system 重新排列組合，做出四種以前不存在的 AI 產品流程。共通點是順序開始流動：spec 不一定先於 prototype、design 不一定先於 code，看你想答的那個問題在哪一層，就從哪一層開始。

這四個案例的共同骨架，是把工作流的順序重排：什麼時候進 code、什麼時候回畫布、什麼時候做 prototype、什麼時候帶 design system 過去。Figma 自己整篇的角度也很清楚：產品團隊正在快速適應 AI 時代的工作方式——他們在寫 spec 之前先跑原型、在做設計之前先寫 code、在前所未有的規模上做探索、並且把 design system 的脈絡一路帶到 production，過去這段在交付時最容易掉。

文章列了四種具體的轉折：在 code 裡測限制、在畫布上大量發散、用原型當第一個共識文件、把 design system 直接接到 production。每一種都對應一家公司，每一家公司都對應一個 AI 工具或工作流。

FloQast 做的是會計團隊用的軟體——那種「這個動作要等另一個動作完成」「兩邊紀錄要對得起來」「沒簽核完什麼都不能往前」的場景。團隊想把原本要在多個頁面之間跳來跳去的對帳流程，收成單一頁面：問題、追查、解決，全在一張畫面上完成。

問題是這頁互動太密——每個 step 都接著真的資料跟邏輯，光看 mockup 看不出來會不會散掉。FloQast 的 UX manager Benjamin Ellis 直接用 AI coding tool 蓋了一個 working prototype，後面接模擬的 backend、灌一份真實客戶的資料，讓整組人實際點過去——完成一個 task 觸發下一個，把那種「畫面看起來對、實際操作會壞」的問題抓出來。等正式選方向時，已經在 code 層被真實情境壓過一遍，後面 build 出來的信心強很多。

整個動線是這樣串的：在 code 裡先做出可動的 prototype → 用 Codex to Figma 把跑起來的介面搬到畫布上一起 review → 要再進 code 就走 MCP，帶著 design context 一起走，設計脈絡不會在來回間掉。

Merkle 的 associate creative director Easton Thomas 在重做一個電信客戶的網站資訊架構——產品要怎麼分類、怎麼擺、搜尋頁怎麼設計。這種題目需要大量發散：要試很多版型、很多內容組合，才有信心收斂。難題是原網站內容太少，他光看靜態 mockup 沒辦法判斷哪一版能撐住真實產品上頁面後的樣子。

Easton 的做法分兩段。第一段是發散到極端：在畫布上先畫 7 種大方向 layout，然後跟 Figma 的 AI agent 說「再給我 10 種變體」，再來 10 種，直到 agent 把所有能組合的可能性都跑完——大約 50 種。他從這 50 種裡挑強的繼續做。第二段是收斂時讓 agent 把細節補齊：寫真實感的 placeholder 文案（讓 stakeholder 評估時不用面對抽象畫面）、把 dev spec 標註直接寫進 annotation card、做最後 review 抓出他可能漏掉的東西，例如螢幕閱讀器的可及性。確定方向後再進 Figma Make 做互動原型，把篩選選單這類有狀態的 UI 拉出來，產出回畫布交付工程師。

效率端的數字是「幾天的工被壓成幾小時」，但更實在的是探索深度——他不用在 7 種方向裡賭一個，可以把整個 option space 跑完再決定。

Accor 是全球連鎖飯店集團，旗下有幾十個品牌。其中一個奢華品牌想探索「AI 怎麼提升網站體驗」。難題是「AI 體驗應該長什麼樣子」沒人說得清楚——把一個 chatbot 丟到網站上不夠，這個品牌的客群會期待這個品牌特有的情緒跟個性。

Accor 的 lead brand designer Justine Grave 直接打開 Figma Make，做出一個她原本不可能來得及手刻的東西：一個會根據使用者輸入重新組織自己的網頁。搜尋 golf，整頁就圍著有高爾夫球場的物件重組——精選 outing、相關體驗、對應的攝影。Make 處理掉微互動跟轉場，Figma MCP server 讓整件事一路接著品牌的 design system。幾天之內，她有一個夠野心去 show 領導層的原型——同時夠具體，足以開啟一場「下一步要做什麼」的真實對話，而非又一場 slide deck 的猜想。

「先做出來再說」這條路，把思考的載體從 deck 搬到 working prototype 上做。對品牌類、體驗類、感受類的題目特別有用——這類東西很難用文字精準傳達，看到、摸到、被驚到才有共識。

Affirm 做分期付款，checkout 體驗橫跨 desktop、行動網頁、Android、iOS，四個平台要長得一致是一個持續性的挑戰。團隊想加 badge 提示客戶選方案——0% 利率、最快繳完、最受歡迎——但每個變體都要在四個平台上忠於同一套 design system，過去從點子到產線常常要走六週。

PM 先在 Figma Make 把 badge 的變體做出來，兩天就有可動原型（過去這段就六週）。設計師在畫布上收斂方向後，team 把 design artifact 載進 Figma MCP server，接 Cursor。MCP 把 component、token、layout 結構整包遞進去——AI agent 在這份「真實的 design system」上長前端，工程師從那個產出開始接著做。產線端寫出來的東西，本來就已經反映 designer 的決定，而非從 spec 重新詮釋一遍。

過去 spec → code 的這段最常出狀況：開發看不到 design system 的全貌，token 是聽說的、component 是 ad-hoc 複製的，最後產線跟設計檔對不齊。MCP 補的就是這段——設計脈絡不再靠人轉述，而是直接餵給寫 code 的 AI。

這四個案例放在一起看，方向很清楚：當 AI 工具讓 code、canvas、prototype、design system 之間的成本變得很低，順序就開始流動。設計師不再被綁在「先做 design 再交給 dev」這條線上——可以從 code 開始（FloQast）、從畫布大量發散開始（Merkle）、從可運轉的 prototype 開始（Accor）、從 design system 出發一路串到產線（Affirm）。

這對學 Figma 的人代表什麼？工具會的東西愈多，「先學會在哪個層次答這個問題」變成更核心的判斷力。題目是邏輯互動，去 code 跟 Make；題目是大量發散，請 agent 在畫布上展開；題目是建立共識，做一個會動的 prototype；題目是把 design 帶過交付，把 design system 練扎實，讓 MCP 有東西可餵。工具會接管執行，但選擇從哪裡開始的能力，留給人。