Figma 編輯模型訓練挑戰通用模型取向

Figma 表示，透過逾 250,000 個範例進行訓練，協助一個早期 Figma 編輯模型在畫布編輯方面與領先模型競爭。其 10 月 29 日發表的工程文章，介紹了由透過範例教學的監督式微調，逐步發展至透過評分結果訓練的強化學習。這種狹窄聚焦十分重要：修改既有設計，與從零生成新設計有不同要求。

這項比較挑戰了一個常見的產品假設：最強的通用模型應可處理應用程式內的所有工作。設計師要求調整間距時，需要的是準確的修改，同時保留周邊工作成果。當眼前工作需要克制時，廣泛的創作能力價值有限。

對應用程式開發者而言，這項公告提出一個實際的投資問題：團隊應持續改善給外部模型的指令，還是圍繞重複操作訓練專門模型？Figma 的說法支持審視後者，但並未證實專門化在所有設計工作中都更勝一籌，亦不代表其他軟件公司應立即跟隨。

Figma 編輯模型帶來的改變

根據 Figma 的 編輯模型訓練說明，範例結合了起始設計、合成請求，以及以其原生格式儲存的成功編輯結果。較大型模型生成候選結果；套用固定檢查的確定性驗證器，以及視覺評審器則負責評估。評估者的回饋亦支援修訂。

關鍵轉變，是由要求模型描述如何編輯，轉為訓練模型產生可直接套用的改動。

透過一項示例請求，這個分別會更清楚：移動標籤，同時不改變其父層卡片。文字說明可以聽起來正確，卻沒有改動實際文件。生成圖像可以呈現預期外觀，卻丟失其背後可編輯的關係。真正有用的結果，是直接修改文件本身。

這令保留原有內容與遵循指令同樣重要。設想助理正確移動標籤，卻替換了附近的文字樣式。可見的請求雖已完成，設計師卻要承擔清理工作。若只評估移動動作，便會錯過這種失敗；若把整個畫面視為一個吸引人的構圖來評判，同樣會錯過。

既有設計亦包含提示詞不會重複交代的決定。某個元件可能反映無障礙審查、合約要求，或剛獲批准的品牌修改。這些都是假設性例子，但可說明編輯為何不同於重新開始。請求處於一段由限制條件構成的歷史之中。

因此，專門模型需要的不只是熟悉設計詞彙。其輸出必須尊重所選物件與周邊文件之間的關係。這令編輯工作比開放式創作提示詞更狹窄、也更具要求：可自由創作的空間較少，保留原有內容的責任則更大。

對評估這項公告的讀者而言，有用的區分是工作能力與通用智能之間的差異。在重複畫布操作上取得成功，只能說明其在這些操作上的表現；這並不能判定哪個模型提供更好的推理、寫作、圖像生成或創意指導。這些能力需要各自的證據。

實際含意不算誇張，卻很重要。產品團隊有理由把重複操作視為獨立類別的工作來評估。即使另一個模型在更廣泛的比較中領先，只要某個模型能可靠地完成這些操作，便值得考慮。比較應由應用程式的實際工作負荷決定。

這亦改變了有說服力的示範應有的樣貌。一個精緻的最終畫面只能提供不完整證據。審查者需要檢視所要求的改動、被保留的周邊內容，以及文件是否仍可編輯。價值在於受控的轉換，而不僅是外觀。

重複編輯令應用程式建構者面對壓力

應用程式建構者面對的選擇，比是否購買或自建 AI 更具體：哪些重複工作值得以專門訓練處理？

設想一個正在審查結帳流程的產品團隊。其設計師希望間距一致、採用獲批准的按鈕元件，並使用符合最新研究結果的文案。每項要求聽起來都很小，但合起來便形成一種工作負荷，重複失誤足以抵銷自動化的好處。

若助理完成第一項編輯，卻干擾下一個畫面，便會增加檢查負擔。設計師既要檢視所要求的結果，也要尋找可能造成的連帶改動。若這類審查變得廣泛，快速生成未必等於更快完成工作。完成時間應包括驗證及修復。

這對在既有工作流程內提供協助功能的軟件供應商構成壓力。廣泛的示範可以吸引注意，但持續使用的用戶會反覆遇到限制條件。產品必須處理令檔案可供同事使用的細節。這些細節難以透過通用的輸出品質指標捕捉。

