Agent 很會加東西。你的工作是刪掉。

Here's my advice for engineers looking to up their design game.

前 Figma、Palantir 的工程師 Matt Dailey 前陣子在 X 上丟了一篇長文 How I Design with AI。副標寫得很直白：As an engineer who is not a designer and hates slop.

我第一反應不是「工程師也開始教設計了」，而是鬆了一口氣。因為他講的，其實不是怎麼讓 AI 生出漂亮畫面，而是怎麼不讓產品變成一坨看起來像樣、用起來卻很空的東西。

開頭那句更狠：

Every landing page, app and TUI look the same. They're slop and most of them are incomprehensible.

這句話我最近幾乎每天都會碰到。不是因為模型不夠強，而是因為生成太容易了。誰都能做出「有按鈕、有卡片、有一點陰影」的第一版。難的是：這個第一版值不值得留下來。

⸻

▍先決定約束，不要打地鼠

Matt 把設計過程收成三步，來源是 Christopher Alexander 的 Notes on the Synthesis of Form：

1. 先把你正在設計的約束全部列出來。
2. 再看有哪些解法能同時滿足這些約束。
3. 如果發現要加一條、或可以拿掉一條，就回到第一步。

真正容易出事的，是跳過第三步，開始打地鼠。使用者搞不懂某個地方，就立刻 prompt：「把 X 做得更明顯」、「加一個做 Y 的入口」。AI 很愛這種指令，因為它本來就很會加東西。加完之後，畫面更滿，使用者更不知道該看哪裡。

The temptation is to spot-fix but that road leads to ruin.

這句我自己也中過。尤其是資訊很多、空間很小的地方，例如 sidebar。看到一個 papercut，手就癢，想當場補一個 icon、加一行說明。單獨看都合理，合在一起就變成一張誰的優先序都不清楚的拼布。

他們的做法很土，但我喜歡：明顯的問題立刻修；小的 papercut 先記在一份清單裡。等真的要 redesign，再一次處理。重點不是反應慢，是不要為了看起來有在做事，再製造下一輪 mess。

❖ 收到 feedback 時，先問這件事有沒有改到你的約束。沒有的話，先不要跳進去做解法。

⸻

▍Agent 的天性是加法。設計的工作是減法。

整篇文章我記得最清楚的，是這句：

Agents love to add stuff. Your job is to remove the unnecessary parts.

寫 code 的人其實早就看過同一套習慣：多包一層 try-catch、同一個 utility 重寫三次、belt-and-suspenders。放到 UI 上一樣——多一段 copy、多一條線、多一個沒人會點的 icon。做出來的東西，往往比工程師手畫的好看，但仍然是一種壞設計：資訊變多了，決定沒有變清楚。

最簡單的檢查，是對畫面上每一個元素問一次：我真的需要這個嗎？答案是否定的，就刪。

前陣子寫 Ian Silber 訪談時，我記過一句 Just do less。兩邊講的其實是同一件事。產出變便宜之後，稀缺的不再是「再多一個版本」，而是有人願意把不必要的東西拿掉。

AI 可以幫你生出四個方向。它不會替你決定哪三個該進垃圾桶。

⸻

▍Prototype gravity 才是安靜的殺手

這篇裡有一個詞，我覺得設計師現在也該收進自己的詞庫：prototype gravity。

Prototype gravity is the silent killer.

意思是：你讓 agent 直接在真實 codebase 裡做出第一版之後，後面就很難再探索別的方向。不是因為那一版已經很好，而是因為它已經長在產品上了。改它，好像比重想更省事。Agent 也會被帶著走——它開始為了接上現有結構而設計，而不是為了問題本身。

所以 Matt 的建議很硬：不要在產品裡 iterate 設計。回到一個能細修、能快速試、不必帶著整份 codebase 上下文的工具。Figma 仍然是他心裡的 GOAT；Cursor Design Mode、Claude Design、甚至一份 HTML prototype 也可以。重點是：這是設計工具，不是實作現場。而且每次都叫 AI 生 3 到 4 個 variants，不要問它「最佳答案是什麼」。

這跟我前陣子寫給設計師的 Git 筆記，其實是同一條路上的兩個坑。Git 讓 coded prototype 變得可以被分享；prototype gravity 提醒你：可跑的第一版，很容易偽裝成已經決定的方向。

❖ 第一版能跑，不代表第一版值得留。能分享的 Preview URL，也不等於已經選好了。

⸻

▍工程師缺的不是感覺，是解法圖書館

Matt 後半段講 component、preview deploy、還有一句很工程師的話：Steal stuff。多數 UX 問題其實已經被解決過，你該做的是去看類似產品怎麼處理，把截圖收成 agent 的 context。他說每個真正厲害的設計師，專案一開始都在做這件事。

這我同意。Moodboard 不是氣氛小組作業，是在借別人已經付過學費的判斷。

但整篇最老實的一句，可能是這段：

Product engineers are excellent at identifying when a design doesn't work but have a hard time knowing how to fix it.

工程師很會看出「這不對」。缺的是解法圖書館：看過夠多、試過夠多，才知道不對的時候可以往哪裡改。Matt 把這件事叫做 taste。不是 Brooklyn loft 裡那種神秘氣質，只是你對自己反應的反省，加上夠多次重來。

他們公司沒有全職設計師，所以用一種很農業的辦法：把一版設計丟到中間，大家輪流打，直到覺得可以。聽起來粗魯，但其實很誠實。品味不是一次選對，是一輪一輪把 slop 打掉。

⸻

▍那設計師還剩什麼？

這篇是寫給工程師的。我反而覺得設計師更該看。

不是因為我們要去糾正工程師「你看，設計沒那麼簡單」。而是因為 AI 讓「做出第一版」這件事，已經不再專屬於任何一個角色。接下來真正分開人的，會是誰負責定約束、誰負責刪、誰能看出第一版只是重力、誰的解法圖書館夠用。

這些本來就是設計工作。只是以前它們藏在 Figma 檔和評稿會議裡，現在被一個討厭 slop 的工程師，用更直白的句子講出來了。

所以如果你也開始跟 agent 一起做畫面，我自己會先記住這幾件：

第一，先寫約束，再生成。不要讓「把 X 做得更明顯」變成預設指令。 第二，把刪當成正式步驟。Agent 交出來的第一版，預設是太多，不是剛好。 第三，設計的探索放在設計工具裡。真實 codebase 是驗證場，不是草稿本。 第四，截圖、component、preview deploy，都是為了讓人用真實資料做判斷。不是為了更快把東西合併回去。 第五，taste 沒有捷徑。就是看、試、打、再看。

工具會一直變。Slop 的形狀也會一直變。暫時還沒被外包掉的，大概還是同一件事：你知不知道什麼不該留下。

⸻

❖ 【Asset】跟 AI 一起設計時，先問這五句

• [ ] 我現在的約束是什麼？這次 feedback 有沒有改到它們？
• [ ] 畫面上每一個元素，我真的需要嗎？
• [ ] 我是在探索，還是已經被第一版的 prototype gravity 吸住了？
• [ ] 這次有沒有生過 3 到 4 個 variants，還是只在同一條路上修？
• [ ] 我是在解決問題，還是只是把 slop 擦得更亮？

來源：How I Design with AI.，Matt Dailey（@reactiverobot），2026 年 8 月 26 日。全文也收在 Ref 的 blog。