AI coding agents 能在幾分鐘內加一個按鈕、提示或側欄，但每個局部修補都可能讓產品更難理解。 工程師要提升設計品質，得先列出整體約束、在低成本工具裡探索多個版本，再用元件庫與 Preview Deployment 把選定方案接回真實資料；更長的 Prompt 解決不了流程缺口。
曾任 Figma 工程師的 Matt Dailey 把自己的方法整理成七個步驟：考慮整體、刪除多餘元素、在設計工具迭代、使用元件與函式庫、建立預覽部署、蒐集參考，以及練習品味。這份清單最有價值的地方，是把 AI 介面設計的失敗原因指向流程，而非模型。
AI 放大「設計打地鼠」
使用者說某個功能找不到，團隊很容易立刻要求代理：「讓 X 更顯眼」或「再加一個能做 Y 的入口」。這個修補可能解決眼前回報，卻把同一個動作放進三個位置，破壞資訊層級，也讓下一批使用者更困惑。
Christopher Alexander 在《Notes on the Synthesis of Form》裡把設計問題描述為形式與脈絡的契合。Dailey 將這套思路縮成一個循環：列出約束、探索符合約束的解法；如果發現約束需要增減，就回到第一步。
這個循環適合 AI，因為約束可以成為模型的評估規格。它也限制了 AI 的弱點：模型很擅長產生可見元素，較不會主動質疑產品是否需要那些元素。
第一步：先寫完整約束，不要先畫畫面
約束可以分成五類：
- 使用者任務：使用者進入頁面要完成什麼，成功與中斷狀態是什麼。
- 內容與資料：真實文字長度、空值、權限差異、錯誤、延遲與大量資料。
- 業務規則：哪些動作可逆，哪些需要確認，哪些角色可以操作。
- 視覺系統：字體、間距、色彩、層級、元件與響應式規則。
- 可用性與無障礙：鍵盤順序、焦點、對比、標籤、錯誤提示與縮放。
可以把這些內容放進一份 design-constraints.md，並為每個重要流程建立狀態表：
## 邀請成員
使用者：workspace_admin
目標：邀請一位或多位成員
必要狀態：empty、typing、invalid、sending、success、partial_failure
不可破壞：鍵盤可操作、重複寄送可辨識、權限不足時不顯示送出動作
視覺約束：只使用既有 Input、Button、Toast、MemberRow
W3C 的 WCAG 2.2 要求跨頁面出現的同功能元件應有一致識別。這不是單純美觀問題；相同動作用不同名稱或圖示，會增加認知負擔，也讓輔助科技使用者更難預測。
第二步：逐一刪除沒有工作要做的元素
Agents 常會加上副標、說明、分隔線、圖示、狀態標籤與第二個 CTA。每個元素看起來都合理，合在一起卻讓畫面失去主次。
審查時可以為每個元素回答三個問題：它幫助哪個任務？如果刪除，哪個使用者會失敗？它是否重複另一個元素已傳達的內容？答不出來，就先拿掉。
刪除不等於追求極簡。錯誤原因、不可逆動作的影響與欄位格式提示都可能必要。WCAG 的錯誤預防原則也要求重要提交能被復原、檢查或確認。真正應刪的是沒有承擔資訊、操作或風險功能的裝飾。
第三步：先在設計工具做三到四個版本
Dailey 稱「原型重力」為沉默的殺手：第一版一旦直接寫進產品程式庫，團隊會因為已投入工程成本而不斷修它，很少再探索結構完全不同的方案。
設計工具、獨立 HTML 原型或隔離的 Storybook 頁面能降低轉向成本。要求 AI 產生三到四個真正不同的版本時，差異應落在資訊架構、互動順序或密度，不是換顏色與圓角。
根據 design-constraints.md，提出四個邀請成員流程。
每個版本必須：
- 支援同一組狀態與權限
- 使用既有元件
- 說明主要取捨
- 與其他版本採用不同的資訊架構或互動順序
不要寫正式產品程式。輸出可評估的線框、狀態圖和決策摘要。
第四步：讓元件庫同時管理視覺與行為
可重用元件不只統一按鈕顏色。它還應封裝焦點狀態、disabled 邏輯、loading、錯誤訊息、鍵盤操作與分析事件。若每個代理在功能分支裡重新做一顆 Button，產品很快會出現相似外觀、不同語意的元件。
可以建立 /showcase 或 Storybook，讓代理先在隔離頁面組合元件。主應用程式只接受通過視覺、狀態與無障礙檢查的元件版本。
新增 UI 前：
1. 搜尋元件目錄與現有使用案例。
2. 能組合既有元件時，不得建立新元件。
3. 新元件先加入 showcase，涵蓋預設、hover、focus、disabled、loading、error。
4. 記錄它和最接近元件的差異。
5. 通過人工視覺審查後才能接進產品流程。
第五步：用 Preview Deployment 接上真實資料
設計稿無法暴露所有問題。真實姓名可能很長，帳號可能沒有資料，API 可能慢，權限也會改變畫面。Preview Deployment 讓團隊在不影響正式站的情況下，以接近生產的環境檢查這些狀態。
Vercel 的 Git 整合會為分支 push 和 Pull Request 建立獨立預覽 URL。前端 PR 可以交給人員檢查流程與視覺；後端變更則先由單元與整合測試驗證。大型功能若前後端綁在同一個 PR，預覽常會等待兩邊同時完成，因此拆分介面契約與部署順序會更容易審查。
預覽環境要使用受控測試資料和自己的環境變數。公開 URL 可能洩漏未發布功能；需要時應開啟部署保護。
第六步：蒐集模式，不要複製成品
Dailey 建議每個專案先收集一批截圖。這能提供模型比「做得像精品 SaaS」更具體的上下文。參考帶應標出要學的是導航密度、表格篩選、空狀態，還是設定流程。
「偷」成熟產品的解法，不代表照抄品牌外觀。團隊應抽取可解釋的互動模式，檢查它是否符合自己的任務、資料與權限。參考圖也可能受著作權與保密條款限制；只把有權使用的素材交給模型。
第七步：把品味變成可回看的判斷紀錄
工程師通常能察覺介面不對，卻未必能立刻提出更好的版本。缺少的往往是一座經驗形成的解法庫。建立它的方法很樸素：看更多案例、做更多版本、說出自己的反應，再追蹤哪個判斷在真實使用中成立。
每次審查可以保存一張簡短決策卡：
觀察：使用者在成員列表找不到批次邀請。
約束變更：大量邀請是主要任務，不是例外。
比較版本：A 在頁首放主要動作；B 使用固定工具列；C 保留列內動作。
選擇：B。
原因：選取狀態與批次動作保持在同一脈絡，窄螢幕仍可使用。
待驗證：首次完成率、誤觸率、鍵盤流程。
這些紀錄會成為下一次給 AI 的高品質上下文。品味仍包含主觀判斷，但它不必停留在「感覺比較好」。
把七步方法做成 PR gate
一個可執行的前端流程可以設四道 gate。第一道檢查需求是否連到約束與狀態表；第二道確認至少比較三個結構性方案；第三道要求使用既有元件或附上新增理由；第四道提供 Preview URL、真實資料狀態與人工驗收紀錄。
Lint、單元測試和視覺回歸可以自動化部分檢查，卻無法判斷資訊層級是否幫助使用者完成任務。AI 也不能批准自己的設計。把人工審查放在預覽環境，才有機會在合併前看見整體。
常見問題
工程師一定要先學 Figma 嗎？
不一定。重點是使用能快速比較多個方案、又不被正式程式庫綁住的工具。Figma、獨立 HTML 原型或元件 showcase 都可以。
為什麼不能直接叫 AI 在產品裡迭代？
直接實作會增加沉沒成本，也讓每個方案被既有程式與資料結構限制。先在隔離環境探索，選定方向後再接回產品，轉向成本較低。
產生三到四個版本會不會只是浪費？
若版本只改顏色，確實沒有價值。有效比較需要改變資訊架構、互動順序或密度，並使用同一組約束評分。
元件庫會限制創意嗎？
元件庫固定重複行為與基本視覺，讓團隊把創意用在流程與問題本身。真正需要的新模式仍可加入，但要先說明差異並驗證各種狀態。
Preview Deployment 可以取代使用者研究嗎？
不能。它讓團隊用真實資料檢查產品行為，也方便分享審查；使用者是否理解與完成任務，仍要靠觀察和研究。
權威來源
- Christopher Alexander Archive — Notes on the Synthesis of Form
- W3C WAI — Consistent Identification
- W3C — WCAG 2.2
- Vercel — Deploying Git Repositories
- Vercel — Accessing Deployments through Generated URLs
Author Insight
AI 把寫出第一版介面的成本壓得很低，卻沒有降低選錯方向的代價。工程團隊最該保護的是探索空間：先把約束說清楚，允許多個版本競爭，再讓真實資料與人工審查決定哪一個值得進入程式庫。
術語表
- 設計約束：解法必須同時滿足的使用者、資料、業務、視覺與無障礙條件。
- 原型重力：第一版進入正式程式後，沉沒成本讓團隊傾向持續修補而不再探索。
- Preview Deployment：與正式環境分離、可透過獨立 URL 審查的部署版本。
- 設計打地鼠：針對單一回饋增加局部元素，卻沒有重新檢查整體約束的做法。
