你把一个页面丢给 AI，说「做得好看点」。出来的东西几乎总是同一张脸：奶油色背景、一根细衬线大标题配斜体点缀、紫蓝渐变、卡片左边一道彩色竖杠。这不是审美口味问题，是可数的、会反复出现的模式。Impeccable 干的事就是把这些模式写成 62 条确定性规则（deterministic，意思是不调用任何模型、同样的输入永远同样的输出），让 coding agent（替你写代码的那个 AI 助手）在交活之前先自己照一遍镜子。
它现在是 10.7 万星、Apache-2.0 协议、作者是前 Google 开发者布道师 Paul Bakaus。我把它整个拉进隔离沙箱，从源码编译出引擎，跑了两套测试，再用仓库自带的 269 个测试样本全量扫了一遍。结论先给：62 条规则里只有 43 条在这条路径上响过，剩下 19 条一次都没触发——这不是缺陷清单，但它划出了这东西真正的适用边界。
一、它是什么：一本设计词典，外加一个独立运行的扫描器
说人话，它由两块拼起来。
第一块是命令。装好之后，你的 AI 助手里多出 24 个斜杠命令，按用途分四组：调风格（让保守的更大胆、让吵闹的更安静、去掉多余、补上配色、重整排版）、做评审（打分的体验检查、技术质量报告）、收尾（上线前打磨、补边界情况、改文案、适配屏幕、优化加载），以及写新页面时的规划。
你用「把定价卡做得更响亮一点」这种话吩咐它，背后加载的是一份专为这个动作写的操作手册。区别于随便一句「好看点」，它知道这个动作要做到什么程度算完。
第二块是一个能脱离 AI 单独跑的扫描器。一条命令扫源码目录，同一条命令换成网址就扫线上页面；加一个开关输出机器可读的结果，再加一个开关直接写成 GitHub 的代码批注。
它有没有发现问题，只用退出码回答你：零是干净、二是有发现、一是连扫都扫不了。这一条对做持续集成的人很关键——它天然就能当闸门用，不用解析输出文字。命令行细节放在下面的表格里。
两块都指向同一个卖点：把「感觉不对」翻译成「第 12 行左边那条 6 像素竖杠，删掉」。
二、怎么做到的：一条设计规则如何从散文变成可执行代码
这是它和站内评测过的同类最不一样的地方——它不是一堆 Markdown 提示词，而是一个正经的 Rust 工程。仓库根目录的构建清单定义一个工作区，底下共有 18 个 crate（Rust 里最小的编译单元，可以理解成模块边界清晰的零件）。分工大致是：
| 零件 | 干什么 |
|---|---|
| 规则注册表与公共类型 | 62 条规则的唯一真身，一条规则 = 一个编号 + 分类 + 严重级别 + 一句给人看的说明 |
| 规则逻辑 | 每条规则的具体判定：什么算「太挤」、什么算「标题跳级」 |
| 源码扫描 | 走文件、读配置、跑正则、出结果 |
| 静态页面引擎 | 自己解析 HTML 和样式表，在没浏览器的情况下算排版和颜色 |
| 浏览器引擎 | 连你本机的 Chrome，在真渲染的页面上量尺寸和对比度 |
| 命令行 | 把所有动词接起来，管退出码 |
版本方面，工具链配置文件只写了一句「stable」，外加一个网页端编译目标——那是为了把同一套规则编译成网页里也能跑的形态，浏览器插件用的就是它。整个工作区 27.5 万行 Rust，锁文件里 218 个依赖包。
62 这个数字在源码里是被测试断言焊死的：注册表末尾有一句「长度必须等于 62」的检查，谁不小心删了一条，测试当场红。它也解释了为什么是 62 而不是 64——有两条规则被退役了（image-hover-transform 和 layout-transition），退役的编号留在配置里不报错、也不生效，只在自检命令里悄悄提示一句。
三、实测：跑了什么，拿到什么数字
沙箱是隔离的，被测项目全程没有落到沙箱外。克隆用浅克隆加只取必要对象，4,526 个文件、除版本库外 98MB，4 秒完成。然后按文档从源码构建引擎，25.5 秒编译完，产物 100MB。
| 我跑的命令 | 真实结果 | 耗时 |
|---|---|---|
cargo test -p impeccable-foundation |
61 个通过，0 失败 | 9 秒 |
cargo test -p impeccable-detect |
117 个通过，0 失败 | 11 秒 |
cargo test -p impeccable-core |
847 个通过，0 失败 | 18 秒 |
cargo test -p impeccable-html |
224 个通过，0 失败 | 29 秒 |
cargo test -p impeccable（命令行） |
81 个通过，0 失败 | 22 秒 |
node scripts/run-tests.mjs core |
270 个用例，264 通过、2 失败、4 跳过 | 7.3 秒 |
Rust 这五个包合计 1,330 个通过、零失败。全仓一共 2,683 个 Rust 测试标记，我没跑全量：一次性跑整个工作区需要补下载依赖，沙箱第一次断网跑直接报下载失败，我改成逐个包跑，这五个是覆盖面最大的。
前端那套 core 套件的 2 个失败都出在环境，不是代码：一个是仓库需要一个叫 gh 的命令行工具去拉一份几兆的提交历史，沙箱里没有，报的是系统层面的「进程资源暂时不可用」；另一个是少装了依赖，模块找不到。两者的原始报错我都留着，不做别的解读。
规则真的会响吗？ 我手写了一个故意做脏的页面：左边 6 像素紫边卡片、渐变文字、9 像素的灰色小字、奶白背景、Inter 字体，再配一份内容一样的 React 组件。同一份脏东西，两种文件给出了两种答案——页面文件报了 7 条（侧边竖杠、渐变文字、对比度只有 1.7:1 不合格、字号低于 11 像素下限、字体太大众、奶白背景），React 组件只报了 1 条。
原因它自己打印出来了：源码文件只跑模式匹配那批规则，并明确写着「发现数量是少算的，不等于体检合格」。这是我认为最该被记住的一条限制：把它挂进 React 或 Vue 项目的持续集成，你得到的是一层很薄的网；要拿到完整结果，得对着跑起来的开发服务器地址扫一遍。
那 19 条从不触发的规则是什么？ 我拿仓库自带的 269 个测试样本全量扫了一遍，43 条规则响过，其余 19 条一次没有。看名单就明白了：设计系统字体、颜色、圆角、字号这四条要读你项目里的设计规范文件才有基准；行宽、贴边、遮挡、首屏横向溢出、边缘卡片这几条要真实的屏幕尺寸。
脚本报错、坏图、静止时被藏起来的内容这几条，要页面真的渲染过才看得见。所以这 19 条不是坏了，是「静态扫文件」这条路根本走不到它们——想覆盖，就得把浏览器接上。
顺带一个方法论陷阱：第一次扫它的测试样本，我拿到的是零发现。查下来是仓库自己的配置文件里把 tests/fixtures/**（测试样本目录）写进了忽略清单——测试语料被当成「已知的脏东西」屏蔽了。这做法本身合理，但意味着任何人想复核它的规则，都得显式关掉配置。
四、三处我实测撞到的问题
一是分发方式带来的体积代价。 仓库根目录下有 20 个以点开头的目录，一个工具一个，每个里面装着一份完整的技能包，58 个文件。我把路径前缀抹掉之后逐字节比对：1,165 个文件里有 942 个和 Claude Code 那份完全一致，占八成。
剩下两百多个差异，绝大多数是同一句话里的路径前缀不同——.claude/skills/impeccable 换成 .cursor/skills/impeccable，另有一处把「用提问工具问用户」改成「直接问用户」。单个技能包 2.3MB，乘 20 就是四十多兆。作者显然是有意的（README 里写明每个工具的产物都提交在仓库根目录，为了让人不用装 Node 也能手动拷），代价是改一句说明书要同步二十份、看代码时噪音很大。
二是引擎二进制不随仓库来。 我找遍全仓，没有任何一个平台的引擎可执行文件；npm 包声明里只有 5 个平台分包的依赖，加一份校验和清单，5 条哈希。
也就是说「Apache-2.0、可以离线从源码构建」这句对开发者成立，对使用者不成立——默认路径是启动器联网下载一次、校验哈希、存到用户目录。这一点 README 说得清楚，不算隐瞒，但它决定了「断网环境能不能用」这个问题的答案是要先自己编译。
三是那 2 个失败用例的位置很说明问题。 它一共定义了 6 个默认测试套件和 8 个可选套件，拆得很细：构建、规则、浏览器、框架适配、插件端到端。我第一次跑默认入口，卡在「拉真实提交历史」这种需要外部网络账号的用例上。
工程严谨度是够的：测试与代码几乎一比一、注册表数量被断言焊死、还有个专门的脚本只跑被改动影响的那些包。但一个想在本地跑绿的人，得先配好那个拉历史的命令行工具和一堆依赖。
五、放进同类里看，值不值得装
站内之前评过三个设计类技能，问的问题各不相同。UI UX Pro Max 那篇问的是「词表够不够用」：192 套配色全过无障碍标准，但中文关键词一个都搜不到。Hallmark 那篇，也就是专治 AI 味的那种设计技能，问的是「它自己达标吗」：31 个成品页面有 21 个过不了它自家 58 道闸门。
StyleSeed 那篇问的是「方法引擎的测试能不能证明效果」：195 项测试全绿。Impeccable 补的是第四个问题：这套规则在真实代码库里跑得动吗——答案是页面级跑得动，源码级只有薄薄一层。
适合谁：已经在用 Claude Code、Cursor、Codex 这类助手，且项目有成型界面的人。它最擅长的是「对着一个已有的卡片、一个已有的设置页反复改」，而不是从零生成整站。把扫描器接进持续集成也靠谱，前提是你扫的是跑起来的地址而不是源码目录。
不适合谁：想用它替代设计判断的人。62 条规则能认出「紫蓝渐变 + 左边彩色竖杠」这种公认的机器味，但认不出你的产品该长什么样——那部分仍然要人给方向。另外不想在项目里多出二十个工具目录、也不想让助手每次改文件都触发一次检查的人，可以先只装扫描器，不装钩子。
一句话判断：值得装，但别指望它是护栏。它是一把尺子——量得准，量得到的地方不多，你得自己决定要不要把页面也摆到尺子下面。
局限说明：本次实测在内存与进程数受限的隔离沙箱内完成，Rust 测试只跑了五个核心包（占全部测试标记的一半），前端六个默认套件只跑了 core 一个，浏览器渲染类的规则因为没有可用的 Chrome 没跑；扫描覆盖面用仓库自带的 269 个测试样本加两个手写样本估算，不等于真实项目里的分布。数据取自 2026-11-11 的仓库快照，主分支当天有提交。
相关阅读：UI UX Pro Max 深度评测：12.7 万 Star 的设计 skill，192 套配色全过 WCAG，中文关键词却 0 命中；Hallmark 深度评测：3 万 Star 的反 AI 味设计技能，31 个成品页面 21 个过不了自家 58 道闸门
关注 AI商业快讯，每天一篇 AI 热点深度解读。