UI 一致性審查
沒有設計師時，「既有畫面」就是設計標準。代理程式會因畫面不同而重新組合 Tailwind 類別，導致相同功能的 UI 在各畫面間略有差異。此審查旨在抓出這些不一致，但不判斷美觀與否。
0. 模式
| 模式 | 目標 | 阻斷對象 |
|---|---|---|
| 自我檢查 | 自己修改的畫面 | 修正 |
| 變更審查 | PR 修改的畫面檔案與樣式 | 僅本次變更產生的不一致 |
| 全面檢查 | 整個畫面 | 全部 |
1. 讀取標準
-
尋找
docs/review/design.md。若無，則使用CLAUDE.md或AGENTS.md指定的設計文件。 -
從標準文件中擷取：原則、Token（顏色角色、間距、寬度、字型）、共用元件、狀態表現（載入、空列表、錯誤、權限不足、成功）、用語語氣與詞彙。
-
若無標準文件，則從既有畫面中提取。
# 依角色列出實際使用的值與頻率 git grep -hoE "text-(red|amber|green|zinc|gray|slate)-[0-9]+" -- 'src/**/*.tsx' | sort | uniq -c | sort -rn git grep -hoE "max-w-[a-z0-9]+|gap-[0-9]+|px-[0-9]+|py-[0-9]+" -- 'src/**/*.tsx' | sort | uniq -c | sort -rn以使用頻率最高的值作為標準，並在報告第一行註明「無標準文件 → 從既有畫面中提取」。若無標準文件，僅將內部不一致標記為 blocking。
2. 檢查項目
- Token：相同角色是否使用了不同值（例如錯誤顏色
red-600與red-500，頁面寬度max-w-2xl與max-w-3xl）。是否引入了標準中沒有的新值。 - 元件：相同功能的 UI（主按鈕、連結、錯誤訊息、空狀態、載入指示）是否複製類別字串重新繪製，而非使用共用元件。
- 佈局外殼：頁面寬度、邊距、標題位置、返回按鈕位置是否與其他畫面一致。
- 狀態表現：載入、空列表、錯誤、權限不足、儲存成功是否以與既有畫面相同的方式（位置、顏色、句子結構）呈現。
- 用語：語氣（敬語、平語等）是否一致。是否用不同詞彙稱呼相同對象。錯誤訊息是否符合「什麼沒成功 + 該怎麼做」的結構。
- 開發用資訊：測量值、內部 ID、雜湊值是否顯示在使用者畫面上。若標準文件不允許，則指出。
- 基本無障礙：輸入欄位是否有 label，狀態是否僅以顏色區分，按鈕是否可用鍵盤操作，文件語言（
lang）是否與畫面語言一致。
3. 以畫面驗證
若可執行，則使用相同資料比對變更前後畫面（使用 compare-output 技能）。若需登入或外部憑證而無法執行，則標註為「僅以程式碼判斷」。不得將未執行的畫面描寫成已執行。
4. 判定
blocking
- 違反標準文件的規則。
- 相同功能的 UI 引入了與既有畫面不同的表現（值、句子結構、位置）。
- 有共用元件卻複製類別字串重新繪製。
suggestion
- 無標準文件領域中的新模式。標註為「標準建議」，供人決定是否加入標準文件。
- 原本就存在的不一致。
不列入的事項：個人偏好（這個顏色比較漂亮）、與標準無關的新設計建議。
5. 報告
第一行：審查範圍、是否有標準文件、是否實際查看畫面、發現數量。
每個項目：
- 標題：以結果描述不一致。（例如：「僅文章畫面的頁面寬度較寬，切換畫面時內容位置會移動」）
- 位置：
檔案:行號與比較對象的檔案:行號。 - 標準：違反了哪條規則或哪個既有畫面。
- 方向：應使用哪個值或元件來統一。
- 等級。若為「標準建議」，則說明應在標準文件中新增什麼。