Impeccable /impeccable distill 命令详解：把前端 UI 剥离到本质的六维系统化精简工作流

distill（萃取/蒸馏）是 Impeccable 设计技能中用于“做减法”的核心命令：它把一套设计剥离到本质，移除任何“不配占据位置”的元素——冗余控件、重复信息、装饰性噪音和无谓的表面复杂度。本文以 distill 参考文档 为主体，完整继承其“评估现状 → 规划精简 → 六维执行 → 验证 → 文档化”五步工作流，并结合仓库中的技能定义、命令元数据与配套命令说明，拆解每一步的判断标准与执行边界，帮助你在使用 AI 编码代理时可靠地驱动“简化 UI”这一类任务。

1. distill 在 Impeccable 命令体系中的定位

Impeccable 是一个面向 AI 编码代理的设计技能包，安装后所有能力通过单一入口 /impeccable <command> 暴露（见 README.md）。在 SKILL.md 的 Commands 表中，distill 被归类为 Refine（精炼） 类命令，与 polish、bolder、quieter、harden 等并列：

命令	类别	作用	参考文档
/impeccable distill [target]	Refine	Strip to essence, remove complexity（剥离到本质，移除复杂度）	reference/distill.md

同一张表中可以清楚看到它的“姊妹命令”与分工：bolder 负责放大平淡设计，quieter 负责压制过度刺激的设计，而 distill 负责移除复杂度——三者方向不同但互补。

命令的触发语义记录在 command-metadata.json 中：

"distill": {
  "description": "Strip designs to their essence by removing unnecessary complexity. Great design is simple, powerful, and clean. Use when the user asks to simplify, declutter, reduce noise, remove elements, or make a UI cleaner and more focused.",
  "argumentHint": "[target]"
}

从这份元数据可以确认两点实操事实：

• 触发条件：当用户说“简化、去杂乱、降噪、移除元素、让 UI 更干净更聚焦”时，代理应加载 distill 参考文档执行；
• 参数形态：[target] 为可选参数，用于把精简范围限定到具体区域，例如 /impeccable distill settings（对设置页做精简）、/impeccable distill the checkout form。

此外，distill 参考文档随仓库有三份发行路径，内容与同一源同步分发：.agent/skills/impeccable/reference/distill.md（Antigravity 等 harness 布局）、skill/reference/distill.md（构建源）和 plugin/skills/impeccable/reference/distill.md（插件包）。

2. 第一步：Assess Current State（评估现状）

文档开宗明义：“Strip a design to its essence. Remove anything that doesn't earn its place”（把设计剥离到本质，移除任何不配占据位置的东西）。但在动手之前，必须先分析“是什么让这套设计显得复杂或杂乱”。

2.1 识别复杂度的六大来源

复杂度来源	典型表现
元素过多（Too many elements）	互相竞争的按钮、冗余信息、视觉杂乱
过度变化（Excessive variation）	没有目的的颜色、字体、尺寸、样式堆叠
信息过载（Information overload）	所有东西一次性全部可见，没有渐进披露
视觉噪音（Visual noise）	不必要的边框、阴影、背景、装饰
层级混乱（Confusing hierarchy）	看不出什么最重要
功能蔓延（Feature creep）	选项、动作、前进路径过多

2.2 找到本质（Find the essence）

对照四个问题定位“真正必要”的部分：

• 用户的首要目标是什么？应该只有一个（There should be ONE）；
• 哪些是真正必要的，哪些只是 nice-to-have？
• 什么可以被移除、隐藏或合并？
• 交付 80% 价值的那 20% 是什么？

2.3 “不确定就问，不许猜”原则

文档明确约束：如果上述要点无法从代码库中推断清楚，不要猜测，直接问用户澄清无法推断的部分（原文：“If any of these are unclear from the codebase, do not guess. Ask the user directly to clarify what you cannot infer.”）。这一点与 SKILL.md 中“Refinement preserves”的总体精神一致——distill 属于精炼类任务，必须保留既有身份、行为与文案，不能借简化之名偷换设计。

2.4 核心哲学：简单 ≠ 删功能

文档用加粗的 CRITICAL 标注了整篇最重要的一句话：

Simplicity is not about removing features. It's about removing obstacles between users and their goals. Every element should justify its existence. （简单不是移除功能，而是移除用户与其目标之间的障碍。每个元素都必须为自身的存在辩护。）

这是使用 distill 时防止“删过头”的第一道思想护栏。

3. 第二步：Plan Simplification（规划精简）

评估完成后，文档要求制定一份**“冷酷的编辑策略”（ruthless editing strategy）**，围绕四个问题展开：

1. Core purpose（核心目的）：这个东西唯一要完成的一件事是什么？
2. Essential elements（必要元素）：达成该目的真正必要的是什么？
3. Progressive disclosure（渐进披露）：什么可以等到需要时再显示？
4. Consolidation opportunities（合并机会）：什么可以合并或整合？

文档同时给出了执行心态上的 IMPORTANT 提示：

