設計交付已死：Notion 團隊如何讓程式碼取代 Figma 成為設計的唯一真相

本文整理自《Dive Club》2026 年 5 月播出的單集。

{{< youtube IfPK0LwbX_0 >}}

{{< spotify "episode/462BYeBqr20C0hLxPbsoAt" >}}

---

Dive Club 主持人 Ridd 自爆：他現在的 Figma 畫布是整個設計師職涯以來最混亂的。以前他是控制狂，Figma 檔案永遠整齊有序，隨時都是 production 狀態的忠實還原。只要知道某個畫面跟實際產品有出入，他就會焦慮到立刻去更新。

現在？他完全不在乎了。因為設計的 source of truth 已經不在 Figma 裡了。它搬進了生產環境的程式碼。

Figma 變成了參考工具，不再是最終成品

Notion 產品設計師 Andy Madrick 在這集 podcast 裡說了一件讓很多設計師共鳴的事：他的 Figma 檔案現在也非常亂，但他已經跟這件事和解了。他不再執著於維護一個「完美的設計文件」，因為真正的設計工作已經發生在別的地方。

他的日常工作流是這樣的：用 Paper Chrome 擴充功能直接從 Notion 的生產環境複製元件，貼進 Figma 做快速探索。改完之後，成果回到程式碼裡。Figma 在整個流程中的角色，從「設計的唯一來源」退化成了「暫時性的參考工具」。Madrick 甚至提到，Notion 內部有大量的 Figma 檔案，內容其實只是產品的截圖，上面疊了一小塊新的 Figma frame，標示預計要修改的部分。文件不漂亮，但夠用。

這個轉變不只發生在 Notion。Ridd 也描述了類似的經歷。他說以前每當發現 Figma 裡的設計跟生產環境不同步，會立刻去修正，彷彿那是一種職業焦慮的來源。但當設計的真實版本就是線上跑的那個產品，Figma 檔案「不同步」這件事就不再令人焦慮了，因為它本來就只是草稿紙。設計圈長年追求的「dealing with ambiguity」（擁抱模糊），現在真的被迫實踐了。

大功能從 code 開始，小功能留給 Figma

這個 source of truth 的遷移不代表 Figma 被完全拋棄。Madrick 對於何時用 Figma、何時用 code 有一套清楚的判斷框架。

如果是大型的基礎架構重新設計，也就是要重新思考 Notion 某個核心概念的時候，他傾向直接用 LLM 搭建一個粗糙但可以點擊操作的 prototype。原因很直接：讓人「實際操作」一個提案，比讓人「看一張圖」來評估體驗，得到的回饋品質完全不同。功能越大、越複雜，這個差距就越明顯。Figma 的靜態 mockup 無法傳達操作的「手感」，但一個即使很粗糙的可互動原型可以。

但如果是小型的功能修改，像是一個 modal 的視覺微調、某個按鈕的動態效果、或是排版的細節打磨，Madrick 還是傾向在 Figma 裡操作。他的理由帶著設計師的執著：Figma 是「我的手的延伸」，每一個像素都可以直接操控，行為是確定性的，你移動什麼它就移動什麼，不會有 AI 自作主張的意外。對於需要精準控制的視覺工作，這種確定性仍然比 AI 的機率性輸出更可靠。

他的決策規則很好記：功能越大，越可能從 code 開始；功能越小，Figma 還是最好的工具。

AI 當翻譯層：合併設計師的美學和工程師的效能

Madrick 描述了一種新的協作模式，核心概念是讓 AI 扮演「翻譯層」。

典型的情境是這樣的：設計師用 AI 做出一個前端原型，視覺上非常好看，但程式碼品質很差，效能不行，架構不對。同時間，工程師用正規方法把同一個功能建構完成，邏輯完整、效能最佳化，但視覺上還停留在 Madrick 所稱的「T-Move 版本」，就是功能到位但外觀未完成的半成品。

傳統做法是設計師提供 mockup，工程師照著做，或是設計師直接改工程師的前端程式碼。但 Madrick 發現了第三條路：把兩份程式碼同時餵給 AI agent，告訴它「保留工程師版本的所有功能和架構，套上設計師版本的所有樣式」。他說這個做法的效果出乎意料的好。因為 AI 不需要從零理解設計意圖，兩份程式碼都已經擺在那裡了，它只需要做對應和搬移，把正確的 CSS 值套到正確的元素上。

這個翻譯層的概念，也解釋了為什麼 Madrick 用不同的程式碼框架做原型，結果還能一次轉換到生產環境。Notion 的生產環境有自己的技術棧，他的原型用的是 Tailwind 和 shadcn/ui，兩者完全不同。但 LLM 不在乎框架差異，它看的是底層的 CSS 和 JavaScript 邏輯。這就是為什麼他能把一個遊樂場裡的原型資料夾，一次餵給 LLM 就得到可用的生產環境程式碼。

每個專案的協作方式都不一樣了

讓 Madrick 和 Ridd 都很有感觸的一件事是：在這個新的工作模式下，沒有標準流程可言。每次開始一個新專案，設計師都得先搞清楚一件事：這個工程師想怎麼合作？

有些工程師不想碰前端，只想專心優化後端效能。這時候 Madrick 可以自己用 AI 工具搞定大部分前端工作，然後提交小型 PR 請工程師 review。有些工程師前端能力很強也有時間，那合作模式就完全不同：設計師做出一個粗略的原型或 Figma 稿，兩人直接在程式碼裡一起迭代。

Ridd 分享了另一種情境：他在做一個探索性的原型，需要引入一個全新的視覺元素，已經用生產環境程式碼做到了 80%，但剩下的 20% 涉及 schema 層級的修改和後端的 mutator，這些他不想碰也不該碰。結果就是原型有一半用真實資料，一半用假資料，看起來像真的但其實不是。工程師看了會覺得「前端已經很好了，我不想從頭來過」，但實際上底層需要整個重建。這種 sequencing 的問題目前沒有標準答案，每次都得靠當事人自己協調。

Madrick 的態度是接受這個現實。設計師面試時最常被問的能力就是「dealing with ambiguity」，現在這句話有了全新的意義。工作流不再是確定的，你用什麼工具、什麼時候插入、誰負責哪一段程式碼，全部都變成了需要逐案討論的問題。

我的觀察：設計交付之死，本質上是信任結構的重組

「設計交付」這個詞在過去意味著一個清晰的動作：設計師完成設計，打包成 Figma 連結或 Zeplin 標注，交給工程師去實作。這個流程的核心假設是分工明確，你做你的，我做我的，中間有一個明確的交接點。

Madrick 描述的世界完全不是這樣。設計師直接提 PR，工程師 review 設計師的程式碼，AI 在中間做翻譯。交接點消失了，取而代之的是持續的、交織的、高度客製化的協作。每個專案的合作方式都不同，沒有誰固定「先做」或「後做」。

這聽起來很混亂，但其實是一種更健康的協作模式。當設計師提交的不是一張圖而是一段程式碼，他就不再只是在表達「我希望它長這樣」，而是在說「這段程式碼可以上線，我為它負責」。這改變了權力結構：設計師從「提出需求的人」變成了「共同交付的人」。Notion 內部的說法是「own the outcome」，擁有最終成果。當你的名字掛在 PR 上面，你對品質的在意程度會跟只交一張 Figma 圖完全不同。