Impeccable distill 设计蒸馏：为 AI 生成的前端界面做“减法”的完整方法论与工程实践

distill 是 Impeccable 技能体系（23 个命令之一）中负责「剥离冗余、回归本质」的精简命令：它要求把界面中一切不配占据位置的元素移除——冗余元素、重复信息、装饰噪音与表面化的复杂度，让用户离目标更近。本文以 distill.md 为准绳，结合本仓库的源码、命令注册表、craft-floor 质量红线与反模式测试语料，从「评估现状 → 制定精简策略 → 六维逐层简化 → 验证 → 记录删除项 → 交接 polish」的完整工作流展开，读完你将掌握一套可直接驱动 AI Agent 执行、也可由设计师手动遵循的界面降复杂度方案。

distill 在 Impeccable 命令体系中的位置

在进入具体方法前，先明确 distill 的定位。本仓库同时维护着多份部署副本（.agent、.claude、.kiro、plugin 等目录下内容相同），其内容源头与持续维护副本是 skill/reference/distill.md（即 .kiro/skills/impeccable/reference/distill.md）。该命令的定义可在命令元数据中找到：

• 在 skill/scripts/command-metadata.json 中，distill 的描述是：“Strip designs to their essence by removing unnecessary complexity. Great design is simple, powerful, and clean.” 触发场景为“用户要求 simplify、declutter、reduce noise、remove elements，或让 UI 更干净、更聚焦”，参数提示为 [target]。
• 在 skill/SKILL.src.md 的命令总表中，distill 归类于 Refine（精修） 类别，与 polish、bolder、quieter、harden、onboard 并列；同类中还有一对天然的“音量旋钮”：bolder 把平淡安全的设计放大，quieter 把过于激进的设计调低，而 distill 负责的是另一条轴——结构性减负。
• 在 README.md 的“23 Commands”速查表中，它的用途被压缩为一行：/impeccable distill → Strip to essence；而 README.md 的使用示例为 /impeccable distill # Remove complexity，直观地表明你可以在 AI 编码工具会话中直接这样发起：

/impeccable distill                # 对当前改动/目标整体去复杂度
/impeccable distill settings       # 聚焦某个具体表面（页面/组件）

与路由规则一致（见 routing.md），distill 不会自动猜测目标：无参数时会走上下文菜单引导用户确认；带显式命令（如 /impeccable distill checkout）则直接加载本参考文档并执行。distill 也会作为 live 变体模式（reference/live.md）中一种受支持的自由动作（bolder/quieter/distill/polish 等之一）出现，用于在浏览器里对单个元素做同类“去噪”实验。

命令前缀 {{command_prefix}}、部署目标 .kiro/skills/ 等是模板安装期替换的变量；本仓库还提供按 Agent 粒度裁剪的 degraded 精简副本（见 plugin/skills/impeccable/reference/degraded），用于资源受限场景下保持同一份方法论的精简形态。

一、核心信念：简洁不是删功能，而是清除障碍

distill.md 的开篇即给出第一性定义：

Strip a design to its essence. Remove anything that doesn't earn its place: redundant elements, repeated information, decorative noise, cosmetic complexity.（把设计剥离到本质。移除一切不配占据位置的东西：冗余元素、重复信息、装饰噪音、表面化的复杂度。）

文档紧接着给出两条必须内化的判断标准：

• CRITICAL：简单（simplicity）不等于删减功能（removing features），而是“移除用户与目标之间的障碍”。每个元素都必须为自己的存在辩护（Every element should justify its existence）。
• IMPORTANT：精简是困难的——它要求对“好点子”说不，以便为“出色的执行”腾出空间。要无情（be ruthless），但这里的无情针对的是噪音，不是功能。

这与本仓库 craft-floor（质量地板，craft-floor.md）中的禁令同源：例如“卡片是懒惰的容器，嵌套卡片永远错误”“每个区块头顶的 eyebrow/kicker 标签是被禁止的默认项”“不需要中断与受保护焦点的任务不该用模态框”等，本质上都是把“删”的裁决标准写成了可执行的机械规则。换句话说，distill 负责宏观裁剪，craft-floor 负责微观红线，二者互补。

二、评估现状（Assess Current State）：先诊断复杂度从哪里来

不要上来就删。第一步是冷静分析“是什么让设计显得复杂或杂乱”。文档给出两条主线：

1. 识别复杂度来源（Identify complexity sources）

六个最常见的复杂度信号，可作为自查清单：

信号	典型表现
元素过多（Too many elements）	相互竞争的按钮、冗余信息、视觉堆砌
过度变化（Excessive variation）	颜色/字体/字号/样式种类繁多但缺乏目的
**信息过载（Information overload）	所有内容一次性摊开在眼前，缺少渐进披露（progressive disclosure）
视觉噪音（Visual noise）	无意义的边框、阴影、背景、装饰
层级混乱（Confusing hierarchy）	看不清什么最重要
功能蔓延（Feature creep）	过多的选项、动作与前进路径