Simplification is hard. It requires saying no to good ideas to make room for great execution. Be ruthless. （简化很难。它要求你对好主意说不，为卓越的执行腾出空间。要冷酷。）

也就是说，规划阶段的产出应是一份明确的“删什么、藏什么、并什么”清单，而不是模糊的“让它更简洁”。

4. 第三步：Simplify the Design（执行六维精简）

这是原文档的主体：沿六个维度系统化地移除复杂度。以下完整继承各维度清单，并结合仓库佐证标注关键约束。

4.1 信息架构（Information Architecture）

• 收缩范围（Reduce scope）：移除次要动作、可选功能、冗余信息；
• 渐进披露（Progressive disclosure）：把复杂度藏到清晰的入口之后（折叠面板、模态框、分步流程）;
• 合并相关动作（Combine related actions）：合并相似按钮、整合表单、归组相关内容；
• 清晰层级（Clear hierarchy）：ONE 个主操作，少量次操作，其余全部降为三级或隐藏；
• 去冗余（Remove redundancy）：别处说过的话，这里不要再说一遍。

4.2 视觉简化（Visual Simplification）

• 收敛色板：1–2 个颜色加中性色，而不是 5–7 个颜色；
• 限制排版：一个字体家族，最多 3–4 个字号，2–3 个字重；
• 移除装饰：删掉不服务于层级或功能的边框、阴影、背景；
• 压平结构（Flatten structure）：减少嵌套、移除不必要的容器；卡片里绝不再套卡片（never nest cards inside cards）；
• 移除不必要的卡片：基础布局不需要卡片，用间距和对齐代替；
• 统一间距：只用一套间距刻度（spacing scale），消除随手拍的间距值。

其中“卡片嵌套”一条与 Impeccable 的整体反模式立场完全一致：README.md 在 Anti-Patterns 一节明确列出“不要把所有东西都包进卡片，不要在卡片里套卡片”；而且该仓库带有 61 条确定性检测规则（见 README 与 npx impeccable detect 说明），部分规则会直接标记 AI 生成前端中常见的嵌套卡片、侧边条边框等“AI slop”构造。因此 distill 的视觉简化清单与检测器规则在语义上是互相咬合的——精简之后，检测器报告的命中点理应减少。

4.3 布局简化（Layout Simplification）

• 线性流（Linear flow）：可能时用简单纵向流替代复杂网格；
• 移除侧边栏（Remove sidebars）：次级内容内联或隐藏；
• 全宽使用（Full-width）：大方地使用可用空间，而不是复杂的多栏布局；
• 对齐一致性（Consistent alignment）：左对齐或居中，选定一个就坚持；
• 慷慨留白（Generous white space）：让内容呼吸，不要把所有东西挤在一起。

4.4 交互简化（Interaction Simplification）

• 减少选择（Reduce choices）：更少的按钮、更少的选项、更清晰的前进路径（文档特别强调：选择的悖论是真实存在的）；
• 智能默认（Smart defaults）：把常见选择自动化，必要时才询问；
• 内联操作（Inline actions）：尽可能用内联编辑替代模态框流程；
• 移除步骤（Remove steps）：这个流程能不能少一步？
• 清晰的下一步（Clear next action）：只有一个明显的下一步动作，而不是五个互相竞争。

4.5 内容简化（Content Simplification）

• 更短的文案（Shorter copy）：把每句话砍一半，然后再砍一半；
• 主动语态（Active voice）：用“Save changes”而不是“Changes will be saved”；
• 去行话（Remove jargon）：朴素语言永远胜出；
• 可扫读结构（Scannable structure）：短段落、项目符号、清晰的标题；
• 只保留必要信息（Essential information only）：移除营销腔、法务腔、模糊措辞（hedging）；
• 去重复文案（Remove redundant copy）：不要有复述引言的标题、不要重复的解释，一次说清楚（say it once）。

4.6 代码简化（Code Simplification）

简化不止发生在画面上，文档要求同步下探到实现层：

• 移除无用代码：死 CSS、未使用的组件、孤儿文件；
• 压平组件树（Flatten component trees）：降低嵌套深度；
• 整合样式（Consolidate styles）：合并相似样式，一致地使用工具类；
• 减少变体（Reduce variants）：那个组件真的需要 12 种变体吗？3 种能不能覆盖 90% 的场景？

这一维度与仓库中的 extract 命令（“Pull reusable tokens and components into design system”，见 command-metadata.json）形成配合：distill 负责删冗余变体，extract 负责把幸存的重复模式收敛为设计系统资产。

5. 六条红线：简化时 NEVER 做的事

distill.md 用 NEVER 清单划定了简化的边界，这六条是执行时最容易踩的坑：

1. 不删必要功能——简单不等于功能缺失（simplicity ≠ feature-less）；
2. 不为简单牺牲可访问性——清晰标签与 ARIA 依然必需；
3. 不要简单到令人困惑——神秘感 ≠ 极简主义（mystery ≠ minimalism）；
4. 不移除用户做决策所需的信息；
5. 不彻底消灭层级——有些东西就应该更突出；
6. 不盲目简化复杂领域——复杂度要与真实任务复杂度匹配（match complexity to actual task complexity）。

