原文：I design with Claude more than Figma now 作者：Edwin Morris（Jane Street 設計師，Options Desk） 來源：Jane Street Tech Blog 日期：2026-02-05

城武導讀

設計師到底要不要學寫 code？這個爭論已經吵了十年以上。但 Jane Street 的設計師 Edwin Morris 給了這個萬年命題一個意外的答案——不是「要不要學」，而是「現在你不需要會寫 code 也能直接做出能動的產品」。

這篇文章不是那種「AI 要取代設計師了」的恐慌文，也不是「AI 好棒棒什麼都會」的業配文。它就是一個設計師，安靜地坐在螢幕前，誠實地記錄自己的 workflow 是怎麼被 LLM 改變的——從 Figma 重度使用者，變成「打開 Claude 的次數比打開 Figma 還多」。

他任職的公司不是矽谷新創，而是 Jane Street——全球最頂尖的量化交易公司，用的是極度冷門的 OCaml 語言和 Bonsai 框架。一個設計師要在這種技術棧裡「親自做出能動的原型」，在 LLM 出現之前幾乎是天方夜譚。

以下是全文翻譯（城武風，非直譯）加上觀點。

翻譯正文

從 LLM 懷疑論者到不可或缺

有很長一段時間，我對 LLM 是持懷疑態度的——每次試用我都很失望。去年我試了 Copilot 和 Cursor 來修改我做的一款遊戲，兩個都沒產出能動的 code。之前在別的公司，我試過用 Gemini 來寫產品摘要和產生線框圖，結果全部丟進垃圾桶。

每次我嘗試 LLM，都是拿來做我已經很擅長的事——而它做得比我還差。

去年夏天加入 Jane Street 後，我的看法完全變了。這裡有太多我不會的東西：OCaml、Bonsai，全都從零開始。LLM 在這些我不擅長的領域幫了大忙。

但真正讓我意外的是：LLM 徹底改變了我最擅長的事——我的設計工作流程。

新的設計 workflow：從 Figma 到終端機

以前我的設計流程是這樣的：

  1. 寫規格文件
  2. 在 Figma 做 mockup
  3. 寫提案
  4. 跟工程師來回討論實作

現在完全不一樣了：

  1. 寫一段描述問題和提案的文字
  2. 打開編輯器，啟動 Claude，把那段描述當 prompt 丟進去
  3. 做出基本能動的功能，向自己證明它是可行的
  4. 無限迭代，想改多少次就改多少次
  5. 推到開發環境，直接問使用者的意見
  6. 提交一個看起來、動起來都完全符合我想像的 feature

他說：「一個在真實 codebase 裡能動的原型，在幾乎所有方面都比 mockup 和文件更好。」

Claude 給了我什麼

他舉了一個實際案例：他最近做了一個 prototype，在 JSQL（Jane Street 內部的 SQL 方言，用於各種用戶端工具）的輸入框裡加入 LLM prompting 功能。

這個原型真的能動。他花了好幾天跟它相處、實際測試它。

Claude 給了我免費、無限的迭代能力。當我改了第 50 次主意、或要求一個超小的調整時，它完全不會不耐煩。

他調整了 Submit 按鈕、加入鍵盤快捷鍵、改了文案、調整了 prompt、加上確認訊息——這些在以前的公司，每一個小改動都要經過「設計師畫圖 → 工程師實作 → 來回討論」的循環，花上幾天甚至幾週。更可能的是：根本不會被做出來。

所有花在這個功能上的心力，都用在改善「真正會被使用的東西」上，而不是 Figma 元件、排版文件這些中間產物。

從 Figma 掉下懸崖

他不是一到 Jane Street 就變成這樣的。剛加入的時候，他只敢用 AI 處理小任務——UI 的小修小補。大一點的想法，他還是回到 Figma 和文件。那時候用 Claude 做大東西會失敗。

但過去兩個月，他打開 Figma 的次數「掉下了懸崖」。

原因有三個：模型變強了、他自己用 AI 的技巧進步了、他學會了為 AI 選擇適當的範圍。

現在他已經用 AI 做了六個以上的原型，包含修改用戶介面、資料模型、甚至函式庫——有些改動超過 2,000 行程式碼差異。有些新 app，他甚至完全跳過 Figma，從視覺設計的第一步就在 Claude 裡迭代。

設計師的被解放

作為一個設計師，這件事給了我巨大的力量。工程師有一個想法的時候，可以直接做出一個能動的概念驗證。設計師沒有這個能力——我們必須說服別人幫我們做。

以「在 JSQL 輸入框裡加入 LLM prompting」這個點子來說，如果照傳統流程，他需要先說服某個工程師：「這個點子可行嗎？有可能浪費你的時間嗎？不確定的話，你要不要先試試看？」

現在他直接用 Claude 做出來，讓別人可以直接「用用看」來評估這個點子，而不是「聽我描述再想像」。

新 workflow 的代價：code review 變難了

但這套流程不是沒有缺點。

當你直接把一個「功能齊全的原型」丟到工程師面前，工程師的角色就從「共同設計者」變成了「code reviewer」——只能審查程式碼，對功能本身沒有參與感。

Review 不是最有樂趣的工作。在設計圈，這就像 PM 給你一份超詳細的線框圖，然後說「把它弄好看」——你沒有創造的空間。

