Impeccable:给 AI 编程助手补一套设计判断

GITHUB 热榜 · 开源项目

Impeccable：用 62 条规则，卡住 AI 写前端的那股套路

AI 编程助手写出来的前端，常常是同一副样子：Inter 字体铺满全站、紫到蓝的渐变、卡片套卡片。Impeccable 想把这些说不清的“一眼假”，变成 62 条可以逐条过的检查项。它的门槛只有两条命令，装完就能对着某个页面跑一次。

项目：pbakaus/impeccable ｜ 来源：GitHub ｜ 2026-10-26

它是什么：让 AI 先记住产品事实，再动手

摘录里对 impeccable 的定性很直接：一套给 AI coding agent 用的设计语言。构成是 1 个 skill、24 个命令、浏览器实时迭代，以及 62 条针对 AI 生成前端的确定性检测规则。

这个构成先摆出来有用，因为它决定了你该怎么看待它：它不是一个要你先读一遍的设计理论，而是一个装进现有工作流、能被调用的 skill。装完之后你面对的是命令和规则，不是章节和原则。

它的起点也不是凭空来的。impeccable 是在 Anthropic 那个被广泛使用的 frontend-design skill 基础上往下做的，承接已有的那套做法，再往具体执行层面延伸，不必当成一套全新的原创方法论。

核心是让 AI 先记住“产品事实”再动手。/impeccable init 会检查项目、只问真正缺失的信息，把受众、目的、运行环境、约束、语气写进 PRODUCT.md；视觉方向另存在 DESIGN.md，两边不混。

这个拆分的实际含义是：AI 在挑字体、定配色之前，手里已经有一份关于“给谁用、在什么环境下跑、有什么限制”的具体描述，而不是从空白页开始猜。

它针对的毛病很具体：字体、渐变、卡片套卡片

AI 编程助手写前端，出来往往是同一副样子。摘录里点名的几个特征非常可指认：Inter 字体铺满全站、紫到蓝的渐变、卡片套卡片、彩色背景上压灰字。

这些不是“感觉不太对”的模糊评价，而是你打开任何一个 AI 刚生成的页面都能对上号的视觉细节。

至于为什么会反复出现这几样，摘录只把它当成一个现象来描述，没有展开更细的原因分析，这里也不替它补。对读者来说，重要的不是归因，而是这些 tell 本身足够具体——具体到可以被写成检测项，而不是只能靠“审美”去争论。

impeccable 的应对方式正是把这些问题变成规则：62 条针对 AI 生成前端的确定性检测规则，配合 audit 查问题、critique 做 UX 评审这类命令，把原本靠模型自觉的部分，转成一份可以逐条过的清单。

怎么用：两条命令装好，命令加目标就能跑

上手路径在摘录里写得很干脆，只有两步。在项目根目录执行 npx impeccable install，然后在你的 AI 编程工具里执行 /impeccable init。摘录里没有提到额外的配置环节，门槛就在这里。

之后的用法是命令加可选目标。比如 /impeccable audit blog 是对着博客这块查问题，/impeccable polish settings 是把设置页收尾。

目标可以省略，也可以指到具体页面或模块上。这让它更像是“对着某个页面跑一次”，而不是对整个仓库做一遍笼统的评估。

24 个命令共享一套词汇，分工是明确的：audit 查问题、critique 做 UX 评审、polish 收尾、distill 去复杂度、bolder 和 quieter 调强弱。

这套词汇的好处是不用每次重新描述意图——你想让它更克制还是更突出，命令本身已经说清楚了。

总结：装之前先想清楚你要它卡哪一步

如果你已经在用 AI 编程工具写前端，而且产出反复落在同一套视觉套路上，那么这个 skill 的尝试成本确实只是两条命令：npx impeccable install 加 /impeccable init。

需要说清楚的是能期待什么。它提供的是设计指导加确定性检测规则，摘录里没有任何效果数据或评测，所以装完能改多少，没有现成答案，得自己对着页面跑一遍才知道。规则能卡住的是可判定的那部分，卡不住的仍然留在原地。

还有一个省不掉的成本：PRODUCT.md 和 DESIGN.md 是分开存的，产品事实和视觉方向要分别维护。产品事实写得越具体，后面那 62 条规则对照的东西就越实在。

至于规则覆盖不到的设计判断，最终还是得人来看。

装与不装，判断依据应该是你自己项目里那几个具体的 tell，而不是它有多少条规则。