Impeccable `distill` 命令全解析：用「剥到本质」方法论系统性移除界面复杂性

导读

/impeccable distill [target] 是 Impeccable 设计技能中专门负责减法的 Refine 类命令——当界面塞满了多余元素、装饰噪音、重复信息与碎片化选项时，它指导 AI 把设计剥离到只剩本质。本文以 .cursor/skills/impeccable/reference/distill.md 为骨架，结合本仓库中命令元数据、SKILL 编排与其他参考文档，完整还原"评估现状 → 制定精简策略 → 六维精简 → 验证 → 记录 → 交接 polish"的操作链路，让你能把一条命令背后的完整思维模型应用到任何待精简的界面上。

核心立场先立于此：简化不是移除功能，而是移除用户与目标之间的障碍——这是理解本文全部操作步骤的前提。正如文档引用的圣埃克苏佩里之言："完美不是无可增添，而是无可删减。"

---

一、distill 在 Impeccable 中的定位：Refine 类命令与命令体系

distill 是 Impeccable 提供的一组共享设计词汇之一。在 .cursor/skills/impeccable/SKILL.md 的 Commands 表中，它被归类为 Refine（精修）类别，描述为"Strip to essence, remove complexity"（剥到本质，移除复杂性），与同属 Refine 的 polish（发货前的最后质检）、bolder（放大平庸设计）、quieter（压制过度刺激）、harden（补足错误态与边界）、onboard（首次引导）并列。

机器可读的元数据定义在 .cursor/skills/impeccable/scripts/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]"
}

关键词法很关键：当用户提出 simplify / declutter / reduce noise / remove elements / make cleaner and more focused 等诉求时，元数据就把它路由到本命令。触发形态为 /impeccable distill [target]，其中 [target] 通常是具体的源文件或路由。在 README.md 的命令清单中，它的用户可见描述同样是"Remove complexity"（第 312 行给出了 /impeccable distill # Remove complexity 的用法示例）。

要避免把 distill 与相邻命令混为一谈：

• distill 与 bolder / quieter 的镜像关系：bolder 负责给安全、平淡的设计加码（放大尺度/饱和度/结构性变化），quieter 负责把色彩、装饰、留白拉回来；而 distill 只专注于"移除一类多余之物"，在 live.md 的视觉变体模式（variant mode）中，它被要求每个变体剥离不同类别的冗余——视觉噪音 / 冗余内容 / 嵌套结构，三选一作为该变体的主轴。
• distill 与 polish 的分工：polish 是"精修而不改设计"的最后一道工序，负责系统一致性、缺陷修复与收尾；而 distill 的目标是改变结构本身。二者的交接点是文档明示的收尾动作：当删减到位后，交给 /impeccable polish 做最终检查（详见第八节）。

---

二、心法：找出那个"本质"，而不是随手删东西

整个 distill 流程建立在一条反直觉的判断上：代码里看到的一切"复杂"未必都需要删，真正要回答的是——这个界面本来要完成哪一件事？文档将这一步称为"Find the essence"，并给出五个递进问题：

1. 用户的首要目标是什么？（应当只有一个）
2. 哪些是真正必要的，哪些只是"有也不错"？
3. 哪些可以移除、隐藏或合并？
4. 是哪 20% 贡献了 80% 的价值？
5. 如果从代码库中无法推断出这些答案——不要猜，直接向用户提问澄清无法推断的部分。

之所以强制"不猜测、去提问"，是因为 distill 属于有损操作：删错了比不改更糟。这一点在 .cursor/skills/impeccable/reference/craft-floor.md（编辑任何 UI 前必读的质量底线文档）中会被反复强化——质量底线要求 AI 以"生产级代码 + 清晰立场 + 对用户需求的深刻理解"为前提作业，而其中"尊重用户提供的既有事实性文案"的约束，正与 distill"删除前必须确认信息是否承载决策价值"相呼应。

判断金句（文档原文）：Simplicity is not about removing features. It's about removing obstacles between users and their goals. Every element should justify its existence.——每一个元素都必须为自己的存在辩护。

---

三、第一步：评估现状（Assess Current State）

动手前先做一次冷静的"复杂源"体检，文档给出两条分析线。

识别复杂性来源（六类典型病灶）

病灶	典型表现
元素过多	互相竞争的按钮、冗余信息、视觉杂乱
变异过度	无目的的多种颜色、字体、字号、风格并存
信息过载	所有内容同时暴露，没有渐进式披露（progressive disclosure）
视觉噪音	无功能价值的边框、阴影、背景、装饰
层级混乱	看不出什么最重要
功能蔓延	选项、动作、前进路径太多

找出本质（上文五问）

