FigJam 變成 coding agent 的白板：架構圖、ERD、專案規劃靠 MCP 一次串起來

Figma 過去一個月推 MCP 推得很重——use_figma 讓 agent 在 design 檔上動手，workflow lab 給 designer 看 build 浮現的狀態。這次新加進去的，是一塊大家原本不會聯想到的地——FigJam。

文章作者 Caroline Okun 是 Figma 後端工程師，自我介紹寫得很直接：「我從沒碰過 C++ editor、也沒在 Figma Design 上做過任何編輯。」她在 MCP team 的 hackathon 裡做了一件「跨部門 advocate」的事——把 FigJam 變成工程師跟 agent 一起想架構的地方。

她寫的工具今天上線：generate_diagram 出 architecture / ERD、figma-use-figjam 讓 agent 直接讀寫 FigJam board、generate-project-plan 把規劃文件變成可協作的視覺板。三個合起來——第一次有官方產品把 FigJam 放進「agent 寫 code 之前」的位置。

Caroline 在文章開頭講她的工作日常——後端工程師、寫 infrastructure、設計平台架構。完全不是 FigJam 的目標用戶。但她團隊最近的速度加快到讓她不舒服：「My team is shipping faster than ever, building features that would have taken quarters in weeks.」

代價是看不見的——「Every agent-written PR we merge without deep human review adds confusion and hidden complexities to the codebase.」每一個沒被人類深度 review 的 agent PR，都會在 codebase 裡多累積一份隱形的複雜度。

她形容自己是 visual learner，需要把所有變更 zoom out 來看才能掌握。MCP team 的 hackathon 給了她一個機會——把 generate_diagram 工具擴成支援更複雜的 architecture 跟 ERD layout，再讓 agent 直接寫進 FigJam。

這背後有個訊號值得讀者留意：會把 FigJam 排進工作流的，往往不是設計師本人，而是工程師或 PM。設計師早就在用 FigJam 開會、做 workshop；現在工程師看見它能放 agent 畫的圖之後，發現它能補一塊長期沒補的洞。

Caroline 描述她的第一個動作很單純——讓 coding agent 把規劃新功能需要的 context 抓回來。文檔、原始碼、過去的決策、相關的 PR。Agent 跑完之後，產出的是一份 markdown 規劃書，裡頭已經有完整的實作選項。

問題是這份東西「hidden in a wall of markdown」。要把它丟進 Slack 收 feedback，工程師同事不會願意一段一段讀完——大家對著一面文字牆，沒有人想留言。

新的 FigJam 能力解決的就是這個轉換成本。Agent 透過兩個工具把 markdown 規劃書攤開來：

— generate_diagram MCP tool 跟 skill 把架構決策畫成 architecture diagram 跟 ER diagram。
— figma-use-figjam skill 把規劃裡的 note、code block、annotation 直接放上 board。

寫一段 markdown 講 service 之間怎麼呼叫，跟看到一張圖上 service A 連 service B、B 連 cache、cache 又被 worker 命中——資訊量是同一份，但腦子處理的成本差很多。

Caroline 的形容更直接：「the cleanest architectural approach becomes obvious.」當設計被攤開成圖，最乾淨的那條路會自己浮出來。

Caroline 在這一段給了兩個具體的 review 例子，也是這篇文章最有畫面感的細節——「Will this tool support multiple file types, or just design files? Should it accept a folderId, or create all new files inside the user's Drafts folder?」

兩個問題都是純設計決策——多檔案類型 vs 單一類型、用 folderId 參數 vs 預設 Drafts。如果這些討論發生在 PR 已經寫了 600 行 code 之後，改回去等於整段重寫。發生在 FigJam board 上，改的成本是把一張卡片從「多類型」拖到「單類型」、底下加一句註解寫為什麼。

過去這種架構討論會發生在會議室——白板、馬克筆、人都在現場。Caroline 點出 remote-first 之後最大的損失：「We may not all be in the same conference room whiteboarding with a marker anymore.」

FigJam 加上 agent 寫的圖，等於把白板還回來——只是現在白板上的內容是 agent 預先準備好的、有結構的、可以非同步留言的。團隊散落世界各地的時候，這個版本反而比實體白板可重複使用——板會留下、決策會留下、後加入的人能回頭看。

Review 收完之後，Caroline 沒有手動把 FigJam 上的決策抄回 markdown，也沒有截圖丟給 coding agent。她用一個新工具——get_figjam——把整塊 board 抓出來：圖、卡片、留言、決策的最終狀態，全部一次餵回 coding agent。

對比過去的流程：截圖、寫一段「這個方向被否決了，我們改用 X」、再用文字描述每張圖代表什麼。Agent 拿到的 context 一直是經過人類二次轉述的、有資訊遺失的版本。get_figjam 把這層轉述拿掉。

她寫得很乾脆——「By the time I put the PR up (which links to the FigJam with all the design context, of course), it's an easy merge because the architecture has already been reviewed.」PR 上去那一刻，架構審查已經做完了。Reviewer 點 PR 描述裡的 FigJam 連結，就能看到所有決策過程。Merge 的決策變成單純的「code 是否實現了 board 上講好的東西」。

Caroline 在文末強調這三個工具的設計哲學是 building block——「a foundation you can use to support your own development process」。Figma 沒有把工作流綁死，而是把零件分開放。

這三個工具在 Augment、Claude Code、Codex CLI、Copilot CLI、Copilot in VS Code、Cursor、Factory、Kiro、Warp 都能用——也就是說，agent 端不用換、Figma 端拿來當畫布就好。Beta 期間免費，之後會以 paid API 形式收費。

Caroline 的另一個提醒值得讀者記下來——figma-use-figjam 是公開的 skill，可以在它之上做自己的延伸。Figma 也把整個 repository 開到 GitHub 收外部 contribution。換句話說，Figma 沒有把這個工作流關起來自己用——三個工具是 building block，留給你組裝自己的版本。

把這次更新放回 Figma MCP 整年的時間線看：去年是 use_figma（agent 動 design 檔）、上週是 workflow lab（agent 把 build 狀態寫回 canvas）、這週是 FigJam（agent 把架構規劃寫成可協作板）。

三步看下來，Figma 在每個工作流階段都放一個 agent-friendly 的 surface——design、code、planning。FigJam 過去的角色比較模糊，介於白板跟簡報之間，主要場景是 workshop 跟 workshop 後遺留的板。現在它有了一個清楚的工作流位置——agent 寫 code 之前的對齊層。

對設計師讀者最直接的提醒：FigJam 的工作流從這次更新之後會被工程師用得越來越多。如果你過去把 FigJam 當成「設計師專屬的 workshop 工具」，可能要開始把它當成跨部門的設計決策中介層——下次工程師打開 FigJam 給你看架構時，你會更熟悉這個地盤。