audit

audit 技能總覽

audit 技能會做什麼

audit 技能會對已實作完成的前端內容執行技術型 UX Audit，並將發現整理成結構化報告。它會檢查可量化的品質面向，包括無障礙、效能、主題一致性、響應式行為，以及實作上的 anti-patterns，接著為各面向評分，並依嚴重程度將問題標記為 P0 到 P3。

誰適合安裝 audit

這個 audit 技能特別適合前端工程師、設計工程師、UX 工程師，以及需要在發版前檢視頁面、元件或功能的 AI agent。若你要的是可重複執行的稽核流程，而不是一句籠統的「幫我 review 這個 UI」，它會特別有價值。

真正要解決的工作需求

多數使用者需要的不是泛泛而談的回饋，而是一套能夠：

• 聚焦在有程式碼依據的問題
• 把關鍵缺陷和細節潤飾清楚區分
• 避免過早直接動手修
• 留下可交接、方便後續實作的報告

這正是它的核心價值：在你請另一個技能或 agent 開始修改之前，先跑一次技術品質審查。

這個 audit 和一般提示詞有何不同

它最大的差異在於範圍控制非常明確。這個技能明白把 audit 定義為技術審查，而不是針對視覺品味的評論。它會要求從五個面向進行診斷式掃描，使用一致的評分模型，並以嚴重程度為基礎輸出報告與行動計畫。這讓不同頁面之間的結果更容易比較，也更容易直接轉成後續工作項目。

導入前的重要注意事項

這個技能依賴前置脈絡。它本身的指示要求先呼叫 $frontend-design，若設計脈絡仍不足，則要在 audit 前先執行 $teach-impeccable。如果跳過這些準備，輸出品質會明顯下降，因為 audit 會依賴共享的設計原則與蒐集脈絡的規則。

如何使用 audit 技能

audit 的安裝與執行脈絡

請從 pbakaus/impeccable repository 將 audit 技能安裝到你的 skills 環境：

npx skills add pbakaus/impeccable --skill audit

由於這個技能位於 .codex/skills/audit，實際上的安裝判斷重點不在依賴套件，而是在於你的工作流程是否適合。你應該預期它會在支援 skill invocation 的環境中使用，並且會搭配同一個 repository 內的其他技能一起運作。

先讀這個檔案

先從這個檔案開始：

• SKILL.md

這個檔案幾乎涵蓋了所有重要行為：前置條件、audit 範圍、評分方式，以及預期的報告風格。這個技能資料夾中沒有可見的輔助腳本或參考檔案，因此多數實作與使用指引都集中在主要的技能文件裡。

執行 audit 前的必要前置條件

不要在沒有脈絡的情況下直接呼叫 audit。技能說明明確要求先執行 $frontend-design，因為其中包含這個 audit 會用到的設計原則、anti-patterns 與脈絡蒐集流程。如果目前仍沒有設計脈絡，則要在 audit 前先跑 $teach-impeccable。

實務上的順序通常是：

1. 蒐集設計與產品脈絡
2. 確認要檢視的是哪個頁面或元件
3. 執行 audit
4. 再用報告驅動後續修正任務或其他技能

audit 技能需要哪些輸入

當你提供明確的目標與 review 脈絡時，audit 技能效果最好。高品質輸入通常會包含：

• 明確的頁面、route、元件或流程
• 對應的程式碼位置或相關檔案
• 預期支援的裝置目標
• 若有需要，提供 framework 或技術棧資訊
• 已知限制，例如 legacy CSS、design system 限制或效能預算
• 此次檢視是發版前檢查、回歸檢查，還是探索性審查

「audit my app」是弱提示；更好的說法會像是：「請針對 checkout page 在 mobile 和 desktop 上執行 audit，重點放在 accessibility、loading behavior 與 responsive breakpoints。」

把模糊需求轉成可用的 audit 提示

好的 audit 使用提示，應該清楚指出目標、定義邊界，並要求結構化輸出。例如：

• 「Run the audit skill on the pricing page. Review accessibility, performance, theming consistency, responsive behavior, and implementation anti-patterns. Score each dimension 0-4, list P0-P3 issues, and end with an action plan. Do not fix anything yet.」
• 「Use audit for the settings modal component. Check keyboard support, semantic structure, focus handling, contrast, theme token usage, and mobile layout failure points.」

這種寫法會比一般的 review 提示更有效，因為它符合這個技能本身的報告模型。

audit 實際會檢查什麼

根據技能說明，這個 audit 會涵蓋五個面向：

• accessibility
• performance
• theming
• responsive design
• anti-patterns

其中 source 對 accessibility 的描述最明確，包含 contrast、ARIA、keyboard navigation、semantic HTML、alt text，以及表單相關問題。這也表示這個技能的取向偏重實作層面，通常會產出具體缺陷，而不是抽象建議。

預期輸出格式，以及它為什麼重要

這個 audit 技能的價值不只是檢查清單，更在於輸出的結構：

• 逐面向檢視
• 每個面向以 0-4 評分
• 使用 P0-P3 嚴重程度標記
• 提供可執行的行動計畫

這種格式很有利於 triage。團隊可以不必重讀整份報告，就先把發版阻塞問題和 backlog 改善項目分開處理。

audit 的最佳使用流程

實務上較理想的流程如下：

1. 先用必要的前置技能建立設計脈絡
2. 選定一個頁面、功能或元件
3. 提供實作範圍與限制條件
4. 執行 audit 技能
5. 檢視分數與嚴重程度
6. 把行動計畫轉成 ticket，或轉成後續修正提示

這個技能在範圍明確、邊界清楚的目標上效果最好。如果你試圖一次 audit 整個產品，發現通常會變淺，優先順序也會變得不準。

