impeccable distill：用「减法设计」把界面剥离到本质的完整方法论与实战流程

导读：本文围绕开源项目 impeccable（一套提升 AI 前端设计能力的 Skill 体系）中的 distill 参考文档（.opencode/skills/impeccable/reference/distill.md），系统讲解如何在界面过载、视觉杂乱、功能蔓延时执行一次严谨的「简化手术」。读完你将掌握：distill 在 impeccable 命令体系中的定位与触发时机、从「评估现状 → 规划减法 → 六维执行 → 验证结果 → 记录取舍」五阶段的可落地流程，以及简化时必须守住的功能完整性与可访问性底线。

distill 在 impeccable 中是什么：一句话定位与调用方式

impeccable 是一套以「让 AI 设计工具产出更出色设计」为目标的设计语言 / Skill 体系。其入口文件 .opencode/skills/impeccable/SKILL.md 维护了一张 Commands 表，把全部能力划分为 Build / Evaluate / Refine / Enhance / Fix / Iterate 六大类别，而 distill 正是 Refine（精修）类中的一个命令：

Command	Category	Description	Reference
distill [target]	Refine	Strip to essence, remove complexity	reference/distill.md

在 scripts/command-metadata.json 中，distill 的元数据给出了更精确的能力描述：

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.

也就是说，当用户表达的诉求落在这几类关键词上时，应路由到 distill：

• simplify（简化）、declutter（去杂乱）
• reduce noise（降低噪声）
• remove elements（移除元素）
• 想让界面 cleaner / more focused（更干净、更聚焦）

调用方式与其它命令一致，使用 [target] 指定作用范围，例如 /impeccable distill dashboard 或 /impeccable distill 作用于某条特定命令所在的源码目标。从 SKILL.md 的 argument-hint "[shape · ... · adapt|clarify|distill · ...]" 可以看到，它通常针对「既有界面上的收窄型改动」，而非从零构建新页面（新页面走 shape / new-work）。

值得强调的是 distill 与相邻命令的分工边界——同属 Refine 类别的是 polish.md（发布前的细节打磨）、bolder（放大视觉冲击）、quieter（给过度刺激的视觉降温）。四者的差异在于：quieter 调的是「强度」，distill 拆的是「结构」，polish 做的是「收尾的一致性」，bolder 走的是「反向增强」。因此 distilling 之后通常是 polish 登场（见文末交棒流程）。

一句话哲学：本质不是做减法本身，而是减去用户与目标之间的障碍

distill 文档用一句警告奠定了整个方法论的基调，这也是全文唯一一段以 CRITICAL 标注的规则：

CRITICAL: Simplicity is not about removing features. It's about removing obstacles between users and their goals. Every element should justify its existence.

翻译过来：简化不等于功能削减，而是移除用户与目标之间的障碍；界面上每一个元素都必须为自己的存在提供理由。 把这句话拆开理解：

1. 简化的检验标准是「用户达成目标是否更容易」，而不是「界面是否更空」；
2. 「元素必须自证存在」意味着默认立场是怀疑——任何说不清自己价值的按钮、文案、卡片、阴影都处在被移除的候选名单上；
3. 一旦目标偏移成「为了空而空」，就会掉进文末 NEVER 清单里「mystery ≠ minimalism」的陷阱。

阶段一：Assess Current State —— 先诊断，再动刀

distill 的第一阶段明确要求：先分析是什么让设计显得复杂或杂乱，然后找出本质。它把复杂度来源归纳为六类，这一分类本身就是一份可复用的「体检清单」：

1. Too many elements（元素过多）：互相竞争的按钮、重复的信息、视觉杂乱；
2. Excessive variation（过度差异）：大量没有目的的配色、字体、字号、样式并存；
3. Information overload（信息过载）：一切同时可见，缺少渐进式披露（progressive disclosure）；
4. Visual noise（视觉噪声）：无必要的边框、阴影、背景与装饰；
5. Confusing hierarchy（层级混乱）：看不清什么最重要；
6. Feature creep（功能蔓延）：选项、动作或前进路径过多。

找到「本质」的四连问

针对上述症状，需要回答四个问题来锚定「要保什么」：

• 用户的首要目标是什么？（应当只有一个：What's the primary user goal? (There should be ONE)）
• 什么是真正必要的，什么只是 nice-to-have（锦上添花）？
• 什么可以被移除、隐藏或合并？
• 哪个是带来 80% 价值的 20%（二八法则）？

