design-review

design-review 技能總覽

design-review 的用途

design-review 是一個設計 QA 技能，用來在真實 codebase 中抓出視覺不一致、間距問題、層級問題、AI-slop 模式，以及互動打磨不夠俐落的地方，然後透過反覆修正與驗證把它修好。它特別適合想要把 design-review skill 從「這裡怪怪的」一路推進到具體原始碼修改與前後對照驗證的團隊。

適合誰使用

當你需要一個有 UX 觀點的 agent 來稽核正在運作的介面、打磨既有實作，或檢查已經寫進 code 的 UI 時，就該用 design-review skill。它很適合產品設計師、前端工程師，以及在視覺一致性比全新版面生成更重要的 app 上工作的 agent。

它和其他方法有何不同

和一般的 UX Audit 提示詞不同，這份 design-review 指南是有工作流程意識的：它的設計目標是找出問題、做原子化修正，然後重新檢查結果。它也支援 plan-mode 分離；當你想先 review 再實作，而不是立刻動手改碼時，這點就特別重要。

如何使用 design-review skill

安裝並導向任務

先用你的 skills manager 執行 design-review 的安裝指令，接著把 agent 指向包含你要檢視 UI 的 repo。若你在 plan mode 中工作，導向 /plan-design-review；如果你要改 code，就使用 skill 中描述的 active review 路徑。

提供正確的輸入

一個好的 design-review 使用提示詞，會明確寫出畫面、使用流程，以及你在意的失敗情境。更好的寫法是：「檢查 checkout modal 在 mobile 上的間距、層級與按鈕清楚度，然後修正最嚴重的問題。」較差的寫法是：「讓它看起來更好。」前者給了 skill 目標、限制與成功條件。

先讀這些檔案

如果你想找一份真正能幫你判斷是否適用的 design-review 指南，先讀 SKILL.md，如果有生成的範本檔，例如 SKILL.md.tmpl，也一起看。也請檢查 repo tree 裡是否有 prompt-routing 或 helper 的慣例，因為這個 repository 的重點是 skill 本體，而不是支援腳本或文件。

用 review loop 的方式跑

把這個 skill 用在短迴圈裡：檢視、修補、驗證、重複。要求它說明改了什麼、為什麼改，並且每一輪最好只處理一類問題，例如排版、間距或互動延遲。這樣可以讓 review 保持聚焦，也更容易看出 regression。

design-review skill 常見問答

design-review 只適合最後的打磨嗎？

不是。design-review skill 可用於上線中的介面打磨、codebase 整理，以及那種已經有視覺成果、但還需要再收斂的 UX Audit 類檢查。它比起早期概念發想，更適合用在修正與驗證已實作的介面。

我一定要是設計師才能用嗎？

不需要，但你必須把畫面與問題描述清楚。不是設計背景的人，只要說明哪裡不對勁、使用者是誰、成功長什麼樣，通常會比只說一個模糊的重設計要求得到更好的結果。

這和一般提示詞有什麼不同？

一般提示詞可能只會產生建議；design-review 則是朝著在 code 中找出問題、修改它們，並檢查結果的方向設計的。如果你只需要建議，這個 skill 可能超出需求；如果你想要可衡量的 UI 修補，它會更合適。

什麼情況下不該用 design-review？

如果任務純粹是策略層、品牌層，或只有內容沒有介面可檢查，就先不要用它。當你無法存取 codebase，或無法在修改後驗證 screenshots 時，它也會比較不適合，因為這個 skill 的價值來自反覆驗證。

如何改善 design-review skill

先鎖定明確的 review 目標

最好的 design-review 結果，通常來自很聚焦的目標：一個頁面、一個元件，或一條使用流程。請提供 viewport、裝置情境與主要關注點，例如「桌面版 settings page，重點看對齊與可掃讀性」或「mobile pricing card，重點看點擊清楚度」。

告訴它你要優化什麼

如果你最在意一致性、無障礙、轉換清楚度，或互動速度，請一開始就說明。這能幫 design-review skill 在彼此衝突的修正之間做取捨，尤其是當某個變更改善了一個面向，卻削弱了另一個面向時。

留意常見失敗模式

常見的低品質輸入包括「讓它更乾淨」、「改善設計」和「全部都 audit 一遍」。這類提示詞通常會引來範圍過大、訊號很低的輸出。更好的做法是直接點出缺陷類型、元件，以及可接受的變動幅度，這樣能減少不必要的修改，也能讓 design-review 的使用流程更順。

用證據持續迭代

第一輪之後，請它列出剩下的主要問題、實際修改了哪些檔案，以及目前從 screenshot 仍看得見的 regressions。如果結果已經接近但還不夠好，就用更尖銳的限制來調整 brief，例如：「保持 layout 不變」、「不要改色盤」或「只修正層級與間距」。