2. 找到本质（Find the essence）

围绕四个问题追问，直到答案收敛：

• 用户的首要目标是什么？（应该只有一个）
• 哪些是真正必要的，哪些只是“有则更好”？
• 哪些可以移除、隐藏或合并？
• 带来 80% 价值的那个 20% 是什么？

3. 底线：不确定就不要猜

文档明确写道：如果以上任何一点无法从代码库（codebase）中推断清楚，不要臆测，直接向用户提问澄清（原始模板中是 {{ask_instruction}}，渲染后的部署副本中为显式的“Ask the user directly to clarify what you cannot infer”）。

从仓库工程实现看，这条“先取证再动手”的原则贯穿整个技能：每次会话的 Setup 要求先运行 context.mjs（见 SKILL.src.md），它会加载 PRODUCT.md、DESIGN.md、对应表面 brief 与原生平台指引；同时 Impeccable 配套的设计检测器（detector/hook）会把界面反模式作为机器证据提供出来。仓库的 tests/fixtures/antipatterns 目录就是一个反模式实证语料库，例如 repeated-container-text.html（同一关键词被重复塞进一个卡片的多个结构槽位）、cramped-padding.html、edge-flush-cards.html、overused-font.html 等。对 distill 而言，这些 fixture 展示了“检测器眼中的冗余/噪音样本”，供 Agent 在裁切时对照真实项目形态，避免空泛地“凭感觉删”。

三、制定精简策略（Plan Simplification）：一份无情的编辑计划

评估之后，先写策略再动手。文档要求用四个问题锁定计划：

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

四、六个维度逐层简化（Simplify the Design）

这是 distill 方法论的正文部分，从信息架构一路裁到代码。每个维度都要系统性地做减法。

4.1 信息架构（Information Architecture）——先砍结构

• 缩小范围（Reduce scope）：移除次要动作、可选功能、冗余信息。
• 渐进披露：把复杂度藏到清晰的入口后面——手风琴（accordions）、模态框（modals）、分步流程（step-through flows）都是合法的“延迟揭示”手段。
• 合并相近动作（Combine related actions）：合并相似的按钮、整合表单、归组相关内容。
• 清晰层级（Clear hierarchy）：一个主动作、少数次动作，其余一律降为三级或被隐藏。
• 去除冗余（Remove redundancy）：如果别处已经说过，这里就不要重复。

4.2 视觉简化（Visual Simplification）——从色彩与字体开始收敛

• 缩减调色板：用 1–2 种主色 + 中性色，而不是 5–7 种颜色。
• 限制字体系统：一个字体族，最多 3–4 种字号，2–3 个字重。
• 移除装饰：删掉不为层级或功能服务的边框、阴影、背景。
• 压平结构（Flatten structure）：减少嵌套，移除多余的容器；永远不要在卡片里再套卡片（这正好呼应 craft-floor.md 中“nested cards are always wrong”的硬禁令）。
• 去掉不必要的卡片：基础布局并不需要卡片，用间距与对齐即可组织信息（“卡片是懒惰的容器”是项目反复出现的裁决口径）。
• 统一间距：只用一套间距刻度，清除任意值间隙。

4.3 布局简化（Layout Simplification）——回归线性与留白

• 线性流动（Linear flow）：能改成简单纵向流（vertical flow）的复杂网格就改。
• 去掉侧栏（Remove sidebars）：把次要内容内联化或隐藏。
• 善用全宽（Full-width）：大方使用可用空间，而不是硬撑多栏。
• 统一对齐：左对齐或居中，二选一并贯彻到底。
• 慷慨留白：让内容呼吸，不要把一切塞得严丝合缝。

4.4 交互简化（Interaction Simplification）——尊重“选择悖论”

• 减少选择：更少的按钮、更少的选项、更清晰的前进路径——“选择悖论是真实存在的”（paradox of choice is real）。
• 聪明的默认值（Smart defaults）：把常见选择自动化，只在必要时询问。
• 内联动作（Inline actions）：能用内联编辑替代的模态流就替代。
• 删除步骤（Remove steps）：流程能否少一步？
• 明确的下一步（Clear next action）：只有一个显然的下一步，而不是五个互相竞争的。

4.5 内容简化（Content Simplification）——把文案减半，再来一次

• 更短的文案：把每句话砍一半，然后再砍一次。
• 主动语态：写 “Save changes”，不写 “Changes will be saved”。
• 去掉行话（Remove jargon）：平实语言永远胜出。
• 可扫读结构：短段落、项目符号、清晰标题。
• 只留必要信息：删掉营销套话、法律术语与模糊措辞（hedging）。
• 移除重复文案：标题不重复引言、不重复解释，同一件事只说一次。

4.6 代码简化（Code Simplification）——让删减落到实处

