Impeccable：给 AI 编码 Agent 装上设计判断力的工具包

核心观点

AI 写的 UI 为什么一眼就看出来是 AI 写的？问题不在模型智力，而在于训练数据的"平均化倾向"------所有模型都见过海量 SaaS 模板，于是默认输出全行业公约数：Inter 字体、紫蓝渐变、卡片套卡片、彩色底上灰色文字。这种现象有个专门的贬义词叫 "AI slop"（AI 糊弄美学）。

Impeccable 的出发点就是对抗这种同质化，但它的方式比"换个 prompt"更系统：它把设计判断力封装成一套可复用的 AI Skill，通过 23 条命令和 60 条确定性规则，把设计决策流程化。

它处于什么阶段？

这不是范式突破，是渐进优化------但位置关键。

2024 年 Anthropic 推出了 frontend-design skill，是把设计意图注入 AI 编码 Agent 的第一次尝试。Impeccable 从那里分叉，是这个思路的第二代实现：原版 skill 更像一份风格指南，Impeccable 在此基础上加了可执行命令、确定性规则检测、跨工具兼容和项目级配置。

参照系应该是：它不和 Figma 或 Storybook 竞争，也不和 Tailwind CSS 竞争------它是专门用来"告诉 AI 该做什么设计决策"的中间层，填的是"AI 执行力有了、但设计判断没有"这个空洞。

最核心的机制：反模式库 + 项目上下文锁定

表面上看 Impeccable 是 23 条命令，但真正巧妙的地方有两处：

第一，反模式库（Anti-Patterns）。 不告诉 AI "你应该用好字体"，而是明确禁止 AI 走的捷径：

禁用 Arial、Inter、系统默认字体
禁止纯黑/纯灰（永远要带色调）
禁止弹跳/弹性缓动（bounce/elastic easing）
禁止彩色背景上的灰色文字

这种"负向约束"比"正向指导"更有效，因为 AI 更容易走已有路径，而不是凭空创造新路径------堵死旧路才能逼出新路。

第二，/impeccable init 的项目上下文锁定。 init 命令会生成 PRODUCT.md 和 DESIGN.md，把受众、品牌调性、反参考（anti-references）、颜色、字体、组件规范固化下来。后续每一条命令都读这两个文件，确保整个项目设计语言一致，而不是每次 prompt 都从零开始。这本质上是把"设计决策上下文"持久化到项目里。

第三，60 条确定性检测规则。 关键在"确定性"：这部分不走 LLM，不消耗 API key，纯规则引擎运行。检测对比度、无障碍标准、响应式断点等客观问题时，比让大模型"自己审查"可靠得多。

和前代方案的对比

维度	Anthropic `frontend-design` skill	Impeccable
定位	风格参考文档	可执行命令 + 规则引擎
覆盖工具	主要 Claude Code	Claude Code、Cursor、Gemini CLI、Codex、Copilot 等 10+
项目上下文	无持久化	PRODUCT.md + DESIGN.md
规则检测	LLM 判断	60 条确定性规则（无 API key）
命令数量	少量	23 条，覆盖 init→shape→craft→polish 全流程

相比原版 skill，Impeccable 牺牲了什么？灵活性和轻量性 。安装步骤更多，有 CLI 依赖，项目里会多出 .impeccable/ 目录和配置文件。对于只需要"偶尔改改界面"的场景来说，这套东西确实偏重。

安装与使用

快速上手（推荐方式）

bash 复制代码

# 在项目根目录安装
npx impeccable install

然后在 AI 编码工具里运行



/impeccable init
`/impeccable init
`

init 会问你这是 brand 面 （落地页/营销/作品集）还是 product 面（应用/dashboard/工具），然后写入对应的设计上下文文件。

典型工作流

bash 复制代码

/impeccable shape          # 先规划 UX/UI，再写代码
/impeccable craft          # 完整的形态→构建流程
/impeccable audit blog     # 审计 blog 页（无障碍+性能+响应式）
/impeccable critique landing # UX 设计评审
/impeccable polish settings  # 发布前最终清理
/impeccable harden checkout  # 错误处理 + 边界情况

也可以直接描述意图：

bash 复制代码

/impeccable redo this hero section
/impeccable bolder   # 放大设计张力
/impeccable quieter  # 收敛过度设计
/impeccable distill  # 剥到最精简

常用命令快捷方式

bash 复制代码

/impeccable pin audit   # 创建 /audit 快捷命令

.gitignore 配置

gitignore 复制代码

# impeccable-ignore-start
.impeccable/config.local.json
.impeccable/hook.cache
# impeccable-ignore-end

