Impeccable：用 61 条确定性规则，把 AI 生成的前端从模板味里拉出来

它到底在解决什么：AI 前端的模板化指纹

每个主流模型都在同一批 SaaS 模板上训练过，于是生成的前端页面总带着同一套指纹：Inter 字体打底、紫色到蓝色的渐变、卡片套卡片、彩色背景上放灰字、标题上方永远悬着一个圆角方形图标。Impeccable 的出发点就是这些可识别的痕迹。它不试图让 AI 更有创意，而是给 AI 一套明确的禁令和检查清单，让它在动手前就知道哪些是雷区。这个项目面向的是用 AI 编码代理写真实产品页面的工程师，不是设计师。设计师有自己的审美系统，工程师需要的是可执行的规则。Impeccable 把设计约束变成命令和规则，让 AI 在生成代码时就能避开最常见的模板化错误，而不是等页面出来后再人工返工。

运行机制：skill 提供语义，规则提供确定性

Impeccable 的架构分两层。上层是 skill，也就是安装到 AI 工具里的指令包，它定义 23 条命令，比如 audit、critique、polish、harden。这些命令由 AI 理解并执行，属于 LLM 行为。下层是 61 条确定性检测规则，由 CLI 和浏览器扩展直接运行，不经过 LLM，也不需要 API key。这两层分工明确：命令负责语义层面的操作，比如“让这个按钮更醒目”或“检查结账流程的边界情况”，规则负责技术层面的硬检查，比如对比度、响应式断点、文本溢出。确定性规则的好处是可复现，同样的输入永远得到同样的检查结果，不会像 LLM 那样飘。代价是它只能检查可量化的指标，无法判断“这个页面是否打动人心”。README 里也承认，critique 这类命令包含 LLM-only 的检查，说明项目自己也知道规则引擎的边界。

安装与初始化：一条命令写入设计上下文

安装流程设计得很直接。在项目根目录运行 npx impeccable install，它会自动检测当前机器上的 harness 文件夹，比如 ~/.claude、~/.codex、~/.grok，或者项目本地的 .cursor。你可以保留检测到的集合，也可以手动指定 providers。想跳过交互式选择，可以用 --providers=claude,codex,cursor,grok 和 --scope=project|global 参数。安装完成后，在 AI 工具里执行 /impeccable init，它会问两个问题：这个界面是品牌向（营销页、落地页、作品集）还是产品向（应用 UI、仪表盘、工具）。根据回答，它写入 PRODUCT.md，并可选生成 DESIGN.md，这两个文件记录了受众、品牌定位、语气、反参考、颜色、字体和组件信息，后续所有命令都会读取这些上下文。这一步是 Impeccable 和其他设计 skill 最大的区别：它不是一次性提示词，而是一个持续存在的项目档案。

23 条命令：从 polish 到 overdrive 的梯度设计

命令列表覆盖了从保守到激进的设计操作。audit 跑技术检查，包括无障碍、性能和响应式；polish 做最终对齐和发布准备；bolder 放大平淡的设计，quieter 则压制过度张扬的视觉。这些命令可以单独调用，也可以组合使用。比较有意思的是 overdrive，它要求添加“技术上非凡的效果”，这显然不是给保守项目准备的。还有 distill，把设计剥离到本质，和 overdrive 形成两个极端。命令之间不是孤立的，比如 harden 专门处理错误状态、国际化、文本溢出和边缘情况，这更像是工程命令而不是设计命令。使用方式上，你可以用 /impeccable audit blog 这种带目标参数的写法，也可以直接说 /impeccable redo this hero section，让 AI 自己理解意图。另外，pin 命令可以把常用命令变成独立快捷方式，比如 pin audit 之后直接输入 /audit 就能触发。

反模式清单：比规则更硬的审美约束

README 里单列了一个 Anti-Patterns 部分，内容非常具体：不要用 Arial、Inter 和系统默认字体；不要在彩色背景上放灰字；不要用纯黑或纯灰，永远要加色调；不要把所有东西都包在卡片里，也不要在卡片里嵌套卡片；不要用弹跳或弹性缓动，因为过时。这些禁令直接写进了 skill 的指令里，AI 在生成代码时会避开这些模式。这比单纯告诉 AI“要有设计感”有效得多，因为负面清单比正面要求更容易被模型遵循。但这里有个明显的取舍：规则是写死的，如果某个团队的设计规范恰好允许用 Inter 或卡片嵌套，这套反模式就会变成束缚。项目没有提供自定义反模式的接口，至少在 README 里没有提到。这意味着团队要么接受这套审美，要么不用。

更新与维护：hook 信任是最大的运维成本

更新机制有两种。用 npx impeccable update 可以刷新现有安装。如果通过 Git submodule 方式安装，更新命令是 git submodule update --remote .impeccable，然后重新运行 npx impeccable link。这里有一个真实的坑：Codex 用户每次更新后都要进 /hooks 重新批准项目 hook，因为 Codex 按 hook 定义跟踪信任，.codex/hooks.json 一变化就可能要求重新授权。Grok Build 用户则需要先设置项目文件夹信任，比如 /hooks-trust 或启动时加 --trust，否则 .grok/hooks/ 里的脚本不会执行。这些细节说明，Impeccable 的安装不是一次性的，每次更新都可能触发信任流程。对于多人的团队，这个成本会累积。另一方面，项目使用 Apache-2.0 许可证，可以自由使用和修改，但修改后维护 fork 的成本需要自己承担。

替代方案与边界：它解决不了审美疲劳

最直接的替代方案是 Anthropic 官方的 frontend-design skill，Impeccable 的 README 明确承认自己是从那里起步的。两者的差异在于：frontend-design 是一份静态的指导文档，模型每次读取同样的内容，没有项目上下文，也没有命令体系。Impeccable 在它之上加了 init 流程、23 条命令和 61 条确定性规则。另一个替代方案是纯人工设计评审，但这不在同一类工具里。Impeccable 的边界很清楚：61 条规则只能抓显性特征，比如字体、配色、卡片结构，它抓不住“这个页面看起来像 2015 年的模板”这种整体感觉。critique 命令虽然有 LLM-only 检查，但那是通过 AI 对话实现的，不是规则引擎。所以如果你需要的是对设计质量的整体判断，Impeccable 只能提供部分帮助。它更适合作为第一道过滤器，把明显的模板化问题挡在生成阶段，而不是作为最终的设计裁判。

编辑结论

Impeccable 适合那些已经受够了 AI 生成界面千篇一律的开发者，尤其是用 Claude Code、Cursor、Codex 或 Grok Build 写前端、又不想在每次生成后手动纠正字体和配色的人。它不适合完全不写代码、只靠聊天界面做设计的用户，因为 23 条命令全部要嵌在 AI 工具的对话里执行。也不适合对设计风格有极强个人主张、且不愿意被一套规则约束的团队。采用前先验证三件事：第一，你的 AI 工具是否在支持列表里，尤其是 Codex 的 hook 信任机制是否已配置；第二，运行 npx impeccable install 后，检查它检测到的 harness 文件夹是否准确，避免装错位置；第三，确认你的项目能接受 PRODUCT.md 和 DESIGN.md 这样的上下文文件被写入仓库。最后一点：61 条规则是确定性检查，它只能抓模板化的显性特征，抓不住审美疲劳这种主观问题，所以别指望它替代人工设计评审。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes