Impeccable（pbakaus/impeccable）三周再访：62 条确定性检测器拦住 AI 设计口水，v4.7 把评审开进桌面应用

一、导读

三周前 Impeccable 以单日 1,171 星上榜时，它的故事还是「把设计判断编译成 61 条确定性规则」；三周后的今天，它以单日 1,113 星再次冲进 GitHub Trending，总星从 76,479 涨到 87,294（均截至 2026-10-26，GitHub API）。这三周它没有躺在热度上：skill 从 v4.5.0 连跳 v4.6.0、v4.7.0 到 v4.7.1，Rust 引擎从 v0.1.11 迭代到 v0.1.17，检测器新增桌面应用评审、排版孤行检查与「访客真实所见」测量。本文跳过上篇已拆的双盲评审与反吸引子机制，专注回答一个新问题：一个已经 87k 星的设计技能，靠什么工程节奏继续涨星、又把「AI 设计口水」的防线推进到了哪里。

二、项目速览

项目	内容
仓库	pbakaus/impeccable（Apache-2.0，Rust monorepo：`crates/` 引擎 + `cli/` + `skill/`）
作者	Paul Bakaus（jQuery UI 作者、前 Google Chrome DevTools 团队），公司 Renaissance Geek 商业化运营
热度	87,294 星、5,217 fork（截至 2026-10-26）；当日 +1,113；三周净增约 10,800 星
版本	skill v4.7.1（10-24）· CLI v4.7.0（10-19）· 引擎 v0.1.17（10-23），三轨独立版本号
核心构成	1 个 skill · 24 条命令 · 62 条确定性检测规则（无 LLM、无 API Key）· 5 家宿主原生钩子 · Live Mode
宿主	Claude Code、Cursor、Codex、GitHub Copilot、Gemini CLI、Grok Build、Hermes、Veto 等 19 种编译目标
新变化	CDP 桌面应用评审 · straggler/unbalanced-heading 排版检查 · roll API 目录学习 · telemetry off 开关

三、为什么是它：二次引爆的涨星动因

第一次上榜靠的是概念与作者信用，第二次上榜靠的是节奏与证据。三周净增 10,800 星、日均约 515 星，而 10 月 26 日单日 1,113 星意味着热度仍在加速而非衰退。动因有四。

第一，发布密度罕见。最近 100 个提交全部落在 10 月，skill/CLI/引擎三轨平均每周双版本：v4.6.0（10-15）、v4.7.0（10-19）、v4.7.1（10-24）、引擎 v0.1.15 至 v0.1.17。对关注 skills 生态的用户来说，这个仓库每周都有可验证的新东西。

第二，宿主矩阵持续扩张。仓库根目录里 .claude、.codex、.cursor、.gemini、.grok、.hermes、.veto、.omp、.kiro 等 19 个宿主目录并排躺着——每接入一个新编码智能体宿主，就多一批该宿主用户的自然涨星。v4.6.0 刚把 Oh My Pi 收入名单。

第三，同赛道项目互相抬轿。同榜的 Hallmark（Together AI 出品，站点昨日刚拆解过）与 Anthropic 的 frontend-design 技能把「AI 设计质量」做成公共议题，用户在每个项目的 issue 区与对比文之间来回跳转，Impeccable 是所有对比里工程最重的那一个。

第四，可验证性仍是护城河。62 条检测规则不花一分钱 API 就能复现，npx impeccable detect 的退出码可以直接当 CI 门禁——这是纯提示词技能给不了的确定性，也是它区别于同类最硬的一条。顺带一提，仓库约 830 MB 的体量里装着测试语料与多宿主产物，克隆前要有心理预期。

四、架构原理：三周里长出的三层新东西

4.1 一图看懂当前架构

Impeccable v4.7 架构全景手绘信息图：从宿主层、技能层、Rust 引擎层、62 条确定性检测器、钩子层到记忆层的六层结构，右侧为 roll API 发牌回路与 craft run 语料校准流水线两条循环，底部为确定性可复现、访客真实所见、单源多宿主三大关键原则

