Figma Code Layers Beta 將共同探索帶入可運作的原型

Figma 表示，其 code layers beta 現已涵蓋 100% 用戶，將可運作的原型直接帶到團隊原本已用於審核設計的畫布上。由運行中程式碼支援的互動原型 code layers，讓設計師可在共享空間中比較互動行為與視覺呈現。這項改變為一套常見工作流程帶來壓力：先在其他地方建立實驗，再帶回連結讓所有人評估。

這項公告關乎擴大可用範圍，而非一次全新的推出。Figma 在 11 月 4 日的工作流程文章中描述全面推出，而其文件則將最初公開 beta 的日期定為 2026 年 10 月 15 日。這個分別十分重要，因為眼前的問題已由是否可用，轉為是否實用。團隊如今可以評估，共享畫布是否足以改善決策，從而值得在設計與實作之間增設另一條途徑。

Framer 已在其畫布上提供 code components，因此在視覺工作空間中運行程式碼本身並非新事物。Figma 的主張集中於協作探索：在投入實作前保留不同方案、編輯其視覺呈現，以及結合各種構想。核心張力在於，一方面令原型更容易討論，另一方面令其底層變更達至可交付的程度。

Figma Code Layers Beta 擴展共享審核範圍

真正的改變是，可運作的實驗現在能成為同一個審核空間的一部分，與周圍的設計一同檢視。

在其 code layers workflow 中，Figma 描述了匯入程式碼、產生替代方案、完善擷取出的設計，以及結合不同探索結果。Figma agent 是其設計檔案內的對話式 AI 助手，可協助進行這些變更。文章以名為 Pickup 的虛構市集為例，當中設計師在既有地圖體驗旁，探索送貨地址選擇功能。

虛構例子可以說明工作流程，但不能證明其成效。Pickup 有助理解 Figma 預期的步驟，但不應被視為經獨立衡量的實際部署。公告並沒有提供依據，讓人得出每個團隊都能縮短開發週期或產出更佳介面的結論。

不過，實驗所在的位置改變了審核者可討論的內容。截圖只捕捉某一刻的外觀。可運作的原型則讓人測試互動、回到周圍設計，再比較另一個方向，而不會失去整體視覺脈絡。

試想一次審核中，分歧集中於地址選擇器。一個吸引人的版面，可能掩蓋了用戶選擇地點後生硬的轉換。相反，一個視覺上較樸素的方案，可能令任務更清晰。把互動行為放在外觀旁邊，能讓討論具備更直接的證據。

這並不會自動令意見更精準。審核者仍須說明自己測試了甚麼，以及為何某個差異重要。當沒有人標示各方案的目的時，滿佈可運作替代方案的畫布，也可以像塞滿原型連結的資料夾一樣令人困惑。

機會在於，讓問題與實驗一同保持可見。一個變體可能測試人們是否明白入口位置；另一個則可能測試在確認前應提供多少資訊。即使兩個原型包含相似畫面，這也是不同的產品問題。

這個分別亦有助避免把生成結果本身變成決策。Agent 可以提供看似合理的替代方案，卻無法確立哪一個最符合用戶需要。團隊仍有責任選定評估準則，並找出欠缺的證據。

因此，對評估這次推出的讀者而言，可用性只是起點。更重要的問題是，共享介面是否令分歧更容易解決。若所有人都看見不同方案，卻沒有人能解釋選擇依據，工作流程雖然移動了，卻未必變得更具問責性。

Figma code layers beta 令更廣泛的受眾可實際面對這個問題。團隊可以直接評估這種協作模式，同時把公司的工作流程示範視為有待驗證的建議。

設計師與開發人員面對更早期的協調決定

共享原型把部分實作討論提前到仍可相對低成本改變方向的階段。

Figma 的 code layers documentation 說明，用戶可從設計、提示詞、網頁或已連接的程式碼開始。它亦支援擷取可編輯的設計圖層，並將其變更送回 code layer。文件提醒，code layers 並不適用於每個 repository。

最後這項限制有助界定誰會感受到壓力。設計師多了一種把互動具體化的方法，但開發人員必須判斷實驗與實際產品有多貼近。產品經理則必須分辨一個令人信服的示範，與已協定的實作範圍。

