critique

critique skill 概覽

critique skill 的功能是什麼

critique skill 是一套結構化的 UX 與產品設計評估流程，用來檢視某個頁面、功能或元件是否真的構成良好的使用者體驗，而不只是看起來像一張視覺稿。它會引導模型評估視覺層級、資訊架構、情緒語氣、認知負荷、可用性啟發式，以及不同 persona 的使用阻力，最後整理成可執行的改進建議。

誰適合安裝 critique

這個 critique skill 特別適合產品設計師、frontend engineers、創辦人，以及已經有畫面、原型或正式上線介面的 AI builders。若你想要的不是泛泛的「幫我看看這個 UI」，而是更銳利、更有判斷力的設計檢視，它會很適合你。尤其在需要做 UX Audit、上線前設計 QA，或想確認某個介面是否顯得制式、混亂、笨重時，這個 skill 很有價值。

真正要解決的工作是什麼

大多數使用者要的不是單純的意見，而是想知道：

• 目前最先傷害體驗的是什麼
• 這個 UI 看起來是否太像模板，或帶有「AI 生成感」
• 哪些問題只是表面瑕疵，哪些會直接卡住轉換
• 沒有完整設計團隊時，該如何排序修正優先順序

這個 skill 就是圍繞這個需求設計的。它把 critique 當成決策工具，而不是單純的風格評論。

這個 critique 有什麼不一樣

它最明顯的差異，在於非常強調脈絡，以及內建的「AI slop detection」步驟。它不會一開始就直接做表層評論，而是先要求設計脈絡，並明確檢查介面是否出現 2024–2025 常見的 AI 產品樣板，例如制式卡片格狀排版、過度發光的深色主題、層級薄弱、以及看起來像模板拼裝的構圖。

它也不只停留在單一審稿視角，而是結合了：

• design-director 風格的 critique
• 認知負荷分析
• 啟發式評分
• 以 persona 為基礎的測試

採用前的重要注意事項

critique 並不是完全獨立可用的 skill。repository 明確把 frontend-design 列為必要依賴，用來提供原則與脈絡蒐集；如果目前沒有設計脈絡，還要求先跑 teach-impeccable。如果你想找的是零設定、裝了就能用的 critique 安裝方案，採用前最需要先知道的就是這條依賴鏈。

如何使用 critique skill

在依賴 critique 之前，先把脈絡裝好

這個 repository 將 critique 放在 .claude/skills/critique，而 skill 內容也明確依賴 /frontend-design。實際使用上，當整套 impeccable skills 一起安裝時，critique 的效果通常最好；如果只是把這個資料夾當成獨立 prompt 檔來用，效果會打折。

如果你的 skill runner 支援從 GitHub 安裝 skills，建議直接從該 repository 安裝，然後確認 critique、frontend-design 與 teach-impeccable 都已可用。

先讀這幾個檔案

如果你想快速判斷值不值得安裝，先看：

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

這條閱讀路徑幾乎能讓你掌握最重要的資訊：前置需求、評估流程、評分模型，以及使用者測試採用的視角。

critique skill 需要什麼輸入

當你提供以下資訊時，critique skill 的表現會明顯更好：

• 介面素材：截圖、mockup、URL，或元件描述
• 要檢視的範圍：頁面、流程、modal、dashboard、onboarding、settings 等
• 主要使用者目標
• 產品脈絡與目標受眾
• 限制條件：mobile/desktop、B2B/B2C、無障礙、轉換目標、技術限制

如果沒有這些脈絡，模型仍然可以評論版面與美感，但無法判斷這個介面是否真的適合它要完成的任務。

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

弱的 prompt：

• 「Critique this UI.」

較強的 critique 用法：

• 「Use the critique skill on this onboarding flow. The product helps finance teams close books faster. Primary goal: get a first report generated in under 5 minutes. Audience: mid-market accounting teams. Constraint: desktop web app, dense data is acceptable but first-time clarity matters. Please evaluate AI-slop signals, hierarchy, cognitive load, heuristic score, and test it as a first-timer and power user.”

較強版本效果更好，因為它給了 skill 明確的優化方向，而不只是提供一個讓它隨意反應的畫面。