flowchart TB
    H["宿主层（19 种编译目标）<br/>Claude Code · Cursor · Codex · Copilot · Gemini CLI · Grok · Hermes …"]
    H --> S["技能层（1 个 skill · 24 条命令）<br/>init/craft/critique/audit/polish/harden/live …<br/>会话描述瘦身 30%，按信号推荐不自动执行"]
    S --> E["引擎层（Rust 二进制，三轨发布 engine-v0.1.x）<br/>launcher 随技能分发，首次运行下载到 ~/.impeccable/bin/"]
    E --> D["检测器层（62 条确定性规则）<br/>AI 口水族 · 质量族 · 设计系统族 · 新排版族<br/>源码扫描 / URL 渲染 / --cdp 桌面窗口"]
    D --> K["钩子层（5 家宿主原生清单）<br/>编辑后报告 + Stop 深扫 · 有基线时抑制既有发现"]
    S --> M["记忆层（仓库内项目真相）<br/>PRODUCT.md · DESIGN.md · surfaces/*.md · critique/*.md"]
    S --> R["roll API 发牌回路<br/>视觉世界目录发一手 → 智能体选卡 → 匿名回报哪张赢 → 目录进化"]
    D -.craft run 语料.-> CAL["校准流水线<br/>craft run 生成页面入库 → 分轮清账边缘用例"]
    CAL -.规则修正.-> D

4.2 三轨发布：技能、CLI 与引擎分家

10 月最结构性的变化是版本号分成了三条线：skill-v4.x（提示词与流程）、cli-v4.x（安装器与检测器入口）、engine-v0.1.x（Rust 编译的检测引擎二进制）。技能副本自带一个几十行的 launcher 脚本，运行时优先使用旁边的引擎二进制，否则首次运行时把钉死版本下载到 ~/.impeccable/bin/；npx impeccable 只是同一个二进制的 npm 外壳。这个拆分的直接后果是：钩子与检测器完全不依赖 Node 或任何运行时，宿主只需能执行一个脚本；而提示词层的迭代（v4.7.0 把会话描述瘦身 30%、删掉旧命令文件里满屏的 CRITICAL/NEVER 横幅）不再捆绑引擎发版，两边各按各的节奏走。

另一层功夫在分发侧。仓库顶层的 dist/ 按宿主编译多份技能副本，提交历史里反复出现「Sync generated provider output」——宿主副本不是手工维护的，而是从单一源生成后同步到 19 个目标目录，一条规则修正能在同一次发版里到达所有宿主；仓库根的 skills-lock.json 锁定技能依赖，安装器的 install/update 在钩子清单损坏时默认中止而非覆盖，只有显式 --force 才备份为 .bak 后替换。更难得的是自体消化：仓库根目录就躺着它自己生成的 PRODUCT.md 与 DESIGN.md，自家的界面也要过自己的检测器。对想抄「技能工程化」作业的团队，这套「单一源、多目标编译、生成物不手工改」的纪律比任何一条设计规则都更值得搬走。

4.3 检测器工厂：craft run 与语料校准轮次

62 条规则不是一次性写出来的，而是被一条校准流水线喂出来的。提交历史清晰可见这个循环：先跑「craft run」让智能体按命令批量产出真实页面（最近一轮编号已到 craft run 1009），页面进入语料库；然后按「round」分轮修规则——10 月 23 日一天内就有「corpus round 11 的延迟边缘用例」「craft run 1009（round 13，分支 D）的测量缺陷修复」等多笔提交。修正方向高度具体：对比度检测「丢弃未经测量的主观裁决，改读被剪切、隐藏、裁切与混合后的真实底面」，圆角检测「只判纯长度值、放过数学函数操作数」，行条纹检测「贴在状态行侧面的色条要按侧标签上报」。这套「生成即造语料、误报即进清单」的机制，是规则数量停在 62 条而精度持续上升的原因——它宁可把边缘用例标记延迟（deferred）也不放任误报进 CI。

值得把它与作者此前在 AI Engineer 大会演讲中披露的测试纪律对照着看：每条规则带唯一标签，可以单独摘除后跑全模型回归再放回（消融测试）；端到端测试由 LLM 驱动并用 Playwright 走真实渲染，覆盖约 20 个设计细分场景，每个模型每个版本跑 5 到 10 次。演讲里的消融体系回答「这条规则有没有用」，本轮提交里的语料轮次回答「这条规则在真实页面上错得多不多」——两套机制合起来，才是「设计规则也能有工程质量」的完整闭环。规则库的克制由此而来：v4.7.0 只净增两条排版检查，却有十几笔提交在修既有规则的测量精度。

4.4 「访客真实所见」：测量口径的两次升级

