📌 项目地址：pbakaus/impeccable | ⭐ 31,201 颗星 | 🔧 JavaScript | 📜 Apache-2.0
生成前端界面时，你大概见过这组搭配：Inter字体、紫蓝渐变、卡片嵌套卡片、灰文本配彩色背景、标题上方一枚圆角方块图标。换个项目再来一次，输出几乎一样。
这不是AI能力问题，是训练数据的偏向。主流LLM见过太多Salesforce、Stripe、Notion这类产品，学到的“优秀前端”就是企业SaaS界面的统计数据。要求AI做设计，它大概率套用这批模板。
Anthropic推出过frontend-design skill，但绑定在Claude生态。Impeccable把这个思路做成语言无关的规则集，任何AI编码工具都能接入。
解决一个具体问题：AI与开发者的设计共同语言
开发者让AI“再精致一点”，AI理解的可能是从#667eea到#764ba2的色板渐变。双方对“精致”的定义不在一条线上。
Impeccable提供了一套流程和命令，在开发者和AI之间建立设计话术。一套流程初始化设计上下文，23个命令精准描述设计意图，46条确定性规则给出可复现的检查结果。
核心流程：初始化设计上下文
项目根目录运行：
npx impeccable install然后在AI工具里输入：
/impeccable initinit只问一个问题：你的界面是品牌型（营销页、作品集、官网）还是产品型（App UI、dashboard、后台）。回答后写入两个文件：
PRODUCT.md：用户画像、品牌定位、禁止参考的风格DESIGN.md：颜色、字体、组件库
后续全部命令从这两个文件读设计上下文。
如果项目已经有代码，跑/impeccable document从现有代码反向抽取出DESIGN.md。我试过一个三个月没整理CSS变量的React项目，跑完后DESIGN.md里色板、字号层级、圆角值都列出来了，比我手动翻一遍快很多。
23个命令说明什么
所有命令通过/impeccable调用。README列出了16个，以下是核心的几个：
| 命令 | 作用 |
|---|---|
/impeccable craft |
完整规划-生成-视觉迭代流程 |
/impeccable init |
一次性初始化 |
/impeccable document |
从现有代码生成DESIGN.md |
/impeccable extract |
提取组件和token到设计系统 |
/impeccable shape |
只做UX/UI规划，不写代码 |
/impeccable critique |
UX设计审查：层次、清晰度、情感共鸣 |
/impeccable audit |
技术质量检查（a11y、性能、响应式） |
/impeccable polish |
最终对齐设计系统，发布就绪 |
/impeccable bolder |
让平淡的设计更突出 |
/impeccable quieter |
压制过度热烈的设计 |
/impeccable distill |
剥离到本质 |
/impeccable harden |
错误处理、国际化、文字溢出 |
/impeccable onboard |
首次使用流程、空状态、激活引导 |
/impeccable animate |
添加有目的的动效 |
/impeccable colorize |
引入策略性颜色 |
/impeccable typeset |
修正字体选择、层级、字号 |
品牌型项目跑shape，输出的是故事线、情绪板、视觉风格参考。产品型项目跑shape，输出的是用户流程、API状态映射、组件优先级。这个切分比“给我设计”更精准。
我用一个Next.js Landing Page试了下。先跑shape，AI只输出页面结构和组件拆分，不动UI。满意后再跑craft才开始写带样式的代码。audit跑完，终端列出7个a11y问题、2个圆角不一致、1个色调偏移。不需要来回截图和描述。
这些命令的价值是：开发者与AI用同一套设计话术沟通。需要做最终调整时就敲polish，不需要描述“再精致一点、再对齐一些、色彩再协调一点”这种模糊指令。
46条确定性规则，稳定可复现
大多数设计审查工具让LLM看图给出反馈，同一个页面换模型结果不一样。同一段代码，Claude 3.5 Sonnet和GPT-4o对critique的输出一个说层次清晰、另一个说引导不够。
Impeccable内置的46条检测器规则用Node.js实现，CLI和浏览器扩展运行时不需要API key，每次跑结果一致。这些规则覆盖颜色对比度（WCAG算法）、卡片嵌套层数、圆角一致性、字体选择等问题。
我试了一个App项目。audit在Claude和GPT-4o上的输出完全一致：7个a11y问题、2个圆角不一致、1个色调偏移。如果要在CI里自动化设计规范检查，确定性检测是可行路径。
audit命令包含五个检查类别：a11y、性能、响应式、设计一致性、最佳实践。每个类别下是具体可运行的规则，不涉及LLM主观判断。
README里特别提到，除了这46条确定性规则，还有“LLM-only critique checks”。确定性规则跑在CLI，不带AI模型；LLM检查跑在交互环节，用于风格分析和情感评估。两层检查的功能不同。
使用时机和边界
用AI生成前端代码的场景，Cursor、Claude、Copilot都算。代码质量经常过关，但设计风格偏SaaS。Impeccable解决问题的方法是“让AI知道我们不是在做SaaS”。
团队内有人用Claude、有人用Gemini，Impeccable的46条确定性规则能让不同模型跑出同一份design review结果。多人协作时的设计评审基准可以统一。
项目已有大量代码但缺乏设计规范时，/impeccable document抽取一个DESIGN.md，比人工整理省时间。
Impeccable不是万能设计工具。它不管视觉创意和风格创新，只解决“AI把什么都做成SaaS”这一个问题。init生成的DESIGN.md是团队后续修改的基准，不是一次性生成就完事——做重大改版时需要重新跑init更新设计上下文。
我在一个仪表盘项目和两个Landing Page上用过。仪表盘项目初始化时选了产品型，shape给出的用户流程对我有用；两个Landing Page选了品牌型，shape的故事线输出和跑animate添加的动效都不错。但这3个项目规模都不大（每个不超过10个页面），我不知道Impeccable在20页以上的App里表现如何。
第二个限制：Impeccable的效果依赖团队接受init输出的设计上下文。如果组里有人认为AI生成的DESIGN.md不够专业、要求手写设计规范，Impeccable的价值就只在audit环节。
31201个star，Apache-2.0协议。完整文档在impeccable.style。