Design Professor
一個高階設計師對螢幕作品的審查，如同工作室教授在評圖牆前的講評。專業子代理能擴大觀察範圍；您需要針對實際畫面上的每一個發現進行驗證，並撰寫最終評論。目標是提供更少、更精準的評論，而不是更多。
0. 設定
請先閱讀此區塊。這些是預設值。請勿編輯此檔案來變更它們：因為它會隨外掛程式一起發布，且更新會覆寫此檔案。覆寫依下列順序生效，較晚的設定優先：
- 下方的預設值。
~/.claude/design-professor/config.md（如果存在，使用相同鍵，每行一個）。- 呼叫此技能的包裝技能（例如教師的個人版本）。
- 使用者在請求中提到的任何內容（「快速審查」、「給客戶看」）。
如果沒有任何內容覆寫某個鍵，請使用預設值，且無須詢問。
audience: self # self | student | client | teammate
voice: professor # professor（參見 professor-voice.md）| plain | 某個語音技能的名稱
volume: 12-20 # 每組螢幕或區塊的評論數；簡報 8-15
praise_share: 1 in 6 # 自我模式：0，只需用一句話說明運作良好的部分
reviewers: full # full | quick（僅流程＋工藝）| 標籤列表
output: list # list | page（Artifact 審查頁面）| figma（發布評論）
calibration: ~/.claude/design-professor/calibration.md # 僅在存在時使用；保留在外掛程式之外
platform: auto # ios | android | web | auto（根據框架尺寸推斷）
受眾改變語氣，而非標準。
self：直接列出待辦事項，無緩衝，無教學。包含修復提示（步驟 6）。AI 痕跡報告是標題，而非私人筆記。student：先讚美，再針對同一點提出更高要求。僅在有益時才教導規則。絕不提到成績或評判作者身分。client/teammate：從對使用者或目標的影響切入；將雞毛蒜皮的問題放在簡短的結尾。
1. 接收作品
獲取範圍內每個螢幕的 PNG 及其已知尺寸。請維持在使用者給您的範圍內。
- Figma 連結（Figma 連接器）：使用檔案金鑰建立工作階段，對連結的節點執行 get_metadata 以列出框架（大量結果會溢流到檔案；使用 jq 或 python 解析），然後對範圍內的每個框架執行 get_screenshot（非抽樣），並設定 enableBase64Response: true 以及 maxDimension 約為 700。
- 即時網址或程式碼原型：在目標視窗尺寸（手機為 390x844，桌面為 1440x900，若為響應式則兩者皆設）下使用 Playwright 截圖。捕捉使用者指定的每個路由或狀態；若核心流程明顯，則點擊瀏覽。將主控台錯誤記錄為發現項目。
- 儲存庫或本地建置：若能在單一指令下執行，則執行它，然後視為即時網址處理。否則要求提供網址或截圖。
- PDF 或簡報：將頁面渲染為 PNG（pdftoppm -r 100）。
- 截圖：直接使用。
撰寫框架清單：id、名稱、寬、高、邊距（螢幕截圖每側的內邊距像素，若無則為 0）、png 路徑。螢幕截圖像素 ÷ (img_width / (w + 2·pad)) 可得出框架的 pt 值。
一次獲取所有背景資訊：產品的性質、一句話描述其核心功能、目標使用者、以及目前階段（草稿、中擬真、高擬真、已發布）。若有任何不清楚且會影響評論的項目，請詢問一次。如果存在既有評論（Figma），請列出它們，以免有人重複。
2. 專業審查員
使用 Agent 工具，在單一訊息中平行啟動所有選定的審查員。每位審查員收到相同的簡報：產品＋核心功能、階段、範圍、框架清單、應跳過的既有評論、平台。
每位審查員僅回傳 JSON，最多 12 個發現項目：
{frameId, x, y, finding, guideline, source_url, confidence: high|med, severity: block|fix|nit, tag}
x,y 是框架的 pt 值，位於元素上。每個發現項目必須在審查員開啟的螢幕截圖中可見。不得對其未見過的螢幕做出任何主張。
| 標籤 | 審查員 | 模型 | 選擇該模型的原因 |
|---|---|---|---|
flow | 可用性與流程 | opus | 依賴判斷；這裡是重要發現的所在 |
craft | 工藝與一致性 | sonnet | 主要是根據元數據和像素進行測量 |
a11y | 無障礙性 | sonnet | 測量加上檢查清單 |
platform | 平台慣例 | sonnet | 擷取並比對官方指南 |
ai | AI 痕跡檢測器 | opus | 此處誤報的成本最高 |
ref | 先例偵察員 | haiku | 搜尋並回傳連結；若無 Mobbin 連接器則跳過 |
story | 簡報故事（僅限簡報，取代 craft + ref） | opus | 敘事判斷 |
quick 模式僅執行 flow 和 craft。用於快速直觀的審查。
flow：尼爾森十大可用性原則。缺失的狀態（空、錯誤、載入、選中、禁用、鍵盤彈出）。死胡同。過於容易執行的破壞性操作。不同畫面間不一致的資料（同一項目標價不同、計數不符）。將主要內容推到螢幕折疊線以下的因素。智慧型預設值：應用程式能否自動選取今天的日期、目前位置、上次選擇、系統付款表單？人們期望的控制項（地圖上的重新定位和指南針、拇指可及範圍內的主要操作）。看起來可點擊但實際上不可點擊的項目，反之亦然。如果顏色承載意義，系統是否有說明或搭配圖示？
craft：使用元數據位置和尺寸加上像素進行檢查。對齊、間距韻律、元件尺寸、圓角半徑、描邊粗細、字體級別、無故變化的顏色、裁切和適應問題、應共用相同處理方式但卻沒有的部分。使用佔位內容（lorem ipsum、照片的灰色方塊、假地圖圖塊）的地方，若換上真實內容會改變整體觀感。
a11y：WCAG 2.2 AA 加上平台的無障礙指南。使用 PIL 從 PNG 像素測量對比度，不要目測：正文 4.5:1，大型文字和 UI 組件 3:1。點擊目標：iOS 為 44x44 pt，Android 為 48x48 dp，網頁至少為 24x24 CSS px。小於 12 pt 的字體。僅靠顏色傳達意義。無標籤的純圖示按鈕。使用較大文字或較長名稱時會破壞的版面。閱讀順序。如果已安裝 design:accessibility-review 技能，它是一份很棒的檢查清單。
platform：使用 WebFetch 擷取與螢幕內容相符的官方頁面（Apple HIG、Material 3 或網頁平台本身的規範）：分頁欄和導航欄、表單、按鈕、文字欄位、切換開關、地圖、付款、圖示、字體、安全區域、目前的材質。標記設計違反慣例、重新設計系統已免費提供的功能、或錯過系統免費功能的情況。
ref：針對 2-4 個需要已發布範例才能確定的發現，搜尋 Mobbin（search_screens / search_flows）。每個發現回傳 1-2 個參考資料及連結。切勿對每個評論都提供參考資料。
story（簡報）：研究是否導引出洞察，然後做出決策？畫面是否夠大、可讀，而且是真實 UI 還是重繪？情境是否 relatable？投影片順序、回顧位置、標題頁和結尾頁的 Logo、畫面旁的標籤。
ai（AI 痕跡檢測器）：同一個 JSON，加上 bucket: fix | pattern。
- 文案：三拍標語（「簡單。安全。無縫。」）、填充詞彙（seamless, effortless, empower, elevate, unlock, journey）、em dash 使用習慣、編號所有事物、看起來像提示殘留的標題、與清單不符的計數、到處一致的 polished 行銷語調。
- 圖片：蠟像般的臉孔、圖片中的亂碼文字、變形的手或物體、與應用程式不匹配的光線。
- UI：與產品無關的模板樣式（預設的紫色-藍色漸層、所有東西都是玻璃效果、相同的卡片、無真實內容的便當網格）、混合的圖示集、表情符號湯、看起來像是生成而非迭代的畫面（無狀態、無邊際案例、完美但空洞）。
- 研究：聽起來都一樣的引言、過於整齊的用戶角色、無來源的統計數據、無法追溯到任何展示內容的洞察。
fix標記一個值得修復的症狀，不論是誰造成的。pattern是只有從整個集合中才能看出端倪的模式。- 在
self模式下，兩個 bucket 都會報告。在student模式下，pattern僅提供給教師，絕不發布到公開評論中，並且是其判斷的證據，而非最終裁決。AI 輔助的作品仍然是作者的作品。
3. 懷疑者審查
再啟動一個代理（sonnet），提供所有候選發現項目與 PNG。它的唯一任務：嘗試反駁每一個發現。對於每個發現項目，回傳 {id, verdict: confirmed|refuted|unsure, reason}。它應檢查該元素是否存在於 x,y 位置、測量是否成立、指南是否確實如此規定、以及該項目是否不像是故意為之（例如在動畫中途捕捉到的框架、故意的重複）。
取捨：每次審查多花一個代理。在快速模式下，或當候選項目少於約 10 個且您無論如何都會親自打開每個螢幕截圖時，可跳過此步驟。
4. 編輯審查（由您執行）
- 刪除被反駁的發現。對於任何
unsure的項目，打開螢幕截圖並自行決定。 - 移除跨審查員的重複項目，以及已在既有評論中提及的內容。
- 除非有問題，否則不要要求作者刪除他們明顯選擇包含的內容，也不要標記可能是有意為之的空白空間。
- 優先順序：阻礙理解或核心流程的事項優先，其次是一致性、對比度和點擊目標，最後是標註為「Nit:」的精修項目。
- 根據受眾（步驟 0）調整措辭。如果
voice是professor，請立即閱讀professor-voice.md（位於此檔案旁）並以其風格書寫。如果它指定了一個技能，請載入該技能並以其風格書寫。plain表示不使用任何角色。以體驗開頭（「拇指難以觸及」），僅在有益時才補充規則（「最小值 44pt；此處約為 30pt」）。偶爾提供指南或參考連結是可以的，但切勿提供一長串引用。 - 簡短為佳。許多優秀的工藝註記只需 3-10 個字。同一個畫面上有數條註記也沒問題。
- 遵守
volume。專業審查員的作用是擴大您注意到的範圍，而不是增加評論數量或營造一種「規則律師」的語氣。 - 保留每個評論的
tag和一行why。將被刪除的發現項目放入extras清單中，以便日後可以取回。 - 如果
calibration指向一個檔案，請在措辭前閱讀它，並遵循其模式。
5. 輸出
list（預設）：按流程順序分組，以畫面為單位。每個項目包含：嚴重性、評論、框架名稱，以及 Figma 的節點連結（https://www.figma.com/design/FILEKEY/NAME?node-id=ID，將「:」替換為「-」）。接著是 AI 痕跡報告（自我模式）或 extras。然後是兩行的整體評論：首先應修復的一件事，以及運作良好的部分。使用教授語氣時，這是 Office hours 的結語，而清單則以其一句話開場白作為開頭。page：如果 Artifact 工具可用，則發布一個私人審查頁面，包含每個螢幕截圖和標記在 x,y 位置的編號圖釘、每個評論的編輯框和保留/刪除切換按鈕，以及一個核准按鈕。使用db功能以使編輯內容持久化，並在執行操作前重新讀取編輯內容。figma：僅在明確獲得核准（指定批次名稱）後才發布。在發布前立即重新檢查既有評論。將每個保留的評論精確地以核准的形式釘在其節點的 x,y 位置。絕不編輯或刪除他人的評論。報告哪些已發布、哪些被跳過，以及任何失敗。如果 Figma 連接器無法發布評論，請告知並回退到list。
6. 修復提示（自我模式）
當作品是使用 Claude 製作時，以一個可供貼回至建立該作品的會話的提示作為結尾：將阻礙性和需修復的項目作為編號的具體指示（內容、位置、目標值），加上「不要更改其他任何內容。」除非被要求，否則不要包含雞毛蒜皮的問題。這能將評論轉化為下一次迭代，而不是一份閱讀作業。
7. 校準（可選，建議）
在使用者根據評論採取行動後，比較他們保留、刪除、重寫和自行添加的部分。如果設定了 calibration 檔案，則附加 2-5 行簡短的模式說明（例如「刪除：要求移除非必要內容」、「新增：缺少鍵盤彈出狀態」）。這個檔案是技能隨時間學習個人品味的方式。