Figma 編輯模型研究公開：AI 改設計時，為什麼「保留原稿」比重畫更難？
已有設計系統的團隊值得試局部修改，先用保留條件和可驗收任務評估，不用內部榜單推定所有設計都能交給AI。
Figma 編輯模型的新研究，碰到設計工作裡很日常的困難：你只想把卡片的標籤移一下，AI 卻可能順便改掉原本已經確認的排版。
因為一張完成中的設計，有許多沒有寫進提示詞的決定。字級、間距與元件來源都可能已經定案，只看最後一張圖漂不漂亮，無法判斷這次修改是否成功。
Figma 在 10 月 29 日公開的研究，解釋它如何訓練懂原生設計檔的專用模型，處理既有畫布上的修改。研究也區分目前代理使用的模型，以及還沒有發布的新版評測結果。
這個差別會影響讀者怎麼看新聞。公司展示的內部測試，能說明研發方向，但我們無法把它直接當成每個帳號今天都能得到的能力。
對已有品牌元件與畫面規則的設計團隊，值得嘗試的是範圍明確的修改任務。先把要改的內容、要保留的決定與驗收方式說清楚，才看得出 AI 有沒有減少返工。
從官方的局部編輯範例開始，比較容易理解「能生成一張圖」與「能接著你的設計工作」之間的距離。
Figma 編輯模型先處理既有畫布上的小修改
局部修改的價值，來自延續已經做好的決定。設計師交給 AI 的原稿，通常已經包含品牌色、按鈕樣式與閱讀順序，後續工作要接著這些決定走。
例如官文展示一張室內空間卡片，要求在照片左上方加入位置標籤。這個任務看似簡單，但要同時顧到標籤對齊、文字可讀，以及其餘內容保持原樣，才算完成。
如果 AI 加上標籤，卻把旁邊的箭頭移走，設計師仍要回頭修復。生成速度再快，也可能把工作轉成逐項找出額外改動，因此局部任務需要有明確邊界。
Figma 的研究公告說明，團隊用原生檔案格式表示設計，讓模型學習能套回畫布的變更。這和產出一張看起來相似的平面圖片，處理的是不同工作。
能繼續編輯，為什麼會影響交接？
原生設計檔保留物件與樣式之間的關係。假設按鈕原本來自共用元件，團隊在意的會是它是否仍連到同一套規則，不能只靠截圖判斷。
元件可以想成重複使用的設計零件。團隊把按鈕做成共用元件後，其他頁面能沿用它。若 AI 只畫出外觀一樣的替代品，後續集中更新可能就接不上。
這也解釋了為什麼「做一個更漂亮的版本」不適合當修稿要求。它沒有說清楚哪些內容已經定案，AI 就缺少保留既有關係的判斷依據。
對讀者而言，這次研究提供的實用提醒，是把設計修改當成有前提的工作。把前提留下來，才有辦法判斷一次變更有沒有減少原本的工作量。
既然修改需要保留上下文，評估結果也得分開看。
漂亮的畫面，仍可能沒有完成你的要求
驗收設計要同時看畫面、結構與指令是否完成。Figma 在官方研究裡也把這些面向分開，並由專業設計師校準評估結果。
畫面這一層，會檢查文字重疊、物件被裁切或對比不足。它直接影響使用者能不能看懂內容，通常也是看截圖最容易發現的部分。
結構這一層，則要確認修改後仍保留正確的設計關係。兩個按鈕看起來一樣，其中一個可能是既有元件，另一個卻是臨時畫出的形狀，後續維護成本會不同。
完成指令又是另一件事。要求把標籤放在照片左上角，結果放在整張卡片左上角，即使對齊很整齊，也沒有完成原本的要求。
把「看起來可以」改成可檢查的條件
假設你正在做課程頁，可以把這次任務限定為「修正行動版價格卡的文字重疊」。完成標準包含價格完整顯示、按鈕可讀，以及桌面版維持原稿。
這份標準讓檢查有順序。先看指定問題是否消失，再看需要保留的區域是否改動，最後確認共用元件與樣式仍然可編輯。
如果任務一次包含換品牌色、調整價格、重做版型與補插圖，結果變好或變差都很難拆解。把修改分開，能讓每次驗收回答一個清楚的問題。
團隊也可以保留失敗案例。像是標籤加對了卻遮住照片主體，就記下原稿、要求與實際結果，作為調整任務寫法的依據。
把驗收條件寫成工作要求，才有辦法交給代理執行。
把修改範圍寫清楚，提示詞就能直接拿來用
一個可執行的修改請求，要交代範圍、保留條件與完成標準。以下是可以自行改用的任務寫法，屬於本文整理的方法，並非官方保證成功的提示詞。
範例：在既有商品卡加入標籤
「請只修改選取的商品卡，在商品照片左上方加入『新品』標籤。沿用目前檔案的標籤元件與文字樣式，保留商品名稱、價格、照片裁切及右上角收藏按鈕的位置。」
接著補上驗收：「完成後列出改動的物件，指出是否用了既有元件。若找不到對應元件，先告知缺少什麼，不要自行建立外觀相似的替代品。」
這樣寫會把設計決策留給團隊，也讓 AI 知道缺資料時應該停在哪裡。它仍可能做錯，但錯誤會比較容易被辨認，不必事後猜測改動原因。
如果原稿沒有共用元件，可以改成先提出樣式建議，再由人選定。把「提出建議」與「直接修改」分成兩次任務，可以減少尚未確認的決定進入正式稿。
範例：把審稿回饋轉成一次修正
「請檢查選取的行動版畫面，修正標題與價格區域的重疊。保留文字內容、按鈕文字與桌面版版型。若需要縮小字級，先提出修改範圍與理由，等我確認後再套用。」
這份要求把使用者問題放在前面，AI 才知道修改的目的。相較之下，「調整成更現代的風格」缺少可驗收條件，往往會引入更多未要求的變更。
官方的產品設計師使用案例提供不同團隊如何分配工作的背景。讀案例時，可以留意他們交給代理的任務範圍，不必照搬整套流程。
若團隊還在整理設計與文字規格的共同背景，可以接著了解把需求留在可共編文件裡的做法。
延伸閱讀：Figma Specs 開放 Beta：把 Markdown、設計與 AI 代理接成共同規格
有了清楚任務，才能分辨模型改善與工作流程改善。
官方評測能說明什麼，還不能保證什麼
這次研究顯示專用模型的發展方向，產品效果仍要看完整代理。Figma 在文章裡明確區分現有產品和研究中的新版，閱讀評測時要保留這條界線。
官文的模型比較圖，包含尚未發布的新版編輯模型。因此，不能看到圖表分數，就推定自己的帳號已經使用相同版本，或把分數直接套到所有設計工作。
目前代理會依工作使用自家的編輯模型與第三方模型。修既有設計、產生圖片和探索新構圖，可能走不同處理方式，因此整體體驗也受到工具與上下文影響。
團隊比較時，把返工時間也算進去
評估一項設計功能時，可以記錄從下指令到完成驗收的時間。若只計算畫面出現的速度，會漏掉檢查額外變更、恢復原稿與重做的時間。
比較也要用相近的任務。今天讓 AI 加一個標籤，明天讓它重做整頁，兩次耗時無法直接說明品質提升。用同一張卡片與同一份標準，會比較有參考價值。
可以把結果分成「直接通過」、「人工小修」與「需要重做」。這些分類不用很複雜，重點是團隊知道哪些工作可以放心交出去，哪些仍需要逐步確認。
如果多數時間花在找回被改掉的內容，改善提示詞的保留條件會比追求更大的任務有效。等小修改穩定後，再增加範圍，才能辨認問題從哪一步出現。
需求改了，怎麼保留每次修改的理由？
修稿常會遇到兩種不同變化。一種是原本要求沒有做好，另一種是團隊看過結果後改變需求。把兩者混在一起，容易錯估工具的工作品質。
例如原本要求標籤放在左上角，AI 放錯位置，這是執行問題。但如果已依要求完成，品牌負責人後來決定放在右上角，則是需求改變，應留下新的修改理由。
團隊可以先在任務裡寫出原本目標，通過後再開下一次修改。這樣累積的紀錄，能讓人理解成品為何變成現在的樣子，也方便之後恢復特定決定。
對設計師而言，這會減少一種常見困擾：修改越來越多，最後卻沒人記得哪個版本是核准方向。將已通過的內容和仍在探索的內容分開，AI 也比較容易取得一致的工作背景。
若同一張卡片有桌面與行動版，可以先指明這次只處理哪個版本。完成後再用另一個版本核對共用內容，避免只因文字相同就推定版型也能直接沿用。
驗收者也可以記錄退回的原因類型。像是位置不符、元件不符、額外改動或資訊缺少，這些分類會讓後續調整更有方向，無須每次從頭猜測。
當問題是資訊缺少，就補設計背景。當問題是範圍太大，就縮小任務。如果規則清楚仍反覆出錯，再考慮改成人工處理。這樣能把採用判斷建立在具體工作上。
最後，保留未使用的提案理由也有幫助。它讓之後接手的人知道某個方向已經被比較過，避免代理或新同事重新提出同一個不適合的做法。
這些紀錄不用寫成冗長報告。一個任務、一次結果、一句驗收原因，就足以讓小修改逐步累積成可參考的工作經驗。
團隊採用時，可以用同一份原稿與檢查表建立自己的比較。
Figma 編輯模型常見問題
這次研究等於推出一個全新的模型選項嗎？
不能這樣理解。官方公開的是訓練與評估方法，並說明現有代理使用專用模型。比較圖中的新版仍未發布。實際可用能力要以產品提供的版本為準。
新手沒有設計系統，還能用局部修改嗎？
可以先用一張已有基本樣式的畫面練習，並把希望保留的文字、位置與配色寫清楚。共用元件能讓規則更一致，但不需要等到整套制度完成才開始整理修改要求。
能把整份設計交給 AI 一次修完嗎？
範圍越大，驗收越難。若目的是減少返工，先選一個可以明確檢查的問題，確認處理品質後再擴大，通常更容易知道工具是否適合自己的工作。
結語：先讓 AI 完成一個能驗收的修改
已有設計規則的人，可以從局部修稿開始評估 Figma。這次研究最值得帶走的觀念，是讓 AI 接續既有決定，同時留下能讓人檢查的修改範圍。
如果你還在探索整體風格，可以先把提案和正式改稿分開。風格提案容許較多變化，正式修改則需要清楚保留已確認的內容，兩種任務的驗收方式也不同。
現在就挑一張原稿，寫下要改的一件事、要保留的決定，以及完成後要檢查的位置。等你能說出結果為什麼通過或退回，這次嘗試才會變成後續可沿用的工作方法。
