一个工具 17 条命令 专门用于去除前端设计的“AI 味”

AI 做的网站为什么都这么像

"Every major LLM trained on the same web data."（所有主流大模型都在同一批网页数据上训练。）

这是 Impeccable 作者 Paul Bakaus 说的一句话。Paul Bakaus 是 jQuery UI 的创始人，后来去 Google 做 Chrome DevTools 的产品经理，再后来是 AMP 开发者关系的创始负责人。他对前端设计的理解，比大多数人深得多。

他做了一个更准确的诊断："The AI is doing exactly what you told it to do. The issue is that you did not tell it enough."（AI 完全按你说的做了，问题是你说得不够多。）

这句话很刺人，但很准。

你跟 AI 说"做一个现代感的落地页"，AI 给了你紫色渐变加卡片布局。不是 AI 偷懒，是"现代感"这个词对它来说确实就长那样。你没有告诉它你想要的是"低对比度的暖米色背景配深棕文字，用 variable font 做标题，间距宽一点，不要弹跳动画"。

问题的瓶颈不在 AI 的能力，在你的语言。你不知道 vertical rhythm（垂直韵律）怎么回事，不知道 tinted neutrals（着色中性色）怎么用，你就没办法把这些要求传递给 AI。

这是一个设计词汇的问题，不是一个计算能力的问题。

Impeccable 的思路：给 AI 补上设计词汇

Impeccable 是一套给 AI 编程助手用的设计技能包，GitHub 上已经 4.3k stars，Apache 2.0 开源。支持 Claude Code、Cursor、Gemini CLI、Codex CLI、VS Code Copilot 等七个平台。

它的思路很直接：既然瓶颈在语言层面，那就把设计知识打包进来，让 AI 用正确的词汇来理解和执行设计任务。

具体分三层。

第一层，7 份领域参考文档： 排版、色彩对比、空间设计、动效设计、交互设计、响应式设计、UX 文案。这些文档不是给你看的用户手册，是直接喂给 AI 的背景知识。AI 做设计决策的时候，会参考这些内容。

第二层，17 个命令： 这是你每天实际用到的东西。每个命令对应一个具体的设计场景，后面会详细讲。

第三层，明确的反模式清单： 告诉 AI 哪些东西是禁止的。禁用 Inter 字体、禁止彩色背景上放灰色文字、禁止纯黑纯灰、禁止卡片嵌套卡片、禁止弹性缓动动画。这一层相当于给 AI 设了一道过滤网，那些"AI 味"最重的设计模式，直接拦掉。

Anthropic 官方有一个 frontend-design 技能包，已经有 27.7 万安装量。Impeccable 是在这个基础上往深里走，更系统、更有原则、更成体系。打个比方：官方版让 AI 知道"设计原则存在"，Impeccable 让 AI 拥有"系统性应用设计原则的具体词汇"。

两分钟装好，开始用

最省事的装法，一行命令：

npx skills add pbakaus/impeccable

运行完就好了，不用去动任何配置文件。

如果你用的是 Claude Code，也可以走插件市场：

/plugin marketplace add pbakaus/impeccable
/plugin install impeccable@impeccable

想全局安装，让每个项目都能用：