这六条与第 2.4 节的 CRITICAL 原则构成同一护栏的两端：既不许“不减”，也不许“减穿”。

6. 第四步：Verify Simplification（验证简化是否有效）

执行完后，文档给出五个验证问题，用于确认简化确实提升了可用性而不是只是看起来更“空”：

• 更快的任务完成：用户能否更快达成目标？
• 更低的认知负荷：是否更容易看懂该做什么？
• 仍然完整：所有必要功能是否仍可访问？
• 更清晰的层级：是否一眼看得出什么最重要？
• 更好的性能：更简单的设计是否加载更快？

从仓库结构看，这套验证可以借助 Impeccable 的确定性检测器补强：npx impeccable detect 可以在没有 LLM、没有 API key 的情况下扫描目录/文件/URL，输出含 61 条规则的命中结果（支持 --json 供 CI 使用，见 README.md 的 CLI 一节）。distill 完成后重跑 detect，命中数下降可以作为“视觉噪音与反模式减少”的客观佐证——但正如 polish 参考文档 强调的“detector result is defect evidence, not proof of quality”，检测器通过不等于设计变好，人工走查交互路径仍是必要环节。

7. 第五步：Document Removed Complexity（记录被移除的复杂度）

如果精简过程中移除了功能或选项，文档要求做三件收尾工作：

• 记录为什么移除它们；
• 评估它们是否需要替代入口；
• 标记需要持续观察的用户反馈点。

这一步把“删减决策”从一次性动作变成了可追溯的产品记录，避免下个迭代（或下一位工程师/代理）把被有意移除的功能当缺陷加回来。

8. 收尾衔接：从 distill 交给 polish

distill.md 的最后一句定义了命令的交接语义：

When the cuts feel right, hand off to /impeccable polish for the final pass. As Antoine de Saint-Exupéry put it: “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.”

即：当删减到位时，把最终打磨交给 /impeccable polish。这与仓库中 polish 命令的自我定位严丝合缝——polish.md 开篇即声明“Polish is refinement, never concealed redesign”（打磨是精炼，绝不是暗藏的重设计）：distill 负责结构性做减法，polish 负责在既定方向上做对齐、间距、一致性与细节收口，两者职责不重叠。

从工作流视角看，distill 处于 Impeccable 的“评估→精炼”链条中：无参数调用 /impeccable 时，代理会按 routing.md 的上下文感知逻辑推荐命令；当信号显示某区域元素堆叠、反模式命中较多时，distill、quieter、typeset 等命令就是典型候选。而“先删后润”的顺序（distill → polish）也是文档明确推荐的路径。

9. 实操：如何调用与验证

结合 README.md 的安装与使用说明，完整实操路径如下（适用前提：已在支持的 AI 编码工具中安装 Impeccable 技能）：

1. 安装技能（项目根目录执行一次）：

   npx impeccable install
   

   安装后按需重载 harness；更新用 npx impeccable update。

2. 执行 distill，可带目标限定范围：

   /impeccable distill                # 对当前默认目标整体精简
   /impeccable distill settings       # 只精简设置页
   

3. 固定快捷键（可选）：高频使用时用 /impeccable pin distill 生成独立 /distill 快捷命令（SKILL.md 中 Pin/Unpin 机制）。

4. 客观复核（可选）：精简前后各跑一次确定性检测器对比命中：

   npx impeccable detect src/            # 扫描目录
   npx impeccable detect --json .        # CI 友好的 JSON 输出
   

   检测默认遵循 .impeccable/config.json / config.local.json 中的 detector.ignoreRules、ignoreFiles、ignoreValues 等配置；单文件豁免可用行内标记 <!-- impeccable-disable <rule>: <reason> -->。

5. 收尾交接：删减到位后执行 /impeccable polish <target> 做最终通过。

10. 小结

distill 参考文档虽然不长，但它把“简化”从一种审美偏好变成了可执行、可验证、有边界的工程流程：

• 评估先于动作：六大复杂度来源 + 本质四问，且“不确定就问”；
• 规划要求冷酷：核心目的唯一、必要元素明确、渐进披露与合并机会成清单；
• 执行沿信息架构、视觉、布局、交互、内容、代码六个维度展开，每一维都有可核对的条目；
• 红线明确：六条 NEVER 防止简化走向功能缺失或可访问性倒退；
• 验证与记录闭环：五个验证问题确认改善真实发生，被移除的复杂度必须留痕；
• 交接清晰：删减到位即交给 polish 做最终收口。

对照仓库中的命令表、元数据与相邻命令（bolder / quieter / extract / polish）可以确认：distill 是 Impeccable 设计词汇表中负责“减法”的单一入口，其文档与确定性检测器规则、精炼类工作流在语义上一致，适合在“UI 越做越挤、信息越堆越多”的阶段作为第一个介入的命令。