Figma 推出 Plan Access Tokens：企業自動化終於擺脫「離職就斷線」的窘境

Figma 內部架自動化流程的工程師或設計系統團隊，多少都有過這種經歷：某個負責設定 token 的同事離職、帳號停權，下一秒整套 CI 同步、設計系統發布腳本、外部工具串接全部 503。所有靠 Personal Access Token（PAT）撐起來的自動化，本質上都是綁在「某個人的命脈」上，這層脆弱長期被當成行業默契接受。

4 月 23 日 Figma 釋出 Plan Access Tokens（簡稱 PLANTs）的 beta 版本，這個原本只在 enterprise 圈內被反覆抱怨的問題，第一次得到產品層級的解法。Token 不再屬於人，而是綁在 plan（組織方案）本身上。這篇文章把 PLANTs 為什麼重要、跟原本的 PAT 差在哪、對企業設計團隊跟 design ops 的實務影響一次拆清楚。

PLANTs 解決的是「人不在了，自動化也沒了」這件事

要理解 PLANTs 的價值，得先看 PAT 的結構問題。Personal Access Token 是綁定到使用者帳號的憑證——當你用 PAT 串接 Figma REST API 或 MCP server，所有請求都會被歸到那個使用者底下。權限繼承自那個人、計費歸到那個人、稽核紀錄掛在那個人名下。

只要那個人還在公司、帳號還在 active 狀態，整套機制運作得很自然。問題出在人事異動：當建立 token 的工程師離職、被停權、或單純被調離專案，那張 PAT 會一起失效。對外表現是 webhook 突然開始 401、CI pipeline 跑出 forbidden、設計系統的自動化 sync 整個停擺。團隊得花時間找出哪些自動化掛在誰底下，重新申請 token，重新部署環境變數。在大型組織這個成本不小。

PLANTs 把所有權從個人轉移到 plan（你的 Organization 或 Enterprise 方案）。Token 屬於組織本身，不會因為任何單一使用者的帳號狀態而失效。建立 token 的人離職了？沒關係，token 還活著。Admin 才有權限創建跟管理這些 token，所有操作都進稽核日誌。

四個官方點出的改善，背後對應的是企業治理痛點

Figma 的 release notes 把 PLANTs 的好處拆成四點：security and governance、reliability、visibility、higher rate limits。這四個項目看起來像 marketing 排比，但每一條都對應一個實際被反覆抱怨的問題。

Security and governance 對應的是「誰能建 token、誰在用 token」這層原本模糊的權責。在 PAT 模式下，任何 Editor 都能自己生 PAT，組織完全沒有集中控管的入口。PLANTs 把建立權收回 admin 手上，等於把原本散落在每個工程師桌面的 dev token 集中到一個 dashboard 管理。對 SOC 2 / ISO 27001 這類有 access control 要求的組織，這是一個直接可以寫進 audit report 的改善項。

Reliability 對應的是前面提的「人離職自動化就掛掉」。對 design ops、平台團隊來說，這代表他們的 SLA 不再受人事流動影響。

Visibility 對應 audit trail。每張 token 在做什麼、被誰建、訪問了哪些資源，都有清楚紀錄。這跟 Figma 同一天釋出的 Developer Logging 功能（給 Governance+ 客戶用）是組合拳——一個負責 token 治理，一個負責活動稽核。

Higher rate limits 是給高頻自動化的禮物。PAT 的 rate limit 是按使用者算，當你的設計系統 pipeline 一次要對 200 個檔案做 sync，PAT 會撞牆。PLANTs 既然是 plan 層級的憑證，rate limit 也跟著放寬，比較貼近 production 等級的 workload。

對哪些團隊有立即影響？

PLANTs 目前是 Organization 跟 Enterprise plan 的 admin 才能用，所以使用者光譜會很集中。實務上會立刻受惠的是這幾類團隊：

設計系統團隊——維護 design tokens sync、component 自動發布、變更通知。這類流程通常需要長期穩定運行，是 PLANTs 最直接的目標客群。原本綁在某個工程師 PAT 上的 sync script，現在可以遷移到 plan token，不用再因為團隊輪調重新部署。

