critique

critique skill 概覽

critique skill 會做什麼

critique skill 是一套有結構的 UX 評估流程，用來檢視頁面、功能或元件是否作為「被設計過的體驗」成立，而不只是介面能不能正常運作。它會引導模型檢查視覺層級、資訊架構、情緒語氣、認知負荷與可用性啟發式，並把觀察整理成具體可執行的回饋，而不是停留在空泛意見。

誰適合安裝 critique

這個 critique skill 特別適合設計師、前端工程師、產品團隊，以及需要快速取得 UX 稽核式回饋的 AI builder。如果你手上有截圖、線上頁面，或已做出的元件，希望得到比「你覺得這個設計怎麼樣？」更銳利、更有判斷力的評估，它會尤其實用。

最適合解決的工作任務

當你的真正需求是：「告訴我這個介面為什麼有效或失敗、使用者會卡在哪裡、以及我應該先改什麼」時，就適合用 critique。它很適合用在設計審查、上線前檢查、AI 生成 UI 的修整，以及 prioritization 比純美感更重要的 critique for UX Audit 工作流程。

這個 skill 與一般做法有何不同

critique 最明顯的差異在於它有明確立場，不只是給一輪寬泛的設計評論。它會明確檢查「AI slop」類型的介面模式、使用啟發式評分，並建議以 persona 為基礎做測試。因此輸出會比一般的 critique prompt 更偏診斷型，也更容易重複套用。

使用前必須先知道的相依條件

實務上，這個 skill 並不是可單獨拿來用的。它自己的指示要求先使用 /frontend-design skill，並遵循該 skill 的情境蒐集流程。若目前還沒有設計脈絡，repository 也寫明要先執行 /teach-impeccable 再做 critique。這個相依關係，是採用前最需要先理解的主要門檻。

如何使用 critique skill

安裝來源與 repo 路徑

critique skill 位於 pbakaus/impeccable 的 .agents/skills/critique。如果你使用 skill loader，請從該 repository 安裝並選擇 critique skill。若你的環境支援直接從 repo 載入 skill，可指向：

• pbakaus/impeccable
• skill: critique

如果你想在安裝前先手動檢查，建議先看這些檔案：

• .agents/skills/critique/SKILL.md
• .agents/skills/critique/reference/cognitive-load.md
• .agents/skills/critique/reference/heuristics-scoring.md
• .agents/skills/critique/reference/personas.md

第一次安裝 critique 前，先讀這段

不要把它當成可直接貼上就用的 prompt 片段。這個 skill 預設你已經有前置設計情境。repository 明確把 /frontend-design 列為必須條件，並要求在執行 critique 前先跑完它的 context-gathering protocol。若跳過這一步，輸出品質通常會下降，因為模型不知道目標、受眾與介面的設計意圖。

critique skill 需要哪些輸入

想把 critique 用得夠強，建議提供：

• 要被評估的介面區域
• 截圖或清楚的視覺描述
• 產品目標
• 目標使用者
• 使用者想完成的主要任務
• 平台、品牌、無障礙、轉換目標等限制條件

只給最低限度資訊也能跑，但如果模型知道「什麼才算成功」，critique 的品質通常會明顯更好。

最佳呼叫方式

這個 skill 的 argument hint 是 [area (feature, page, component...)]。實務上，最好用明確範圍來呼叫，例如：

• critique checkout page
• critique onboarding modal
• critique dashboard sidebar
• critique pricing page for UX Audit

像這樣指定範圍，通常會比只說「critique my app」得到更可執行的回饋。

把模糊需求改寫成高品質 critique prompt

較弱的請求：

• 「Critique this UI.」

較好的請求：

• 「Critique this settings page for UX Audit. The goal is to help first-time users enable notifications without confusion. Audience is non-technical SMB owners. Prioritize visual hierarchy, cognitive load, and whether the main action is obvious.」

這樣寫有效的原因是：

• 有指出使用者是誰
• 有指出任務是什麼
• 有指出成功標準
• 有告訴 skill 應該優先看什麼

實務上建議的 critique 工作流程

一套實用的 critique guide 流程是：

1. 先用 /frontend-design 蒐集脈絡。
2. 說清楚產品目標與使用者任務。
3. 把要評估的畫面、功能或元件明確交給 critique。
4. 要求依嚴重程度分組列出發現。
5. 第一輪評估後，再要求根據你的工程或品牌限制，提出修正版建議。

和一次要求它同時做 critique 與 redesign 相比，這樣的流程通常更可靠。

critique skill 特別擅長評估什麼

根據 repository，critique skill 最強的地方包括：

• 找出常見的 AI 生成介面套路
• 評估層級與清晰度
• 辨識認知過載
• 套用啟發式評分
• 用相關 persona 對流程進行壓力測試

因此它很適合做 triage：找出那些看起來 polished，實際上仍會讓使用者失敗的地方。

如何善用 reference 檔案

這些 reference 檔案的重要性，比看起來更高。

reference/cognitive-load.md 能幫模型分辨「任務本身很複雜」和「設計把事情弄得更複雜」之間的差別，因此建議通常會更準。

reference/heuristics-scoring.md 則提供一個跨 Nielsen heuristics 的 0–4 具體評分框架。當你想比較多個畫面時，這會特別有用。

reference/personas.md 最適合有選擇地使用。比起每次都硬套全部五種 persona，更建議挑 2–3 個真正符合受眾的 persona。

適合 UX Audit 的 critique prompts

