AI 写的界面为什么＂一眼假＂?用 impeccable 给编码助手补上设计评审

AI 编码助手 · 前端设计评审 · 确定性检测规则 · 浏览器实时迭代 —— pbakaus/impeccable 是一套装在 AI 编码工具里的设计语言： 一个技能、24 条命令、61 条确定性检测规则，再加上一个在浏览器里实时改界面的工作流。

它想解决的问题很直接：让 Cursor、Claude Code、GitHub Copilot 这类工具写出来的前端，不再带着同一股"AI 味"，而是能通过专业设计评审。

同一个模子刻出来的界面

只要用 AI 写过几个页面，就会认出那套固定的"配方"。 标题上方顶着一枚圆角图标块，卡片里再套卡片，正文用 Inter 或者系统默认字体， 紫色到蓝色的渐变铺在首屏，灰色文字压在彩色背景上，按钮和状态点还会不自觉地呼吸闪烁。

这些不是某一个人的审美问题，而是模型层面的趋同。训练语料里堆满了同一批 SaaS 落地页模板， 模型学到的是"平均答案"，所以每个项目都会滑向同一个安全区。 代码能跑、功能也对，可交给设计师评审时，一句"看起来就是 AI 做的"就很难反驳。

麻烦在于，这种判断目前只能靠人。团队里能挑出这些问题的人有限， 评审往往发生在开发完、甚至上线前，改起来的成本远高于一开始就避开。 面向的人群其实很明确：用 AI 写前端的工程师、带团队的产品经理，以及那些被迫给 AI 产出"擦屁股"的设计师。 他们缺的不是又一篇设计教程，而是一套能嵌进现有工具链、可重复执行的标准。

项目的起点是 Anthropic 那套较早流行的 frontend-design 技能，作者在此基础上把它做成了更完整的系统。

一条命令装进编码助手

安装从项目根目录开始，一行命令就能把技能装进当前编码工具：

npx impeccable install

安装器会先探测本机装了哪些编码工具（Claude Code、Cursor、Codex、Grok 等）， 让你保留或增删，再问装到当前项目还是全局。脚本化场景可以跳过交互：

npx impeccable install -y --providers=claude,codex --scope=project

装完的第一件事是初始化，它把项目里"不会随时间改变的产品事实"记下来，写成 PRODUCT.md：

/impeccable init

这份文件记录的是受众、用途、运行环境、约束与语气，和具体视觉方向分开保存。 之后每条命令都会读它，AI 不必每次重新猜这个产品是干什么的。

接下来是 24 条命令，全部通过 /impeccable <命令> [目标] 调用，大体分成建、评、改、增、修、迭代几类。 几个贴近真实需求的用法：

不打开编码工具也能用同一套规则。命令行直接扫目录或线上页面：

npx impeccable detect src/                 # 扫描目录
npx impeccable detect https://example.com  # 扫描渲染后的页面
npx impeccable detect --json src/          # 给 CI 用的 JSON 输出

退出码有明确语义：0 表示扫描完成且没有主要问题，2 表示扫完但发现问题，1 表示有目标根本没能扫。 这条约定让它天然适合当质量门禁。误报可以用项目配置忽略，也可以写进文件注释随文件走：

<!-- impeccable-disable overused-font: exported brand doc -->

浏览器里的实时迭代是另一条主线。/impeccable live 启动后，在页面上选中一个元素、选一个设计动作， AI 生成的 HTML + CSS 变体会通过开发服务器的热更新直接替换上去，看着不对就换一个。 这里有几个容易踩的坑：实时模式只对本地 checkout 生效，注入线上站点（含 HTTPS）不受支持， 线上检查请改用 detect <url> 或浏览器扩展；Codex 用户装完要在 /hooks 里手动批准项目钩子； 同一个工作区里别同时装两份 impeccable 技能，否则命令会打架。

确定性检测，加上模型判断

这套系统的核心，是引擎与技能分离。仓库里是一个 Rust workspace， cargo build --release -p impeccable 产出一个自包含的引擎二进制； 技能目录里的启动器优先运行随附的二进制，缺失时才按固定版本下载到 ~/.impeccable/bin/。 也就是说，检测能力本身不依赖 Node，也不依赖任何模型运行时。

最值得说的是它把"检测"和"判断"拆成了两层。 第一层是 61 条确定性规则，全部本地执行、不需要 API Key： 其中 32 条归为"AI 套路"（例如单侧彩色边框、滥用字体、卡片套卡片、深色发光）， 另外 29 条属于通用设计质量（例如彩色背景上的灰字、对比度不足、行宽过长、字号过小）。 这些规则对同一份输入永远给同一个答案，因此能进 CI、能写进回归基线。 第二层才是模型的设计评审——层级、情绪、信息架构这类需要判断力的部分，作为独立的判断层保留。

钩子把这套检测嵌进了编辑流程。装好之后，直接编辑 UI 文件就会触发扫描并把结论回传给模型： Cursor 在写入落盘前拦截，Claude Code、GitHub Copilot 与 Codex 在编辑后回传（部分工具在停止时再跑一遍更深的检查）， Grok Build 则在停止时汇总。先有人说"这里不对"，再让它改，比写完一整页再回头看要便宜得多。

和"给每个工具各写一套提示词"的常见做法相比，这里是另一种取舍： 仓库维护一份规范来源 skill/，构建脚本派生出各家工具的发行版本、站点资源与校验产物。 好处是 16 个受支持的工具共享同一套设计词汇，不会因为某个工具升级就漂移； 代价是这条发行流水线本身要维护，二进制和五个平台包也要各自发布。

它还有一个容易被忽略的态度：规则是建议而不是铁律。项目的显式约定是"简报优先"（brief wins）—— 用户明确指定的美学、字体、年代感，会压过检测器的套路告警。 这避免了一个常见误区：把工具当成唯一的审美权威，反而做出千篇一律的"标准答案"。 同理，一次干净的扫描只是证据，不是质量证明；它替代不了在真实视口里看一眼渲染结果。

放进 CI 与团队流程

最直接的落地是把检测器接到代码评审上。 在 PR 流程里跑 npx impeccable detect --json src/，退出码 2 就让流水线失败， 团队就有了一个不依赖个人审美的"AI 味"闸门：谁引入的紫色渐变、嵌套卡片、对比度不达标的文字，在合并前就会被标出来。 配合 --no-config 可以忽略项目配置做一次原生扫描，配合忽略清单又能把历史遗留文件放过， 让新代码从启用当天起就守住底线。

另一个场景是把设计系统真正绑进 AI 的工作流。 项目支持 DESIGN.md 记录既有视觉体系，检测器里有一组 design-system-* 规则专门盯字体、颜色、圆角、字号是否越界。 当 AI 不断往项目里塞新的色值和字号时，这些规则会在编辑时就把它拉回既有 token。 对长期由多个人、多个工具协作的前端仓库，这比事后统一整理要省力得多。

往后看，这条思路可以走得更远。 一套可插拔的规则包机制，意味着团队能把自己的品牌规范写成检测项，让"内部设计规范"变成机器可执行的约束， 而不是躺在文档里没人读的说明。当 AI 承担了越来越多的界面产出， "把设计标准前置成工具、让它随代码流动"这件事，很可能会像 lint 和格式化一样，成为前端工程的基础设施之一。