v4.6.0 与 v4.7.0 连续两版都在收紧同一件事：检测器看见的必须是访客看见的。v4.6.0 修掉了一整类「幽灵发现」——屏幕阅读器专用标题、被滚动画布转走的卡片、藏在幕式页脚与穿透遮罩后面的文字、磨砂玻璃上的浅色文案，这些对真实访客不可见或无害的元素不再报警；对比度检测开始读取文本背后真实的表面，包括深色 hero 照片、滤镜与随滚动位置变化的渐隐。v4.7.0 补上排版侧：新增 straggler（段落末行孤字）与 unbalanced-heading（标题末行成短桩）两条检查，且在 CSS text-wrap: balance/pretty 已经解决问题时自动退位——规则与平台新特性握手而不是打架。同版的误报治理清单更长：看似按钮的文本标签、卡片上的编号、横向滚动的代码示例、幕式页脚后面的文字、穿透型遮罩、深色光晕上的浅色文案、磨砂玻璃表面，都改为按访客视角判断；侧边框强调色改按选择器判定，不再受附近空行数量干扰。工程细节上，评审页面跟随系统深色模式而对比图保持自有底色，Live Mode 支持局域网与 Tailscale 地址的纯 HTTP 启动，决策卡片修复了 WebKit 内核浏览器里的渲染，中断的引擎下载在 Windows 上也会自我清理。同版还把桌面应用纳入射程：impeccable detect --cdp 9222 对开着调试端口的 Electron、NW.js、CEF、WebView2 窗口做即时扫描，评完恢复原状。

4.5 与既有机制的衔接与取舍

上篇详述的双盲评审、反吸引子与按宿主过拟合规避没有变，但各接了一个新接口。反吸引子的「脚本化随机」升级成了服务端的 roll API 目录：新设计启动时向 impeccable.style 请求发一手「视觉世界」，智能体选卡后匿名回报「哪张卡赢了」（指派、挑选、挑战者、正典还是重掷）以及目录修订号，目录据此学习什么有效。隐私面的设计值得安全团队细读：上报字段只有发牌键（128 位随机数）、范围、访客模式、重掷轮次、目录修订号、赢卡类型与页内位置、客户端版本及一个去重用的随机 id；项目名、文件、代码、PRODUCT.md 与方向命名永不上传；仓库内只存发牌键的加盐哈希，盐保存在本机 ~/.impeccable/seed-salt，盐存不了就干脆不记录种子。v4.6.0 补上 telemetry off、DO_NOT_TRACK=1 与项目级 "telemetry": false 三种关法，关闭后发牌照常、只是目录不再记录你的选择。

钩子面板也有两处值得注意的新设计。其一，Stop 基线抑制：Stop 深扫时若有已验证的「编辑前基线」，既有发现被抑制——只报本轮编辑新引入的问题，钩子从「每轮都喊同一批旧问题」变成增量噪声。其二，钩子安装位置的分化：Claude Code 把钩子装进 gitignore 的机器本地 settings.local.json（项目共享的 settings.json 永远不会带上你家目录的路径），GitHub Copilot 的钩子清单则随仓库提交、CLI 与云端代理共享，Cursor 从旧的编辑前拦截统一迁移到编辑后钩子（旧配置兼容），Codex 清单带 commandWindows 兼容 cmd.exe，Grok Build 只在 Stop 时上报。Hermes 的处理最能说明边界意识：项目级技能被它视为提示注入向量，必须逐仓库手动 hermes skills trust，Impeccable 在文档里把这个信任步骤写成了显式要求而不是试图绕过。构建路径上，buildPath 把「先出高保真稿再实现」（comp）与「直接写代码」（code）拆成显式选择，monorepo 可整仓设默认、各 workspace 覆盖，没有图像生成能力的宿主该选项自动隐身。

五、应用场景：四个三周内新解锁的切入点

场景一：Electron 桌面应用的设计评审

痛点：桌面端应用（安装器、内嵌 WebView 的客户端）长期是设计检查的盲区，网页扫描器进不去、人眼评审又不系统。解决：v4.7.0 的 CDP 通道让检测器直接扫运行中的窗口。

# 以调试端口启动你的 Electron / NW.js / CEF / WebView2 应用后：
npx impeccable detect --cdp 9222 --target "My App"

收益：扫描的是「你眼前这个窗口的现状」，评完把窗口原样恢复；critique 与 audit 均已内置该通道的操作配方，多窗口应用用 --target 指名挑窗。对桌面端团队，这意味着无障碍对比度、字号层级、触控目标这些以前只能靠人眼抽查的问题，第一次有了可复现的自动化出口。边界：只覆盖开放调试端口的本地进程，不适用已发布的封闭成品；CDP 扫描看到的是运行时渲染树，与源码扫描的发现口径略有差异，两类结果不宜直接合并计数。

