設計師 Tech Stack 轉向：從 Figma Handoff 到 Code-based Design 與多 Agent 工作流
原文脈絡
@yvonhuang 觀察到近期越來越多設計師在自己做產品設計時不太使用 Figma。她提到設計師 Ridd 在 Dive Club 影片中展示目前流程：用 Conductor + Paper 在短時間內完成 landing page 修改、產品卡片迭代探索與 prototype 製作。Ridd 也說，六個月前自己的工具與流程幾乎和現在不一樣。
這個觀察背後有兩個趨勢：
new tool、new model、new workflow 不斷出現，設計師需要的核心能力不只是熟練某一套軟體，而是能快速適應新工具，把它接進自己的產品開發流程。
Paper / Pencil 這類 code-based design tool，以及 Conductor 這類多 agent 工作台，把設計探索、程式修改、prototype 與 PR 管理放進同一個工作流，讓傳統 handoff 變薄。
這波 workflow 改變了什麼
| 傳統產品設計流程 | Code-based / Agent-native 流程 | 影響 |
|---|---|---|
| 設計師在 Figma 畫 mockup | 設計師直接在 prototype / 前端環境改 UI | 更早看見真實互動、資料狀態與邊界情境 |
| Figma library 作為設計系統中心 | 元件庫在 code 端維護，再同步或映射到設計工具 | 減少設計系統與實作版本分岔 |
| Handoff 給工程師重做 | 工程師把真實資料與商業邏輯接入既有 prototype | 降低 padding、狀態、動畫、edge case 的落差 |
| 單一工具內手動迭代 | 多 agent / 多 worktree 並行探索 | 速度更快，但 token、版本與品質控管成本升高 |
Conductor + Paper 在討論中的角色
原文補充提到，Conductor 可以同時用多 agent 多工處理，並在同一介面管理不同 worktree、session 與 PR。YC CEO Gary Tan 也展示過 Conductor 內建的 GStack virtual engineering team 模板，包含各種 skills，甚至有 /officehour skill 可用 YC CEO 風格問題拷問產品定位。
價值在於同時協調多個 agent、工作樹、session 與 PR，適合把產品修改拆成多條探索線。但留言也提醒，這類工具可能很容易燒 token；如果沒有公司額度或預算控管，成本會成為限制。
這類工具卡在 design 與 code agent 之間，讓設計師不是只丟 prompt 給 AI，也不是回到純手動畫布，而是能在更接近產品程式的地方做視覺與互動探索。
留言區的實務訊號
這篇留言區很值得收，因為它呈現出設計圈對這個轉向的幾種典型立場。
| 觀點 | 代表留言 | 含義 |
|---|---|---|
| Handoff gap 是核心痛點 | maylogger_designer 認為進入產品 mockup 後若仍在 Figma，最後 dev 肯定有執行落差；更先進的做法是直接設計元件，用假資料在 app / web 前端做互動 prototype。 | Figma 最大問題不是不能設計，而是設計結果常和實作環境分離。 |
| Source of Truth 不再一定是 Figma | yvonhuang 回覆：「設計的 Source of Truth 已不在 Figma 上」。 | 設計資產的權威來源可能轉到 code component、design token、prototype 或 repo。 |
| 設計師開始連元件庫工作 | cha_wang348 說現在用 Claude Code 連自己的元件庫工作。 | 設計師能力邊界往工程與 AI orchestration 擴張。 |
| Figma 仍是團隊協作與探索工具 | yvonhuang 也補充：如果公司團隊要用，就不能關 Figma；自己做還行。 | 個人 side project 可以完全 code-native，團隊環境通常仍需要 shared canvas。 |
| 雙向同步比不用 Figma 更精準 | uiux.taony 認為「程式碼 & 設計雙向同步是趨勢」，說「做產品設計不用 Figma」有點 clickbait，容易誤導新手。 | 重點不是淘汰 Figma，而是設計與程式碼的邊界同步。 |
| 細節微調可能帶來 agent 往返成本 | caibo_design 問：後面要微調細節不會一直跟 agent 來回很多次嗎？ | AI 設計流程的瓶頸可能從 handoff 轉成 prompt iteration 與細節控制。 |
Figma 的反方辯護：Visual Canvas 仍然不可取代
Related threads 中有一段很重要的反方：視覺畫布不會消失，甚至更不可取代。對早期 design exploration 來說，Figma 的強項是能把一個 frame 複製 20 次，散落在無限畫布上，幾秒內比較各種變體；但在 code 裡測試五種 layout，可能要註解、改屬性、管理 state、重新整理瀏覽器，探索阻力更高。
什麼時候用 Figma，什麼時候進 Code？
| 階段 | 更適合的工具 | 原因 |
|---|---|---|
| 品牌視覺探索 | Figma / visual canvas | 需要大量並排比較、自由排版、風格發散與非線性探索。 |
| 早期 wireframe | Figma、Paper、AI wireframe tool 都可 | 重點是快速驗證資訊架構；工具取決於團隊習慣。 |
| 元件化產品 UI | Code-based design + component library | 可直接使用真實元件、狀態、資料與 responsive 行為。 |
| 互動 prototype | 前端 prototype / Storybook / app sandbox | 互動、loading、error、empty state 與 edge case 更接近真實產品。 |
| 設計系統維護 | Code repo + token + linter + Figma sync | 單靠 Figma library 容易腐爛；code 端能以 lint、CI、token 管控一致性。 |
| 團隊評審與對齊 | Figma / FigJam / 文件 + prototype | 跨職能討論仍需要低門檻可視化介面，不一定每個人都能讀 code。 |
對設計師能力模型的影響
過去設計師常以 Figma 熟練度、component library、auto layout、prototype 能力建立優勢；現在更重要的是能組合 AI agent、元件庫、前端環境、設計 token 與驗證流程。
產品設計交付物不再只是畫面，而是能被點、能接資料、能測狀態、能讓工程師直接延伸的 prototype。
設計師與工程師不再只是交接，而是一起維護 component、token、interaction pattern 與產品品質。
對 Allen / BigIntTech 的實務判讀
這篇對內部產品開發很有參考價值，尤其是 BigIntTech 這種 AI agent-heavy、已有多個產品線與前端專案的環境。比較務實的策略不是立刻捨棄 Figma，而是分層：
- 品牌與早期視覺探索：保留 Figma / visual canvas，因為它適合快速比較方向。
- 已有元件庫的產品功能：優先走 code-based prototype，讓 AI agent 直接基於真實元件修改。
- 複雜互動與資料狀態：不要只畫 mockup，直接做前端 sandbox 或 Storybook 狀態矩陣。
- 設計系統：以 code repo / token / CI 作為 source of truth，再同步到 Figma，而不是讓 Figma library 單獨漂移。
- AI agent 多工：Conductor / cmux / Claude Code 類工具適合探索，但要設 token budget、PR review 與視覺回歸檢查，避免快但品質散掉。
結論
設計師不一定要「不用 Figma」，但不能只會 Figma。更精準的趨勢是：
Source: Threads / @yvonhuang