紅大探索 Impeccable Repo 的大發現：把設計判斷，寫成 AI 的工作流程 (Codex)
從產品訪談、設計診斷到程式檢查，拆解一套值得借鏡的 AI 工作方法
Impeccable 最值得我們學的，是把「設計師怎麼判斷」寫成 AI 能遵循、能檢查、能反覆使用的工作流程。
我追進 Repo，想弄清楚它到底幫了什麼
讀完〈AI 設計的「去味」挑戰：Impeccable 流程如何提升設計深度〉，我最想知道的是：這個 Skill 到底會問我什麼？它憑什麼讓 AI 做出更有設計感的介面？
於是，這次我請 Codex 沿著作者 pbakaus 的 GitHub 專案，核對 README、Skill 原始指令，以及檢測引擎文件。
越往裡面看，越覺得有意思。作者把設計工作拆成了具體任務：先理解產品，建立方向，再動手製作，最後檢查結果。每一段都有它要回答的問題，也有要留下的依據。
這篇記錄的是原始碼與文件研究，還沒有安裝實測。因此，我會把「repo 提供什麼」和「我打算怎麼用」分開說清楚。 第一個發現：先問產品，再談漂亮
我原本好奇，它是不是一開始就問「喜歡什麼顏色、想走什麼風格」。讀了 init 的指令後發現，它先讀專案裡已有的資訊，再補問會影響決策的缺口。 使用者是誰？ 他在什麼情境下，要完成什麼任務？ 產品的價值是什麼？ 它讓什麼事情變得可能，與其他方案有什麼差異？ 哪些事情必須保留？ 有哪些功能限制、品牌資產與已確認的事實？
這些答案會整理到 PRODUCT.md。視覺上的長期決策，則另外記錄在 DESIGN.md。
這個區分讓我很有感：產品要服務誰，是一件事；要用什麼字體與版面表達，是另一件事。前者沒弄清楚，後面再精緻，都可能只是把錯誤的重點放大。 第二個發現：「漂亮一點」可以拆成明確的工作
目前 README 列出 24 個主要指令，涵蓋規劃、審查、修改與瀏覽器中的視覺迭代。對使用者來說，最實用的是終於可以講清楚：這一輪，到底要改善什麼。
我們遇到的問題 可以交給它的任務 --- --- 不知道頁面哪裡出了問題 critique：檢視設計與使用體驗 內容很多，卻抓不到重點 distill：刪減複雜度、凸顯核心 字太小、層級亂、間距不舒服 typeset、layout：處理字體層級與版面 按鈕與提示讓人看不懂 clarify：改善介面文案 想檢查無障礙、效能與響應式表現 audit：進行技術品質檢查 想比較同一個元素的不同版本 live、generate：在瀏覽器中迭代與選擇
我的理解是，這些指令建立了一套共同語言。當我說「先幫我診斷」，AI 應該先找問題；當我說「把閱讀層級整理好」，這一輪就有了清楚的範圍。
對已經有穩定風格的產品，局部修改也應沿用既有設計。加一個功能，不必每次都重新發明整個品牌。 第三個發現：創意探索與程式檢查，各自負責不同的事
文章提到的隨機抽選設計方向，原始指令裡確實找得到。建立全新視覺方向時，AI 先提出有產品與受眾根據的候選，再用 concept-seed 打破總是選安全方案的慣性，讓使用者比較方向。
我把它理解成一種「讓探索真的發生」的安排。候選方案仍然要說明與產品的關係、設計理由和風險，使用者也保有選擇權。
另一個發現是，repo 裡還有實際執行檢查的 Rust 引擎，以及供瀏覽器使用的 WebAssembly 核心。目前 README 說明有 61 條確定性檢測規則，另有交給 LLM 判斷的審查項目。 注意：固定規則的檢測本身不需要 LLM 或 API key；AI 訪談、設計、修改與審查，仍會使用所搭配模型的資源。通過檢測，也不等於已證明使用者會覺得好用。
這個分工很值得學：能明確判定的條件交給程式，必須理解情境的問題交給 AI，再由人確認成果是否符合目的。 想自己試：README 寫的三個步驟
我還沒實際安裝，以下照 README 整理，順序由淺到深： 先健檢，不花 token：npx impeccable detect https://你的網址（也可以掃資料夾）直接跑那 61 條固定規則，不經 LLM、不需 API key，先看自家頁面有哪些 AI 味。 正式安裝：在專案根目錄跑 npx impeccable install，再到 AI 工具裡跑 /impeccable init 開始產品訪談。安裝時會問要不要一起裝 design hook（預設要）：之後 AI 每次改 UI 檔案，hook 就自動掃描，把問題回饋給 AI 修正，不用靠人一條條盯。 先在測試專案試裝：README 特別提醒，在 Claude Code 裡這個 hook 會獨立於模型的工具核准機制執行，第一次編輯就可能下載並快取檢測引擎。確認行為符合預期，再裝進正式專案。 以前：AI 改完畫面，得靠你自己一條條挑出 AI 味。 現在：hook 在 AI 每次改 UI 時自動掃描，問題直接回到 AI 手上修正。 我想怎麼用：先拿一個閱讀頁來驗證
如果拿 MakeClass 來試，我會先挑一個文章閱讀頁，觀察讀者能不能順利找到重點、來源與練習入口。
確認讀者任務 → 診斷理解障礙 → 修改一個重點 → 比較前後表現
這個想法也呼應 Skill 對頁面目的的區分：文章頁幫人理解，編輯器幫人完成操作，招生頁促成行動，作品集則讓作品成為主角。它們可以共享品牌，但不必使用同一套資訊優先順序。
若放進課堂，我會讓學生保留初稿、診斷與修改後的版本，再回答：你改了什麼？為什麼？使用者完成任務時，差別在哪裡？
這樣才有機會把「我覺得比較好看」，推進到「我能說明這樣設計的理由」。 紅大的大發現：專業可以寫成可交接的方法
這次探索最讓我想繼續追下去的，是作者如何把自己的設計經驗，寫成提問方式、工作順序、判斷依據與檢查機制。
對我們而言，這也可以是一個練習：教學、內容編輯、圖文傳播裡，有哪些判斷總是靠老師或資深同事口頭提醒？哪些能整理成規則，哪些必須保留情境判斷？
我會先採用 Impeccable 的產品訪談、設計診斷與局部修整；重要首頁或全新品牌視覺，再考慮投入完整的概念探索。真正的成效，留待實作與使用者測試來回答。
如果要把你最擅長的一項專業寫成 Skill，你希望 AI 在動手之前，先問哪三個問題？ 延伸閱讀與查核說明
本文依本次讀取的 repo 文件整理。專案持續更新，指令與規則數量應以實際安裝版本為準。原文章萃取區的「67 條設計毛病」與目前 README 的「61 條確定性檢測規則」可能涉及不同版本或統計口徑，不直接視為同一數字；文章中的耗時比較也只代表該次案例。
Impeccable GitHub 專案｜Skill 原始指令｜產品訪談流程｜設計方向探索｜檢測引擎架構
起點文章：AI 設計的「去味」挑戰：Impeccable 流程如何提升設計深度
文／紅大・史傑州老師