场景二：monorepo 与原生移动项目的定向评审

痛点：monorepo 里 context 会把 tsconfig、lint、脚本包一起端上来，智能体选错目标浪费整轮；iOS/Android 项目此前跑网页扫描只会得到一张「干净」的假报告。解决：v4.7.0 让 context 只列出真正渲染 UI 的 workspace；v4.6.0 让原生项目（iOS、Android、adaptive）的 critique 走自己的设计评审逻辑，而不是拿空网页扫描充数。最小示例：

/impeccable critique apps/mobile          # 原生项目走专属评审
npx impeccable detect --viewport 390x844 apps/web   # 移动视口网页检查

收益：大仓里每次评审都落在正确目标上，原生团队第一次有了非空的 AI 评审输出。边界：原生评审深度依赖平台适配，边缘框架建议先小范围试跑。

场景三：团队级设计治理与合规部署

痛点：设计规则天然带观点，品牌字体、既有设计系统会持续误报；安全团队会追问「它上报了什么」。解决：三件套配置——DESIGN.md 记录系统边界让设计系统族规则有法可依、ignores 带原因登记例外、v4.6.0 的 telemetry off 或 DO_NOT_TRACK=1 关闭选择回报（发牌功能本身照常工作，只是目录不再记录你的选择）。落地顺序建议是先审钩子、再配例外、最后关遥测：钩子审阅确认无越权路径，例外登记把误报压到可忍受，遥测开关留给合规最后确认。

npx impeccable ignores add-value overused-font Inter --reason "Brand font"
npx impeccable telemetry status && npx impeccable telemetry off

收益：误报被制度化管理而非关掉规则；隐私面有明确清单（上传发牌键与卡类，永不上传项目名、代码与文档；本机盐文件保证仓库内只存加盐哈希）。边界：roll 请求本身是功能必需、无法关闭；需要完全离线的团队要评估这一点。

场景四：与 Hallmark 组成「生成 + 治理」双技能工作流

痛点：新页面从零生成时需要强方向约束（不然直接长成 AI 口水），而存量页面的持续治理需要确定性检查——单一技能两头兼顾容易顾此失彼。解决：两者并行安装。新页面用 Hallmark 的 48 套主题发牌加 88 条 Gate 从源头定调；落地后的日常迭代交给 Impeccable 的钩子拦截与 polish/harden 例行治理，62 条检测器进 CI 把关回归。

npx impeccable install --providers=claude,cursor --no-hooks   # 先装技能，钩子后置
# Hallmark 负责新页面的第一次生成；Impeccable 负责此后每一次编辑

收益：生成侧的「审美先手」与治理侧的「确定性后手」各司其职，两者检测逻辑互不冲突。这套组合还有一层团队意义：Hallmark 的主题发牌把「页面该长什么样」的方向决策前置到了生成时刻，Impeccable 的 DESIGN.md 与检测器则把「页面不许退化成什么样」的底线固化进了日常编辑，一软一硬正好覆盖设计治理的两端。边界：两套技能同时激活时提示词预算会变大，弱模型宿主建议按阶段启用而非常驻并行。

六、快速上手

# 1) 项目根安装（识别宿主，选择项目级/全局；Codex 装后需 /hooks 批准，Grok 需 /hooks-trust）
npx impeccable install

# 2) 宿主里初始化项目上下文（写出 PRODUCT.md，记录 comp/code 构建路径）
#    /impeccable init

# 3) 零成本先跑检测器（无模型、无 API Key、可复现）
npx impeccable detect src/
npx impeccable detect --cdp 9222 --target "My App"   # 桌面应用