如果你的目標是做 critique for UX Audit，可以要求結構化輸出，例如：

• 前 5 大可用性風險
• 啟發式分數與簡短證據
• 選定 persona 的可能失敗點
• 優先度最高的修正項目
• 哪些部分應該維持不變

這種格式產出的評估，通常可以直接交給團隊使用，而不用重寫一遍。

常見誤用，會讓輸出品質下降

最常見的誤用，是在沒有介面、沒有截圖、也沒有任務脈絡的情況下，直接要求設計回饋。另一種常見錯誤，是拿 critique skill 從零開始生一套新 UI。這個 skill 更擅長評估與排序問題，而不是憑空發明完整設計系統。

critique skill 常見問題

critique 對新手友善嗎？

友善，但前提是你至少要提供基本情境。新手只要分享一個畫面與一個使用者目標，通常就能很快得到價值。若沒有這些資訊，critique skill 雖然可能聽起來很有權威，但實際上可能沒抓到真正的產品問題。

它真的比一般 critique prompt 好嗎？

通常是。它的價值不只在措辭，而在於內建的評估框架：AI slop 偵測、認知負荷分析、啟發式評分，以及 persona 測試。這讓 critique usage 比一般 prompt 更穩定一致。

我一定要先用 frontend-design skill 嗎？

實際上是要。repository 已經把它標成必須條件。如果你希望 critique install 從第一天就有用，最好一開始就規劃搭配 /frontend-design 一起使用，而不是孤立地單獨跑。

哪些素材最適合拿來用？

最理想的輸入是截圖、已渲染頁面、prototype，或帶有清楚任務脈絡的詳細介面描述。單看程式碼的幫助較有限，除非 UI 行為已被清楚描述，或能直接看得到介面結果。

什麼情況下不該用 critique？

當你需要以下能力時，不建議用 critique：

• 深入的程式碼實作審查
• 單獨完成無障礙合規稽核
• 以 analytics 為基礎的轉換診斷
• 在沒有既有介面的前提下做完整 redesign

它是偏 UX 的評估工具，不是各類專項稽核的替代品。

critique 可以比較多個設計方案嗎？

可以。如果你要求 comparative scoring 與 tradeoff 分析，它很適合做並排比較。重點是每個方案都要給相同的任務與受眾脈絡，才能讓比較維持公平。

如何把 critique skill 用得更好

給模型介面目標，不要只丟畫面

想提升 critique 結果，最有效的方法就是說清楚這個介面要達成什麼。repository 也明確要求這件事。畫面再漂亮，如果主要任務不清楚，一樣可能失敗；而這正是這個 skill 被設計來抓出的問題。

要求嚴重程度、證據與修正建議

如果你希望輸出能直接促成行動，可以要求 critique skill 依這種格式整理發現：

• 問題是什麼
• 為什麼重要
• UI 中的證據
• 嚴重程度
• 建議修正方式

這能避免流於空泛評論，也更方便後續排序。

選擇真正符合受眾的 personas

當你只挑選相關 archetype 時，persona 測試的品質會強很多。例如：

• onboarding 適合 first-time user
• 資訊密集 dashboard 適合 impatient power user
• 金流或高風險操作流程適合 anxious user

如果每次把所有 persona 都用上，反而可能稀釋 critique 的判斷力。

用具體限制強化較弱的 prompts

更強的 critique guide prompt 應包含這類限制條件：

• mobile-only
• brand cannot change colors
• must keep current information architecture
• engineering team can only make low-effort fixes this sprint

限制條件越清楚，建議通常越貼近現實。

留意 critique 最常見的失敗模式

最主要的失敗模式，是輸出看起來很有風格、很會講，但沒有連回真實的使用者任務。如果第一輪結果聽起來太泛，可以追問：

• 「Which issue most likely blocks task completion?」
• 「What would confuse a first-time user in the first 10 seconds?」
• 「Which recommendation has the highest impact with lowest implementation effort?」

謹慎使用啟發式評分

分數很適合拿來比較與排序，但也可能製造假的精確感。比較好的做法，是要求每個分數下方都附一段簡短證據。這樣 critique skill 才會持續錨定在看得見的 UI 問題上，而不是流於任意打分。

分兩輪執行 critique

高品質的 workflow 通常是：

1. 第一輪：診斷問題
2. 第二輪：在真實限制下收斂解法

把 diagnosis 與 redesign 分開，通常能讓結果更清楚，也更值得信任。

第一次 critique 後，如何把輸出再提升

第一輪跑完後，可以再補回這些資訊：

• 你修正過的使用者假設
• 修改後狀態的截圖
• 模型忽略的限制條件
• 團隊同意或不同意的發現有哪些

把 critique skill 當成可反覆互動的 reviewer，而不是一次定生死的 judge，效果通常會更好。

在它最有優勢的場景使用 critique

這個 critique skill 最有價值的場景，是那些表面看起來 polished、實際上可能藏著 UX 問題的介面：AI 生成 landing page、dashboard、onboarding flow、settings panel，以及資訊密集的功能介面。在這些地方，它對 anti-pattern 的辨識與認知負荷分析最能帶來額外資訊增益。

採用前先看懂這個取捨

取捨其實很簡單：critique 能提供比一般 prompting 更嚴謹的 UX 回饋，但前提是你願意提供足夠脈絡，並接受它這套帶有明確立場的框架。如果你只想快速拿一個輕量、臨時的意見，一般 prompt 可能更快；如果你要的是可重複執行的 critique for UX Audit，這個 skill 會是更適合的選擇。