Canva 的可編輯設計生成提供了一個競爭參考點。Canva 表示，其 Design Model 理解結構、分層、層級、品牌及視覺邏輯，以建立可編輯內容。這項公告涉及相關目標：讓 AI 輸出在設計應用程式內維持可用。

這項比較並不能證實哪家公司表現較好。生成一個可編輯的構圖，與修改受約束的選定內容，是不同任務。公平的評估應先把兩者分開，再比較結果。否則，在廣泛創作上的高分，可能掩蓋精準修訂上的弱點。

對獨立開發者而言，專門化帶來機會，也帶來重大責任。掌握應用程式的文件結構，有助界定有用的訓練工作。然而，訓練項目亦需要評估、維護，以及足以證明投入合理的重複需求。取得獨特格式是一項起始優勢，而非完整策略。

企業買家面對的是另一種決定。他們需要證據證明協助功能能在自身元件庫及審查實務中表現可預期。吸引人的供應商示範，無法回答有關內部元件、特殊檔案或既有批准規則的所有問題。這些條件應納入買家的評估。

因此，眼前應採取的做法是更清楚界定工作負荷。團隊可在選擇模型或比較產品前，先區分精準修訂與開放式探索。這會產生比「哪個助理最擅長設計」更有資訊價值的問題。答案可因工作而異，並不構成矛盾。

長遠而言，這種壓力有利於理解用戶在生成後把時間花在哪裏的供應商。能減少修正及檢查的產品，具有實際優勢。這種優勢需要在真實工作流程中量度，包括用戶在助理可見回應以外所進行的工作。

強化學習將問題帶入獎勵機制

Figma 表示，基於模仿的訓練遇到泛化及樣本效率限制，因而推動其投資於強化學習環境及由設計師參與制定的獎勵。泛化是指處理陌生案例的能力；樣本效率則描述改進需要多少訓練資料。

改變訓練方法不會消除判斷設計的難題；它只會令這種判斷成為優化目標的一部分。

一項假設性的對齊工作可說明原因。假設助理只要物件具有相同的水平位置便會得分，它可能通過這項檢查，卻在其他位置造成不自然的間距。獎勵捕捉了一項可量度的屬性，但用戶意圖包括該屬性無法表達的關係。

增加更多檢查，只有在這些檢查真正代表所需行為時才有幫助。系統可能驗證文字仍在容器內，卻忽略結果是否感覺擠迫；另一項檢查可能獎勵視覺一致性，卻懲罰有意為之的例外。評估設計必須分辨錯誤與合理選擇。

這與收集成功示範構成不同挑戰。範例展示特定情況下可接受的結果；獎勵則界定引導進一步改進的誘因。模型可以更擅長取得這些獎勵，卻未必改善用戶體驗的每個方面。

因此，核心分析問題在於覆蓋範圍。獎勵是否同時涵蓋所要求的修改，以及應維持不變的內容？它們能否容納不同的有效解法？它們能否辨認技術上正確、但令周邊介面更難使用的修改？

Anthropic 對代理評估的討論，提供了有用的方法學參考。該文說明如何結合基於程式碼的檢查、模型判斷及人工審查，亦區分環境最終狀態與代理對所發生事情的敘述。這種區分直接適用於可編輯成品。

對畫布助理而言，若檔案包含錯誤元件，自信的完成訊息幾乎不能帶來任何保證。文件本身才是結果。評估者應檢查文件，而非把助理的說明當作成功證據。這是進行有意義測試的分析要求，並非對某個特定實作的主張。

當合理的設計師存在分歧時，專家審查尤其重要。獎勵不應悄悄把一種偏好的美學轉化成普遍標準。團隊需要識別哪些準則表達功能要求，哪些反映品味。否則，優化可能收窄可接受設計決定的範圍。

Figma 模型訓練亦提出有關困難範例的問題。更多訓練請求不會自動產生更有意義的變化。若資料集充滿簡單而相似的編輯，不尋常的文件結構便可能代表不足。有用的單位，是模型學會處理的不同失敗情況。