仓库对 .impeccable/ 的提交纪律值得照抄：官方给出带 impeccable-ignore-start 标记的 .gitignore 块，把截图、Live 会话、每人私有配置全部排除，同时明确保留 config.json、design.json、surfaces/*.md、critique/*.md——临时产物与项目记忆显式分开，跨会话的判断才能累积。更新用 npx impeccable update；Cursor 项目会自动从旧的编辑前拦截迁移到编辑后钩子。安装通路还有三条备选：团队想跟随上游更新可以把仓库挂成 Git 子模块后用 npx impeccable link 按宿主链接编译产物；VS Code 用户可装 Visual Studio Marketplace 上的扩展（要求 VS Code 1.109.3+，注意扩展只带技能不带钩子）；Claude Code 也能走 /plugin marketplace add pbakaus/impeccable 的插件市场通路。常用命令可用 /impeccable pin audit 固定成独立的 /audit 快捷方式，Codex 里技能以 $impeccable 形式调用。

七、横向对比

维度	Impeccable v4.7	Hallmark v2	Anthropic frontend-design	传统 Stylelint
路线	确定性引擎 + 技能 + 钩子	主题发牌 + 设计 Gate	静态提示文件	样式规则 linter
确定性检查	62 条，无 LLM	88 条 Gate（随主题）	无	有（不懂 AI 口水）
生成侧审美	反吸引子 + roll 发牌	48 套成品主题	禁令清单	不适用
桌面/原生评审	CDP 桌面窗口、iOS/Android critique	无	无	无
跨会话记忆	PRODUCT/DESIGN/surfaces/critique	主题即约定	无	无
遥测	默认上报选择，可关	未公开细节	无	无

一句话选型：从零生成新页面求「不一眼假」，Hallmark 的主题发牌更快；治理存量页面与团队流程，Impeccable 的确定性引擎更重；两者并非互斥（见场景四）。教学场景理解「AI 为什么长得都一样」，Anthropic 的 frontend-design 仍是最好的入门读物。

八、局限与风险

第一，评测体系未开源。语料校准、按模型消融测试都发生在闭源侧，社区能复现的是检测器结论，不是校准过程；商业实体（Renaissance Geek，已获风险投资支持，融资细节本篇未重新核验）与 Apache-2.0 代码之间的边界需要持续观察。第二，遥测默认开启。roll 的选择回报默认上报（v4.6.0 起可关），隐私清单虽清晰，但合规敏感团队应在部署清单里把 telemetry off 写成默认步骤。第三，钩子的安全面。Claude Code 的钩子独立于模型工具审批运行，首次编辑就可能触发引擎二进制下载缓存到 ~/.impeccable/bin/，无人值守运行前应审阅钩子；Codex 每次钩子定义变更可能要求重新批准。第四，规则即观点。它劝阻 Inter、嵌套卡片与弹跳缓动，品牌恰好中招时只能走带原因的例外登记，落地前必须预留一轮 ignore 治理。第五，品味边界未变。作者自己承认模型的评审能力只比随机略好，检测器覆盖的是「可判定缺陷」，「好不好看」仍要人眼终审。他还观察到混合评委会系统性偏爱塞得更满的首屏，某些维度需要把分数取反再用——在更完整的方法论公开之前，AI 评审结果只宜当第一遍筛子。

九、小结与行动建议

三周时间线给出了一个难得的观察样本：一个 skills 生态项目如何在热度顶点继续用工程密度换信任——引擎独立成 Rust 三轨发布、检测器靠 craft run 语料分轮校准、评审半径从网页扩到桌面窗口与原生项目、随机性反制升级成会学习的服务端目录。四条行动建议：

三周前装过的用户直接 npx impeccable update，v4.6/v4.7 的误报治理与桌面 CDP 值得重跑一轮检测；
桌面应用团队把 detect --cdp 9222 接进手工验收清单，这是目前唯一能扫 Electron 窗口的确定性设计检查；
部署时把 telemetry off、ignore 治理与钩子审阅写进团队上手文档，三项都是「装完再做」成本最低的合规动作；
关注 roll API 目录的进化——如果「发牌学习回路」能证明自己持续产出高胜率方向，它可能成为技能类项目接入服务端智能的首个可复制范式。

参考资料

仓库主页与 README（https://github.com/pbakaus/impeccable ，获取日期 2026-10-26，含 62 条规则、19 宿主、roll API 隐私清单与 .gitignore 纪律）
Releases：skill-v4.6.0（10-15）、skill-v4.7.0 与 cli-v4.7.0（10-19）、engine-v0.1.17（10-23）（https://github.com/pbakaus/impeccable/releases ，获取日期 2026-10-26）
提交历史：corpus round 11/13、craft run 1009 测量缺陷修复等校准记录（https://github.com/pbakaus/impeccable/commits/main ，获取日期 2026-10-26）
官方文档站 impeccable.style（https://impeccable.style ，获取日期 2026-10-26）
钩子文档与各宿主信任步骤（https://impeccable.style/docs/hooks ，获取日期 2026-10-26）
Neo Mirai 前后对比案例（https://impeccable.style/cases/neo-mirai ，获取日期 2026-10-26）