用 Impeccable `distill` 把界面"剥到本质"：面向 Agent 的复杂度削减与简化工作流

把设计"剥到本质"（strip a design to its essence），删掉所有不配占据位置的东西：冗余元素、重复信息、装饰噪音与表面化复杂度——这是 Impeccable 设计语言中 distill 命令的核心使命。它属于整个命令体系中的 Refine（精修） 类别，与 bolder（放大平淡设计）、quieter（压制过激设计）、polish（交付前终检）并列，专用于"让复杂、臃肿、堆砌的界面变简洁、清晰、聚焦"。读完本文，你将掌握一套可供 AI Agent 直接执行的五步简化流程——评估现状、制定策略、六维度系统性减法、验证、留档，并理解 distill 如何与 Impeccable 其他 Refine 命令协同，在削减复杂度的同时绝不误伤必要功能与可访问性。

distill 在 Impeccable 命令体系中的定位

Impeccable 是一个"让 AI 在设计中做得更好"的设计语言与技能包：通过结构化 playbook 把资深设计总监的判断力交给 Agent。.claude/skills/impeccable/SKILL.md 的命令总表将每个子命令分成 Build（构建）、Evaluate（评估）、Refine（精修）、Enhance（增强）、Fix（修复）与 Iterate（迭代）几类，其中 Refine 一族如下：

命令	类别	作用	参考文档
polish [target]	Refine	交付前的最终质量扫描	reference/polish.md
bolder [target]	Refine	放大平庸、平淡的设计	reference/bolder.md
quieter [target]	Refine	调低过度激进、过度刺激的设计	reference/quieter.md
distill [target]	Refine	剥到本质，移除复杂度	reference/distill.md
harden [target]	Refine	生产就绪：错误态、i18n、边界情况	reference/harden.md
onboard [target]	Refine	设计首访流程、空状态、激活路径	reference/onboard.md

从命令触发看，各 Agent 运行时（Claude Code、Cursor、Gemini、Trae 等）会加载自己目录下的这份参考，本仓库 .claude/、.agent/、.cursor/、.gemini/、plugin/、skill/ 等处的 reference/distill.md 是同一份文档的镜像分发；scripts/lib/skill-categories.js 内部把 distill 归类为 simplify，plugin/skills/impeccable/scripts/command-metadata.json 则记录了它的触发语义：

"Strip designs to their essence by removing unnecessary complexity… Use when the user asks to simplify, declutter, reduce noise, remove elements, or make a UI cleaner and more focused."，参数形态为 [target]。

也就是说，当用户提出"帮我简化""太乱了，去噪""把界面做得更干净、更聚焦"，Agent 即可加载本参考并按下面的五步流程执行；[target] 指向被简化的具体文件或路由。

第一步：评估现状——先弄清设计为何显得复杂

动手删除任何元素之前，必须先做诊断。distill.md 要求 Agent 分析"什么让这个设计显得复杂或杂乱"，并按两类问题逐项过一遍：

1. 定位复杂度来源（Identify complexity sources）

• 元素过多（Too many elements）：互相竞争的按钮、重复的信息、视觉杂乱；
• 过度变化（Excessive variation）：没有目的的颜色、字体、字号、样式堆了一大堆；
• 信息过载（Information overload）：所有内容同时可见，缺少渐进式披露（progressive disclosure）；
• 视觉噪音（Visual noise）：不服务于层级与功能的边框、阴影、背景、装饰；
• 层级混乱（Confusing hierarchy）：看不出什么最重要；
• 功能蔓延（Feature creep）：可选项、操作、前进路径过多。

值得注意的是，仓库的测试夹具 tests/fixtures/antipatterns/ 中保存了大量与这六类问题一一对应的"应被标记"样例，例如 repeated-container-text.html（容器内重复文本）、clipped-overflow-container.html（容器裁剪溢出）、edge-flush-cards.html / flush-against-border.html（卡片贴边）、buried-raster.html（位图沉底）以及 legitimate-borders.html、modern-color-borders.html（边框的合法与滥用之别），是理解"装饰噪音 vs 功能性边框"的现成正反例。distill 的减法方向与这些反模式检测同源：能删的装饰要删，但承担层级或功能的边框要留。

2. 找出本质（Find the essence）

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

如果上述答案无法从代码库中确认，不要猜测——文档明确要求 STOP，先调用 AskUserQuestion 工具向用户澄清，而不是自作主张删掉用户真正依赖的能力。

关键红线：简单不是"去掉功能"，而是"移除用户与目标之间的障碍"。每个元素都必须为自己的存在辩护（Every element should justify its existence）。

第二步：制定无情的编辑策略

诊断之后，写出一份"残忍的编辑策略"（ruthless editing strategy），把简化决策显式化：

• 核心目的（Core purpose）：这东西唯一该做成的事是什么？
• 必要元素（Essential elements）：达成该目的真正不可或缺的是什么？
• 渐进式披露（Progressive disclosure）：哪些可以藏到用户需要时才出现？
• 合并机会（Consolidation opportunities）：哪些可以合并或整合？

这一步是态度层面的校准：distill.md 反复强调"简化很难，它要求你对好主意说不，好让伟大的执行有空间"，因此策略要"Be ruthless"——但不是乱砍。结合 SKILL.md 中 Refine 族的总体纪律："Refinement preserves; redesign replaces"，distill 属于保留式精修：保留既有身份、行为、文案与范围外的一切；若概念本身错了，应指出并推荐 bolder 或重设计，而不是借"简化"之名偷换设计世界。

第三步：沿六个维度系统性移除复杂度

简化不是碰运气式的删减，而是沿六个维度逐项过筛。下面每个维度都是可落地的检查清单。