cp -r dist/claude-code/.claude/* ~/.claude/

Cursor 用户：

cp -r dist/cursor/.cursor your-project/

装好后第一件事，做一次初始化：

/teach-impeccable

这个命令会问你几个问题：项目走什么设计风格、有没有特定的字体要求、品牌色是什么。它把偏好存在本地配置里，后续所有命令都按你的标准来，而不是按默认值来。

17 个命令，分场景来讲

命令多不等于复杂，关键是每个命令对应一个很具体的场景。按照我的理解拆一遍：

开始一个新项目，先跑 /teach-impeccable。 这个命令会主动问你一些问题：项目是什么类型、面向什么用户、有没有已有的设计系统。它在建立项目的设计背景，后续所有命令都会在这个背景下运行。这一步不跑的话，AI 对你项目的理解还是空白的。

做完一版想检查质量，用 /audit 和 /critique。 两个命令方向不同。/audit 查的是技术质量，代码是不是规范，有没有明显问题。/critique 查的是 UX 设计，用户体验上有没有缺陷，信息层级是不是清晰。一个是工程视角，一个是设计视角，通常一起用。

做完发现风格不统一，用 /normalize。 多次迭代之后，AI 生成的组件风格会飘，这里按钮是圆角，那里按钮是直角，颜色也对不上。/normalize 做的是对齐，把所有东西拉回同一套设计系统。

准备发布前，跑一遍 /polish。 这是最后的发布前检查，细节层面的扫描，字间距、行高、边距这些容易被忽略的地方。

设计太满，想简化，用 /distill。 这个命令做的是减法，把不必要的视觉元素去掉，找到设计的本质形态。做着做着堆了很多东西，用这个清一遍。

文案读起来别扭，用 /clarify。 专门处理 UX 文案，按钮文字、错误提示、空状态说明这些。不是改语气，是让功能描述更清晰、更符合用户预期。

性能跑起来慢，用 /optimize。 图片没压缩、代码没分割、请求没优化，这些交给 /optimize 扫一遍。

要做得更健壮，用 /harden。 错误处理、边界情况、国际化这些枯燥但重要的东西，不容易做全，/harden 帮你系统性地过一遍。

想加动画，用 /animate。 不是给你加弹跳缓动，而是基于 motion design 原则做有意义的动效。什么地方该动、怎么动、动多少，有原则可依。

配色想改，用 /colorize。 颜色层面的全面检查和调整，对比度、无障碍要求、整体色彩关系。

感觉太普通，用 /bolder。 这是我个人最喜欢的一个。设计太保守、太平、没有记忆点，跑一下 /bolder，它会在设计原则范围内放大视觉强度，字更大、对比更强、空间更有张力。

反过来，感觉太张扬，用 /quieter。 把设计的大胆度往下调，适合风格要求克制的场景。

想要有惊喜感，用 /delight。 加一些用户预期之外的细节，悬停效果、微交互、意想不到的小动画。不是花哨，是有温度。

想把某个组件单独抽出来复用，用 /extract。 把页面里某个做得不错的元素提取成独立组件，方便在其他地方用。

要适配不同设备，用 /adapt。 移动端、平板、桌面的响应式处理，不只是断点，而是针对不同设备的体验优化。

需要做新用户引导，用 /onboard。 设计用户首次使用的引导流程，从进入到完成首个核心操作，路径怎么走，提示在哪里放。

三个具体的使用场景

场景一：接了一个独立开发项目，从零开始。

先跑 /teach-impeccable 建立项目背景。然后正常开发，做完第一版跑 /audit + /critique 检查，发现问题修一轮，再用 /normalize 对齐风格，发布前 /polish 扫一遍。这是 Impeccable 推荐的标准流程，没什么弯路。

场景二：已有项目，设计太普通，想做一次改版。

先 /critique 看清楚问题在哪，然后 /bolder 放大视觉强度，/colorize 重新处理配色，/animate 加一点有意义的动效，最后 /polish 收尾。不用推倒重来，定向改几个关键地方，效果差很多。

场景三：产品快上线，发现有几个坑。

文案读起来绕：/clarify。页面卡顿：/optimize。边界情况没处理：/harden。三个命令各司其职，不会互相干扰，可以按需单独跑。

一张图看完整流程

把上面几个场景合在一起，一个完整的项目流程大概是这样：

1. AI 生成初稿
2. /teach-impeccable 初始化设计标准（只做一次）
3. /audit 查技术问题
4. /critique 查设计问题
5. /normalize 对齐设计系统
6. 有针对性地用 /bolder /distill /animate 调整风格
7. 用 /harden /clarify 处理细节
8. /polish 最终检查

这不是固定公式，实际用起来可以跳着来。对技术层面很有把握，/audit 可以跳过；只是小改动，/normalize 也不一定非要跑。重要的是知道每个命令在做什么，然后按需组合。

AI 工具的上限，越来越取决于它携带了多少领域知识。同样的模型，加了正确的设计知识和反模式约束，输出质量就是不一样

对每天用 AI 做前端的人来说，这个工具值得认真试试。免费开源，装上就用，17 条命令记住常用的 5、6 个就够了。

来源：Impeccable | GitHub 4.3k stars | Apache 2.0 开源