當原型揭示隱藏的依賴關係時，讓開發人員更早參與很有價值。原型可能呈現用戶操作後的即時回應；生產環境中的產品卻可能需要等待服務、檢查權限，或處理本機無法取得的資訊。

這些是說明性的工程考量，而非 Figma 功能已知的失敗情況。它們解釋了為何可運作的介面無法回答每一個實作問題。原型確立的是使用者在實驗中可體驗到甚麼，而生產環境審核則確立組織能可靠支援甚麼。

壓力亦延伸至審核流程本身。若設計師可在會議中帶來可運作的替代方案，對「需要更清晰」這類模糊要求便更難維持。參與者可以直接指出互動，並解釋哪個部分造成不確定性。

與此同時，開發人員可利用同一討論，把視覺決定與架構決定區分開來。一個按鈕標籤可能可立即採用；一連串新的請求則可能需要更廣泛的技術改動。把這些判斷分開，能避免一個有前景的介面被附加不切實際的交付承諾。

因此，Figma agent prototyping 改變的更多是協作時機，而非責任歸屬。設計師仍負責設計判斷，工程師仍評估實作，產品領導者仍決定擬議的體驗是否解決值得處理的問題。

亦存在參與度問題。若只有生成原型的人懂得如何評估，共享工作空間便難有太大價值。審核者需要足夠脈絡，才能探索相關互動行為，而毋須每次都依賴口述導覽。

對組織而言，有用的採用訊號是審核後得出更清晰的決定。一次成功的會議應識別首選方向、尚未解決的假設，以及推出前所需的工作。只有在更多替代方案有助改善這個決定時，產生更多方案才有幫助。

既有工作流程面對壓力，是因為它把實驗與集體評估分隔開來。Figma 的做法令這些活動更接近。這種接近是否減少返工，仍須每個團隊透過自己的項目加以確立。

Agent 把視覺探索連接至運行中的互動行為

Figma 主張中最有力的部分，是能在不離開周邊討論的情況下，於互動行為與視覺細節之間切換。

從分析角度看，這是一個回饋循環。團隊嘗試一項互動、發現設計問題、修訂相關視覺呈現，然後評估更新後的互動行為。重點是讓每次修訂都連繫到促使它出現的問題。

這個分別很重要，因為介面品質涉及局部細節與更廣泛的流程。間距可以影響操作看起來是否可用；措辭可改變使用者選擇後的預期；轉換效果則可能揭示一個視覺平衡的畫面，卻在不恰當的時刻要求提供資訊。

在這些議題之間切換，往往正是審核失去精準度之處。對話原本由可觀察的問題開始，繼而變成對風格的普遍偏好。讓可運作的體驗靠近視覺探索，可讓參與者回到原本的證據。

Figma 的客戶材料對這個解讀提供了一些支持。其 customer prototype examples 描述 Checkout.com 設計師 Kris Murphy 擷取畫面，以便共同檢視，然後把視覺編輯帶回原型。同一集合亦描述 Superside 的 Leonardo Rica 在探索互動卡片概念時，提供精確尺寸與動態細節。

這些是由 Figma 發布、具名客戶的說法，而非獨立比較。它們說明人們如何使用這項功能，卻不能確立典型結果。它們有用的共同線索在於具體性：當有人知道需要檢查或修正甚麼，工作流程才更具意義。

例如，評估結帳互動的團隊可把對措辭的不確定性，與對導航的不確定性分開。若同時修訂兩者，便更難理解為何結果感覺較佳。保留比較有助讓討論聚焦於正在測試的決定。

這是比較所帶來的分析優勢，而非聲稱 Figma 會自動進行受控實驗。團隊仍須讓條件保持足夠一致。不同的範例內容或缺少的狀態，可能令某個方案因無關原因而顯得更強。

同樣的審慎亦適用於結合不同探索結果。把吸引人的功能帶在一起，並不保證結果仍然一致。個別看來合理的選擇，可能在共用導航、術語或對下一步的預期時互相衝突。

因此，組合後的原型需要另一輪獨立審核。它應作為完整體驗加以評估，而不應因其組成部分先前已獲批准便被接受。這正是即使生成速度加快，設計判斷仍然居於核心的位置。

