Impeccable（pbakaus/impeccable）：把「设计评审」编译成确定性检查——让 AI 编程智能体不再产出同一套界面

一、导读

Impeccable 是 Paul Bakaus（jQuery UI 作者、前 Google Chrome DevTools）开源的 AI 编程智能体设计技能层（Apache-2.0，2025-11-16 创建，2026-10-05 当日涨星 +1,171、总星 76,479）。它只回答一个问题：为什么 AI 生成的界面长得都一样？ 核心结论是——「禁止清单」治不好 AI 设计口水，因为它只是把模型推到潜空间的下一簇；真正有效的是把「设计判断」拆成可确定执行的检查器 + 双盲评审子代理 + 跨会话记忆，让 61 条规则在没有 LLM、没有 API Key 的情况下跑出可复现的结果。

二、项目速览

项目	详情
仓库	pbakaus/impeccable（GitHub API，数据获取日 2026-10-05）
作者	Paul Bakaus（jQuery UI 作者、前 Google Chrome DevTools 负责人、Renaissance Geek 创始人）
主语言	JavaScript（技能 Markdown + 原生引擎二进制 + 安装器 CLI）
Star 总数	76,479；当日涨星 +1,171（GitHub Trending daily，2026-10-05 抓取）
License	Apache-2.0
首次发布	2025-11-16（仓库创建）
最新版本	Skill v4.5.0（2026-10-02）／Engine v0.1.11（2026-10-02）
核心构成	1 个 skill · 24 条命令 · 61 条确定性检测规则 · 6 类设计评审模式 · 设计钩子 · Live Mode
支持宿主	Claude Code、Cursor、Codex CLI、GitHub Copilot、Gemini CLI、Grok Build、OpenCode、Trae、Qoder 等 17 种
运行前提	需要 AI 编程宿主；检测器与钩子本身不需要 Node 或任何运行时

三、为什么是它：问题背景与定位

痛点不是「模型不会写前端」，而是「模型写出的前端高度同质」。 所有模型都在同一批 SaaS 模板上训练过：Inter 字体打天下、紫到蓝渐变、卡片里套卡片、彩色背景上放灰字、每个标题上方都顶一个圆角方形图标块。这类「AI 口水」不是能力问题，而是统计中位数问题——模型的默认输出就是它训练分布的重心。

它的定位：从 Anthropic 的 frontend-design 技能出发，补上三件缺失的东西。 作者自述起点是 Anthropic 那个「让 Claude 停止产出通用紫渐变模板」的设计技能，Impeccable 在其上加了：① 一次性的项目上下文采集（/impeccable init 写出 PRODUCT.md，记录受众、目的、约束、语气）；② 24 条共享设计词汇命令（polish、audit、critique、distill、animate、bolder、quieter…）；③ 61 条确定性检测规则，无需 LLM、无需 API Key 即可运行。

为什么「禁止清单」路线被明确否定。 作者在 AI Engineer 大会的演讲中给出了两层理由：其一，规则会误伤——「不要用系统字体」对营销落地页成立，对应当看起来原生的产品 UI 恰恰相反；其二更根本，禁令不创造创造力，它只是迁移模型。告诉模型别用紫渐变，它就会去取潜空间里次优的 token；社区曾把口水等同于紫渐变，如今已迁移到米色。「Slop is a moving target」——禁止一个字体或颜色，只是把模型推向下一簇。

涨星动因拆解。 一是可验证：61 条规则是确定性的，同一份代码两次扫描结果一致，这是「让 AI 评审设计」永远给不了的；二是零成本可独立使用：npx impeccable detect 完全不碰模型，可以单独进 CI；三是作者信用：jQuery UI 与 Chrome DevTools 的履历让「设计品味」这件事有了可托付的对象；四是生态位卡得准：工程师每周都有新工具，设计师几乎被落下，而 Impeccable 让设计工作发生在真实代码库与浏览器里；五是分发杠杆：据作者公告，Impeccable 已随新版 GitHub Copilot 应用预置捆绑，并由 a16z 领投的种子轮支持（Renaissance Geek），GitHub 为其合作方。

