Impeccable 教學：62 條設計檢查能抓什麼，為什麼潤飾後還要驗收？

Impeccable 希望讓「再有設計感一點」變成比較明確的工作。你可以請 AI 潤飾或調整層級，再用一組固定規則檢查頁面。

它把兩種能力放在同一個專案：給 AI 讀的設計指令，和不用模型也能執行的偵測器。兩者各自解決一部分問題。

AI 郵報 11 月 14 日用五張定價頁做了一次小型比較。依照潤飾說明修改後，偵測命中從十八筆減為十四筆，但一個價格折扣矛盾沒有被規則抓出來。

這個結果讓工具的用途更清楚。它適合幫團隊整理修改方向、找出部分排版問題，重要內容和實際操作仍要另行驗收。

Impeccable 的設計指令，為什麼不能只看名字？

同一個形容詞，交給不同人可能得到完全不同的畫面。Impeccable 的做法，是替指令補上設計原則，讓 AI 知道這次改動要往哪個方向走。

專案 README把 polish、critique、audit 等用途分開。polish 偏向收尾潤飾，critique 偏向設計評論，audit 則檢視技術與可用性問題。

作者 Paul Bakaus 在演講裡，以 bolder 說明這種定義的重要性。它指向更明確的層級、大小與字體決定，並不等於任意加上發光或漸層。

所以，選指令前先說清楚工作目標。例如你想讓價格更容易比較，應先描述讀者目前找不到哪個數字，再讓 AI 選擇如何修改。

如果只留下「更大膽」，卻沒有說明要凸顯什麼，仍可能得到風格改了、問題沒解的頁面。工具提供詞彙，判斷優先順序仍由人負責。

偵測器不用 AI，但掃描方式會影響結果

偵測器採固定規則，會依頁面特徵判斷是否命中。11 月 14 日的專案與本地規則清單共有六十二條，分為三十一條 AI 常見樣式及三十一條品質檢查。

固定規則的好處是，可以重複跑同一組檢查。它不必每次請模型評論，也不需要模型服務的金鑰，讓修改前後比較更容易保持條件一致。

但檢查原始碼和檢查網址有不同的資訊。官方偵測器文件說明，需要渲染結果的檢查，例如字太小或對比不足，必須在掃描網址時執行。

渲染指瀏覽器把程式碼變成實際畫面。字怎麼換行、顏色疊在一起是否清楚，往往要到這一步才看得出來。

因此，只對檔案跑完得到零項，不能推定網站沒有問題。若要檢查交付畫面，應啟動頁面，再用實際網址與指定寬度掃描。

以已在本機啟動、網址為 http://localhost:3000 的頁面為例，可以分別掃桌面和手機版。執行以下指令需要 Node.js，以及本機可用的 Chrome 或 Edge。

npx impeccable detect http://localhost:3000
npx impeccable detect --viewport 390x844 http://localhost:3000

五張定價頁的十八筆命中，怎麼計算？

這次實驗的單位是規則命中紀錄，沒有把所有結果統稱成獨立缺陷。相同頁面在不同寬度命中同一規則，可能各形成一筆。

AI 郵報使用同一份 Tidepool 定價頁需求，請五個子代理各製作一頁，第一輪不提供設計技能。模型身分為子代理自報 Opus 5.5，無法獨立驗證。

接著分別以 1280×800 和 390×844 掃描。五頁都有至少一筆命中，合計十八筆，單頁合計最少一筆、最多九筆。

這十八筆包含六筆 warning 與十二筆 advisory。後者是供人考慮的觀察，不會單獨讓掃描判定失敗，因此命中數也不能直接當成必修錯誤數。

其中兩頁在桌面寬度沒有命中，手機寬度卻各有一筆。這說明單看電腦版會漏掉此樣本裡的排版狀態，並不代表所有網站都會有相同比例。

第二輪讓子代理讀官方 polish.md，再各自修改一頁。這是依文件進行的實驗，並非在 Claude Code 裡執行外掛的完整 /polish 工作流。

以下把兩輪數字放在同一個口徑下比較。

命中總數少了四筆，但改善並不平均。標題斷行的兩筆消失，尾行問題仍大多存在，所以不宜只用總數宣告潤飾完成。

輔助提示則往另一個方向提醒我們：有些改進不在偵測清單裡。這五頁新增給螢幕閱讀器的狀態訊息，卻沒有對應的固定規則可用來計分。

價格折扣錯了，六十二條規則為何沒提醒？

規則檢查排版特徵，無法替代商業內容核對。實驗中有一個清楚的例子，頁面寫節省兩成，但團隊方案從每月十二美元變成十美元，依這兩個價格計算約省百分之十六點七。

第二輪的四個子代理指出這個矛盾，偵測器的結果沒有價格相關命中。這項差異沒有被十八或十四的總數表達出來。

因此，交付前應把文案與數字另外列為驗收項目。定價頁至少要核對每月和每年計價的單位、切換後顯示的金額，以及折扣是否對得上。

這些是根據本次案例整理的檢查建議。實驗只有五頁、一種需求和同一個自報模型，不能據此估計工具在其他任務的準確率。

用在哪一步，才比較能幫上忙？

適合的用法是先找出具體問題，再選對應的指令修改，最後重掃同一個頁面與寬度。這樣每次改動都有前後依據，也容易發現修了一處卻改壞別處。

例如偵測器指出手機標題換行不平衡，可以把那一筆結果交給 AI，要求保留意思與字級層級，只修正該寬度的版面。

修改後除了確認原命中消失，也要查看其他寬度。否則為了手機縮小字體，可能讓桌面上的內容層級一起變得不清楚。

當任務牽涉按鈕、表單與鍵盤操作，可再搭配無障礙檢查。設計規則與操作測試各有範圍，兩份報告應對照實際頁面閱讀。

延伸閱讀：frontend-design 官方技能怎麼用？把五種模板感改成可檢查的設計需求

常見問題

Impeccable 需要模型服務金鑰嗎？

固定規則的偵測器不需要。若要讓 AI 依照設計指令修改網站，則仍要有你原本使用的 AI 開發環境，兩部分要分開理解。

六十二條全部通過，就沒有 AI 味嗎？

不能這樣保證。規則只能辨認已定義的特徵，內容是否合適、視覺是否有辨識度，以及操作是否順暢，仍須由人檢視。

開源代表所有服務都免費嗎？

專案採 Apache-2.0 授權，這說明原始碼的使用條件。若使用另外的帳號服務，仍要查看該服務的方案與條款；開源授權無法替所有服務決定價格。

先挑一頁，保留修改前後的證據

如果你常需要把 AI 產生的介面修到可交付，可以先挑一張熟悉的頁面，用相同寬度保存兩次檢查。每次只處理看得懂的一組問題，比追求一次清空數字更容易維持設計方向。

需要先把元件名稱說清楚，可搭配介面詞彙教學，讓修改要求直接指到畫面上的對象。

延伸閱讀：UI 元件名稱教學：下拉選單、抽屜、載入與手勢，怎麼寫成 AI 看得懂的需求？

資料來源

• Impeccable 官方原始碼與 README
• Impeccable 官方網站
• Paul Bakaus：AI Engineer 演講