當 Figma agent prototyping 支援具體調查時最有用。要求探索特定互動，會讓團隊留下可評估的成果；要求一個整體而言更佳的體驗，則留下太多未說明的評估內容。

實際含義是，共享畫布上的探索依賴清晰意圖。運行中的程式碼令互動行為可供檢視，卻不會決定哪種行為值得保留。

畫布上的程式碼已是一個競爭類別

Figma 的競爭論點建基於團隊審核的連續性，因為以畫布為基礎的程式碼已在其他地方存在。

Framer 的 code components 是以 JavaScript library 編寫、可重用的 React 介面元素，可在其畫布、預覽及已發布網站中呈現。其文件亦描述視覺屬性控制與元件分享。

這為相關的歷史脈絡提供參考，但不把這些產品視為可互換。擴展網站建立工具的元件，與在產品設計檔案內探索的原型，目的有重疊之處，卻並不相同。其價值取決於團隊希望交付甚麼。

正在建立已發布網站的團隊，可能會優先考慮視覺編輯與最終網站之間的關係。探索應用程式改動的產品團隊，則可能更重視不同方案、相關畫面，以及說明所選方向的討論。

兩種需求本身都不代表較為先進。它們代表不同的終點。若只按工具能否產生程式碼來比較，便忽略了產生之後的工作，以及需要參與其中的人。

這令 Figma 的定位更為清晰。它的機會在於，讓共享設計檔案成為檢視可運作構想的實用場所。問題在於，這個位置能否保留足夠脈絡，以抵銷將程式碼帶入其中所需的成本。

獨立的編碼環境亦可以是探索介面的有效場所。工程師可能偏好在既有專案慣例和開發檢查已存在的環境中實驗。設計師則可能偏好在其設計工作區中取得更全面的視覺概覽。

這些偏好不應演變成視覺工具與程式碼工具之間的人為競爭。實際問題是，某項決策在哪裡能夠清楚地作出。同一專案的不同階段，合理地可以使用不同環境。

主要對手仍然是零散的探索。當原型、相關設計、意見回饋和理據變得難以連結時，這種零散便會出現。切換應用程式只是其中一種徵狀。單一應用程式內也可以存在彼此斷開的工作。

因此，單靠計算減少了多少次工具切換，會是一種不完整的評估。團隊可能減少了切換次數，卻花更多時間辨認目前版本。另一個團隊可能保留不同工具，卻能在證據與決策之間維持清晰連結。

Figma 範例所說明的程式碼圖層，提供了一個空間上的答案：把不同方案和討論放在一起。當關係一目了然時，空間上的接近會有所幫助。當不斷擴展的畫布令這些關係變得模糊時，其幫助便會減少。

因此，競爭壓力與其說在於生成能力，不如說同樣關乎檢視品質。Figma 需要證明，當原型可以在其既有協作環境中運行時，該環境會變得更有用。只要競爭方案能讓團隊更清楚地由構想走向有理據支持的實作決策，它們仍然可信。

可運作的原型仍需要程式碼與存取權檢視

在共享檔案內運行的原型，會就其實作方式和可見性帶來檢視責任。

Figma 的 Git integration 文件說明了儲存庫複製、分支和 pull requests，以及在合併前提交作檢視的建議改動。文件亦說明，檔案檢視者可以看到程式碼圖層的預覽和預覽原始碼。即使沒有相應的 GitHub 權限，檔案編輯者仍可存取底層儲存庫程式碼。

在匯入私有專案前，這個可見性模式值得注意。相關受眾是可存取設計檔案的群組。團隊應評估該受眾是否與引入程式碼原本預定的受眾相符。

這是有文件記錄的存取特性，並非安全事故的證據。其實際重要性取決於儲存庫和共享安排。處理專有程式碼的機構，在把匯入視為日常設計操作前，需要理解這項安排。

此外還有另一條實作界線。Figma 記錄了返回儲存庫檢視的途徑，但該途徑的存在並不代表生成的改動必然正確。建議改動仍需要按專案要求進行評估。

