評審技能 · 5 維度專家評審
產出一個單一檔案的 HTML「設計審查報告」，對任何成品在 5 個維度上進行評分，並提出可操作的修正建議。靈感來自 huashu-design 的專家評審流程。
使用時機
- 當代理（或使用者）產出一個成品（簡報 / 原型 / 登陸頁面），且使用者問「這有什麼問題？」或「幫我審查這個」
- 作為代理在發出其輸出前，針對自身輸出執行的自我檢查迴圈
- 用於比較同一設計的兩個變體
你將產出的內容
一個單一自包含的 <artifact type="text/html"> 審查報告，包含：
- 頁首 — 被審查的成品名稱、日期、審查者（「OD · Critique skill」）、一句話總結
- 雷達圖（內嵌 SVG，無需任何函式庫）顯示 5 項評分
- 五個維度卡片，每個包含：
- 評分 0–10（附帶等級區間：0–4 損壞 · 5–6 可用 · 7–8 優秀 · 9–10 卓越）
- 一段證據說明（引用具體元素 / 檔案 / 行號）
- 各一個「保留 / 修正 / 速效改善」要點
- 底部合併的動作清單：
- 保留 — 哪些做得好，不要動
- 修正 — P0 / P1 級、視覺代價高昂的問題
- 速效改善 — 5–15 分鐘就能完成、且影響力不成比例的小調整
5 個維度
每個維度是獨立的 — 一個成品可能在創新性上獲得 9/10，但在層級上只有 4/10，報告應該如實陳述。不要平均掉有趣的失敗。
1. 哲學一致性 · 哲學一致性
成品是否選擇了一個明確的方向，並在每個微決策（邊框 / 引言 / 間距 / 強調色）中堅持到底？
需尋找的證據：
- 是否有一個明確的設計方向（例如 Monocle / WIRED / Kinfolk），還是三個風格混搭？
- 邊框 / 引言詞彙是否保持同一語調，還是第 3 頁寫「Vol.04 · Spring」，第 7 頁卻寫「BUT WAIT 🔥」？
- 強調色 / 襯線字 / 等寬字是否從頭到尾遵循同一規則？
0–4 三種風格互相衝突。5–6 一個方向，但有一半元素偏離。7–8 連貫，邊緣頁面偶爾偏離。9–10 每個元素都支持同一個論點。
2. 視覺層級 · 視覺層級
陌生人能否在不需他人告知的情況下，知道先讀什麼、再讀什麼、最後讀什麼？
需尋找的證據：
- 每頁最大的字型是否清楚地標示該頁最重要的資訊？
- 等寬 / 襯線 / 無襯線字型的角色是否與資訊的角色相符（元資料 / 內文 / 標題）？
- 是否有過多「強烈」的元素在競爭？還是有一個清晰的主要 + 次要 + 第三層級？
0–4 所有元素都在搶眼。5–6 層級在首頁有效，但在內頁失效。7–8 層級明確，偶有碰撞。9–10 視線毫無阻礙地移動。
3. 細節執行 · 細節執行
那 90/10 的部分 — 對齊、行距、大字型的字距、圖片構圖、頁尾/邊框潤飾、邊緣情況的間距。
需尋找的證據：
- 大數字頁面：數字是否座落在基線上，還是浮動？
- 在
grid-2-7-5中，左右欄頂部是否對齊？ frame-img與說明的比例是否在頁面間一致？- 等寬標籤：是否有相同的字母間距？相同的大寫規則？
- 是否有孤立的
<br>導致出現單一字的行？
0–4 明顯的膠帶和繩子。5–6 大部分頁面乾淨，1–2 處粗糙。7–8 精緻，專家眼光能找到 2–3 處失誤。9–10 雜誌等級 — 那種會讓手作排版師點頭的細節。
4. 功能性 · 功能性
成品是否能運作於其預期用途？點擊目標、導航、在簡報距離的可讀性、程式碼區塊的可複製性、相關的行動裝置備援。
需尋找的證據：
- 簡報：鍵盤 / 滾輪 / 觸控導航是否都正常？Iframe 滾動備援？
- 登陸頁面：CTA 是否在折頁之上？電話號碼在行動裝置上是否可點擊？
- 執行手冊：程式碼區塊可複製、使用等寬字型、無智慧引號？
- 關鍵資訊在 4 公尺外（大螢幕簡報）是否可讀？
0–4 視覺上還可以，但無法完成其任務。5–6 核心流程正常，邊緣情況失效。7–8 在正常使用下穩健。9–10 防禦性工程 — 處理 iframe / 全螢幕 / 貼上 / 列印時毫不猶豫。
5. 創新性 · 創新性
是否超越了一般水準？是否有一個元素能讓人們湊近看？
需尋找的證據：
- 一個出乎意料的版面 / 動態 / 字型手法，且並非必要？
- 還是 100% 安全 — 可能是任何一家公司做出的任何簡報/登陸頁面？
- 這個創新是掙來的（符合方向）還是硬貼上去的（在一個 Kinfolk 慢活風格的簡報上亂加 WebGL）？
0–4 一般的 AI 垃圾水準。5–6 稱職但令人難忘。7–8 一個令人難忘的時刻，其餘部分紮實。9–10 多個你會想偷來用的手法 — 但每一個都明顯服務於主題。
評分紀律（在評分前閱讀）
- 務必引用證據 — 「評 4 分因為首頁將 Playfair 顯示字型與 Inter 無襯線字型放在同一行」優於「感覺不一致」。沒有證據的數字會被拒絕。
- 不要平均拉高 — 如果層級是 5 分因為第 3 頁壞掉了，不要因為第 1、2 頁不錯就提高到 7 分。分數代表最差的持續水準。
- 不要分數膨脹 — 7 分代表優秀，不是可接受。如果每個分數都是 7+，表示你沒有認真在評審。
- 創新性可以低分 — 生產用途的交付物 5/10 完全可以。不要懲罰恰當的保守。
工作流程
步驟 1 — 取得成品
三種模式：
- 專案檔案 — 使用者說「審查我剛做好的 index.html」：從專案資料夾開啟它。
- 貼上的 HTML — 使用者在聊天中貼上程式碼：從訊息中讀取。
- 由你在本次對話中產生 — 你剛剛在上面發出一個成品，想要自我評審：重新讀取你自己的
<artifact>。
如果有多個 HTML 檔案存在，詢問哪一個（不要全部審查）。
步驟 2 — 讀取足夠資料以進行評分
快速瀏覽整個 <style>，然後閱讀 6–8 個代表性內容區塊。不要只靠前言就評分。 評分取決於實際執行出來的設計，而非聲稱的意圖。
步驟 3 — 帶著證據評分
針對 5 個維度中的每一個，寫下評分和一段 30–80 字的證據段落，並具體命名元素。使用行號、類別名稱、頁碼。
範例：
維度：細節執行
評分：6 / 10
證據：第 3 頁的統計卡片對齊乾淨（grid-6, 3×2），但在第 8 頁，右欄的頁腳比左欄高了 2vh，因為 .callout 有 3vh 的上邊距，而圖片沒有。圖片說明在第 5 頁使用等寬字，但在第 7 頁使用無襯線字 — 請選擇一個統一。
步驟 4 — 建立動作清單
將 5 段證據彙整成：
- 保留（3–5 個要點）— 具體指出哪些地方做得好，使用者在下一輪迭代中絕對不能破壞它們。用類別 / 頁面 / 元素來引用。
- 修正（3–6 個要點）— 必須做的事，依每分鐘花費所節省的視覺成本排序。每個要點不超過一句話。
- 速效改善（3–5 個要點）— 每個花費 5–15 分鐘，訊噪比高（例如「將第 4 頁的
display:flex換成grid以修正欄位移動」）。
步驟 5 — 發出報告 HTML
建立一個單一檔案：
- 頁首：成品名稱 + 審查者署名 + 日期
- 大雷達圖（SVG）
- 5 個維度卡片，以 1 欄或 2 欄網格排列
- 底部三個動作清單，帶有核取方塊
如果存在活躍的 DESIGN.md token 則使用它；否則預設為中性淺色主題（米白背景、近黑文字、一個雷達填充強調色）。
輸出合約
<artifact identifier="critique-<artifact-slug>" type="text/html" title="Critique · <Artifact Title>">
<!doctype html>
<html>...</html>
</artifact>
在成品之前說一句話（「已在 5 個維度上審查 X，請見下方報告。」），然後在 </artifact> 之後停止 — 不要在聊天中複述報告內容；使用者會直接閱讀成品。
嚴格規則
- 5 項評分，每次都要 — 不允許部分報告（例如只有 3 個維度）。
- 每個評分都要有證據 — 不允許「感覺不對」/「需要改進」。如果你無法引用一個元素，該評分就沒有正當性。
- 不要分數膨脹 — 總平均超過 8 分很可疑；請自我檢查。
- 在同一次對話中不要審查自己剛發出的成品 — 使用者需要先看到它。只有在明確的要求下才進行自我評審（例如「現在評審你剛做的東西」）。
- 僅限單一檔案 HTML — 不允許外部 CSS/JS。所有內容內嵌。
- 雷達圖是強制的 — 它賦予報告一個可識別的輪廓，讓使用者能一眼看出弱勢維度。