config.json、design.json、critique/*.md 属于项目共享产出，应该提交到 git。

交叉验证

信源一：Text Matrix（txtmix.com）的独立评测（非官方，第三方技术博客）

该文章认同 Impeccable 的核心价值，并补充了一个关键数据点：项目在 GitHub 上已积累约 15,000 Stars，这是社区真实认可度的客观指标，不是官方自述。文章也独立确认了反模式库是区别于其他工具的核心差异，并指出其"不需要设计背景"的低门槛特征------AI 内置了设计知识，用户只需要指令驱动。

信源二：掘金社区（juejin.cn）对 frontend-design skill 的独立分析

该文章没有直接评测 Impeccable，但从上游视角验证了 Impeccable 解决的问题是真实存在的：AI 生成界面同质化是公认痛点，原版 frontend-design skill 的四层框架（Purpose → Tone → Constraints → Differentiation）也有明显局限------它依赖 prompt 质量，描述模糊则输出仍偏"安全"。这从侧面支撑了 Impeccable 用"持久化上下文文件"替代"每次 prompt"的设计决策是合理的。

两个信源均未反驳原文核心观点，但也都没有指出 Impeccable 存在的潜在问题------这一点需要独立判断（见下文边界部分）。

诚实的边界与局限

命令是引导，不是保证。 23 条命令最终还是交给 LLM 执行，输出质量依赖模型能力和当前代码库上下文。确定性规则检测了 60 条客观问题，但"设计有没有灵魂"这件事仍然由 LLM 主观判断。
对强设计团队价值有限。 如果团队本来有成熟的设计系统和设计师参与，Impeccable 的价值主要集中在 audit/harden 这类检查命令，而非 craft/bolder 这类创作命令。
工具生态碎片化风险。 目前支持 10+ 工具，但每个工具的安装方式、hooks 机制、信任模型都不同（Codex 需要 /hooks 审批，Grok 需要 /hooks-trust），维护这套适配层的长期成本不低，工具本身升级时可能需要重新安装。
目前版本和文档存在滞后。 原文中部分数字（如"60 条规则"）与其他信源（"58 条"）存在微小出入，说明文档和实际版本有时不同步，使用时建议以实际 npx impeccable 输出为准。

个人启发

对独立开发者/小团队： 最高 ROI 的用法是把 init 走一遍，生成 PRODUCT.md + DESIGN.md，然后把这两个文件提交进 git。这一步的价值不只是给 AI 看------它强迫你在写代码前先把"这是给谁用的、什么调性、反参考是什么"想清楚，而这个思考过程本身比生成的文件更值钱。

对已有项目的改造： /impeccable document 可以从现有代码逆向生成 DESIGN.md，这是一个低风险的切入点，不需要从头规划，适合遗留项目。

对决策者： Impeccable 本质上是在回答"如何在 AI 辅助开发流程里保持设计一致性"这个问题。如果团队里 AI coding tool 已经是标配，值得花半天时间评估这套工具是否能减少设计返工。

推演：接下来会怎样

这类"AI Agent Skill"正在成为一个独立的软件品类。Addy Osmani（Chrome 团队）也在做 agent-skills（production-grade engineering skills），方向一致。可以预见的趋势是：各垂直领域（测试、安全、性能、文案）都会出现类似框架，本质是把领域专家知识编译成 AI 可消费的"约束集"。Impeccable 是前端设计领域的早期布局者，先发优势明显，但护城河不深------如果主流 IDE（VS Code/Cursor）或大模型厂商把类似功能内置进去，独立工具的位置会被压缩。

延伸思考

"反模式库"作为一种设计模式本身值得深思：告诉 AI "不要做什么"比告诉它"要做什么"更有效，这个现象背后是 AI 的什么推理机制？在哪些其他领域也可以用负向约束来提升输出质量？
确定性规则 vs LLM 判断的边界应该怎么划？ Impeccable 用 60 条确定性规则处理可量化的设计问题（对比度、间距），用 LLM 处理主观设计问题（是否有灵魂感）。这个划分是否足够？有哪些设计问题目前被错误地交给了 LLM 处理？
当 AI Agent 的设计能力持续提升，DESIGN.md 这类人工编写的上下文文件会消失还是会变得更重要？ 设计意图的表达本来就是人类的工作，工具进步后，人类的职责是从"写代码"转移到"写设计意图"------这是一种降级还是升级？

📚 参考来源

GitHub - pbakaus/impeccable: The design language that makes your AI harness better at design. · GitHub