用设计技能改善AI生成的前端

AI 能很快拼出一个能用的网站，但页面经常带着相似的痕迹：Inter 字体、紫蓝渐变、层层嵌套的卡片。Impeccable 想解决的，就是这种「功能交付了，设计还停在默认模板」的问题。

它把设计指导做成 AI 编程工具能使用的 skill，配上 24 个命令、62 条确定性检测规则和浏览器内迭代。对前端开发者而言，值得借鉴的不只是这套工具，还有它的思路：把抽象的审美要求拆成可执行、可检查的步骤。不过，检测通过和设计优秀之间，仍有一段距离。

为什么设计指导不能只靠一句提示词

Impeccable 从 Anthropic 的 frontend-design skill 延伸而来。作者认为，只给 AI 一份设计说明还不够，应该让它拥有一套共同的设计词汇，知道什么时候规划、什么时候检查、什么时候收敛细节。

其中最具体的是 62 条确定性检测规则。所谓确定性，就是不需要语言模型参与，按照固定条件检查，同样的输入可以得到可重复的结果。CLI 和浏览器扩展执行这些规则时，不需要 API key。

规则针对的是一些常见视觉特征：过度使用 Arial、Inter 和系统默认字体，在彩色背景上放灰色文字，大面积使用未经调色的纯黑或灰色，把所有内容都塞进卡片，甚至卡片里面再套卡片，以及使用显得过时的 bounce、elastic 缓动。

这类检查的价值在于稳定。AI 不必每次都记住长提示词，开发者也不必每次重新解释哪里看着别扭。

但规则覆盖不了全部设计判断。原文把视觉层级、表达清晰度、情绪感染力等问题交给 LLM 批评检查。前者寻找具体特征，后者判断整体效果。

可重复的检测适合发现问题，却不能单独证明设计好坏。

先写清产品，再决定页面长什么样

安装从项目根目录执行 npx impeccable install 开始，再在 AI 编程工具中运行 /impeccable init。

按原文描述，init 会检查项目，只针对缺失的重要信息提问，然后生成 PRODUCT.md，记录受众、目的、使用环境、约束、语气和依据。视觉方向则单独放进 DESIGN.md。

这个拆分很实用。产品服务谁、用户要完成什么任务，不应该因为换了一套配色就跟着变化；反过来，明确了用户和任务，也不代表字体、布局已经有了答案。两个文件分别保存这些信息，能减少 AI 把产品定位和视觉风格混为一谈的情况。

后续命令覆盖了从规划到交付的过程。shape 在写代码前规划 UX 和 UI；craft 串起先规划、再构建、再做视觉迭代的流程。critique 检查层级、清晰度和情绪感染力，audit 检查可访问性、性能及响应式表现，polish 负责上线前的细节整理。

调整方向也有对应词汇：bolder 强化平淡的设计，quieter 降低过度表达，distill 去掉多余部分。局部处理则包括 animate、colorize、typeset、layout、delight 和 overdrive，分别涉及动效、色彩、字体层级、间距节奏、趣味细节和更复杂的技术效果。

原文还列出 harden、onboard、clarify、adapt、optimize，覆盖错误处理、国际化、文字溢出、首次使用流程、空状态、文案、多设备适配和性能优化。这让「改好看一点」变成了更容易分配和验收的任务。

它怎样接进现有 AI 编程流程

Impeccable 宣称提供 24 个命令，入口统一在 /impeccable 下。pin 可以把命令固定成独立快捷入口，例如 pin audit 会得到 /audit。

浏览器迭代由 live 和 generate 承担，二者都能直接围绕页面元素调整，generate 还支持无需手动选择的变体挑选。不过，原文没有展开变体的评价依据，也没解释自动挑选怎样确认符合产品目标。

安装器会识别本机目录和 CLI，支持 Claude Code、Cursor、Codex、GitHub Copilot、Gemini CLI、Grok Build、Hermes Agent 和 Veto，并允许安装到项目或全局。

这里还有一个容易误读的技术细节：skill 本身不需要单独的运行时，但随附启动器会在首次运行时下载自包含的引擎二进制。Node 只在使用 npx 安装器时参与，手动安装和 Git 安装不依赖它。因此，它并非所有执行都只靠一份 Markdown。

项目采用 Apache 2.0。原文称它于 2025 年 11 月发布，不到一年超过 86,000 GitHub stars、5,000 forks，并且在文章撰写前几天仍有提交。这些是原文报告的时间和规模，不能直接当成当前数据。

我的判断

我认同它把设计指导拆成产品信息、视觉方向、固定检查和整体批评。相比反复追加「高级一点」「有设计感」，这种方式更便于团队复用，也更容易定位一次修改到底在解决什么问题。

但把 Inter、卡片或渐变识别成风险信号，有使用前提。后台系统可能就需要稳定的系统字体，信息密集的工作台也可能适合卡片。原文没有说明这些规则如何适配已有设计系统、怎样设置例外，以及误报有多少。

因此，检测结果更适合作为复核入口，不能替代产品场景判断。

证据也要分开看。原文提到 Neo Mirai 项目的前后对比案例，但没有提供任务完成率、可访问性得分、性能变化，或与普通提示词、既有组件库的对照数据。「能减少默认模板感」有明确的方法支撑，「能持续做出更好的设计」目前仍主要是经验之谈。stars 和 forks 能说明关注度，不能证明每个团队接入后都有同样收益。

能拿来做什么

• 在下一次 AI 生成页面前，先整理 PRODUCT.md 和 DESIGN.md，把受众、任务、约束与视觉方向写清楚，再让 AI 开始构建。
• 对已有前端页面先运行 audit 或 critique，把技术问题和整体设计意见分开处理，再用 typeset、layout 等命令逐项修改。
• 给使用现有组件库的项目设定明确边界，遇到字体、卡片或颜色告警时，结合设计规范复核，避免为了消除提示而破坏一致性。
• 试用 live、generate 时，保留修改前后的页面，并按真实使用任务比较结果；原文没有给出的效果证据，可以从自己的项目中补齐。