不清楚就问，禁止瞎猜

文档对「猜测」给出了强约束：若以上任何一点无法从代码库中确认，不要猜测，停下来调用 question 工具向用户澄清（对应 distill.md 中 STOP and call the question tool to clarify 的指令）。这也与 impeccable「视觉权威来自证据而非文件名」的原则一致：简化动作建立在真实理解用户目标之上，而不是建立在臆测之上。

阶段二：Plan Simplification —— 制定不留情面的删减策略

诊断完成后的规划阶段，distill 文档要求产出四个明确的决策点，它们共同构成一次「削减的编辑策略」：

• Core purpose：这件事应该达成的「那一件事」是什么（ONE thing）？
• Essential elements：为达成该目的，真正必要的是哪些元素？
• Progressive disclosure：哪些内容可以「隐藏到需要时再出现」？
• Consolidation opportunities：哪些东西可以合并或集成？

同时，distill 给出了一个情绪化的执行建议：简化是困难的，它要求你为成就出色的执行而对「好点子」说不（It requires saying no to good ideas to make room for great execution）。这里的潜台词是：规划的产出物不是「温和的删减列表」，而是一份有胆量砍掉冗余、但保留核心价值的优先级清单。

阶段三：Simplify the Design —— 沿六个维度系统性移除复杂度

distill 把具体执行拆成六个维度，这是全文信息密度最高、最适合作为实际操作手册的部分。每个维度都给出可逐条对照的动作项。

维度一：信息架构（Information Architecture）

• Reduce scope：移除次要动作、可选功能与重复信息；
• Progressive disclosure：把复杂隐藏到清晰的入口之后（手风琴、模态框、分步流程）；
• Combine related actions：合并相似按钮、整合表单、聚合相关内容；
• Clear hierarchy：一个主动作、少量次动作，其余全部降级为第三级或隐藏；
• Remove redundancy：别处已经说过的信息，这里不要重复。

维度二：视觉简化（Visual Simplification）

• Reduce color palette：使用 1–2 种强调色加中性色，而不是 5–7 种颜色（原文给出的是具体数量约束）；
• Limit typography：一个字体家族、最多 3–4 种字号、2–3 个字重；
• Remove decorations：删掉不服务于层级或功能的边框、阴影、背景；
• Flatten structure：减少嵌套、移除多余容器，绝不在卡片里再套卡片；
• Remove unnecessary cards：基础布局不需要卡片时就不用卡片，改用间距与对齐表达分组；
• Consistent spacing：只使用一套间距刻度，清除随意的空隙。

维度三：布局简化（Layout Simplification）

• Linear flow：能用简单的纵向流，就替换复杂网格；
• Remove sidebars：把次要内容移入正文内联，或直接隐藏；
• Full-width：大方使用可用空间，替代复杂多栏布局；
• Consistent alignment：在左对齐与居中之间二选一并贯彻到底；
• Generous white space：让内容呼吸，不要把所有东西压得紧紧的。

维度四：交互简化（Interaction Simplification）

• Reduce choices：更少的按钮、更少的选项、更清晰的前进路径（“选择悖论”真实存在）；
• Smart defaults：让常见选择自动化，只在必要时发问；
• Inline actions：能用内联编辑就不要弹模态框；
• Remove steps：这个流程能否少走一步？
• Clear next action：给出一个显而易见的下一步动作，而不是五个互相竞争的入口。

维度五：内容简化（Content Simplification）

• Shorter copy：把每句话砍掉一半，然后再砍一次（Cut every sentence in half, then do it again）；
• Active voice：写 “Save changes”，不写 “Changes will be saved”；
• Remove jargon：平实的语言永远胜出；
• Scannable structure：短段落、项目符号、清晰标题；
• Essential information only：删掉营销套话、法律文书腔与含糊其辞；
• Remove redundant copy：不要让标题复述引言、不要重复解释——同一句话只说一次。

维度六：代码简化（Code Simplification）

distill 没有止步于像素与文案，还要求同步处理代码层面的复杂度，因为对 AI 生成的设计而言，干净的实现同样属于「设计质量」的一部分：

• Remove unused code：死 CSS、未使用的组件、孤儿文件；
• Flatten component trees：降低组件嵌套深度；
• Consolidate styles：合并相似样式，一致地使用工具类；
• Reduce variants：这个组件真的需要 12 个变体吗？3 个能否覆盖 90% 的场景？