Edwin 的解法是：在提交描述中明確寫上——「這份 code 是拋棄式的，原型本身就是一個活的提案文件。Reviewer 的任務不是審查 code，而是對設計和使用者體驗給出回饋。」

最終，工程師還是會接手這個點子，用一個全新的 feature 來實作，參考原型但完全掌控 production code。

老實說，我們還在摸索——這個新 workflow 到底怎樣做才合理、才舒服。

另一個恐懼：創意的邊界被限縮

還有一個他擔心的事：用 Claude 設計，會不會讓我一直待在「迭代優化」的心態裡，而不是「流暢、發散、創意爆發」的心態？

對成熟的產品來說，迭代就夠了。但對全新的東西，如果我只在「Claude 能產出的範圍內」想點子，我可能會錯過真正突破性的想法。

這個恐懼，很熟悉。

回到原點：設計師寫 code 的萬年爭論

2011 年他剛入行的時候，設計圈正在吵「設計師要不要寫 code」。

反對派說：一旦你開始寫程式，你就不太可能對一個點子做出大規模的改變——你會被實作細節綁住思考。

但他就是喜歡做網站，就是喜歡寫程式。所以他繼續寫。

然後 React 出現了。前端開發突然變得超級複雜。像很多人一樣，他選擇了專業化——不再碰 code，把幾乎所有工作時間都花在 Figma 和文件上。他還是會用 React 做個人專案，這幫助他跟工程師溝通，但僅此而已。

如果我是在 LLM 出現之前加入 Jane Street，我想我會在 Figma 裡陷得更深。JavaScript 我至少還有經驗，但 OCaml 和 Bonsai 是完全陌生的東西——在技術層面上貢獻，根本是想都不敢想的事。

但現在，他回來了。

我重新回到「做真正的東西」的狀態。在媒介本身裡面工作的感覺太棒了。我從來沒有覺得自己這麼自由——就是去試，去做出來。

城武觀點

1. 這不是「取代」，是「回到原點」

這篇文章最觸動我的不是「AI 讓設計師更有生產力」這種老生常談，而是 Edwin 說的最後一句話：「我重新回到在媒介本身裡面工作的狀態。」

他從 2011 年就喜歡寫 code，但 React 時代的前端複雜度把他推離了那個媒介，逼他退到 Figma——一個「描述最終產出物」的工具，而不是「直接操作最終產出物」的工具。LLM 不是給了他新能力——是還給了他本來就有、但被技術門檻奪走的能力。

城武覺得，這是 LLM 最被低估的價值。它不是讓你做你不會的事，是讓你重新能做你本來會、但被環境逼到不能做的事。

2. 創意工作的「中間產物」正在消失

Edwin 說了一句讓所有設計師都應該停下來想三秒的話：

所有花在這個功能上的心力，都用在改善「真正會被使用的東西」上，而不是 Figma 元件、排版文件這些中間產物。

Figma、文件、提案、規格書——這些都是為了「讓別人理解並實作你的想法」而生的中間產物。如果你的想法可以直接變成能動的東西，那這些中間產物的價值是多少？

當然，協作還是需要的。但協作的載體可以從「描述性的文件」變成「可以互動的原型」——而後者的溝通效率，城武敢說，至少是前者的十倍。

3. 設計師的談判權力正在重組

這篇文章裡有一個極度低調但極度重要的觀察：

工程師有一個想法的時候，可以直接做出一個能動的概念驗證。設計師沒有這個能力——我們必須說服別人幫我們做。

在傳統的產品開發流程裡，設計師和工程師之間存在一個根本的權力不對等：誰能「讓想法變真實」，誰就擁有話語權。 工程師可以自己做 prototype 來證明一個點子可行；設計師只能畫圖，然後祈禱有人願意幫他實作。

LLM 正在打破這個不對等。當設計師可以自己做出能動的原型，「說服」的門砍從「相信我，這個點子會很棒」變成了「你自己用用看」。這個轉變對設計師職涯的影響，城武覺得，可能比任何 AI 繪圖工具都更深遠。

4. OCaml 這個細節不能忽略

Edwin 任職的公司是 Jane Street，一家以 OCaml 為主要語言的量化交易公司。OCaml 是一個極度冷門的語言，Bonsai 是 Jane Street 內部的前端框架，外部幾乎沒有教學資源。

一個設計師，在這種技術棧底下，可以獨立做出超過 2,000 行 diff 的功能原型。

這不是「AI 幫我寫了一點 CSS」，這是「AI 讓一個不懂冷門語言的人，在一個極度專業的環境裡，成為一個可以直接貢獻 production 等級程式碼的人」。城武認為，這個意義遠大於任何 benchmark 數字。

5. 最後一個問題：誰來守護創意的邊界？

Edwin 自己提出了這個擔憂：用 Claude 設計，會不會讓我一直待在「Claude 能產出的範圍內」思考？

這是一個真實的風險。LLM 天生是收斂的——它會給你最有可能的答案，而不是最瘋狂的答案。如果你過度依賴它來發想，你可能永遠停在 local maximum。

但城武覺得，這個風險不是 LLM 獨有的。Figma 的元件庫、設計系統、best practice——這些東西也在限縮你的創意邊界。好的設計師本來就應該在「收斂的工具」和「發散的思考」之間來回切換。LLM 只是多了一個需要管理的工具，不是多了一個本質上不同的問題。

城武的未解檔案——最好的工具不是讓你做更多，是讓你重新做你本來就會的事。