對考慮強化學習的產品團隊而言，含意很具體。在投資優化之前，先判定是否能充分評估成功，以引導優化。訓練迴圈會放大回饋的品質；若回饋獎勵的是不完整版本的工作，它也會放大當中的遺漏。

專門模型仍需要情境及其他模型

Figma 表示，其代理把自家的編輯模型與第三方模型結合，用於處理其他工作。這種安排令此公告成為選擇性專門化的案例，而非要取代所有通用模型。

專門模型的價值，在於能否把界定清楚的工作負荷處理得足夠好，以證明周邊協調成本合理。

路由，即把請求分配至不同模型或工作流程的過程，本身亦涉及決定。一項假設性請求可能同時包括新的插圖，以及對既有版面的修改。系統需要判斷應否拆分工作、選擇較廣泛的模型，還是要求澄清。

在那個階段犯錯，可能會掩蓋任何一個模型的優點。一個精準的編輯模型，可能收到超出其範圍的開放式創意任務；一個通用模型，則可能收到專門模型能更穩定處理的受限操作。分開評估模型，無法揭示產品是否作出了正確選擇。

周邊脈絡同樣重要。模型無法可靠地遵從從未收到的指令。若被選取的元件屬於共用程式庫，這層關係可能影響應採取的合適修改。若助理只看見一段孤立片段，看似合理的變更可能違反更廣泛文件的規則。

因此，脈絡品質是另一項產品責任。訓練改善模型已學得的行為，而脈絡則提供當前任務的資訊。兩者不能互相取代。具備能力的編輯模型即使資訊不完整，仍可能作出不恰當的修改。

這個區別亦延伸至畫布以外的回饋。Figma 對設計系統工作流程的說明，提到 Uber 設計師使用 agent skills 處理元件文件；亦提到 Granola 的 Paavan Buddhdev 透過 connector 將會議回饋帶到畫布上。這些是供應商發布的客戶案例，而非獨立的比較測試。

其相關性在於連結設計工作及其周邊證據。回饋、元件定義及實作要求，有助決定何謂良好的修改。助理必須在執行前取得相關材料，才能在脈絡中判斷其執行表現。

對於管理這類證據的團隊而言，可搜尋的工程知識庫可支援審核流程。兩者的關聯很實際：保留決策背後的理據，讓審核者能據此評估後續變更。更好的檢索與更好的編輯，處理的是同一工作流程中不同環節。

這亦帶來維護層面的含意。模型更新、工具變更及文件格式變動，都可能影響同一項操作。產品團隊需要能偵測原本可靠的任務是否退步的評估機制。強勁的初始結果並不代表持續整合工作可以省略。

因此，專家模型與通用模型的比較應放在系統層面。買方應評估完整工作流程，包括模型選擇、脈絡、執行及審核。專家模型的個別分數仍具參考價值，但產品的實際行為才決定使用者能否體驗到其效益。

內部結果仍留下重要問題

內部評估可支持一項有界限的效能主張；它無法建立普遍排名，也不能解釋每一項產品改善。

持懷疑態度的解讀，應從任務分布開始。一個基準測試，即一組界定好的評估任務，只代表某一部分工作。其效用取決於該部分工作與實際使用情況的關係。若不檢視任務內容，讀者無法知道結果是否可轉移至自己的檔案。

公平比較亦需要可比的輸入及工具。試想：為專家模型提供詳細的文件結構，同時只給另一個模型一張截圖。結果衡量的會是不同資訊存取條件，以及模型能力。這個假設說明，評估條件與標題分數同樣重要。

重複試驗相當重要，因為一次成功嘗試可能誇大可靠性。偶爾能產出出色修改的系統，與持續能產出可接受修改的系統並不相同。買方需要了解評估捕捉的是哪一種行為，也需要看見那些必須人工修復的失敗案例。

視覺評審亦帶來另一重不確定性。關於模型評審偏誤的研究指出，語言模型評估存在位置偏誤、冗長偏誤及自我強化偏誤等限制。該研究涉及不同任務，並不證明 Figma 的系統存在缺陷；它說明了應驗證自動評審，而非假設其保持中立的理由。

對設計評估而言，相應問題是：這些判斷是否與合資格審核者在不同任務類型中的判斷一致。評審對明顯重疊可能可靠，卻未必能可靠處理含糊的層級關係。匯總這些判斷可能掩蓋表現不均。公布分歧情況，會令最終分數更容易解讀。