绝不允许清单（NEVER）：简化的六条安全边界

为了防止「简化」退化为「破坏」，distill 文档明确列出了六条红线，任何一次 distill 执行都不得越界：

• NEVER remove necessary functionality —— 简化 ≠ 没有功能；
• NEVER sacrifice accessibility for simplicity —— 清晰标签与 ARIA 仍然必需，可访问性是底线；
• NEVER make things so simple they're unclear —— 神秘不等于极简（mystery ≠ minimalism）；
• NEVER remove information users need to make decisions —— 用户做决策所需的信息不能删；
• NEVER eliminate hierarchy completely —— 某些东西就应该突出，层级不能被推平；
• NEVER oversimplify complex domains —— 把复杂任务削成不适配的幼稚形态同样失败，复杂度要与实际任务复杂度匹配。

这六条红线从功能、无障碍、清晰度、决策信息、层级、领域匹配六个角度为减法动作「上锁」，与阶段一的六类复杂度来源形成闭环——诊断时逐类找病灶，执行时逐类守边界。结合 impeccable 体系看，这与 audit.md 强调的可访问性/质量检查一脉相承：简化后依然要能通过质量闸门，而不是制造一个「好看但不达标」的空壳。

阶段四：Verify Simplification —— 用四条可验证标准确认简化有效

执行完删减后不能直接宣布胜利，distill 要求回答一组「是否真的变好」的验证问题：

• Faster task completion：用户能否更快完成目标？
• Reduced cognitive load：理解「该做什么」是否更容易？
• Still complete：所有必要功能是否仍然可达？
• Clearer hierarchy：什么最重要是否变得更显而易见？
• Better performance：更简单的设计是否加载更快？（隐含的性能收益）

注意验证对象永远是「用户体验质量」，而不是「删了几行代码/几个元素」。如果删得更多但没有更快、更清晰、更完整，那么这次简化并没有达成目的。

阶段五：Document Removed Complexity —— 把每一次取舍都变成记录

distill 要求把简化动作当成一次「需要留下审计痕迹的工程变更」对待。一旦移除过功能或选项，必须：

• 记录为什么被移除（rationale）；
• 考虑是否需要为它们提供替代入口；
• 留意需要长期观察的用户反馈信号。

这一阶段的价值在于：a) 防止「删除→用户报障→又加回来→再次删除」的摇摆；b) 让未来的 critique/polish/doctor 等巡检知道当前状态是「有意为之」而非「意外缺失」；c) 为用户反馈建立观测基线。

收尾交棒：让 polish 完成最后一公里

distill 文档给出的收尾指令非常明确：

When the cuts feel right, hand off to /impeccable polish for the final pass.

当删减方向确定、手感对的时候，把工作移交给 polish.md 做最后一轮：polish 的职责是校准对齐、间距、一致性与微细节，其参考文档也明确区分了「refinement（精修，保持现状）」与「redesign（重设计，整体替换）」。distill 属于前者——它只负责移除复杂性，不负责换一套视觉语言；如果概念本身错了，polish 文档甚至建议直言并改推 redesign 或 bolder，而不是借精修之名偷换实现。

两者叠加后的典型工作流是：distill 拆结构 → polish 补细节 → audit 验质量，恰与 impeccable 中「Evaluate（critique/audit）→ Refine（polish/bolder/quieter/distill）→ Iterate（live）」的分类协同呼应。

方法论溯源：为什么设计界把减法奉为终点

distill 文档在结尾引用了《小王子》作者安托万·德·圣埃克苏佩里（Antoine de Saint-Exupéry）的名言作为哲学落点：

"Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away."

（完美不是无可增添，而是无可删减之时。）这句话概括了 distill 的全部方法论内核——评估找病灶、规划定取舍、六维执行减法、验证守住体验、记录留痕，最后让 polish 收尾。对 AI 驱动的界面设计而言，这五阶段流程的价值在于把「审美直觉」翻译成了可执行的检查清单与决策规则，让模型在做减法时既不手软、也不越界，最终产出那种「干净、有力、聚焦」的设计。

如果你正在使用 impeccable 处理一个「信息太多、不知道该保什么」的界面，直接以 /impeccable distill <目标> 起步，并让本仓库中的 distill 参考文档（以及与其配套的 SKILL.md 命令表、command-metadata.json 触发定义）成为你与模型共同的执行基准。