信息架构（Information Architecture）

• 收窄范围：删掉次要操作、可选功能、冗余信息；
• 渐进式披露：把复杂度藏到清晰的入口后面——折叠面板（accordion）、模态框、分步流程；
• 合并相关动作：合并相似按钮、整合表单、把相关内容归组；
• 建立清晰层级：一个主操作、少数次操作、其余全部降级为三级或隐藏；
• 消除冗余：别处说过的，这里就不要再重复。

视觉简化（Visual Simplification）

• 收敛色板：用 1–2 个主色加中性色，而不是 5–7 个色相；同类约束可参考 Impeccable 对色彩纪律的更细指引 reference/colorize.md；
• 限制字体：一个字体族，最多 3–4 个字号、2–3 个字重（字号与层级细节见 reference/typeset.md）；
• 删除装饰：去掉不为层级或功能服务的边框、阴影、背景；这也是 audit/反模式检测对"无意义装饰"的常见判定方向；
• 扁平化结构：减少嵌套、去掉多余容器，绝不在卡片里再套卡片；
• 去掉非必要卡片：基础排版并不需要卡片，用间距与对齐代替；对应地，edge-flush-cards、flush-against-border 这类夹具正是"卡片滥用"的证据样本；
• 统一间距：使用同一套间距刻度，消除任意间隙（节奏系统详见 reference/layout.md）。

布局简化（Layout Simplification）

• 线性流：能用简单纵向流，就不用复杂栅格；
• 移除侧栏：次要内容内联展示或隐藏起来；
• 全宽使用：大方利用可用空间，替代复杂的多栏布局；
• 统一对齐：选择左对齐或居中，坚持到底；
• 慷慨留白：让内容"呼吸"，别把所有东西塞得满满当当。

交互简化（Interaction Simplification）

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

内容简化（Content Simplification）

• 更短文案：把每个句子砍半，然后再砍一次；
• 主动语态：写 "Save changes"，而不是 "Changes will be saved"；
• 去掉行话：平实语言永远胜出；
• 可扫读结构：短段落、要点列表、清晰的标题；
• 只留必要信息：删掉营销吹嘘、法律套话、模棱两可的限定词；
• 去掉重复文案：不要让标题复述引言，不要重复解释，同一件事只说一次。

文案方向的专项细化可参见 Fix 类的 reference/clarify.md（UX 文案、标签与错误信息），它与内容简化互为补充。

代码简化（Code Simplification）

• 删除未使用代码：死 CSS、未用组件、孤儿文件；
• 扁平化组件树：降低嵌套深度；
• 合并样式：合并相似样式，统一使用工具类；
• 削减变体：那个组件真的需要 12 种变体吗？也许 3 种就能覆盖 90% 的场景。

// 代码简化自检示例
<Layout>
  <Container>            // 可移除的冗余包装层
    <Card>               // 容器套容器，可扁平化
      <CardBody>
        <InnerWrapper>…</InnerWrapper>
      </CardBody>
    </Card>
  </Container>
</Layout>
→ 目标：能减少一层是一层，能去掉的包装 div 一律去掉

第四步：明确"绝不允许"清单

简化有边界。distill.md 专门列出 NEVER 清单，约束减法不能变成伤害：

• 绝不可删除必要功能——简单 ≠ 无功能（simplicity ≠ feature-less）；
• 绝不可为简化牺牲可访问性——清晰标签与 ARIA 仍然必需（技术性可访问性检查见 reference/audit.md）；
• 绝不可简单到令人费解——神秘感 ≠ 极简（mystery ≠ minimalism）；
• 绝不可移除用户做决策所需的信息；
• 绝不可把层级彻底抹平——有些东西本就该突出；
• 绝不可过度简化复杂领域——让复杂度匹配实际任务的复杂度。

第五步：验证简化确实改善了可用性

删减完成后不能直接宣布胜利，要逐项核验简化的实际收益：

• 任务完成更快了吗（Faster task completion）：用户能否更快达成目标？
• 认知负荷降低了吗（Reduced cognitive load）：是否更容易看懂该做什么？
• 功能仍然完整吗（Still complete）：所有必要功能是否仍可触达？
• 层级更清晰了吗（Clearer hierarchy）：什么最重要是否一目了然？
• 性能更好了吗（Better performance）：更简单的设计是否加载更快？

第六步：为移除的复杂度留档

凡是删掉的功能或选项，都要留下可追溯的记录：

• 说明它们为什么被移除；
• 评估是否需要替代访问入口；
• 记录需要监控的用户反馈信号，以便后续回归验证。

这一步让"简化"从一次性的个人判断，变成可复查、可回滚、可迭代的项目决策。

与 Refine 生态衔接：蒸馏之后交给 polish

distill 并不是流程终点。distill.md 明确写道：当删减"感觉对了"的时候，把成果交接给 /impeccable polish 做最终一遍质量扫描。而 polish.md 也反过来定义了精修的纪律——"Polish 是精修，绝不是隐蔽的重设计"，它保留既有视觉世界、内容、行为与范围外的一切。二者一减一收，构成 Refine 族的完整闭环：先由 distill（或 bolder、quieter 等定向精修命令）修正方向与密度，再由 polish 做交付前终检；若发现概念本身错了，则直言并转向重设计，而不是把错误修修补补。

整份参考以一句安托万·德·圣-埃克苏佩里（Antoine de Saint-Exupéry）的话收尾，这句话也正是 distill 的美学信条：

"Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away."（完美并非无可增添，而是无可删减。）

对 Agent 而言，这意味着每一次简化都应止步于"删掉任何东西都会开始损失价值"的那个临界点——那正是界面被剥到本质的时刻。