把"用户首要目标只有一个"当作评估标尺，对每个现有元素问：它是服务于那个唯一目标的必要构件，还是 nice-to-have？评估时如果不能从代码库推断（例如无法判断某段重复文案是否承担决策信息），就必须回到提问环节。

提示：这一步的"视觉噪音/层级混乱"判定，与同一参考目录下 layout.md 中"眯眼测试（squint test）"的思想一致——把细节模糊后，是否仍能按顺序辨认主元素、次元素与主要分组？distill 聚焦"删什么"，layout 聚焦"怎么摆"，两者在界面结构上互补。

---

四、第二步：制定精简策略（Plan Simplification）

评估之后，文档要求制定一份"不留情面的编辑策略"（ruthless editing strategy），四个锚点：

• 核心目的（Core purpose）：这个东西应当完成的"那一件事"是什么？
• 必要元素（Essential elements）：要达成目的，真正必需的是什么？
• 渐进式披露（Progressive disclosure）：什么可以藏起来，直到用户需要时再出现？
• 合并机会（Consolidation opportunities）：什么可以整合或融合成一个？

文档特别提醒：简化是难的，它要求你对"好主意"说不，为"出色的执行"腾出空间。要无情（Be ruthless）。 这里的"无情"始终受第五节边界清单约束——它只对"好的但多余的"下手，绝不动"必要的"。

---

五、第三步：六个维度的系统性精简

这是整个流程的实操主体。文档把"删什么"拆成六个互不重叠的维度，逐一清扫，避免只处理看得见的视觉层而放任结构与代码层的复杂度。

1. 信息架构（Information Architecture）

• 收窄范围：移除次级动作、可选功能、冗余信息；
• 渐进式披露：把复杂性藏到清晰的入口后面——手风琴、弹窗、分步流程（step-through flows）；
• 合并相近动作：合并相似的按钮、整合表单、按语义分组相关内容；
• 建立清晰层级：一个主动作、少量次动作，其余全部降为第三级或隐藏；
• 删除冗余：别处已经说过的，此处不要重复。

2. 视觉简化（Visual Simplification）

• 收缩色板：使用 1–2 个强调色 + 中性色，而不是 5–7 种颜色；
• 限制字体系统：一种字体家族、最多 3–4 个字号、2–3 个字重；
• 移除装饰：删掉不服务于层级或功能的边框、阴影、背景；
• 压平结构：减少嵌套、移除多余容器；绝不在卡片里再套卡片；
• 移除不必要的卡片：基础布局不需要卡片，用间距与对齐来表达分组；
• 统一间距：使用一套间距刻度，清掉随手写的零散间距。

3. 布局简化（Layout Simplification）

• 线性流动：能用一个简单的纵向流，就不要用复杂栅格；
• 移除侧栏：把次级内容移到正文内或直接隐藏；
• 充分利用全宽：大方使用可用空间，而不是叠多层栏；
• 坚持一种对齐：选左对齐或居中，并贯彻到底；
• 慷慨的留白：让内容呼吸，不要塞得过紧。

4. 交互简化（Interaction Simplification）

• 减少选择：更少的按钮、更少的选项、更清晰的前进路径——"选择悖论（paradox of choice）"真实存在；
• 智能默认值：把常见选择自动化，只在必要时询问；
• 内联动作：能用内联编辑就不要开模态弹窗；
• 删步骤：这个流程能不能少一步？
• 明确的下一步：一个显而易见的下一步，而不是五个互相竞争的。

5. 内容简化（Content Simplification）

• 更短的文案：把每个句子砍半，然后再砍一次；
• 主动语态：写 "Save changes"，而不是 "Changes will be saved"；
• 去行话：平实语言永远赢；
• 可扫读结构：短段落、要点列表、清晰标题；
• 只留必要信息：删掉营销浮词、法务腔、含糊其辞；
• 删重复文案：标题不重复引言、不重复解释同一件事——说一次就好。

6. 代码简化（Code Simplification）

• 删死代码：死 CSS、未使用的组件、孤儿文件；
• 压平组件树：降低嵌套深度；
• 合并样式：合并相近样式，一致地使用工具类（utilities）；
• 削减变体：那个组件真的需要 12 种变体吗？还是 3 种就能覆盖 90% 的场景？

维度 6 是本文档区别于纯视觉清单的独特之处：distill 同时把"代码层的复杂度"视作设计复杂度的一部分——死代码与过多组件变体最终都会表现为维护成本与渲染噪音，删它们与删一条边框同属"剥离到本质"。这与参考目录其他 Refine 命令（如 polish.md 中"移除调试输出、死代码、未用导入、废弃样式"的要求）相互印证。

---

六、红线：distill 的 NEVER 清单

文档为"无情"划出了硬边界，以下行为一律禁止：