四、【重点】架构原理

4.1 整体架构：技能层 + 确定性引擎 + 钩子

┌── 宿主层（17 种 AI 编程工具）────────────────────────────────────┐
│ Claude Code · Cursor · Codex CLI · GitHub Copilot · Gemini CLI   │
│ Grok Build · OpenCode · Trae · Qoder · Kiro · Rovo Dev · Pi …    │
└──────────────┬───────────────────────────────────────────────────┘
               │ ① /impeccable <command> <target>   ② 钩子自动触发
               ▼
┌── 技能层（.claude/skills/impeccable/，按宿主编译多份）───────────┐
│ SKILL.md（frontmatter：name/description/version/argument-hint）  │
│ reference/*.md（40+ 篇：craft / polish / audit / critique /      │
│   typeset / colorize / layout / animate / harden / live …）      │
│ reference/mode-{persuade,operate,read}.md（按任务类型路由）      │
│ reference/degraded/*.md（子代理不可用时的降级路径）              │
│ agents/*.toml（asset-producer / documenter / finish-reviewer）   │
└──────────────┬───────────────────────────────────────────────────┘
               │ ③ 调用 launcher
               ▼
┌── 启动器与引擎层 ────────────────────────────────────────────────┐
│ scripts/impeccable（sh 启动器，Windows 为 impeccable.cmd）        │
│   → 就近的引擎二进制，或首次运行下载到 ~/.impeccable/bin/         │
│ 动词：context · signals · detect · hook · hook-before-edit …     │
└──────────────┬───────────────────────────────────────────────────┘
               │ ④ 源码扫描 / URL 渲染扫描
               ▼
┌── 检测器层（61 条确定性规则，无 LLM、无 API Key）────────────────┐
│ AI 口水族：gradient-text · side-tab accent · purple gradient ·   │
│   bounce easing · dark glow · nested cards · overused font       │
│ 质量族：low contrast（WCAG AA）· line length 65–75 · 触控目标过小 │
│   · 跳级标题 · 内边距过挤 · 文本溢出容器 · 图片被遮罩盖住         │
│ 设计系统族：字体/颜色/圆角/字号是否越出 DESIGN.md 记录的范围      │
└──────────────┬───────────────────────────────────────────────────┘
               │ ⑤ 退出码 0 / 2 / 1，或 --json 输出
               ▼
┌── 宿主钩子层（把结论塞回智能体流程）─────────────────────────────┐
│ Claude Code：.claude/settings.local.json（PostToolUse + Stop）    │
│ Copilot：.github/hooks/impeccable.json（提交，团队共享）          │
│ Cursor：.cursor/hooks.json（编辑前拦截，坏写入不落地）            │
│ Codex：.codex/hooks.json（需 /hooks 手动批准）                    │
│ Grok Build：.grok/hooks/impeccable.json（需 /hooks-trust）        │
└──────────────┬───────────────────────────────────────────────────┘
               │ ⑥ 读回项目真相
               ▼
┌── 项目真相层（.impeccable/ 与仓库根）────────────────────────────┐
│ PRODUCT.md（受众/目的/约束/语气） · DESIGN.md（视觉系统）         │
│ .impeccable/config.json（团队共享）· config.local.json（每人私有）│
│ design.json · surfaces/*.md（每个界面的方向契约）· critique/*.md  │
└──────────────────────────────────────────────────────────────────┘

关键约束：.impeccable/ 只提交共享产物。 仓库给出一段带 # impeccable-ignore-start 标记的 .gitignore 块，把截图、Live Mode 会话、缓存、每人私有配置全部排除，但明确要求保留 config.json、design.json、surfaces/*.md、critique/*.md——「临时产物」与「项目记忆」被显式分开，这是它能跨会话累积判断的前提。

4.2 分层模块拆解

层	职责与关键接口
技能层	SKILL.md 的 frontmatter 用 description 声明触发条件（何时该用、何时不该用，明确排除纯后端任务）；argument-hint 列出全部子命令；正文规定「每会话先跑一次 scripts/impeccable context」
路由层	reference/routing.md 定义无参数调用时的上下文感知菜单：先读 impeccable signals 的 JSON，再按信号给出 2–3 条最该执行的命令，并明确「永不自动执行命令，推荐只是建议」
启动器层	scripts/impeccable（Windows 为 .cmd）是唯一入口，启动器缺失时静默 no-op；引擎二进制就近查找或首次下载到 ~/.impeccable/bin/，因此钩子与技能本身不依赖 Node
检测器层	61 条确定性规则 + 6 类需人工判断的评审模式；支持源码扫描与 URL 渲染扫描（默认视口 1280×800）、--scope type,layout 限定域、--viewport 390x844 查移动端、管道输入
钩子层	五家宿主各自的钩子清单；Cursor 是编辑前拦截（坏写入不落地），Claude Code/Copilot/Codex 是编辑后报告 + Stop 深扫，Grok 只在 Stop 上报
多代理层	agents/*.toml 定义 asset-producer、documenter、finish-reviewer、manual-edit-applier 四个子代理；reference/degraded/ 是子代理不可用时的降级剧本
记忆层	PRODUCT.md、DESIGN.md、surfaces/*.md、critique/*.md 构成可被后续会话读取的项目记忆
分发层	dist/ 下按宿主编译多份（claude-code、cursor、codex、agents、gemini、opencode、pi、dsh、hermes、trae、rovo-dev、qoder、vibe、grok、github），另有 VS Code 扩展与 Claude Code 插件市场两条通路

4.3 核心机制与算法原理

① 检测器：把「品味」里可判定的部分编译成规则。 这是全项目最硬的工程内核。npx impeccable detect src/ 不需要任何模型调用，因此结果可复现——这正是「让 AI 评审设计」做不到的。规则分三族：AI 口水族（渐变文字、侧边色条、紫渐变、弹跳缓动、暗色辉光、嵌套卡片、滥用字体）、质量族（对比度、行宽 65–75 字符、触控目标过小、跳级标题、内边距过挤、文本溢出、图片被遮罩盖住）、设计系统族（字体/颜色/圆角/字号是否越出 DESIGN.md 记录的范围）。退出码被设计成 CI 契约：0 无主要问题、2 有主要问题、1 至少一个目标扫描失败，且部分失败时以失败优先。

② 双盲评审：为什么必须是两个互不可见的评审者。 作者在演讲中给出了非常具体的失败模式：让模型自评等于自己给自己批作业，它会锚定自己已产出的东西而给出宽松分数。Impeccable 的 critique 因此派生两个子代理——一个扮演设计总监做层次与口水的启发式判断，另一个跑确定性 linter 报硬事实（对比度失败、字体过多、元素贴边）。单代理会以两种可预测的方式失败：一个页面很漂亮但有几百条 lint 错误，单代理会判定设计很差；一个空页面零问题，单代理会判定设计很好。两个互不可见的意见恰好堵住这两个洞。

③ 反吸引子（anti-attractor）：不禁止，而是把模型推出簇。 既然禁令只是迁移，那就用三种递进手段强行发散：其一，削掉安全选项——让模型给出它最想用的三个字体，然后要求全部弃用，重复三轮，每轮把模型推得更远（最终仍会收敛）；其二，无上下文排序——为作者自己的着色器库 Radiant Shaders 生成约 100 个互不重复的着色器时，他用名人名字做创意种子（「蕾哈娜做成着色器会是什么样？」），再让不带会话上下文的子代理排序，因为无锚点才能重排；其三，脚本化随机——项目启动时调用 color.js，从 100 多个手工挑选的主色里返回一个，模型围绕它构建整套配色。同一个 brief 会因返回的颜色不同而产出完全不同的结果。

④ 脚本回话：让指令从 stdout 出来，而不是写在长文里。 作者实测发现长散文式规则会被模型略读，且模型越弱越严重（他点名 GPT-5 mini 经常不加载某些 Markdown 文件）。对策是每次调用都跑 context.mjs，把策略文档合并后从标准输出吐出；文件缺失时返回结构化 JSON 明确告诉模型该怎么处理。经验结论是「从脚本的退出值/标准输出出来的东西，模型遵守度明显更高」。代价：动态脚本输出会破坏 prompt 缓存，因此他建议只用于交互场景，而非高频调用。

⑤ 钩子：被动护栏胜过没人记得敲的命令。 宿主常常不会主动调用技能，除非用户点名。因此 Impeccable 把检测器装成钩子：编辑后钩子报告违规、依赖模型自行修正（适合强模型）；编辑前钩子直接阻止文件写入（更重，但对 Cursor 里的弱模型是必要的）。作者同时给出运维警告：必须配 ignore 规则，因为钩子会产生误报，否则「很快会变得非常烦人」。

⑥ 按模型编译：同一份规则不能简单合并。 作者记录了具体的过拟合尾巴：Codex 把任何东西都圆角化、字距处理差、偏爱发丝边框；Gemini 习惯给每张图加悬停缩放；GPT 与 Codex 特别爱说「gate」。因此不能把规则简单合并——「如果你告诉 Claude 不要字距太大，它会往完全相反的方向字距」。Impeccable 的应对是按宿主替换变量 + 为 Gemini/Codex 插入 XML 块的过拟合规避规则，并针对 Codex/GPT 加载一份含 8 道必须全部通过的 gate 的 codex.md，且要求逐条记录结果。

⑦ 复合工程：跨会话记忆。 技能默认每次从零开始。Impeccable 允许把一次 critique 存成文件，后续（哪怕在不同会话）的 polish 会读取此前的 critique 作为信号，从而看到页面随时间的演进；用户若写下「我不同意这条 critique，我喜欢我的乐器字体」，技能会记录该偏好并遵守。

4.4 性能优化手段与设计取舍

取舍	为什么这么做	代价
检测器完全不用 LLM	结果确定可复现，可进 CI，零 API 成本	只能覆盖可判定的缺陷，无法评价「好不好看」
双盲子代理评审	同时规避「漂亮但 lint 全红」与「空白但零问题」两种误判	跨宿主有墙：Codex 需用户显式授权才能跑子代理
指令从 stdout 输出	弱模型遵守度显著提升	破坏 prompt 缓存，不适合高频调用
按宿主编译多份构建	各宿主的钩子语法、权限模型结构性不同	维护成本高，作者不得不自建 CLI 安装器
编辑前拦截（Cursor）	弱模型不会自行回改，必须硬拦	更重手，误报会直接阻塞写入
用 Live Mode 而非 MCP	作者明确因上下文污染顾虑而完全避开 MCP	需自建本地服务 + SSE，且只能用于本地开发
记忆文件留在仓库	跨会话累积判断，团队共享设计真相	必须精细区分「共享产物」与「临时产物」，否则仓库被截图与缓存污染
不锁死 buildPath	comp（先出高保真稿）与 code（直接写代码）各有适用面	需在 init 时做一次选择，且只在有图像生成能力时才有意义

4.5 与其他架构路线的差异

与 Anthropic frontend-design 技能：后者是静态提示文件，靠「不要用 X」的清单；Impeccable 把清单换成可执行检测器 + 多代理 + 记忆 + 钩子。作者对前者的评价是「证明了方向，但禁令会迁移模型」。

与「写一份超长规则文件」的通用技能路线：不同任务需要互相矛盾的指令（落地页要避开系统字体，产品 UI 恰恰要用），朴素做法是巨型 if/else，作者称其「绕、浪费 token、而且老实说效果不好」。Impeccable 改为内部路由：先判断你在做「品牌向」还是「产品向」，再加载完全不同的规则集。

与纯 Linter（ESLint/Stylelint 类）：传统 linter 不懂 AI 的特定口水，也不懂设计系统语义。Impeccable 的规则是为「每个模型各自会犯的缺陷」编译的，并额外做设计系统一致性检查。

与「让模型自评设计」的路线：作者的态度是模型不能可信地判断品味。他坦承自己的专家混合设计评委「只比随机略好」，并给出一个反直觉的修正：某些维度上把评委分数取反——因为评委 Gemini 会把「首屏塞得越满」评得越高，而模型天生是极繁主义者。

五、【重点】应用场景

场景一：把设计检查变成 CI 门禁（不花一分钱 API）

业务痛点：团队用 AI 批量生成页面，评审时只能靠人眼，且每次结论不一致；想上自动化又不想为「AI 评审」付 token 费。 如何解决：只用检测器，完全不启动 AI 对话。

npx impeccable detect src/                    # 扫目录
npx impeccable detect src/components/Card.tsx # 扫单文件
npx impeccable detect --json src/ > findings.json   # CI 友好
npx impeccable detect --viewport 390x844 http://localhost:3000  # 查移动端
npx impeccable detect --scope type,layout src/      # 只看排版与布局域

收益与量化：退出码即契约（0 通过 / 2 有主要问题 / 1 扫描失败），可直接写进流水线；61 条规则、零 LLM、零 API Key，且因为确定性，同一份代码两次扫描结果一致。适用边界：官方明确「一次干净的扫描是证据，不是证明」——它不替代在真实视口下检视渲染效果，也不评价视觉美感。

场景二：让钩子在编辑当下就拦住 AI 口水

业务痛点：问题总在代码评审才被发现，而那时已经写了十几个文件；让模型「注意设计」的口头提醒基本无效。 如何解决：安装时开启设计钩子，让检测器在每次 UI 文件编辑时自动运行并把结论塞回智能体流程。

npx impeccable install          # 检测宿主并写入钩子清单
npx impeccable update           # 后续刷新
# Claude Code / Cursor / Codex 等需完成各自的可信步骤
# Codex：打开 /hooks 手动批准；Grok Build：/hooks-trust

收益与量化：流程是「智能体编辑页面 → 检测器报出 AI beige / 标签被裁切 → 智能体自行修复 → 二次扫描 0 findings」。Cursor 上钩子是编辑前拦截，坏写入不会落地；Claude Code/Copilot/Codex 是编辑后报告 + Stop 深扫。适用边界：官方要求必须配置 ignore 规则，因为钩子有误报；Claude Code 的钩子独立于模型工具审批运行，无人值守前应先审阅钩子；Codex 的钩子按定义跟踪信任，更新后可能需重新批准。

场景三：用双盲 critique 做一次「设计总监级」复盘

业务痛点：让模型自查设计，它总是给自己高分；请人做设计评审又贵又慢。 如何解决：调用 critique，由设计总监子代理与确定性 linter 子代理分别出意见，主线程综合。

/impeccable critique landing     # 对落地页做 UX 设计评审
/impeccable audit blog           # 无障碍/性能/响应式的技术检查
/impeccable polish settings      # 上线前最后一轮
/impeccable harden checkout      # 错误态、国际化、文本溢出、边界情况

收益与量化：critique 会保存为 critique/*.md，后续 polish 会把它当作待办清单读取，并在过期或清空时关闭；routing.md 明确：critique.latest 的 score 低或 p0/p1 非零时，推荐动作就是 polish。适用边界：作者坦承其专家混合设计评委只比随机略好，定位是「第一遍的导演之眼」，最终仍需人眼标注；且 Codex 上子代理需用户显式授权，否则会走 reference/degraded/ 的降级路径。

场景四：Live Mode 在浏览器里直接改，而不是在聊天框里调像素

业务痛点：设计调整需要「看到并感受变化」，聊天框里描述像素几乎无法收敛；而把设计稿冻结再交给工程翻译的流程已经跟不上每天变化的代码。 如何解决：/impeccable live 起一个本地小服务，向开发服务器注入片段，通过 SSE 把页面交互回传，模型读到 stdout 消息后动作。

/impeccable live                 # 进入视觉变体模式
/impeccable generate             # 对指定元素生成变体，无需手动挑选

收益与量化：作者演示的闭环是「选中元素 → 出现带子命令的浮层 → 选择变化幅度 → 模型立刻生成三个 CSS 变体 → 点选接受 → Esc 退出」。它刻意不用 MCP，理由是避免上下文污染；产物是真实生产代码。适用边界：官方明确 Live Mode 只用于本地检出，把 localhost 助手注入已部署的生产站点（含 HTTPS）不受支持，也不得为它关闭浏览器安全或削弱生产 CSP；此外应用拷贝编辑时会以你的用户权限执行 package.json 里的 impeccable:manual-edit-validate 脚本，在陌生检出中使用前应先审阅该脚本。

六、快速上手

# 1) 项目根目录安装（会自动识别宿主并询问项目级/全局）
npx impeccable install
# 脚本化：--providers=claude,codex,cursor,grok,hermes,veto --scope=project|global
# 跳过钩子：--no-hooks

# 2) 重新加载宿主后，在智能体里初始化项目上下文
/impeccable init        # 写出 PRODUCT.md，并记录 buildPath（comp 或 code）

# 3) 独立使用检测器（无需 AI）
npx impeccable detect src/
npx impeccable ignores add-value overused-font Inter --reason "Brand font"

其他安装通路：Git 子模块（npx impeccable link --source=.impeccable --providers=claude,cursor）、Claude Code 插件市场（/plugin marketplace add pbakaus/impeccable）、VS Code 扩展（需 VS Code 1.109.3+）、官网 ZIP、或直接拷贝 dist/<宿主>/ 目录。

七、横向对比

维度	Impeccable	Anthropic frontend-design	通用 ESLint/Stylelint	「让模型自评设计」
形态	技能 + 确定性引擎 + 钩子 + 多代理	静态提示文件	代码风格 linter	提示词
检查是否确定性	是（61 条规则，无 LLM）	否	是	否
是否需要 API Key	检测器不需要	需要（走模型）	不需要	需要
是否懂 AI 特定口水	是（按模型编译）	部分（靠禁令）	否	否
设计系统一致性检查	是（对照 DESIGN.md）	否	否	否
跨会话记忆	是（critique/PRODUCT/DESIGN）	否	否	否
编辑时自动拦截	是（含编辑前拦截）	否	视配置	否
浏览器内实时迭代	是（Live Mode，SSE）	否	否	否
可进 CI	是（退出码 + --json）	否	是	否
能否判断「好不好看」	否（作者明确承认）	否	否	声称可以

一句话选型：要可复现、零成本、能进 CI 的设计缺陷门禁 → Impeccable 检测器；要给智能体一套设计词汇与工作流 → Impeccable 技能；要代码风格一致性 → 传统 linter（与 Impeccable 互补，不替代）；要判断作品是否动人 → 目前只有人。

八、局限、风险与社区观察

一、作者本人对能力边界的表述极其克制，这是最重要的风险提示。 他在演讲中明确表示：品味无法在模型层面解决——「品味是伤疤与独特，一旦所有人都用同一套品味，它就不再被当作品味」；模型能处理功能性检查（「正确的东西是否在首屏」），但不是好看与否的好评委；自己的专家混合设计评委只比随机略好，只够做第一遍。官方文档同样写明「一次干净的检测器运行是证据，不是证明」。

二、规则天然带观点，会与品牌冲突。 它劝阻 Inter、Arial 等字体，反对嵌套卡片与弹跳缓动。若品牌本身用 Inter，官方给出的出路是记录一条带原因的例外（npx impeccable ignores add-value overused-font Inter --reason "Brand font"），而不是关掉规则。这意味着落地时必须先做一轮 ignore 治理，否则误报会迅速淹没信号。

三、跨宿主适配是持续成本，也是「在我机器上能跑」的重灾区。 作者列出的结构性差异包括：子代理在 Claude Code 可编程派生、在 Codex 需用户显式请求、在 Cursor 多由代理自选；ask-user 工具在 Codex 仅计划模式可用；后台任务在 Claude Code 完成即唤醒、在 Codex 不反应需手动提示。他还指出 npx skills 不区分宿主目录（把第一个目录复制到所有地方），因此 Impeccable 不得不自建 CLI 安装器，并称「技能分发目前没有行业标准」。

四、钩子带来真实的安全与运维面。 官方提示：Claude Code 的钩子独立于模型工具审批运行，首次编辑或 Stop 事件可能触发引擎二进制下载并缓存到 ~/.impeccable/bin/，无人值守前应审阅已安装钩子；可用 --settings '{"disableAllHooks": true}' 为单次运行禁用全部钩子。Live Mode 会以用户权限执行项目脚本，且不得注入生产站点。

五、维护与商业化观察。 正面信号：发布节奏密集——Skill v4.5.0 与 Engine v0.1.11 均发布于 2026-10-02，此前 v4.3.0/v4.3.1（09-08/09-09）、v4.4.0（10-01）连续迭代；工程纪律体现在端到端测试（含 LLM 驱动与 Playwright）、覆盖约 20 个设计细分场景、每个模型每个版本 5–10 次测试，以及逐条规则的消融测试（每条规则带唯一 XML 标签，移除后跑全模型评测再放回）。风险面：项目已商业化（Renaissance Geek，a16z 领投种子轮），虽然代码仍为 Apache-2.0，但评测框架尚未开源，且作者明确表示 Impeccable「正在超出技能平台的形态」，Live Mode 更适合做成一等公民的宿主集成——未来路线图与开源边界的走向待确认。另需注意口径差异：作者公告中称「超过 40,000 星、仅 skills.sh 渠道就有 160,000 次安装」，而本次 API 抓取为 76,479 星，两者时点与统计口径不同，以 API 实测为准。

九、小结与行动建议

一句话概括其价值主张：它不去解决「AI 有没有品味」这个无解问题，而是把「品味里可判定的那部分」编译成 61 条确定性规则，再用双盲评审、跨会话记忆和编辑时钩子，把人类的判断力插回智能体的循环里。

1. 先只用检测器，不装钩子。 npx impeccable detect src/ 零成本、零风险、结果可复现，先用它摸清自己代码库里的口水密度，再决定是否上钩子——这是验证价值最快的一步。
2. 把 ignore 规则当成落地前置工作，而不是事后补丁。 官方明确钩子有误报且「很快会变得非常烦人」；品牌字体、既有设计系统等必须带原因记录例外，否则检测器会被关掉，价值归零。
3. 把退出码接进 CI，但别把它当设计评审。 0/2/1 的语义清晰且部分失败优先，适合做门禁；但官方与作者都反复强调「干净扫描是证据不是证明」，它不替代在真实视口下看渲染结果。
4. 理解「禁令会迁移模型」这条底层判断，再决定自己要不要写规则。 如果你正打算写一份「不要用 X」的长清单，先读作者的论证——更耐久的做法是把可判定的部分做成脚本，把判断留给人和双盲评审。
5. 在 Codex 上预留降级路径与授权步骤。 子代理需用户显式授权、钩子需 /hooks 批准，否则会走 reference/degraded/；多宿主团队应把「钩子可信步骤」写进上手文档，而不是假设装完即生效。

资料来源（抓取日期 2026-10-05）：GitHub 仓库主页与 README.md（26,987 字符）、.claude/skills/impeccable/SKILL.md、reference/routing.md、仓库文件树；GitHub REST API（仓库元数据、releases，2026-10-05）；GitHub Trending daily（2026-10-05）；官方站点 impeccable.style 首页、/slop 规则目录、/docs/detector；作者 Paul Bakaus 在 AI Engineer 大会演讲的文字整理（BigGo Finance 转载，含双盲评审、反吸引子、按宿主编译、8 道 gate、约 20 个设计细分场景与消融测试等细节）；a16z 专栏《Impeccable by Design》（Renaissance Geek 融资与 GitHub 合作、作者自述星数与安装量）；dev.to 第三方上手评测。作者自述星数（40,000+）与 API 实测（76,479）口径不同，本文以 API 实测为准并已标注；评测框架细节未开源，相关表述标注为作者口径。