• 删除未用代码：死 CSS、未使用组件、无主文件。
• 压平组件树：降低嵌套深度。
• 合并样式：合并相似样式，一致地使用工具类（utilities）。
• 收敛变体（Reduce variants）：这个组件真的需要 12 种变体吗？还是 3 种就能覆盖 90% 的场景？

这部分的终极拷问与 polish.md 中的收尾动作一致——polish 要求“移除调试输出、死代码、未用导入、过时样式与 polish 造成的重复”。distill 在宏观删，polish 在微观清，二者接力完成整个“减负—收尾”闭环。

五、绝对不能做的事（NEVER）——简化的护栏

“减法”最容易变成“误伤”。文档用六条硬约束划出红线：

• 绝不删除必要功能（简单 ≠ 无功能）。
• 绝不为简洁牺牲可访问性：清晰的标签与 ARIA 仍然必需。
• 绝不简化到语义不明（神秘 ≠ 极简，mystery ≠ minimalism）。
• 绝不删除用户做决策所需的信息。
• 绝不彻底抹平层级——总该有些东西脱颖而出。
• 绝不把复杂领域过度简化：让实现的复杂度匹配任务真实的复杂度（match complexity to actual task complexity）。

这六条红线意味着：distill 的目标是“干净而有重点”，不是“空无一物”。从项目工程角度看，它也和 craft-floor 的“Verfiy/Refuse”结构呼应——craft-floor 明确“地板只约束机制，绝不替你选方向”（craft-floor.md），distill 的 NEVER 清单同样只设边界、不预设审美。

六、验证精简效果（Verify Simplification）

改完之后，不是“删完就完事”，而是用五条可量化的问题验证精简真的改善了可用性：

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

这里的验证哲学与整个技能“分轮批量验证、不做开放式自 QA”的原则一致（见 SKILL.src.md：构建完整后用一轮批量检查桌面+移动端，批修，最多再确认一轮，然后停止打磨）。

七、记录被移除的复杂度（Document Removed Complexity）

如果确实删除了功能或选项，文档要求留下“审计足迹”：

• 记录移除原因（Document why they were removed）。
• 考虑替代入口：这些能力是否需要替代的访问点（alternative access points）？
• 标记需监控的用户反馈：哪些用户反馈值得后续跟踪（Note any user feedback to monitor）。

这一步让“删”可追溯、可回滚、可复盘——尤其当被删对象涉及真实产品功能而非纯装饰时，删除理由必须能经受住利益相关方的追问。

八、交接：把最终润色交给 polish

文档的收尾是一个明确的工作流约定：

When the cuts feel right, hand off to /impeccable polish for the final pass.（当删减到位后，交给 /impeccable polish 做最后一轮。）

也就是说，distill 与 polish 是串行协作而非竞争关系：distill 完成结构性去重与本质收敛后，由 polish（其完整流程见 reference/polish.md）在“精修而非隐蔽重设计”的纪律下，统一收齐间距、对齐、一致性与微细节，并在最终 source diff 中清理这次改动产生的意外碎片（polish.md）。

附：distill 心法速查

阶段	核心动作	自检问题
评估现状	找出 6 类复杂度源，锁定唯一主目标	这一屏最重要的东西是什么？
制定策略	定核心目的/必要元素/披露时机/合并点	砍掉它是否影响唯一主目标？
六维简化	IA / 视觉 / 布局 / 交互 / 内容 / 代码	每个元素是否证明了自己的存在？
守住红线	NEVER 六条	可访问性、决策信息、层级是否完好？
验证	速度/负荷/完整性/层级/性能	用户是不是真的更快、更省心？
记录+交接	写删除理由、留替代入口、交给 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.”（完美的达成，不是无可再增，而是无可再减。）

如何在真实项目中使用本方法论

1. 安装并初始化：在项目根目录执行 npx impeccable install，在 AI 编码工具中运行 /impeccable init（详见 README.md），让上下文被 PRODUCT.md / DESIGN.md 记录。
2. 触发命令：在 AI 会话中输入 /impeccable distill（可带 [target]，如页面、组件名），Agent 会加载本文对应的 reference/distill.md 作为执行手册。
3. 遵循流程：它会按“评估 → 计划 → 六维删减 → 验证 → 记录 → 交接 polish”推进，并在信息不足时向你提问而不是臆测。
4. 人工复核：你可以用第四节六维清单与第五节 NEVER 红线作为人工评审 checklist，对 Agent 的裁剪结果做二次把关；需要更精细的局部收敛时，可组合 quieter（降噪调低）、clarify（文案清晰化）、layout（节奏与层级）与 typeset（字体收敛）协同处理。

若项目无法在本仓库内运行，本仓库也以只读方式提供了完整的方法论出处（skill/reference）、命令元数据（skill/scripts/command-metadata.json）与可供对照的反模式语料（tests/fixtures/antipatterns），可直接查阅，无需修改任何仓库文件。