依照 repository 要求做前置準備

這個 skill 的說明很明確：先執行 /frontend-design，並遵循它的脈絡蒐集流程。如果目前沒有設計脈絡，則要在做 critique 前先跑 /teach-impeccable。也就是說，預期中的工作流程是：

1. 蒐集設計脈絡
2. 釐清介面想完成的任務
3. 依照這個目標執行 critique
4. 回傳排好優先順序的建議

如果跳過第 2 步，輸出通常會變得很泛，因為模型無法分辨哪些資訊密度是刻意的，哪些是真的設計不良。

把 critique 用在 UX Audit 工作上

如果你是為了 critique for UX Audit 類型的任務使用這個 skill，不要只要求「給我一些 feedback」，而是應該要求：

• 依嚴重程度排序的主要問題
• 啟發式評分摘要
• 使用者最可能流失的節點
• 不同 persona 的失敗模式
• 具體的 redesign 建議

這樣可以把結果從一般評論，提升成利害關係人真的能採取行動的 audit 級輸出。

這套流程實際在檢查什麼

從 repository 的設計來看，critique skill 最擅長檢查的是：

• AI 生成設計常見的同質化問題
• 視覺層級問題
• 認知過載
• 資訊架構薄弱
• 互動模式不清楚
• 可用性啟發式缺口
• 介面語氣與使用者需求不匹配

因此它更適合評估已上線或接近真實使用情境的 UI，而不是用來發想全新、尚未成形的概念。

建議的 critique 使用流程

一個實用的流程是：

1. 收集畫面與使用目標
2. 說明使用者類型與成功標準
3. 針對特定區域啟用 critique，而不是一次看整個產品
4. 先檢視最嚴重的前 3 個問題
5. 補充限制條件後，再要求修正版建議
6. 對下一個流程重複同樣做法

實務上，逐頁或逐流程使用 critique skill，通常比一次做整個產品的大型總體評估更有訊號、更能聚焦。

如何把範圍切得恰到好處

好的範圍包括：

• signup flow
• pricing page
• analytics dashboard
• settings panel
• empty state
• mobile checkout

不好的範圍包括：

• 「整個 app」
• 「我們的 design system」
• 「網站上的所有東西」

這個 skill 的分析粒度其實很細，所以範圍一旦過大，輸出就容易流於表面。把檢視區域縮小，反而能得到更具體、更好排序的結論。

能提升輸出品質的實用技巧

如果你想讓 critique 的使用效果更好，建議至少補上：

• 一句話說明商業目標
• 一句話說明使用者的急迫性
• 一句話說明什麼叫成功
• 任何你不希望模型「順手改掉」的既有限制

例如：

• 「This page exists to get a team admin to invite coworkers immediately after signup. Speed matters more than education. We cannot remove required compliance messaging.”

這類輸入能幫助 skill 分辨什麼是真正的缺陷，什麼只是必要的複雜度。

critique skill 常見問題

critique 真的比一般 UX prompt 更好嗎？

通常是，特別是當你想要可重複、可比較的檢視方法時。critique skill 的價值不在於某種神奇的設計品味，而在於它內建的結構：前置脈絡、反模式偵測、啟發式評分、認知負荷框架，以及 persona 測試。一般 prompt 也許能給出不錯的意見，但一致性通常較差，也更容易滑向空泛稱讚。

critique 對新手友善嗎？

大致上算友善，但有一個前提：它依賴 frontend-design，有時還需要 teach-impeccable。新手當然也能使用 critique，但要有心理準備，先花幾分鐘理解預期工作流程，而不是丟一句 prompt 就想直接得到理想結果。

什麼情況下 critique 不適合？

以下情況建議先跳過這個 critique skill：

• 你需要的是程式碼生成，而不是設計評估
• 你只有模糊的產品想法，還沒有實際介面
• 你現在更需要 brand strategy 或 copywriting
• 你完全無法提供任何使用者或產品脈絡

它當然仍可針對純視覺做評論，但那並不是這個 skill 最有辨識度、最值得裝的地方。

critique 只能用在成熟、精緻的 UI 上嗎？