什麼情況適合用 audit 來做 UX Audit

當你需要以實作證據來判斷 UX 品質問題時，audit for UX Audit 特別合適。它很適合用於：

• 發版準備度檢查
• redesign 後的回歸檢查
• 比較不同頁面的技術品質
• 在使用者測試前找出無障礙與響應式缺陷
• 產出缺陷清單，交給其他 agent 修復

但它並不適合純研究型問題，例如資訊架構、訊息表達是否清楚，或視覺品牌探索。

邊界與不適用情境

這不是設計評論技能，也不是修復技能。它的任務是記錄問題，而不是解決問題。如果你的真正目標是「讓這個頁面看起來更好」，那只有在你也想要取得一份技術缺陷清單時，才值得安裝它。如果你的目標是「現在就把元件改好」，那除非品質風險很高，否則這一步 audit 可能不是必要流程。

audit 技能 FAQ

這個 audit 技能對新手友善嗎？

是的，只要你已經知道想檢查哪個畫面或範圍。這個技能提供了很清楚的 audit 框架，但新手很容易忽略前置脈絡這一步。如果你在需要時沒有先用 $frontend-design 與 $teach-impeccable，audit 結果就可能變得空泛或前後不一致。

我需要整個 impeccable repository 嗎？

對這個技能來說，主要依賴比較偏概念層，而不是很多檔案本身。可見的 audit 資料夾只有 SKILL.md，但技能說明明確依賴同一個 repository 中的其他技能。因此，你大多數情況下需要的是 repository 層級的存取，而不是孤立地只拿這一個檔案。

audit 和直接叫 AI 幫我 review UI，有什麼差別？

一般提示往往會把主觀的設計喜好與技術缺陷混在一起。這個 audit 技能則強制縮小範圍、固定檢查面向，並要求有分數的輸出。這通常會帶來更好的 triage、更高的跨次 audit 可比較性，也能減少大家圍繞模糊評論來回討論的時間浪費。

audit 可以自動修問題嗎？

不行。這個技能的設計目標是診斷與回報。若你想把審查與實作清楚分開，這反而是它的優點，而不是缺點。正確做法是用這份報告去驅動另一個獨立的修復任務。

我應該先 audit 什麼？

先從一個高影響範圍開始：

• homepage hero 與 nav
• signup 或 checkout flow
• dashboard 入口畫面
• 共用元件，例如 modals、forms、tables

這些區域通常很快就會暴露出 accessibility、responsive 與 performance 問題，讓第一次 audit 更有收穫。

什麼情況下不該用這個 audit 技能？

以下情況可以跳過這個 audit：

• 你只想要主觀的設計靈感
• 目前沒有具體實作可供檢查
• 你需要的是完整產品研究，而不是技術審查
• 你只是要快速交付 prototype，不需要帶評分的正式報告

如何改善 audit 技能的使用效果

給 audit 更明確、更小的目標

想讓 audit 輸出更好，最快的方法就是縮小範圍。請它看一個 route、一段 flow，或一組元件家族即可。「Audit the account deletion flow」通常會比「audit the whole app」產出更有力的發現。

提供 audit 技能預期的脈絡

因為這個 audit 依賴 frontend design 脈絡，最好一開始就補齊它需要的背景：

• 畫面的使用者目標
• 預期的互動模型
• 裝置優先順序
• theme 或 design system 規則
• 商業限制條件

這能減少 false positives，也能讓 audit 依照實際意圖來判斷哪些 anti-patterns 真的是問題。

明確要求只回報有證據的發現

如果你想讓 audit 在實務上更可靠，可以明確要求它只提出可觀察、可驗證的證據。例如要求 agent 在每一項發現後，都指出對應的 element、pattern、state 或 behavior。這會讓報告更貼近實際實作，也更容易驗證。

用發版脈絡提升嚴重程度判定品質

當你定義清楚影響情境時，severity 標記會更準。請告訴 audit 目標屬於哪一種：

• public marketing page
• authenticated product UI
• checkout 或 conversion flow
• internal tool
• mobile-first experience

例如，checkout 裡的 keyboard trap，嚴重程度就應該和 admin 畫面中單純視覺間距不一致的問題區分開來。

audit 使用時常見的失敗模式

最常見的問題包括：

• 跳過必要的前置技能
• 一次 audit 過大的範圍
• 要求直接修復，而不是先診斷
• 沒有提供裝置或 viewport 脈絡
• 把主觀設計偏好當成技術缺陷

這些情況通常會導致報告雜訊變多、優先順序變弱，或範圍混雜不清。

哪些更強的輸入能提升輸出品質

更好的提示通常會包含這類具體要求：

• 「focus on keyboard navigation and forms」
• 「treat mobile Safari as a priority」
• 「check theme token consistency in dark mode」
• 「flag only measurable anti-patterns」
• 「score each dimension and end with top 5 fixes by impact」

這些細節能引導 audit 把深度放在真正重要的地方，因此結果會更好。

第一次 audit 之後如何迭代

做完第一輪後，不要原封不動地重跑同一個大範圍提示。更好的做法是：

1. 先修正或整理出最嚴重的問題
2. 針對同一個明確範圍重新執行 audit
3. 要求對得分最低的面向做更深入檢查
4. 比較分數變化與尚未解決的 P0-P1 發現

這樣可以把 audit 技能變成可重複使用的品質關卡，而不是一次性的報告工具。

把 audit 和後續實作工作配對使用

audit 技能最強的用法，是把它當成兩階段工作流中的診斷階段。先產出報告，再把那份報告當成結構化輸入，交給另一輪獨立的實作處理。這樣可以保留 audit 的客觀性，也能避免一邊 review 一邊修改，反而把重要缺陷掩蓋掉。