Design ops / 平台工程——做 Figma → Storybook、Figma → Notion、Figma → 內部設計系統文件站的串接。這些 pipeline 一旦上線就不應該下線，PLANTs 直接解決長期穩定性問題。

第三方 SaaS 整合——像 Zeplin、Supernova 這類設計協作工具，過去要求客戶提供 PAT 才能讀取 Figma 檔案。轉用 PLANTs 後，整合的可靠性跟稽核能力會明顯提升。預期接下來幾個月會看到一輪 SaaS 廠商更新整合方式的公告。

內部 MCP server——Figma 已經把 MCP（Model Context Protocol）拉進官方支援，企業內部跑的 MCP server 如果要長期接 Figma，PLANTs 是更合適的選擇。

不在 Organization 跟 Enterprise plan 的團隊暫時還沒辦法用，依然得靠 PAT。Figma 沒有公布 Professional plan 是否會跟進，但從產品邏輯看，PLANTs 的設計初衷就是給多人組織治理用，下放到個人或小團隊方案的可能性很低。

編輯部觀點：Figma 在偷偷把自己變成基礎設施

從產品策略角度看，PLANTs 是一個訊號比功能本身更重要的更新。把 token 從 user-scoped 升級到 plan-scoped 是 SaaS 平台「成熟」的關鍵指標——這代表平台正式承認自己被當成 production-grade infrastructure 在用，必須處理基礎設施該有的治理問題。

GitHub 走過一樣的路。早期 GitHub 只有 PAT，後來推出 Fine-grained PAT、再推 GitHub Apps，最後才有 Organization-level secrets 跟 OIDC。每一步的觸發點都是「客戶已經把它當基礎設施在用，但它的權限模型還停留在個人開發者時代」。Figma 現在處於同樣的轉折——使用者已經把它當設計系統的 source of truth、把它接進 CI、接進 internal tooling，token 治理問題自然浮上來。

值得注意的是 Figma 沒有把 PLANTs 包裝成「AI 時代的新功能」這種行銷敘事，雖然 MCP 顯然是這次推進 PLANTs 的觸發點之一（同樣 release 提到 MCP activity 也會被 audit log 記錄）。Figma 選擇用「企業治理」的角度切入，避開 AI hype 的包裝，這個語氣處理本身就是專業度的展現。

對設計師來說，PLANTs 看起來離日常工作很遠，但長期影響其實會回到創作端。當 token 治理變得健全，企業會更願意把 Figma 接進關鍵流程；接進去之後，設計師寫的每一筆變更才會自動同步到 production，設計系統才有機會真正做到「single source of truth」。這條路上最容易斷的環節，恰好是 PLANTs 補的這一塊。

怎麼開始用？

目前是 beta，admins 可以到 Organization 或 Enterprise plan 的後台找 Plan Access Tokens 設定頁面建立第一張 token。建議遷移流程是：

第一步先盤點現有的 PAT，把哪些自動化跑在誰的 PAT 上記下來。第二步在 plan 後台建立對應的 PLANTs，每個用途獨立發一張 token，避免共用以便日後 audit 跟 rotate。第三步逐步把現有自動化的環境變數換成 PLANTs，PAT 保留一段時間做 fallback。第四步在 Developer Logs 裡確認新舊 token 的活動是否符合預期，沒問題後就可以撤掉 PAT。

完整 token 規格、API endpoint 對應、scope 設定方式可以在 developers.figma.com 的開發者文件找到。

結語

PLANTs 不會改變設計師打開 Figma 的方式，但會改變企業願意把 Figma 接進多深的流程。這種底層治理的更新通常最容易被忽略，可是當你看到一家 SaaS 開始認真處理 token 生命週期、稽核日誌、rate limit 分層，這代表它已經跨過「工具」變成「基礎設施」的門檻。對設計組織而言，這個更新的意義其實在更遠的地方：當 Figma 變成基礎設施，我們的設計系統流程能不能跟著升級到那個層級。