以地址選擇功能為例，檢視者可能會問如何處理無法使用的地點，或在請求失敗後確認資訊是否仍然清晰。這些只是示例性的檢視問題，其目的在於區分實驗中令人信服的行為，與真實條件下可靠的行為。

無障礙設計也需要作出同樣區分。介面可以看起來很有說服力，同時仍然難以在不使用指標裝置的情況下操作。鍵盤操作、焦點順序和易於理解的回饋，需要直接評估，而非從視覺精緻度推斷。

原型程式碼與現有專案慣例之間的關係同樣重要。一項局部改動可以看似合理，卻引入難以在其他地方維護的模式。即使原型清楚呈現其預期行為，仍有必要在脈絡中檢視改動。

因此，質疑的理據很具體：更容易展示可能鼓勵過早的信心。持份者可能把可運作的畫面解讀為其餘工作並不多的證據。只要實驗仍有重要依賴關係未解決，便需要挑戰這種解讀。

有用的檢視應指出哪些行為已實作、哪些行為屬模擬，以及哪些假設仍未經測試。這能保留原型的價值，同時避免它意外地變成一項承諾。

決策紀錄有助在會議後保留這種區分。比較不同方案的團隊，可以把理據保存在 可搜尋的知識庫 中，並與相關技術文件一同保存。重要資訊是方向為何改變，以及哪些事項仍需驗證。

因此，Figma code layers beta 應按送達工程檢視的建議改動品質來判斷。較易理解的原型固然有用。附帶明確假設和可檢視實作的原型，則是更強的成果。

留意採用情況、修訂保真度及探索成本效益

下一批證據應顯示，團隊是否能作出更清晰的決策、保留預期改動，並在初步實驗後持續採用這套工作流程。

第一個訊號，是在真實專案中重複進行協作使用。未來數月，更有力的證據會包括團隊成員比較不同方案，並把選定方向帶入實作檢視的案例。重複使用將支持 Figma 的說法，即畫布解決的是持續存在的協調問題。

一系列令人印象深刻的示範，提供的支持則較弱。示範能證明工作流程可以產生吸引的結果，卻較少揭示當專案限制變得棘手時，團隊是否會再次採用該流程。

這項區分應引導正在評估採用案例的買家。應問清楚哪項決策變得更明確、誰人參與，以及原型檢視後發生了甚麼。這些細節比泛稱實驗感覺更快更有用。

第二個訊號是修訂保真度：當工作在視覺編輯和程式碼之間流轉時，改動是否保留其預期外觀和行為。這是建議採用的評估準則，而不是 Figma 已發布的基準。它直接針對產品承諾背後的核心機制。

修正工作的證據有限，會強化這項承諾。若反覆出現無關改動、遺失細節或難以協調的報告，則會削弱它。無論結果如何，都需要交代專案複雜性和所嘗試的改動。

第三個訊號，是在實際點數消耗下能否持續探索。Figma 的 AI credit rules 指出，程式碼圖層請求會消耗可變動的點數。該公司亦表示，AI 工作開始前無法預測確實消耗量。

這使完整檢視週期成為相關的評估單位。生成一個替代方案、加以精煉和修正，都是達成可用決策的一部分。若只評估首個輸出，便令其餘投入變得不可見。

持續使用將顯示團隊認為結果值得投入所需資源。若出現初步試用後便放棄比較的模式，則會引起對可重複性的疑問。單憑發布公告，無法確立任何一種結論。

這些訊號讓預測繫於可觀察的結果。Figma 已在其共享設計環境中提供可運作的探索。剩下的問題是，周邊流程是否變得足夠清晰，讓團隊持續使用它。

在你下一次檢視時，選擇一項已經引發分歧的互動，並清楚保留評估問題。以相同的使用者任務比較不同方案，保留所選方向背後的理據，並識別工程團隊必須驗證的假設。詢問檢視者：可運作的比較是否改變了他們的判斷，還是只令展示更吸引。然後讓建議改動通過實作檢視，沿途記錄所需的任何修正。把 Figma code layers beta 視為檢視團隊如何作決策的機會。當工作流程有助參與者理解取捨，並讓開發人員得到更清晰、可檢視的建議時，便繼續採用它。