• 移除必要功能（简化 ≠ 无功能）；
• 为追求简洁牺牲可访问性（清晰的标签与 ARIA 仍然必需）；
• 把事情简化到含混不清（神秘感 ≠ 极简）；
• 移除用户做决策所需的信息；
• 完全消灭层级（有些东西就该突出）；
• 过度简化复杂领域（复杂度要与任务本身的复杂度匹配）。

这六条红线与 .cursor/skills/impeccable/reference/craft-floor.md 中的"绝对禁令（absolute bans）"共同构成不可逾越的质量下限：distill 可以在结构、文案、视觉与代码上做减法，但可访问性、信息完整性与真实的任务复杂度不允许被"为了好看"而牺牲。

---

七、第四步：验证简化真的改善了可用性（Verify Simplification）

删减结束后，文档要求用以下五项标准自查，确认减法换来的是加法：

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

注意验证对象不是"界面是否变空"，而是"用户的可用性是否提升"。这与 layout.md"每个验证项都要以渲染或源码证据作答，不允许用一句干巴巴的 yes 代替"的纪律一致——distill 的验证同样应当落到具体证据上（如完成路径步数、剩余元素对照、加载体积变化）。

---

八、记录被移除的复杂性，并把收尾交给 polish

文档要求：只要删除了功能或选项，就必须留下可追溯的记录：

• 说明这些功能为什么被移除；
• 评估它们是否需要替代的访问入口；
• 记录值得持续监测的用户反馈（例如某处删除后用户反复问"原来那个按钮去哪了"，就是需要恢复或加替代入口的信号）。

这一"记录而非静默删除"的要求，与 Impeccable 的 .cursor/agents/impeccable-finish-reviewer.md（finish-reviewer 评审代理）等 agent 角色关注的"功能完整性、事实性文案、决策信息不缺失"一脉相承——被 distill 的每一项都有据可查，才能让后续 review 判定"删除是否越界"。

流程的最后一步是明确交接：

当删减效果满意后，交给 /impeccable polish 做最终一道质检。

这是 Refine 命令族的标准收尾协议：distill 负责把结构改到"只剩本质"，polish 负责在既有视觉世界里把细节、一致性与状态完备度打磨到可发货（参见 polish.md 的缺陷分级与验证流程）。两者一个做结构减法、一个做质量加法，顺序不可颠倒。

---

九、代码库证据：一份指南、多份载体，跨平台分发

值得一提的实现细节是：这份 distill 参考文档在仓库中并非孤立存在，而是同一份内容以多种载体分发，服务于不同 AI 编码工具链：

• .cursor/skills/impeccable/reference/distill.md（Cursor 等工具的技能目录）
• skill/reference/distill.md（仓库主技能源，含模板占位符，供打包生成各平台版本）
• plugin/skills/impeccable/reference/distill.md（插件形态的发布版）

对比可见，三份文件正文完全一致，仅有两处模板占位差异："无法从代码库推断时"一句中的提问方式（.cursor 版写为 "Ask the user directly"，skill 源版与 plugin 版分别替换为 {{ask_instruction}} 模板与显式的 AskUserQuestion 工具指令），以及收尾交接处的命令前缀（{{command_prefix}}impeccable polish）。这说明 distill 的决策逻辑与质量要求与运行环境无关，只是"如何向用户提问/如何渲染命令"随宿主平台不同而被参数化。

从调用链看：用户输入 /impeccable distill [target] → 路由逻辑依据 routing.md 与命令元数据加载本文档 → 参照 SKILL.md 的 Setup 步骤（先跑 context.mjs 读取 PRODUCT.md / DESIGN.md 与 surface brief）与 craft-floor 质量底线 → 在 live.md 的变体模式中则作为"剥离不同类别冗余"的变体主轴被引用。若希望为 distill 创建独立快捷命令，可用 SKILL.md 中说明的 pin 脚本：

node .cursor/skills/impeccable/scripts/pin.mjs pin distill

---

十、把 distill 用好的三条实战建议

基于整份文档的思维闭环，可以总结出把这条命令用得准的三个要点：

1. 先问"哪一个目标"再问"删哪些"。本质未明之前的删减只是碰运气；当界面承载多个目标时，先与用户确认唯一主目标，再按第五节清单逐维执行。
2. 把六个维度当扫描清单，而不是灵感。信息架构、视觉、布局、交互、内容、代码逐项过一遍，能有效防止"只删了看得见的边框，却留下看不见的组件变体与死代码"。
3. 永远以"验证 + 记录 + 交接"收尾。删到满意不是终点——用第七节五项标准自证可用性、为每项移除留档，然后交棒给 /impeccable polish，才构成完整的 Refine 工作流。

当你把这份方法论当作"如何对界面做减法"的标准作业程序，distill 就不再只是一条命令，而是一套可以被任何前端界面复用的简化决策框架：剥到本质，然后为每个留下的元素负责。