How I Design with AI.（我如何用 AI 做設計）
原始來源與檔名：2026-08-28T094041+0800-How I Design with AI..md
SOURCE | 資訊源評估
- 準確性：中 - 這是 @reactiverobot（Ref 團隊工程師）發表於 X 的長推文串，屬作者直接的實務經驗分享，引用了 Christopher Alexander 的經典設計理論著作，立場清晰；但所有主張（如「AI 加劇打地鼠式設計」）皆為個人觀察，無量化數據佐證
- 易理解性：高 - 七條原則各自獨立、編號清楚，每條都附具體實踐做法（papercut 文件、/showcase 頁、前後端 PR 分離），推文體短句直白
- 閱讀策略建議：先讀餐巾紙與骨架掌握七原則的全貌邏輯，再精讀第 1、3、7 條（約束驅動、prototype gravity、品味培養）——這三條是心法，其餘四條是手法；若你在團隊推行，直接把「約束清單 + papercut 文件 + preview deploy」三個實踐搬進工作流
NAPKIN | 餐巾紙
餐巾紙公式
去 slop 設計 = （工程師自訂的約束清單）驅動整體方案 → 減法刪除 AI 冗料 → 設計工具內生 3-4 個 variant 迭代 → 元件化組裝 → 真實資料預覽驗收 → 借用既有解 → 品味反覆打磨 核心是「約束先行、整體考量」：AI agent 天生傾向堆料與局部修補（slop 的來源），工程師的價值在於定義約束、做減法、並用真實資料與品味把關；流程是一個迴圈，約束一變就回到源頭重想，而不是在症狀上打地鼠。
一句話
工程師用 AI 做設計時，別讓 agent 逐點修補，而是自己定義約束、在設計工具中探索多方案、用減法刪掉 AI 的堆料，最後靠真實資料與反覆批判養出品味。
餐巾紙草圖
┌── 反 slop 設計迴圈（工程師 × AI）
│
│ 自訂約束清單（字體/流程/商業邏輯狀態）
│ │
│ ▼
│ 多方案探索：設計工具中生 3-4 個 variants
│ │
│ ▼
│ 減法：對每個元素問「我真的需要它嗎？」
│ │
│ ▼
│ 元件化組裝（/showcase 頁先試玩）
│ │
│ ▼
│ 真實資料驗收（preview deploy）
│ │
│ ▼
│ 品味打磨（團隊圍毆式批判）
│ │
│ ├── 約束增刪？──▶ 回到最頂端重想整體
│ │
│ └── 感覺對了 ──▶ 非 slop 的成品
│
│ 貫穿全程的敵人：
│ ‧ 打地鼠式修補（頭痛醫頭）
│ ‧ prototype gravity（第一版綁架探索）
│ ‧ agent 堆料（多餘文案/線條/圖示）
└──ROUND 1: SKELETON | 骨架掃描
- 核心問題：工程師（非設計師）用 AI 做產品設計時，為什麼以及如何避免產出千篇一律、難以理解的「slop」？
- 核心答案：slop 的根源不是 AI 能力不足，而是「跳過約束定義的局部修補」加上「agent 天生的堆料傾向」；解法是工程師自己掌管約束與整體性，把 AI 侷限在「快速產生多個 variant」的角色，再用減法、元件化、真實資料驗證與品味批判收斂。
- 論證結構：先立論（AI 時代所有頁面長得一樣且難懂）→ 引經據典定義正確流程（Alexander 的約束驅動三步驟）→ 指出兩個墮落路徑（打地鼠修補、agent 堆料）→ 給出五個工程化手法（設計工具迭代、元件化、preview deploy、借用既有解、品味打磨）→ 收斂於「品味 = 反思自己的反應，靠次數累積」。
章節骨架（條列）
- 開場：工程師討厭 slop——每個 landing page、app、tui 都長得一樣且難以理解
- 第 1 條 Always consider the whole：Alexander 三步驟設計流程；打地鼠式修補是頭號陷阱；回饋先問「是否改變約束」；papercut 追蹤文件
- 第 2 條 Remove stuff：agent 愛加東西（code 與 UI 皆然）；對每個元素問「我真的需要嗎」
- 第 3 條 Iterate in a design tool：別在產品內迭代；prototype gravity 是沉默殺手；Figma 仍是 GOAT；每次生 3-4 個 variants
- 第 4 條 Use components and libraries：分離 view 與 logic；Ref 用 /showcase 頁先建元件再接主 app
- 第 5 條 Use preview deploys：真實資料才是設計的考場；前後端 PR 分離；GitHub action 自動開 preview deploy
- 第 6 條 Steal stuff：多數 UX 問題已被解決；截圖收集是給 agent 的最佳 context
- 第 7 條 Explore your taste：品味 = 反思自己的反應；工程師缺的是「解法庫」，靠 reps 累積；Ref 的農業打穀式批判
- 結尾：GLHF（good luck, have fun）
ROUND 2: DISSECTION | 血肉解剖
論證鏈
┌── 論證鏈
│
│ 觀察：AI 時代所有 landing page / app / tui 長得一樣（slop）
│ │
│ ▼ 歸因一（流程面）
│ 跳過「列出約束」直接解題
│ → 使用者一困惑就進入 solution mode
│ → AI 加劇：prompt「讓 X 更顯眼」「加個 Y 的 affordance」
│ → 產出隨機偏重某些互動的破碎拼湊（patchwork）
│ │
│ ▼ 歸因二（產物面）
│ agent 天生堆料：多餘文案、線條、圖示
│ → 看起來比工程師手做的好，其實「kind of bad」
│ │
│ ▼ 解方（七條原則層層設防）
│ 1 約束驅動整體 ── 對抗歸因一（回饋先驗證是否動搖約束）
│ 2 減法清理 ── 對抗歸因二（逐元素存續審問）
│ 3 設計工具迭代 ── 阻斷 prototype gravity，強制多案探索
│ 4 元件化 ── 防止 re-implement 按鈕的拼湊感
│ 5 preview deploy ── 真實資料揭穿「看起來對」的假象
│ 6 借用既有解 ── 站在已解決的 UX 問題上
│ 7 品味打磨 ── 用批判次數換取解法庫（最終收斂機制）
│ │
│ ▼
│ 結論：工程師不需要變成設計師，需要的是流程紀律 + 反思的 reps
└──關鍵證據
- Christopher Alexander《Notes on the Synthesis of Form》的三步驟流程：列出所有約束 → 考慮滿足約束的方案組合 → 發現約束需增刪就回到第一步。這是全文的理論地基，把「設計」從美感活動重定義為約束求解活動——正好對上工程師的思維模式，也解釋了為何約束必須由人（而非 agent）決定。
- 「Prototype gravity 是沉默殺手」的鎖死機制：讓 agent 直接在真實 codebase 蓋出第一版後，「就地 refine」感覺比「另起探索」省力，於是探索空間被第一版綁架。這是 AI 時代新增的路徑依賴，作者開出的解藥是隔離的設計工具 + 每件事物生 3-4 個 variants。
- Ref 的四個可複製工程實踐：(1) papercut/annoyance 追蹤文件——明顯的修很快做、次要的記錄起來等改版一次性整體處理；(2) /showcase 頁——agent 先在孤立頁面建 UI 元件、試玩後才接主 app；(3) 前後端 PR 分離——backend 用 unit/integration test 驗證、frontend 靠人工驗證；(4) GitHub action 為每個 frontend PR 自動架 preview deploy，用真實 backend 試新設計。
隱形假設與邊界
- 預設讀者是「有 codebase、有 PR 流程、有 GitHub Actions 的產品工程師」，在沒有這些基礎設施的環境（如設計師、獨立開發者無 CI）第 4、5 條需要重新發明輪子
- 「打穀式批判」（把設計丟中間圍毆到滿意）預設團隊有安全的文化與夠密集的同步時間；遠端或大型組織中可能退化為政治角力
- 全文假設「品味可經由 reps 與反思習得」，反對品味是天生或階級專屬（對 Kyle Chayka 的反駁），但未處理「團隊整體品味上限」的問題——全工程師團隊的解法庫可能集體偏窄
- 「AI 加劇打地鼠設計」「agent 愛堆料」是經驗觀察，無 A/B 或量化證據；隨模型演化（更好的 design 工具、更強的 constraint following），這些缺陷的嚴重度可能改變
- 未觸及無障礙（a11y）、效能、在地化等設計約束——約束清單的「完整性」本身是未被檢驗的假設
ROUND 3: SOUL | 靈魂提取
- 作者盲點：
- 批判全是內部視角（團隊圍毆），全文沒有出現「真實使用者測試」——打穀式批判驗證的是團隊品味，不是使用者理解度；作者自己說「更多使用者感到困惑」是 slop 的症狀，卻沒給偵測使用者困惑的機制（只有 papercut 文件是被動收集）
- 「多數 UX 問題已被解決」的借用策略，可能正是「每個 landing page 都長得一樣」的部分成因——借用與 slop 的界線在哪裡，作者未深究
- 品味培養「很殘酷，因為 critique 如洪水直到夠好為止」，但沒有給防止品味共識退化為疲勞妥協（「改到大家懶得吵」）的收斂準則
- 知識連接：
- Christopher Alexander 的形式綜合理論，同一個源頭日後啟發了軟體界的 Design Patterns（GoF）——「約束 → 形式」的思維與「forces → pattern」同構
- 「Remove stuff」對應寫作的 “kill your darlings”、對應 code review 中的 belt-and-suspenders 反模式（過度防禦的 try-catch）
- 「生 3-4 個 variants 再選」對應 LLM 推理的 best-of-n sampling：先擴散取樣再收斂挑選，避免單次生成的局部最優
- prototype gravity 對應行為經濟學的現狀偏誤（status quo bias）與程式設計的 legacy code 路徑依賴
- Kyle Chayka 的 taste 論戰：作者主張反思自身反應不是布魯克林閣樓派對的專利，而是創作的必要條件
- 行動觸發：
- 今天就開一份 papercut/annoyance 追蹤文件，並立規矩：使用者回饋進來先問「它改變約束了嗎」，再決定修或記
- 在 repo 加一條 GitHub action：每個 frontend PR 自動開 preview deploy，接真實 backend
- 建 /showcase（或 storybook 式）頁面，規定 agent 先在裡面建元件試玩，驗收後才接主 app
- 對 AI 生成的每個設計，逐元素執行「我真的需要它嗎？」審問；對每個設計決策，要求 agent 生 3-4 個 variants 才准評比
- 專案開工先花時間截圖收集同類產品，整包餵給 agent 當 context
留白提問（2 題，需附架構師引導思路）
- 問題一：約束清單本身失效時，誰、用什麼訊號、多久偵測一次？ 架構師引導：這是把第 1 條推到極限的問題。Alexander 的迴圈假設約束增刪會「被意識到」，但商業模式轉向、新競品、法規變更這類宏觀約束變化不會自己敲門。思考路徑：(1) 約束清單要有 owner 與 review 週期（像架構決策記錄 ADR 一樣對待）；(2) 定義「約束失效」的領先指標——例如同一類 papercut 三個月內重複出現三次，可能不是設計問題而是約束過時；(3) 區分「回饋改變約束」與「回饋只是雜訊」的判準由誰仲裁。
- 問題二：打穀式批判如何防止劣化為「改到沒人有意見為止」的疲勞妥協？ 架構師引導：作者的收斂準則是 “until we feel good about it”——主觀且無下界。思考路徑：(1) 為批判掛上具體標準（對照第 1 條的約束清單逐項檢驗，而非自由發揮）；(2) 引入外部錨點——真實使用者片段、競品的處理方式（第 6 條的截圖庫正好是現成的評審基準）；(3) 設定批判輪次的時間盒，強迫在「有依據的分歧」上表決而非無限圍毆。
跨域映射
- 建築學 → 軟體設計：Alexander 用「fit between form and context」（形式與脈絡的適配）定義好設計，遷移到 UI 就是「介面與使用情境的適配」，slop 正是「形式與脈絡脫鉤」的批量產物
- 編譯器/型別系統：約束清單類似型別簽名——先宣告邊界再求解；打地鼠修補則類似到處塞
any或 null check，症狀消失、成因仍在 - 程式碼審查 → 設計審查：前後端 PR 分離對應測試金字塔（底層自動化、頂層人工）；「agent 愛包 try-catch」與「agent 愛建 component」是同一個過度防禦本能的兩種投影
- 農業隱喻：打穀（threshing）——把穀粒從稈中打出來，留下可食的部分；設計批判的本質是用外力分離「必要元素」與「AI 稈殼」
DEEP READ | 精讀指引（2-3 段，需先摘錄原文金句 + 推薦理由，製造認知阻力）
“The temptation is to spot-fix but that road leads to ruin… When feedback arrives, evaluate if it changes your design constraints before jumping to solutions.”
這句是全文的樞紐，值得停下來抵抗一下「同意然後滑過去」的衝動。請先自問：你上一次收到使用者回饋時，中間隔了幾分鐘就動手改 code？作者的挑戰在於順序顛倒——不是「回饋 → 解法」，而是「回饋 → 它動搖了哪條約束 →（若無）記進 papercut 文件 →（若有）重跑整個設計迴圈」。真正難的不是理解這句話，而是在「使用者正在困惑、老闆正在催」的壓力下守住這個順序。精讀時請把 Alexander 三步驟中的第 3 步（約束增刪就回到第 1 步）在腦中跑一遍你目前的專案：你列得出自己的約束清單嗎？列不出來，表示你一直是在無約束狀態下打地鼠。
“Prototype gravity is the silent killer. This is when you have the agent build the first version in your code base then it feels easier to just refine that instead of exploring other options.”
這句的認知阻力在於它反直覺地指控了一個「看起來像效率」的行為：讓 AI 直接在你的 codebase 蓋第一版，起手超快、成果超好，誰都會這麼做。但作者指出這正是探索空間被謀殺的現場——第一版一旦存在，「refine 它」的心理成本就永遠低於「另起爐灶」，於是你從「在方案空間中搜尋」被降級為「在單一方案的鄰域中微調」。讀這段時請誠實回想：你最近一個 UI，看過幾個真正不同的版本才定案？若答案是 1，那你已經在 gravity 裡面了。作者給的逃脫艙門很具體：設計工具隔離 + 強制 3-4 variants。
“Even if the agent builds exactly what you told it, you may still hold it in your hands with real data and realize it’s not right.”
這句戳破了「指令正確 = 結果正確」的等式，也是 preview deploy 那一條的靈魂。它隱含一個深層主張：設計的驗證媒介是「手握真實資料的身體感」，不是 spec 的忠實度——agent 越聽話，這個斷裂越顯得是你的問題而非它的。精讀時可以追問：哪些類型的錯只有真實資料才會揭穿？（空資料狀態、極端長度文字、真實延遲下的感知…）這直接決定你的 preview deploy 要多「真」：接真 backend、真流量形狀的資料，還是 mock 也行？作者的答案偏向前者，而這正是多數團隊省略的那一步。
STRUCTURE MAP | 全書結構圖
┌── How I Design with AI. — 結構圖
│
│ 開場宣告：工程師反 slop 宣言
│ （所有頁面長一樣且難懂）
│ │
│ ├─【心法層】
│ │ ├─ 1. Always consider the whole
│ │ │ ‧ Alexander 三步驟（約束→方案→增刪回圈）
│ │ │ ‧ 陷阱：打地鼠式修補
│ │ │ ‧ 實踐：papercut 追蹤文件
│ │ │
│ │ └─ 2. Remove stuff
│ │ ‧ agent 堆料本能（code/UI 同源）
│ │ ‧ 實踐：逐元素「需要嗎？」審問
│ │
│ ├─【工具層】
│ │ ├─ 3. Iterate in a design tool
│ │ │ ‧ 敵人：prototype gravity
│ │ │ ‧ 實踐：Figma 等工具 + 3-4 variants
│ │ │
│ │ └─ 4. Use components and libraries
│ │ ‧ view/logic 分離、可復用元件
│ │ ‧ 實踐：/showcase 頁先建後接
│ │
│ ├─【驗證層】
│ │ └─ 5. Use preview deploys
│ │ ‧ 真實資料是唯一考場
│ │ ‧ 實踐：FE/BE PR 分離 + GitHub action
│ │
│ ├─【素材層】
│ │ └─ 6. Steal stuff
│ │ ‧ 多數 UX 問題已有解
│ │ ‧ 實踐：截圖收集餵 agent 當 context
│ │
│ └─【素養層】
│ └─ 7. Explore your taste
│ ‧ 品味 = 反思自己的反應
│ ‧ 缺的是解法庫，靠 reps 補
│ ‧ 實踐：Ref 打穀式團隊批判
│
│ 結尾：GLHF
└──How I Design with AI. (Architectural Deep Dive)
前言/背景
作者 @reactiverobot 是 Ref 團隊的工程師——一個自陳「不是設計師、且痛恨 slop」的人。他所謂的 slop，指 AI 時代批量生成的設計平庸物：每個 landing page、每個 app、每個 tui（terminal UI）看起來都一樣，而且多數難以理解。這篇 X 推文串（2026-08-26 發表）是他的反 slop 作戰手冊：七條原則，混合了 Christopher Alexander 的經典設計理論、對 AI agent 行為模式的觀察，以及 Ref 團隊（沒有全職設計師）的具體工程實踐。文章的隱含命題是：AI 沒有讓設計變難，而是把「工程師跳過設計紀律」的舊病放大成流行病——因此解法不是等更好的模型，而是工程師自己重建流程紀律。
章節詳細總結（依原文結構）
開場：反 slop 宣言
作者自述身份：工程師、非設計師、痛恨 slop。現象診斷：AI 時代所有 landing page、app 與 tui 看起來都一樣，是多數難以理解的 slop。隨後展開七條「去 slop」原則。
1. Always consider the whole（永遠考量整體）
設計流程約是三步驟，出自 Christopher Alexander 的《Notes on the Synthesis of Form》（形式綜合論）——一本作者評為「令人愉悅地嚴謹」的設計流程探索：
- 列出你正在設計的所有約束（constraints）
- 考慮一組滿足這些約束的方案
- 若意識到必須增加或可以移除某條約束，回到第 1 步
（《Notes on the Synthesis of Form》，一本非常好的書。）
約束的形式很多元：字體與尺寸規則、必須支援的工作流程、商業邏輯的狀態機。關鍵在於——約束必須由你決定，不是由 agent。
最常見的病是跳過第 3 步、玩「設計打地鼠」：使用者一困惑，團隊很自然就跳進 solution mode。作者坦承自己團隊常被 nerd-snip（被誘惑分心去解有趣的問題），尤其面對左側 sidebar——它在極小空間裡塞了巨量資訊與操作。誘惑是就地修補（spot-fix），但那條路通往毀滅。
（小空間裡塞了巨量資訊與操作。避免打地鼠式設計。）
跳過約束佈建的後果，是得到一個隨機偏重某些互動的破碎拼湊（disjoint patchwork）。而 AI 加劇了打地鼠的引力——它鼓勵你 prompt「讓 X 更顯眼」「加一個做 Y 的 affordance」，最終更多使用者感到困惑。
回饋到來時，先評估它是否改變你的設計約束，再跳向解法。 Ref 的做法是維護一份追蹤 papercut（小割傷）與惱人細節的文件：明顯的修復快速進行，次要的記錄下來，等改版時一次性整體處理。重點是避免過度反應、製造更多混亂。
2. Remove stuff（刪除東西）
Agent 愛加東西。你的工作是移除不必要的部分。
工程師對此應該很熟悉，因為 agent 在 code 與計畫中做的一模一樣：熱愛 belt-and-suspenders（雙重保險）、多包一層 try-catch、把同一個 utility 反覆重新實作。
UI 設計中，agent 也一樣：愛加多餘的文案、線條與圖示。你會得到「看起來比多數工程師手做還好、但其實有點糟」的設計。
簡單的做法：檢視設計的每個元素，對每個元素問——「我真的需要它嗎？」
（清掉 agent 的垃圾。）
3. Iterate in a design tool（在設計工具中迭代）
你不該在產品內迭代設計。用一個提供精細控制、能快速迭代、且幾乎不需額外 context 的工具。
Prototype gravity 是沉默殺手。 指的是：你讓 agent 在 codebase 裡蓋出第一版之後，「就地 refine 它」感覺比「探索其他選項」更容易。在真實 codebase 裡做設計，也迫使 agent 打造一個得嫁接到你真實（複雜環境）上的版本。
Figma 仍是 GOAT（史上最強），而且它的 AI 整合每週都在進步。Cursor Design Mode、Claude Design、一堆新創、甚至 HTML prototype 也都很好。
總之：用為設計而生的工具，並讓 AI 對每樣東西生成 3-4 個 variants。
（Figma 仍是設計迭代的 GOAT。）
4. Use components and libraries（使用元件與函式庫）
這條對多數工程師大概顯而易見，但很重要所以快速帶過：分離 view 與 logic，建立可復用元件。 不難，且持續生息——你的 app 會是視覺一致的整體，而不是一堆重新實作的按鈕拼成的拼湊。
Ref 的做法是維護一個 /showcase 頁：讓 agent 先在那裡建 UI 元件、試玩之後，才連接到主 app。
（/showcase 頁，收藏 Ref 全部元件。）
5. Use preview deploys（使用預覽部署）
評估設計最好的方式是用真實資料。Preview deploy 讓你用真實 backend 試用新設計。
要記住：永遠會有需要 polish 與重做的地方。即使 agent 蓋出的正是你吩咐的東西，你仍可能雙手握著它、配上真實資料後，發現它不對勁。
對橫跨前後端的大型功能，preview deploy 會變得棘手。Ref 的解法是前後端 PR 分離：backend 變更用 unit test 與 integration test 驗證；frontend 變需要人工驗證，而 preview deploy 讓分享一條連結變得容易。
（GitHub action 為每個 frontend PR 架起 preview deploy。）
6. Steal stuff（偷東西）
多數 UX 問題已經被解決了，你該做的是把碎片撿起來拼在一起。花時間研究正在解決相似問題、或溝通相似概念的產品。
作者合作過的每個狠角色設計師，每個專案都是從收集一大疊截圖開始。你也該這麼做——這是餵給 agent 的絕佳 context。
（一位非常優秀的真設計師收集的 landing page 靈感。）
7. Explore your taste（探索你的品味）
這是有趣的部分！
品味，是反思你對某事物的反應。作者向 Kyle Chayka 致歉（對方寫過〈為何科技宅痴迷於 taste〉），但反思自身經驗並不是布魯克林閣樓派對的專利——它是「創造」與「創造 slop」的必要分界。
產品工程師非常擅長辨識「設計行不通」，卻很難知道怎麼修。 工程師缺的是從經驗累積出來的解法庫。建立它只需要反覆嘗試與反思（reps）。把玩與探索很有趣，但過程也相當殘酷——那是一場批評的洪水，直到某個版本夠好為止。
Ref 沒有全職設計師，於是採用「農業打穀式」方法煉化品味：把設計丟到中間，用棍子圍毆，直到大家覺得 OK。
（Ref 團隊把設計打到投降為止。GIF）
結尾
「我能講的就是這些。GLHF（good luck, have fun）。」
總結與結論（3-5 點）
- slop 的根本原因是流程缺陷，不是 AI 能力問題：跳過「定義約束」直接解症狀（打地鼠），加上 agent 天生的堆料本能（多餘文案/線條/圖示），兩者相乘才產出「看起來不錯其實難懂」的批量設計；解藥是工程師自己掌管約束清單與整體性，把 AI 侷限在「快速生成多 variant」的角色。
- 最有戰鬥力的三個實踐可直接落地：(1) papercut 追蹤文件——回饋先問「是否改變約束」，明顯的快修、次要的累積到改版整體處理；(2) /showcase 頁——元件先在孤立頁面建好試玩再接主 app；(3) 前後端 PR 分離 + GitHub action 自動 preview deploy——backend 靠自動化測試、frontend 靠人工用真實資料驗收。
- Prototype gravity 是 AI 時代新增的路徑依賴：在 codebase 蓋第一版很爽，但會把「方案空間搜索」降級為「單一方案微調」；隔離的設計工具（Figma 等）+ 每件事物 3-4 個 variants 是具體的逃脫艙門。
- 「指令正確 ≠ 結果正確」：設計的最終考場是真實資料下的手握體驗，不是 spec 忠實度——agent 越聽話，這個斷裂越是驗收流程（而非生成流程）的責任。
- 品味是可習得的工程素養：它不是天賦或階級專利，而是「反思自己反應」的反覆練習；工程師缺的是設計解法庫，靠 reps 與密集批判（Ref 的打穀式圍毆）累積——但需自覺其邊界：內部批判驗證的是團隊品味，使用者理解度仍需外部機制把關。