保留原有內容值得獨立審視。一項修改可以改善被要求處理的區域，卻損害其以外的內容。審核者應檢查所選區域及相關的周邊關係。否則，系統可能因可見的成功而獲得肯定，卻把隱藏的清理工作轉嫁給使用者。

歸因帶來另一項限制。產品行為取決於模型、所提供的脈絡、執行工具，以及它們之間的協調。當多個元件同時改變時，較佳結果並不能分離出訓練所帶來的貢獻。要區分這些效果，需要受控比較，而非假定最新模型造成了全部改善。

數據來源是另一個獨立問題。合成請求是由機器生成的指令；僅憑這個描述，無法說明每項底層設計的來源。讀者不應把「合成」視為對訓練數據權限的完整交代。企業審核需要相關的合約及行政細節。

這些考慮因素都不代表必須否定這項公布。它們只是界定結論的範圍。公開說明描述了一種處理反覆出現的產品問題的合理方法。獨立測試、更清楚的評估條件，以及具代表性的客戶試驗，將能加強其實際優勢的證據。

恰當回應既不是自動認同，也不是一概懷疑。應把報告結果視為調查某項明確工作負載的理由，然後詢問相同方法能否在使用團隊重視的限制下改善成果。

留意遷移能力、部署及客戶修復工作

下一步有用的證據，應探討專門化在哪些地方能在初始評估以外維持表現。在未來數月，讀者可以留意具體披露及產品行為，而無須假設發布時間表。相關訊號涉及遷移能力、部署，以及客戶在完成修改後所做的工作。

最有力的證據，會把較佳的任務表現與在陌生設計系統中較少的檢查及修復工作連結起來。

首先，留意涉及保留程式庫、文件結構或編輯模式的評估。保留範例是指在訓練中排除、用以測試模型處理陌生材料能力的例子。這些任務的結果有助區分較廣泛的能力，與對一小組範例的熟悉程度。

披露內容應說明陌生任務與訓練材料有何不同。不同的提示措辭，所測試的程度遠低於實質不同的文件結構。在具意義的差異之間保持一致表現，會強化專門化的論點；表現急劇下降，則會縮窄值得信賴的工作負載範圍。

其次，留意 agent 的部署邊界如何改變。若伴隨穩定品質及清晰的任務定義，專家模型獲更廣泛使用將具參考價值。單憑較大的部署覆蓋範圍，無法證明表現更佳；還需要證據證明分配的工作仍然適合該模型。

相反訊號同樣重要。若特定編輯類別仍持續依賴通用模型，將有助揭示專家模型的限制。這不會否定該方法，反而會提供有用資訊，說明廣泛能力在哪些地方仍較集中訓練可取。

第三，留意客戶的修復工作。有用的指標包括被拒絕的變更、人工修正、復原工作量，以及核准修改所需時間。這些指標應區分簡單的外觀請求與涉及共用元件的變更。把不相似的任務合併，會令改善幅度難以解讀。

獨立的客戶證據可帶來內部模型比較無法提供的視角。使用自家程式庫的團隊，可以揭露供應商範例中未有呈現的假設。若能在這類環境中持續獲得接受，將加強專門編輯的理據；若持續需要清理，則會削弱其實際價值。

這些訊號亦讓開發者能以有紀律的方式解讀 Figma 的模型訓練。這項公布不要求每間應用程式公司都成為模型實驗室；但它確實促請團隊辨識重複出現的操作：當結構化執行及保留原有內容的重要性足以值得集中投資時，便應予以重視。

在採用畫布助理前，請從自己的工作中選取具代表性的修改，並保留起始檔案。比較不同方案下所要求的變更、非預期修改及審核工作量。請同事在不依賴完成訊息的情況下評估所得文件。保留設計理據，包括元件規則及相關回饋。在有重大產品更新後，重訪相同任務，同時加入反映新工作的陌生案例。對 Figma 編輯模型而言，有用的問題很具體：它能否幫助你的團隊以較少修正完成一項受限修改？以這個問題指引試用，並讓最終檔案決定專門化是否值得擔當更重要的角色。