给模型一套设计词汇：Impeccable 如何把「AI 味」变成可检测、可修复的工程问题

文章目录

• 一、从一个熟悉的挫败感说起
• [二、先把问题定义清楚：AI slop 到底是什么](#二、先把问题定义清楚：AI slop 到底是什么)
• • [2.1 它是一份可以穷举的清单](#2.1 它是一份可以穷举的清单)
  • [2.2 为什么模型会稳定地产出这些东西](#2.2 为什么模型会稳定地产出这些东西)
• [三、词汇层：把设计干预拆成 23 个可调用的动词](#三、词汇层：把设计干预拆成 23 个可调用的动词)
• • [3.1 命令即接口](#3.1 命令即接口)
  • [3.2 词汇的双向价值](#3.2 词汇的双向价值)
  • [3.3 一个具体的调用长什么样](#3.3 一个具体的调用长什么样)
• [四、上下文层：`PRODUCT.md` 与 `DESIGN.md`](#四、上下文层：PRODUCT.md 与 DESIGN.md)
• • [4.1 一次说清，每次都读](#4.1 一次说清，每次都读)
  • [4.2 反向生成：`document` 与 `extract`](#4.2 反向生成：document 与 extract)
  • [4.3 四种模式：先问「这个界面是干什么的」](#4.3 四种模式：先问「这个界面是干什么的」)
• 五、约束层：把审美判断降级成确定性规则
• • [5.1 检测器：59 条不需要 LLM 的规则](#5.1 检测器：59 条不需要 LLM 的规则)
  • [5.2 工程化的例外机制](#5.2 工程化的例外机制)
  • [5.3 Hook：把反馈闭环装进编辑循环](#5.3 Hook：把反馈闭环装进编辑循环)
• 六、探索层：用骰子把模型推出舒适区
• • [6.1 「创意」这个词对模型无效](#6.1 「创意」这个词对模型无效)
  • [6.2 为什么是「随机」而不是「更好的提示词」](#6.2 为什么是「随机」而不是「更好的提示词」)
  • [6.3 「完全承诺」比「面面俱到」更重要](#6.3 「完全承诺」比「面面俱到」更重要)
• [七、Live Mode：让视觉修改变成可指称的操作](#七、Live Mode：让视觉修改变成可指称的操作)
• 八、分发层：一条命令，多份构建
• 九、一条可落地的实践路径
• 十、这套结构的通用性：不止于设计
• 十一、边界与需要警惕的地方
• 十二、结语：把品味变成基础设施
• • 参考与延伸

一句话概括：Impeccable 做的不是「让 AI 画得更好看」，而是把「好看」拆成可命名的命令、可读取的上下文、可判定的规则和可回滚的产物------设计从审美争论变成了工程流程。

一、从一个熟悉的挫败感说起

把需求丢给 Coding Agent，几十秒后一个能跑的页面出现在浏览器里：紫色到靛蓝的渐变标题、圆得过分的卡片、若隐若现的玻璃拟态、右上角一个永远在呼吸的绿色小圆点、正文里塞着「Boost your productivity」。功能没问题，交互也没问题，但你一眼就知道------这是机器写的。

这种「一眼假」有个已经被叫开的名字：AI slop。它不是 bug，测试跑得通，Lighthouse 分数也不低；它是一种气质上的失败：所有 AI 生成的界面长得像同一个人做的，而那个人品味平庸、缺乏立场。

更难受的是，你想改，却说不清要改什么。你能说「感觉有点廉价」「再高级一点」，但很难说出「垂直韵律不统一」「字阶跨度不够，H1 和 body 的对比度只有 1.6 倍」「主色在 OKLCH 空间里明度太高，压不住大面积留白」。这才是真正的瓶颈：不是模型不会做设计，是你和模型之间缺一套共用的设计词汇。

impeccable.style 这个项目（作者 Paul Bakaus，开源在 pbakaus/impeccable）正面回答了这个问题。它把自己定义成「agents 缺失的那层设计词汇」（the missing design vocabulary for agents），形态是一个 Agent Skill：装进 Claude Code、Cursor、Codex CLI、Gemini CLI、GitHub Copilot、Grok Build 等主流 harness，用 /impeccable polish、/impeccable typeset、/impeccable distill 这样的斜杠命令，在你的真实代码库里做设计干预。

这篇文章不打算写成一份使用说明。更值得拆的是它背后那套结构：当一个模糊的、主观的、依赖品味的任务，需要交给概率模型稳定完成时，工程上应该怎么组织？ Impeccable 给出的答案有四层------词汇层、上下文层、约束层、探索层------每一层都能迁移到设计之外的领域。

---

二、先把问题定义清楚：AI slop 到底是什么

2.1 它是一份可以穷举的清单

很多人把 AI slop 当成玄学，Impeccable 的第一个关键动作是把它降维成具体的、可枚举的视觉特征。项目维护着一份「slop 目录」，里面每一条都是能被指认的模式，比如：

• 紫色/靛蓝渐变：模型对「科技感」的默认联想，出现频率高到成为标记物；
• AI beige：那种介于米白和浅灰之间、谁都不得罪也谁都记不住的背景色；
• 玻璃拟态（glassmorphism）：半透明 + 背景模糊，滥用后所有层级都糊在一起；
• 侧边条边框（side-tab border）：卡片左侧一条 4px 彩色竖线，配上大圆角，边框曲率和圆角互相打架；
• 呼吸小圆点 ：用 animate-pulse 表示「实时」，但页面上没有任何东西是实时的；
• 过度圆角 ：rounded-2xl 无差别铺满，按钮、卡片、输入框全一个曲率，层级消失；
• 弹跳缓动（bounce easing）：所有过渡都带回弹，界面像果冻；
• 暗色辉光：深色背景 + 大范围彩色投影，冒充「高级感」；
• 斜体衬线小标题：用来假装「编辑感」的廉价手法；
• Modal 滥用：三栏 + 滚动条的设置面板硬塞进弹窗，它本该是一个独立页面。

除了「AI 特征」这一类，目录里还有另一类------通用设计质量问题，与谁写的无关：行长超过舒适阅读区间、padding 过于局促、触控目标小于最小可点区域、标题层级跳跃（H2 直接跳 H4）、对比度不足、字阶没有节奏。

把这两类分开是有讲究的：前者是「像 AI」，后者是「不专业」。混在一起谈，就会退化成风格口水战；分开谈，才能分别给出检测手段和修复策略。

2.2 为什么模型会稳定地产出这些东西

把清单列完，根因就浮出来了，大致四条：

第一，训练分布的引力。 模型学到的是「互联网上大多数落地页长什么样」。2020 到 2024 年间，Tailwind 默认色板 + shadcn/ui 默认圆角 + 渐变标题构成了一个巨大的模式峰值。让模型「自由发挥」，它会滑向这个峰值------这是采样的必然，不是模型偷懒。

第二，提示词的词汇缺失。 用户说不出精确的干预指令，只能给出「更好看一点」这类零信息量的反馈。零信息量的反馈 = 模型按默认分布重采样 = 换汤不换药。

第三，上下文缺位。 模型不知道这个产品给谁用、在什么场景下用、品牌语气是什么、已有哪些 token 和组件。缺了这些约束，它只能用通用最优解填空，而通用最优解就是平庸。

第四，没有反馈闭环。 传统工程有类型检查、lint、测试、CI 门禁；设计侧什么都没有。模型写完就走，没有任何机制告诉它「你刚才又用了紫色渐变」。

Impeccable 的四层结构，恰好一一对应这四条根因。

---

三、词汇层：把设计干预拆成 23 个可调用的动词

3.1 命令即接口

项目最核心的设计判断是：设计不是一个动作，而是一组彼此正交的干预类型。 于是它提供了 23 个命令，每个命令只命名一种干预：

命令	类别	干预对象
craft [feature]	构建	从构思到实现，端到端做一个功能
shape [feature]	构建	写代码前先规划 UX/UI
teach	构建	建立 PRODUCT.md 与 DESIGN.md 上下文
document	系统	从现有代码反向生成 DESIGN.md
extract [target]	系统	把散落的样式抽成可复用 token 与组件
typeset	精修	字体、字阶、行高、垂直韵律
colorize	精修	品牌色应用与色彩策略
arrange	精修	布局与空间关系
animate	精修	动效与缓动曲线
distill	精修	削繁就简，回到本质
bolder / quieter	精修	整体表达力度的双向调节
delight	精修	加入记忆点与细节
polish	加固	交付前的最终质量收口
audit	加固	生产级质量检查
critique	加固	LLM 设计评审
harden / optimize	加固	健壮性与性能
live	系统	在运行中的应用里实时迭代
init	系统	首次安装后的项目扫描与初始化

这张表最值得琢磨的不是命令数量，而是颗粒度的选择 。typeset 和 colorize 是分开的，bolder 和 quieter 是一对反向操作，polish 和 audit 一个是修一个是查。这意味着每次调用只改变一个维度------对模型来说，单维度指令的方差远小于「把这页做好看」；对人来说，多轮迭代可以逐步逼近，而不是每次全量重掷骰子。

这本质上是把设计操作做成了幂等、可组合的算子集合。跟图像处理的滤镜链、跟数据库的关系代数是同一种思路。

3.2 词汇的双向价值

值得强调的是：这套词汇不只喂给模型，也在教人。

大部分开发者不是不在乎设计，是缺少表达设计意图的语言。当你的 harness 里躺着一个 /impeccable typeset，你就自然会意识到「排版是一个可以单独处理的维度」；当你看到 distill 的说明写着「strip to the essence」，你就会开始怀疑自己那个塞了七个 CTA 的首屏。

一个好的抽象层，同时抬高了工具和使用者的水位。 这是我认为 Impeccable 最被低估的地方。

3.3 一个具体的调用长什么样

/impeccable polish the pricing page. Keep our sharp corners and sober palette. Remove the AI tells.

agent 的响应路径大致是：

↳ DESIGN.md loaded            现有设计系统已载入，不覆盖
↳ 4 tells found               AI beige · 斜体衬线 · 侧边条 · 呼吸圆点
✓ Written to source           检测器复检 0 findings

注意三个细节：先读系统再动手 、明确列出发现的 AI 特征 、改完自动跑检测器复检。这已经不是「生成一段代码」，而是一条带前置条件和后置断言的流水线。

---

四、上下文层：PRODUCT.md 与 DESIGN.md

4.1 一次说清，每次都读

词汇解决了「怎么说」，上下文解决「基于什么说」。Impeccable 用两个 Markdown 文件承载项目的设计语境，并要求每个命令执行前都读一遍。

PRODUCT.md 记录产品语境，典型内容：

# PRODUCT.md

# Users
值班中的 SRE。快速扫读，常在昏暗环境，注意力被告警切碎。

# Mode
Operate ------ 设计服务于任务完成，不服务于说服。

# Brand voice
冷静、临床化、零营销腔。

# Anti-references
紫色渐变。玻璃拟态。"Boost your productivity"。
任何需要用户停下来欣赏的动效。

这里最狠的一栏是 Anti-references（反向参考） 。正向描述「我想要高级感」几乎无法约束采样空间，但「不要紫色渐变、不要玻璃拟态、不要营销腔」是可判定的负向约束，直接砍掉分布中最肥的那几个峰。写 prompt 的人都懂：negative constraints 往往比 positive ones 更有力。

DESIGN.md 记录视觉系统本身，采用 Google 推出的 DESIGN.md 开放格式（Stitch 生态在用的那套）------单个 Markdown 文件，描述色板、字体、组件、间距规则，让任何支持该格式的工具都能读懂：

# DESIGN.md

# Color
primary:   oklch(78% 0.12 82)
surface:   oklch(21% 0.01 260)
danger:    oklch(62% 0.20 25)
对比度基线：正文 ≥ 7:1，次要文本 ≥ 4.5:1

# Type
Wordmark: Avenir Next, letter-spacing 400
Body:     Avenir Next Regular 400 / 1.6
字阶：1.25 模块化比例，共 6 级，禁止跳级

# Shape
radius: 2px / 6px（仅两档，卡片用 6px，控件用 2px）
禁止：任何大于 8px 的圆角

# Components
34 个，Button（primary / secondary / ghost / destructive）、
Card（3 变体）、Input、Select、Dialog、Toast、Table...

用 OKLCH 而不是 HEX 是个有信息量的选择：OKLCH 在感知上均匀，明度分量可以独立调整而不影响色相观感，这让「把主色压暗两档」这种指令对模型来说变成了确定的算术，而不是猜色号。同理，用模块化比例定义字阶、用两档圆角替代自由取值，都是在把设计决策压缩成参数空间里的离散选择------离散化之后，模型出错的空间就小了。

4.2 反向生成：document 与 extract

现实项目往往已经有一套（哪怕混乱的）视觉系统。所以有两个反向命令：

• /impeccable document 扫描代码库，把实际在用的 token、组件、约定固化成 DESIGN.md；
• /impeccable extract 把散落在各处的魔法数字和重复样式抽取成可复用的 token 与组件。

这一步的工程价值很直接：你的视觉系统从「存在于某个人脑子里和几千行 CSS 里」变成了一个可版本控制、可 diff、可跨工具携带的文件。 换 harness、换模型、换同事，系统还在。

4.3 四种模式：先问「这个界面是干什么的」

还有一个容易被忽略但极其关键的抽象------在设计之前先声明界面的模式：

模式	目标	典型场景	设计取向
Persuade	赢得注意力	落地页、定价页	允许表达、对比强烈、有戏剧性
Operate	完成任务	控制台、后台、仪表盘	信息密度高、干扰最小、可预测
Read	建立理解	文档、博客、知识库	排版优先、行长可控、节奏稳定
Experience	让作品说话	作品集、品牌站	视觉主导、允许打破常规

为什么重要？因为「好设计」在不同模式下的定义完全相反。落地页的大留白和戏剧化排版，搬到值班仪表盘上就是灾难；仪表盘的紧凑表格搬到落地页就是劝退。模型如果不知道模式，只能取一个「平均值」------而所有平均值都是平庸的。先声明模式，等于先把目标函数换掉。

---

五、约束层：把审美判断降级成确定性规则

5.1 检测器：59 条不需要 LLM 的规则

这是整个项目里最「工程」的部分。Impeccable 附带一个确定性检测器，覆盖 59 条规则，不调模型、不需要 API key，纯静态/布局分析：

npx impeccable detect src/                    # 扫描目录
npx impeccable detect https://example.com     # 通过 Puppeteer 扫真实页面
npx impeccable detect --no-config src/        # 忽略项目配置，做原始扫描

规则按检测方式分成几档，这个分层非常务实：

• CLI：纯静态可判定，读文件就能查（紫色渐变、圆角上的粗色边框、bounce 缓动）；
• Browser：需要真实布局才能判定（行长、触控目标尺寸、实际对比度），走浏览器扩展或 Puppeteer；
• LLM only ：没有确定性检测手段的，交给 /impeccable critique 的模型评审；
• opt-in ：特定模型的习惯性 tell，默认关闭，用 --gpt、--gemini 显式开启。

最后一档尤其有意思：不同模型有不同的口癖。 Gemini 偏爱图片 hover 位移，Codex 偏爱幽灵卡片和过度圆角。把这些做成可选规则集，等于承认「AI 味」不是一个统一概念，而是按模型分布划分的一组指纹。

5.2 工程化的例外机制

一个检测器好不好用，关键看它怎么处理误报。Impeccable 提供了三层豁免：

// .impeccable/config.json
{
  "detector": {
    "ignoreRules": ["overused-font"],
    "ignoreFiles": ["src/legacy/**"],
    "ignoreValues": {
      "overused-font": [{ "value": "Inter", "reason": "品牌指定字体" }]
    },
    "designSystem": { "enabled": true }
  }
}

以及跟着文件走的内联豁免：

// impeccable-disable-next-line gradient-text
<h1 className="bg-gradient-to-r from-brand-500 to-brand-700 bg-clip-text">

仓库级配置 + 文件级注释 + 命令行覆盖------这套组合和 ESLint 的心智模型完全一致。熟悉的形状降低了采用成本，也说明作者清楚：任何静态规则集想活下来，必须先解决「规则错了怎么办」。

5.3 Hook：把反馈闭环装进编辑循环

检测器最有价值的用法不是手动跑，而是挂成 hook，插在 agent 的编辑动作之后：

1  编辑落地        agent 更新 Hero.tsx
2  hook 返回两条   AI beige · 标签被裁切
3  agent 自我修正  第二遍：clean
✓  深度审查        0 findings，可以提 PR

这一步在架构上很关键：agent 获得了一个不依赖人类在场的、即时的、机械的反馈信号。 它把「人来发现问题 → 人来描述问题 → 模型修改」的慢环，替换成「机器发现 → 结构化回传 → 模型自纠」的快环。同一套规则再往上一层挂到 CI：

# .github/workflows/design.yml
name: design-gate
on: [pull_request]
jobs:
  detect:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '22.12' }
      - run: npx impeccable detect src/ --format json

JSON 输出 + 退出码，可以直接卡合并。到这一步，设计质量第一次和类型错误、lint 违规站在了同一个位置：一个会让构建失败的客观信号。

此外还有 Chrome 扩展，把同一套检测器做成任意页面上的浮层------扫自己的预发环境，也可以扫竞品。这个能力被低估了：它让检测器从「我的项目的门禁」变成「一把随身的尺子」。

---

六、探索层：用骰子把模型推出舒适区

6.1 「创意」这个词对模型无效

约束层解决了「不要难看」，但还有另一半问题：不要千篇一律。

让模型「有创意一点」，它每次都会给你它最喜欢的那个方案。原因还是采样分布：在没有额外信息的情况下，高概率区域就是它的「创意」。多跑十次，得到十个近似解。

Impeccable 的应对方式是 worlds + dice ：维护一个人工评审过的「视觉世界」牌库，每个世界是一套完整的图形系统------有自己的色彩逻辑、排版立场、构图法则、动效性格。设计开始前，系统从牌库里发牌（官网展示的是从 177 个高分世界里实时抽取），让这些外部方案与模型自己从产品推导出的方向同台竞争，胜出的方向被完整执行，不做折中。

6.2 为什么是「随机」而不是「更好的提示词」

这里的技术直觉值得单独说：随机注入是一种廉价而有效的分布外采样手段。

• 提示词优化是在同一个分布里换措辞，边际收益递减；
• 随机发牌是直接把一个高质量的、模型不会自发选择的先验塞进上下文，强行改变条件分布；
• 牌库经过人工评审，保证了「随机」不等于「随便」------它是在一个已知优质的候选池里随机，方差来自选择，质量下限由策展保证。

这跟遗传算法里的变异算子、跟推荐系统里的探索项、跟 Oblique Strategies 那套创作卡牌是同构的。结构化的随机性，是对抗模式坍缩最经济的工具。

6.3 「完全承诺」比「面面俱到」更重要

还有一条隐含的设计哲学：方向选定后要完整执行（fully committed），不做多个风格的加权平均。

模型天然倾向于折中------因为折中在损失函数上更安全。但设计上，折中的结果是「哪个方向都沾一点，哪个都不成立」。强制承诺单一方向，是用流程对抗模型的风险厌恶。这一点对任何生成式任务都适用：平均是安全的，也是没有记忆点的。

---

七、Live Mode：让视觉修改变成可指称的操作

用文字改界面的根本困难在于指称。「把那个按钮再小一点」------哪个按钮？「那块区域太挤」------哪块？纯文本通道下，你和模型在描述同一个空间对象时，坐标系是不共享的。

/impeccable live 的做法是把运行中的应用变成共享工作台：

/impeccable live
↳ Live helper started      picker 注入到应用中
↳ localhost:3000 opened    连接到生产源码
●  Waiting for input       选一个元素，或对整页下指令

然后你在浏览器里直接点中 h1，选 adapt，要 3 个变体：

Generating variants...
‹ 1 / 3 ›   ✕  Accept
→ Variant 3 written to source

这里有三个关键性质：

1. 指称问题被解决了。 点选替代描述，歧义降到零。
2. 变体基于真实设计系统计算。 生成的三个方案用的是你的品牌色、你的字阶、你的间距，不是通用变体。
3. 接受后写回源码。 不是截图、不是 Figma 稿，是可提交的代码 diff。

第三点尤其重要。设计工具与代码之间那道传统的鸿沟------设计稿改完还要有人翻译成代码------在这里被绕过了。唯一的真相源始终是仓库。

---

八、分发层：一条命令，多份构建

安装只有一行：

npx impeccable install

但底下做的事情不简单：它检测你的 harness 与模型，编译出针对该目标的专属构建。

目标	附加内容
Claude Code	hooks + 专用 subagent
Cursor	pre-edit hook
Gemini CLI	Gemini 专属 slop 规则（如禁掉图片 hover 位移）
Codex CLI	Codex 专属 slop 规则（如禁幽灵卡片、过度圆角）

首次运行 /impeccable init 扫描 token、组件与 Tailwind 配置，建立上下文；升级用 npx impeccable update。环境要求 Node 22.12+。除上述之外，OpenCode、Kiro、Trae、Qoder、Rovo Dev、Mistral Vibe、Antigravity 等一批 harness 也在支持列表里；GitHub Copilot 应用里则是内置的，在设置的实验项里直接启用。

「同一份技能，按目标重新编译」这个模型值得单独拎出来讲。 它承认了一个现实：Agent Skill 不是纯文本，它的效果强依赖于运行环境的能力（有没有 hook、支不支持 subagent）和模型的具体偏差（各家有各家的口癖）。把这些差异吸收进构建产物，而不是暴露给用户去配置，是很成熟的产品判断------跨平台一致性的代价，应该由工具链承担，不是由用户承担。

---

九、一条可落地的实践路径

把上面的能力串起来，一个真实项目的推进顺序大致如下。

第 0 步：安装与初始化

npx impeccable install
# 重载 agent
/impeccable init

init 会走一遍代码库：

✓ src/styles/tokens.css      14 colors, 6 font sizes, 7 spacing steps
✓ tailwind.config.ts         theme.extend merged
✓ src/components/            34 components
✓ DESIGN.md                  brand rules loaded
→ Matching your system. Not inventing one.

最后一行是这个项目的立场声明：继承你的系统，不是覆盖它。 这一点决定了它能不能进存量项目------大多数「AI 设计工具」失败在这里，它们只会从零生成漂亮的新东西，一碰到既有代码库就水土不服。

第 1 步：写清楚产品语境

/impeccable teach

认真填 PRODUCT.md，尤其是 users、mode 和 anti-references 三栏。这是整套流程中投入产出比最高的一步，十分钟的投入会在之后每一次命令调用里复利。

第 2 步：固化既有视觉系统

/impeccable document      # 生成 DESIGN.md
/impeccable extract       # 抽取零散样式为 token

第 3 步：单维度迭代，而不是许愿

/impeccable typeset the docs layout        # 只动排版
/impeccable distill the settings page      # 只做减法
/impeccable quieter the dashboard header   # 只降表达强度

每次只动一个维度，改完看一眼，不满意就反向调（bolder ↔ quieter）。这比一次性「重做这个页面」收敛得快得多，也更容易定位是哪一步坏了事。

第 4 步：交付前收口

/impeccable polish the pricing page
/impeccable audit src/components/
/impeccable critique      # LLM 评审，抓确定性规则抓不到的

第 5 步：把门禁装进 CI

npx impeccable detect src/ --format json

退出码接进 PR 检查。团队协作时这一步是分水岭：没有门禁的规范只是建议，有门禁的规范才是标准。

---

十、这套结构的通用性：不止于设计

跳出前端看，Impeccable 其实示范了一个模板------如何把一个「主观的、依赖专家品味的」任务，交给概率模型稳定完成。四层结构可以原样搬到别的领域：

层	作用	在设计中的形态	迁移到别处
词汇层	把模糊意图拆成正交、可命名的干预	23 个命令	法务：/tighten-liability、/plain-language；文案：/de-hype、/tighten
上下文层	一次说清语境，每次执行前载入	PRODUCT.md • DESIGN.md	领域词表、写作风格指南、合规基线、架构约定
约束层	把专家判断降级成确定性规则 + 门禁	59 条检测规则 + hook + CI	术语一致性检查、依赖白名单、API 设计 lint、SQL 反模式扫描
探索层	用结构化随机对抗模式坍缩	worlds 牌库 + 掷骰	方案模板库、对立观点注入、多风格候选池

有几条经验值得单独记下来：

1）负向约束比正向描述更可靠。 「不要 X」是可判定的，「要高级感」不是。Anti-references 这一栏的信息密度远高于任何形容词堆砌。

2）能确定性判定的，绝不交给模型判定。 紫色渐变用正则就能查，何必花一次 LLM 调用；反过来，「这个页面的气质是否统一」没法用规则判，那就老老实实交给 critique。混合架构的分工，应该按「可判定性」而不是按「难度」来切。

3）把连续空间离散化。 两档圆角、六级字阶、模块化比例------离散选择让模型的输出方差骤降。这个技巧在参数生成类任务里普遍有效。

4）反馈闭环要短到不需要人。 hook 在编辑落地后立刻回传结构化 findings，agent 自己改。人只在最后看结果。每引入一次人类等待，迭代速度就掉一个数量级。

5）产物要可携带。 DESIGN.md 用开放格式，意味着换工具不重来。任何想活得久的 agent 工具，都应该把知识沉淀成中立格式的文件，而不是锁在自己的数据库里。

---

十一、边界与需要警惕的地方

客观地说几条限制。

其一，规则本身也是一种品味。 「禁止大于 8px 的圆角」「禁止渐变文字」是有立场的判断，不是自然律。某些品牌的视觉资产恰好建立在这些元素上（比如以渐变为核心识别的品牌）。豁免机制存在，但默认值会施加一种引力------大规模采用之后，是否会产生一种新的、更精致的同质化？ 这个问题现在还没有答案，值得观察。

其二，确定性检测器只能覆盖可静态判定的部分。 行长、对比度、圆角冲突能查；「这个页面讲的故事是否成立」「信息架构是否合理」查不了。检测器给的是质量下限，不是上限。把 0 findings 当成设计合格证，是误用。

其三，它替代不了设计判断，只是提高了默认值。 一个不知道自己要什么的人，用完这套工具会得到一个「更干净的平庸」。真正的增量来自你能否把产品判断写进 PRODUCT.md------工具放大信号，也放大噪声。

其四，生态还在快速变化。 命令集、规则条数、支持的 harness 在持续迭代（不同时间点的公开材料里，命令数从 17 到 20+ 再到 23，检测规则的口径也随版本调整）。具体数字以你安装的版本为准，不要照着任何一篇文章（包括这一篇）的数字去写死配置。

其五，它依赖 harness 的能力边界。 hook 和 subagent 不是每个工具都支持，不同构建之间的体验并不完全等价。选型时值得先确认你的主力 harness 拿到的是哪一档能力。

---

十二、结语：把品味变成基础设施

过去两年，AI 编码工具解决的是「写得出来」。功能实现的边际成本趋近于零之后，瓶颈立刻上移到了「做得好不好」。而「好」这件事，长期被认为是不可编码的------它属于品味、直觉、经验，属于那个说不清但一眼能认出的东西。

Impeccable 的价值在于，它拒绝接受这个前提。它把「好」拆开来看，发现里面有很大一块其实是可命名的干预、可声明的约束、可判定的规则、可策展的先验------这些统统能工程化。剩下那部分确实不可编码的，交回给人，但人现在有了精确表达它的语言。

对做 agent 工具的人来说，这里面有一条更普适的启示：当你希望模型在某个领域做得像专家，不要只想着换更强的模型或写更长的提示词。先去问：这个领域的专家在脑子里用的是什么词汇？他们判断好坏的依据里，哪些能变成规则？他们做决策时参考的先验，能不能变成一个可抽取的牌库？

把这些答案变成文件、命令和门禁，模型就会突然「变得专业」------而实际上变的不是模型，是你给它的那套坐标系。

---

参考与延伸

• 官网：impeccable.style ------ 命令参考、slop 目录、检测器实验室
• 源码：github.com/pbakaus/impeccable ------ 检测器规则、配置项、豁免机制
• DESIGN.md 开放格式与社区设计系统：designmd.ai
• Anthropic 关于 Agent Skills 与渐进式披露的工程说明：anthropic.com/engineering
• Claude Code 做出好看界面：Impeccable 4.0 与 Live、Worlds 工作流