Impeccable：62 條不必靠模型的規則，專門抓 AI 味

模型做出來的頁面，有一種一眼就認得出的長相。你一定看過：全部都用 Inter，首屏壓一層紫到藍的漸層，卡片裡再塞卡片，彩色背景上放灰字，每個標題上方還飄著一塊圓角方形圖示。Paul Bakaus 替這種長相取了名字，然後為它寫了一個 linter。

Impeccable 是給編碼代理用的設計技能。它這週進帳約 6,700 顆星，總數大約 91,500。它的說法是「給你的編碼代理用的設計字彙」，但這句話低估了真正不尋常的部分：它的 62 項檢查是以確定性規則執行，全程不牽涉任何模型。

具體來說是什麼

一個 skill、24 個指令、一個偵測器。它原本是 Anthropic frontend-design skill 的延伸，後來長成一個有自己的主張的東西。

安裝就是在專案根目錄下一行指令：

npx impeccable install
/impeccable init

第二步是多數人會跳過的那一步。init 會針對產品訪談你一輪——受眾、目的、限制、語氣——再把答案寫進 PRODUCT.md。另外還有一個 document 指令，會從你既有的程式碼產生 DESIGN.md。這個拆分很關鍵：產品事實和視覺系統是兩份不同的產物，變動的節奏也不一樣；把它們塞進同一個檔案，正是設計文件最快過期的原因。

接著是那 24 個指令。它們比較像一套字彙，而不是一條工作流程：

craft 跑完整的「先定形狀、再動手做」流程，中間帶視覺迭代。critique 檢視層級、清晰度和情緒調性。audit 檢查無障礙、效能和響應式。polish 在發佈前對齊設計系統。bolder 和 quieter 是方向性調整——放大或收斂。harden 處理錯誤狀態、i18n、文字溢出和邊界情況。typeset 和 layout 修的，是代理生成的介面最常弄錯的兩件事。live 會開一個瀏覽器，就地為指定元素產生變體。

你可以把其中任何一個釘成獨立捷徑：

/impeccable pin audit

它會生出一個頂層指令 /audit。功能很小，但這套字彙到底會不會真的被拿來用，差別就在這裡。

偵測器才是真正有意思的工程

Impeccable 和那一堆 prompt 合集專案的分野在這裡：那 62 條規則不需要模型、不需要 API key，也不需要代理。

npx impeccable detect src/
npx impeccable detect index.html
npx impeccable detect --json .
npx impeccable detect --list-rules

意思是它可以進 CI。一個把回彈緩動加回來、或偷塞一道紫色漸層、或留了 14px 灰字壓青綠底的 PR，可以直接被檢查擋下來，而且沒有人需要為 token 付錢。它還有一個 --github 旗標會輸出 GitHub Actions 標註——對多數團隊來說，這是唯一值得在意的整合細節。

這套規則很有主見，有主見到會惹人不快，而文件也不遮掩。反模式清單禁止 Arial、Inter 和系統預設字體；禁止純黑和純灰（一定要帶色調）；禁止什麼都套卡片、禁止卡片裡再塞卡片；禁止回彈和彈性緩動，理由是過時；禁止彩色背景上的灰字。

其中有些是站得住腳的手藝論證。段落文字在飽和背景上對比不足，是實實在在的無障礙缺陷，只是它同時也顯得很廉價。禁 Inter 則是流行判斷，而流行規則老得快——同一份文件，三年後自己就成了時代標本。但一個沒有主張的 linter 就只是個格式化工具，這個工具的意義恰恰在於它有立場。

因為它是確定性的，所以它也繞得過去。任何想硬上紫色漸層的團隊，加一行行內豁免就好：

<!-- impeccable-disable overused-font: exported brand doc -->

或者用 npx impeccable ignores add-value overused-font Inter --reason "Brand font" 全域管理忽略項目。--reason 這個旗標在做一種安靜的社會工程：它讓例外在 diff 裡看得見。

它怎麼掛進代理

你選的安裝路徑，決定它有多「侵入」。對 Claude Code、Copilot、Codex、Cursor 和 Grok Build，install 會寫一份各家原生的 hook 清單。在 Claude Code 裡是 .claude/settings.local.json，被 gitignore、只在本機生效。在 Copilot 裡是 .github/hooks/impeccable.json，會被提交，和雲端代理共用。在 Cursor 裡是 .cursor/hooks.json，在檔案寫入時的 postToolUse 觸發。

效果是偵測器跑在代理自己的改動上，把發現餵回它的迴圈。這和「想到的時候跑一下 audit 指令」是機制上的差別：它在生成的那一刻就攔下垃圾，而不是等到審查。

代價也是老一套：會往 repo 設定寫東西的 hook，就會出現在 code review 裡；Codex 使用者裝完還得透過 /hooks 明確核准專案 hook。如果你們團隊對「把工具設定提交進 repo」很有意見，submodule 這條路就是為此存在的——git submodule add 加 npx impeccable link --source=.impeccable --providers=claude,cursor，讓工具和它所管轄的程式碼一起被版控。

它修不了什麼

三個界線值得點名。

它沒辦法告訴你這個頁面到底好不好。62 條規則抓的是表面特徵。一個頁面可以通過全部檢查，卻依然毫無觀點——這是 AI 味問題更深的那一層，也是至今沒有 linter 解掉的那一層。

live 模式只能在本地 checkout 上跑。它不會注入到線上網站，HTTPS 也一樣。這合理，但意思是視覺迭代迴圈是開發期的工具，不是審查工具。

而且這套字彙只有在代理真的讀了才有用。Impeccable 自己的說法對這點很誠實：所有模型產出同一種設計，是因為所有模型都在同一批 SaaS 模板上訓練出來的。一個 skill 檔案是對訓練分佈的輕推，而輕推輸給分佈的次數，比任何人希望的都多。

那為什麼不乾脆寫一份檢查清單？

這問題問得對。一份 markdown 風格指南不花什麼成本，做的事差不多。

差別在於強制力。寫在 prompt 裡的清單是建議：模型讀了、同意了，然後照樣給你紫色漸層，因為那道漸層在它的訓練資料裡出現過四萬次。確定性規則會讓 build 失敗。這是另一種性質的壓力，也是唯一能在 deadline 面前活下來的那一種。

第二個差別是顆粒度。清單說「用好字體排印」。Impeccable 的 typeset 指令具體處理層級、字級階梯和字體搭配，偵測器對每一種具體失誤都有各自的規則——也就是說，回饋可以指到某一行 CSS，而不是對著品味比手畫腳。這就是「工具勝過文件」的全部論證，它在這裡成立的理由，和二十年前在 linter 身上成立的理由是同一個。

第三是這套字彙是共用的。bolder、quieter、distill、harden——這些詞設計師和代理都能據此行動。「讓它 pop 一點」則不行。

它為什麼現在紅

因為量的問題來了。一年前，代理偶爾生成一個著陸頁。現在一個團隊午飯前就能生出四十個版本，瓶頸已經從「我們做不做得出來」變成「我們能不能夠快地判斷哪一個是好的」。

針對廉價失誤做確定性檢查，是這個問題裡唯一能規模化的部分。品味不能規模化。六十二條關於字體和緩動的、正則形狀的規則可以；而把它們做成一個不需要模型呼叫、能跑在 CI 裡的東西，是這個 repo 裡最不性感也最有用的決定。