不是。它也能用在 wireframes、粗略 mockups 與早期元件上，特別是在檢查層級與認知負荷時仍然有幫助。不過，當互動模型呈現得夠清楚時，persona 測試與啟發式評分的可信度會更高。

我可以只拿一個元件來跑 critique 嗎？

可以，前提是這個元件在脈絡裡有一個真實任務。像是 filter panel、modal、table 或 form，都適合用 critique 檢視。你只需要說清楚它出現在哪裡、誰會用、以及使用者想完成什麼。

我應該期待什麼樣的輸出？

好的 critique 輸出應該包含：

• 主要 UX 風險
• 嚴重程度或優先順序
• 這些問題為何重要的具體原因
• 可以怎麼改的實例
• 清楚區分表層修飾問題與結構性 UX 問題

如果結果大多只是一些形容詞，通常代表 prompt 缺乏足夠脈絡。

如何改善 critique skill 的使用效果

給 critique 的不只是畫面，還要有成功指標

想快速提升 critique 輸出品質，最有效的方法就是說清楚預期的使用者結果。「Review this dashboard」遠不如「Review this dashboard for whether a new manager can spot blockers in under 30 seconds」來得有力。成功指標會讓後續每一個判斷都更精準。

提供受眾與產品成熟度

同一個介面可能：

• 很適合高熟練度的 B2B 工具操作人員
• 不適合第一次接觸的消費者
• 在內部工具裡可以接受
• 但用於高端對客產品時會顯得薄弱

只要你說明受眾與成熟度，critique skill 就能評估取捨，而不是自動套用主流 UX 建議。

明確指定要測哪些 persona

repository 內含多種 personas，但不是每次都需要全部用上。若要提升 critique for UX Audit 的效果，請直接說明哪些使用者類型最重要，例如：

• first-timer
• power user
• cautious admin

這樣能避免輸出把注意力分散在不相關的失敗模式上。

第一輪之後，強制要求排序優先順序

很常見的失敗情況是：得到一長串觀察，但沒有決策價值。做完第一輪 critique 後，可以接著追問：

• 「Which 3 issues most threaten task completion?」
• 「Which issue is most likely to reduce trust?」
• 「What should be fixed before launch versus later?」

這樣能把分析真正轉成可執行的行動計畫。

提前說明模型必須遵守的限制

如果你的介面必須維持：

• 高資訊密度
• 企業感
• 合規要求
• 品牌一致性
• mobile-first
• 低工程成本

就直接說清楚。否則 critique 很容易提出更乾淨、但實際上不可行的 redesign 建議。

留意不要對「AI slop」過度矯正

這個 critique skill 的強項之一，是能抓出常見的 AI 生成式設計套路。但使用者也不應因此反應過度，為了顯得特別就把所有現代設計慣例全部拿掉。更好的問題不是「有沒有不一樣」，而是「這個設計是否有辨識度，且符合使用情境」。把這一段用來揪出偷懶式同質化，再回頭用可用性驗證修正方向是否合理。

用前後版本迭代來改善輸入品質

最佳做法：

1. 先對目前設計執行 critique
2. 套用或模擬 2–3 個重大修改
3. 再對修正版執行一次 critique
4. 比較主要風險是否真的下降

當你把這個 skill 當成迭代式設計循環，而不是一次性的定論，它會變得實用得多。

critique 輸出偏弱的常見原因

通常是以下幾項少了其中之一：

• 沒有使用者目標
• 沒有產品脈絡
• 範圍太大
• 沒有交代限制
• 提供的 artifact 品質不足以判讀
• 只要求「想法」而不是明確的評估結構

把這些補齊之後，這份 critique 指南通常就會變得更具行動性。

一個更好用的 critique prompt 模板

你可以用這種 prompt：

• “Use the critique skill on [area].
• Product: [what the product does]
• Audience: [who this is for]
• Primary task: [what the user needs to do]
• Success metric: [what success looks like]
• Constraints: [platform, compliance, technical, brand]
• Review for: AI-slop signals, hierarchy, cognitive load, heuristics, and 2 relevant personas.
• Output: top issues, severity, why they matter, and concrete fixes.”

這個模板和 repository 預期的 critique 使用方式高度一致，通常也比開放式提問更能產生高訊號的結果。