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 命令」是机制层面的差别：它在生成的那一刻就拦住垃圾，而不是等到评审。

代价也是老一套：往仓库配置里写东西的 hook，就会出现在 code review 里；Codex 用户装完还得通过 /hooks 显式批准项目 hook。如果你们团队对「把工具配置提交进仓库」有强烈意见，submodule 路线就是为这个存在的——git submodule add 加 npx impeccable link --source=.impeccable --providers=claude,cursor，让工具和它所治理的代码一起被版本化。

它修不了什么

三个边界值得点名。

它没法告诉你这个页面到底好不好。62 条规则抓的是表面特征。一个页面可以通过全部检查，却依然毫无观点——这是 AI 味问题更深的那一层，也是至今没有 linter 解决的那一层。

live 模式只能在本地检出上跑。它不会注入到线上站点，HTTPS 也不行。合理，但这意味着视觉迭代循环是开发期的工具，不是评审工具。

而且这套词汇只有在智能体真的读了才有用。Impeccable 自己的说法对此很诚实：所有模型产出同一种设计，是因为所有模型都是在同一批 SaaS 模板上训出来的。一个 skill 文件是对训练分布的轻推，而轻推输给分布的次数，比任何人希望的都多。

那为什么不干脆写个检查清单？

这问题问得对。一份 markdown 风格指南不花什么成本，干的事差不多。

差别在于强制力。写在 prompt 里的清单是建议：模型读了，表示同意，然后照样给你紫色渐变，因为那个渐变在它的训练数据里出现过四万次。确定性规则会让构建失败。这是另一种性质的压力，也是唯一能在 deadline 面前活下来的那一种。

第二个差别是颗粒度。清单说「用好字体排印」。Impeccable 的 typeset 命令具体处理层级、字号阶梯和字体搭配，检测器对每一种具体失败都有单独的规则——也就是说，反馈可以指到某一行 CSS，而不是对着品味打手势。这就是「工具优于文档」的全部论证，它在这里成立的理由，和二十年前它在前辈 linter 身上成立的理由是同一个。

第三是这套词汇是共享的。bolder、quieter、distill、harden——这些词设计师和智能体都能据此行动。「让它 pop 一点」则不能。

它为什么现在火

因为量的问题来了。一年前，智能体偶尔生成一个落地页。现在一个团队午饭前就能生成四十个版本，瓶颈已经从「我们能不能做出来」变成「我们能不能足够快地判断哪个是好的」。

针对廉价失败做确定性检查，是这个问题里唯一能规模化的部分。品味不能规模化。六十二条关于字体和缓动的、正则形状的规则可以；而把它们做成一个不需要模型调用、能跑在 CI 里的东西，是这个仓库里最不性感、也最有用的决定。