Impeccable:給 AI 編碼智能體的設計語言與確定性檢測規則

技术背景与问题定义

几乎所有用于写代码的大语言模型都在同一批公开网络代码上训练:相同的组件库、相同的 SaaS 营销站模板、相同的 Tailwind 风格设计稿。结果是,无论用哪个模型生成前端,最终呈现出的视觉习惯都高度趋同:默认用 Inter 字体、紫到蓝的渐变英雄区、卡片里嵌套卡片、彩色背景上叠灰色文字、每个小标题上方都飘着一个圆角方形图标。

这些不是某个模型的缺陷,而是训练数据的统计产物,靠提示词工程很难根除,因为模型既不记得自己昨天交付过什么,也没有机制去对照一份规则手册检查自己的输出。Anthropic 的 frontend-design 技能是第一个被广泛采用的尝试,给编码智能体明确的设计指引,而不是把审美判断交给随机性。Impeccable 由 Paul Bakaus 创建,在此基础上更进一步:它把问题定义为工作流与工具链的缺口,而非一份技能文件能解决的事——智能体需要跨会话持久的产品背景、一套共享的改动词汇,以及一种不依赖同一个模型自我评分的验证方式。

核心架构与原理解析

Impeccable 作为单条命令 `/impeccable` 安装,但真正的架构体现在两份文档与两层校验的分离上。`PRODUCT.md` 由 `/impeccable init` 一次性写入,记录受众、目的、运行场景、约束、语气与证据等持久的产品事实,刻意与表层的视觉方向分开;视觉方向按每个界面单独选定,一旦已有或新建了视觉系统,就记录在独立的 `DESIGN.md` 中。

在此基础上,24 条命令对应设计工作流的不同阶段:`shape` 与 `craft` 负责规划与搭建,`critique` 与 `audit` 负责评审,`polish`、`harden`、`onboard` 负责交付就绪,还有一组力度旋钮式命令——`bolder`、`quieter`、`distill`、`animate`、`colorize`、`overdrive`——用来调节强弱而无需重新争论整体设计方向。第二层是 61 条确定性检测规则,不依赖大模型也不需要 API key,CLI 与配套的浏览器扩展共用同一套规则,因此对比度、间距节奏或字体搭配是否违规这类检查每次都给出相同答案,不会因为换一次运行或换一个模型而漂移。

关键功能与实战评估

实际使用时,一个项目只需运行一次 `npx impeccable install`,并在每个新任务开始时执行 `/impeccable init`;初始化步骤只追问产品背景中缺失的部分,不会把团队已经记录过的事实再问一遍。之后,`/impeccable craft` 跑一整套"先定方向再搭建"的流程,配合实时浏览器迭代,让智能体能看到自己渲染出的结果并在交还控制权之前自行修正。

评审类命令是确定性规则真正发挥作用的地方:`/impeccable audit` 执行 61 条规则的技术性扫描——无障碍、性能、响应式——而 `/impeccable critique` 保持定性判断,像设计负责人在评审会上那样评价层次、清晰度与情感共鸣。`/impeccable document` 与 `/impeccable extract` 则闭合了这个循环:从既有代码生成 `DESIGN.md`,并把可复用的组件与设计令牌提取进共享系统,这对那些代码库已经形成——但从未文档化——视觉语言的团队尤其重要。

行业影响与未来演进

Impeccable 在短时间内收获超过 7.4 万星标,说明一旦智能体编码工具真正接管了大部分前端代码的编写,团队对"千篇一律"的焦虑就会被迅速放大。它真正的贡献不在于某一条具体命令,而在于坚持一个原则:对 AI 产出的设计质量检查,理应享有和测试套件同等的严谨性——凡是不需要主观判断的部分,都应当是确定性的、可重复的、无需模型参与的。

这种拆分——主观半部分交给大模型评判,可核验半部分交给确定性规则——很可能成为该领域后续工具争相效仿的范式,因为这是唯一能规避"让写代码的模型同时给自己打分"这一不一致性的做法。悬而未决的是 61 条规则能在设计潮流演变中走多远:针对当下这批"AI 套路"调校出的规则集,也需要像任何 lint 配置一样持续维护,否则只会追着昨天的渐变色跑,而智能体早已换上了明天的默认风格。对国内团队而言,这也提示了一个更现实的落地路径:与其让每次评审都临时依赖模型主观打分,不如先沉淀出一份可复用、可审计的检测清单,再把真正需要判断力的部分留给人类或大模型去把关,这样既能控制成本,也能让设计质量的提升变得可度量、可追溯,而不是停留在"感觉好像还不错"这种模糊笼统的主观感受式评价上面,这一点值得国内团队认真借鉴参考。