一個資料夾餵進 LLM 就上線了：Notion 設計師的 AI 前端實戰

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

{{< youtube IfPK0LwbX_0 >}}

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

---

Andy Madrick 把原型遊樂場裡的整個資料夾丟進 LLM，跟它說「讓這個在生產環境跑起來」，結果一次就成功了。動畫完美、程式碼零修改。他和工程師 Rob 看著成果，兩個人同時冒出同一句話：這也太扯了。

Madrick 是 Notion 的產品設計師，負責 AI Meeting Notes 的設計工作。他不是工程師出身，過去做過景觀建築，後來到華盛頓大學念了互動設計碩士。但現在他每天做的事包括寫前端程式碼、提交 PR、和工程師一起看 diff。這個轉變不是因為他苦練了三年 JavaScript，而是因為 AI 工具讓「設計師直接碰程式碼」這件事，從理論上的可能變成了日常操作。

用原型遊樂場取代 Figma 連結

Notion 每年舉辦 Make with Notion 大會，會場上公布的新功能會透過一個高曝光的 modal（彈出式介面）來呈現。這個 modal 的設計很受重視，執行長趙翼丞（Ivan Zhao）會親自參與。Madrick 進 Notion 才一個月就接下了這個任務，整個過程中他每天跟趙翼丞直接對接。

他的起點很傳統：在 Figma 裡做了一大堆版本的 mockup，嘗試各種構圖和視覺方向。但接下來就脫離了一般流程。他沒有把 Figma 連結丟到 Slack 讓大家看圖給意見，而是把這些設計搬進了 Notion 內部的「原型遊樂場」（prototype playground），一個輕量版的 Notion 程式碼庫。每個版本都有獨立的 URL，任何人點開就能直接操作，不用學 Figma，不用裝任何東西。

更聰明的是他在原型上加了一層互動編輯功能。用 Cursor 的 Composer，他做了一組文字輸入欄位，直接連動畫面上的內容。同事可以改標題、換區塊名稱、調整呈現的功能數量，然後截圖回傳。有點像 iPhone 主畫面的自訂功能：你可以拖來拖去、隨意排列，但底層的設計框架和視覺規範還是設計師定義好的。

這個做法解決了一個實際問題：Dive Club 主持人 Ridd 提到，他認識的設計師正在為此苦惱，因為以前在 Figma 裡，內容設計師可以直接點進去改文字，但轉到 code 之後，他們就失去了在「真正的介面脈絡」中調整文案的能力。Madrick 的原型遊樂場把這個能力還了回來。

動畫設計的秘訣：截圖比文字描述有效十倍

Madrick 在動畫設計上有一個核心心得，也是他在這集 podcast 裡反覆強調的：不要用文字告訴 LLM 你想要什麼動態效果，用截圖。

他早期嘗試過用純文字描述動畫邏輯，像是「我要這個角色往右移動、縮小、淡出，然後另一個元素從左邊進來」。結果就是跟 AI 來回拉扯好幾個小時，不斷繞圈子，改了又改，最後改回原點。後來他換了方法：在 Figma 裡畫出關鍵影格（keyframes），標註每個元素在不同狀態下的位置、大小和移動方向，截圖後直接餵給 Composer。電腦視覺模型讀圖的理解能力遠超過解析一段描述動態效果的文字，這是他踩過坑之後得出的結論。

他的標注非常細緻。每一個影格都有編號和狀態標籤，箭頭標示移動方向，旁邊寫著「State 1」「State 2」「Final Position」。這不是一次就完美的過程，但 AI 回傳的初步結果已經夠接近，後續只需微調而不是從頭來過。他的形容是：動畫設計這種事，AI 工具的執行能力其實很強，但你必須非常精準地描述你要什麼，否則就等著拉扯好幾個小時。

最讓他驚訝的是原型轉生產環境的那一步。Notion 的生產環境不用 Tailwind 也不用 shadcn/ui，但他的原型遊樂場兩套都用了。他把整個資料夾餵給 LLM，要求轉換成生產環境格式，結果一次成功，動畫完整保留，CSS 樣式正確對應。他認為原因很單純：說到底就是 CSS 和 JavaScript，而 Claude 跟 Composer 在前端領域特別強。

設計師的 PR 紀律：100 行以內，自己能解釋每一行

Madrick 對想用 AI 寫程式碼的設計師有一個很務實的建議：你的 PR 要非常小。

他的原則是這樣的：如果你期望 reviewer 花在讀 PR 上的時間，比你自己花在做這個 PR 的時間還多，那中間就有嚴重的不對等。一個不是工程師出身的設計師，用 AI 工具生成了 500 行 diff，自己沒有逐行看過，然後丟給工程師 review。結果就是一場尷尬的對話。工程師問「這段邏輯為什麼這樣寫」，你答不出來，因為你也不知道。Madrick 說他自己也踩過這個坑，這些教訓都是實戰得來的。

他建議的目標是 100 行以內。流程是這樣的：讓 LLM 做完改動，拿到你滿意的結果，然後仔細看 diff。它改了什麼？為什麼改？改動合不合理？當你能解釋每一行，提交出去的 PR 就會非常乾淨。工程師掃一眼，確認不會炸掉系統，蓋章通過，出門。沒有多餘的來回，沒有「你能不能解釋一下這段」的尷尬場面。五行 PR 當然不太實際，但一百行的 PR，只要你真的理解內容，對工程師來說就是快速確認的事。

Dive Club 主持人 Ridd 也分享了類似的經驗：他送出過一些 PR，工程師回覆的不是「這段要改」，而是「你建構這個功能的根本前提就是錯的，我為什麼要看程式碼 diff？」這讓他開始在提 PR 之前先用 AI 的 plan mode 產出一個 Markdown 計畫書，讓工程師先 review 方向，確認架構正確之後再寫程式碼。審查的重點從「程式碼對不對」轉移到了「計畫合不合理」。

我的觀察：AI 給了設計師寫 code 的能力，但真正的門檻是紀律

這集 podcast 最讓我有感的不是技術細節，而是 Madrick 對紀律的反覆強調。AI 工具讓任何人都能產出程式碼，但「能產出」和「能負責任地產出」完全是兩回事。

他提到的 100 行 PR 原則，表面上在講程式碼管理，其實在講一種工作倫理：你不能把自己不理解的東西丟給別人處理。這個道理適用於所有 AI 輔助的工作場景，不只是設計師寫前端。當 AI 能幫你產出任何東西，品質把關的責任就完全落在你身上。

Madrick 的職稱只是「設計師」，不是「設計工程師」，但他做的事已經跨越了傳統的職稱分界。他自己也說了：這些頭銜正在瓦解。我覺得他說對了。在 AI 工具夠成熟的團隊裡，區分「設計師」和「工程師」的意義越來越小。真正重要的問題只有一個：你能不能為你交出去的東西負全責？Madrick 的原話是，我們再也沒有藉口不為自己想看到的改變承擔責任。這句話聽起來像雞湯，但放在「設計師現在可以直接提 PR」的脈絡裡，它是非常具體的。