distill

distill 技能概览

distill 是做什么的

distill 是一套聚焦于 UI 设计简化的工作流，目标是把一个界面收缩到“最核心的任务”上。它适合用于这样的场景：当某个界面显得繁杂、嘈杂、装饰过度，或者塞进了太多选项时，你需要的不是继续加功能，而是给出一个更干净、更有力的方向。

distill for UI Design 最适合什么场景

当你已经有一个具体的页面、流程或组件，需要把它变得更平静、更清晰时，就适合使用 distill for UI Design。它适用于设计师、前端工程师、产品团队，以及处理以下任务的 AI agent：

• 清理仪表盘、表单、设置页和详情页的杂乱内容
• 减少彼此竞争的操作入口
• 简化视觉层级
• 去掉装饰性噪音
• 把“功能很多”的布局改造成“任务优先”的布局

distill 真正要解决的问题

用户安装 distill skill，并不只是为了得到一个“更简洁的设计”。他们真正想解决的是更难的判断题：

• 什么必须保留？
• 什么应该删掉？
• 什么应该隐藏、合并，或延后展示？
• 这个页面上唯一的核心用户目标到底是什么？

这也是 distill 比普通的“把这个做得更干净一点”提示词更有价值的原因。它的重点不在重画界面，而在于先强制完成优先级排序。

关键差异点

distill 最核心的区别在于：它不是一个独立可用的风格化提示词。这个技能明确依赖上游设计上下文：

• 先运行 /frontend-design
• 如果还没有任何设计上下文，先运行 /teach-impeccable
• 如果核心目标或约束不清楚，就先停下来提澄清问题

这一依赖关系对是否采用它非常关键：distill 放在更大的 impeccable 设计体系里会明显更强，而不是作为一次性、孤立使用的 prompt。

安装前需要知道什么

这是一个很轻量的技能，主要只有一个文件：SKILL.md，没有附带脚本、示例或参考素材。好处是非常容易审查；但反过来，也意味着输出质量会高度依赖你提供的上下文。如果你想找的是一个自带完整脚手架、开箱即用的 distill guide，那这个仓库路径更偏“原则驱动”，而不是“工具驱动”。

如何使用 distill skill

distill 的安装上下文

上游 SKILL.md 没有提供安装命令，所以请按你平时的 Claude Skills 安装流程来安装该仓库，并在 pbakaus/impeccable 中定位到 distill 这个技能。如果你是从仓库直接安装，相关路径是：

https://github.com/pbakaus/impeccable/tree/main/.claude/skills/distill

由于这个技能可由用户直接调用，并且参数提示为 [target]，更实用的使用方式是：把 distill 用在某个具体页面、流程或组件上，而不是提出一个模糊的、覆盖整个产品的请求。

先读这个文件

从这里开始：

• SKILL.md

这个技能目录里没有配套的 README.md、metadata.json、rules/ 或 references/ 文件，因此几乎所有有价值的行为定义都集中在这一个文件里。对于安装评估来说，这是个好消息：你可以很快判断整个 distill skill 是否适合你。

大多数人会忽略的强制依赖

在使用 distill 之前，技能说明要求先调用 /frontend-design。这一步上游流程包含设计原则、反模式，以及 “Context Gathering Protocol”。如果当前还没有设计上下文，则应先运行 /teach-impeccable。

这一点非常重要，因为结果不佳通常不是技能本身的问题，而是跳过了这层准备。如果你只是拿一张截图或一句粗略抱怨，直接调用 distill，模型很可能会删错东西。

distill 需要什么输入

想获得高质量的 distill usage，起点是一个明确的目标对象，以及足够的上下文来识别 UI 的核心任务。好的输入通常包括：

• 具体是哪个页面或组件
• 用户的主要任务是什么
• 当前问题是什么，比如操作太多、层级太弱
• 硬性约束，比如合规要求、必须保留的控件、工程限制
• 这次简化更倾向于删除、合并、隐藏，还是渐进披露内容

一个较弱的输入：

• “Simplify this page.”

一个更强的输入：

• “Use distill on our analytics dashboard. The primary user goal is to spot traffic changes in under 10 seconds. Keep the date range picker and export action. We can remove secondary filters from the default view if needed. Current issues: too many cards, repeated metrics, heavy borders, and three competing CTAs.”

如何把模糊目标变成完整提示词

一个实用的 distill guide 提示结构是：

1. 说明目标对象。
2. 写清唯一的核心用户目标。
3. 列出必须保留的元素。
4. 列出可能可以删除或隐藏的内容。
5. 指出哪里显得拥挤、杂乱。
6. 先要求输出简化方案，再进入最终重设计。

示例：

“Apply distill to the onboarding modal for first-time team admins. The one goal is helping them invite teammates. Must keep: email entry, role selector, skip option. Nice-to-have elements that can be deferred: tips carousel, template preview, feature badges. The current design feels crowded because it mixes setup, education, and marketing. First identify complexity sources, then propose what to remove, combine, or hide.”

推荐的 distill 使用流程

一个高信号的 distill usage 工作流如下：

1. 通过 /frontend-design 收集上下文。
2. 确认核心用户目标只有一个。
3. 把 distill 用在单个页面上，而不是整个产品。
4. 审查它建议删除、合并或隐藏的内容。
5. 检查那些“建议删除”的元素里，是否其实受政策、客服流程或业务逻辑约束，必须保留。
6. 用更明确的约束继续迭代。
7. 只有在这之后，再进入视觉打磨或实现阶段。

这个顺序很关键，因为 distill 本质上是一个“优先级判断工具”，而不是最后一轮润色工具。

distill 通常会分析什么

根据技能文本，distill 会重点寻找：

• 元素过多
• 视觉变化过多
• 信息过载
• 视觉噪音
• 层级混乱
• 功能堆叠

它还明确强调要找出“创造 80% 价值的那 20%”。如果你的团队总是很难砍需求，这种思路本身就是使用这个技能的一个重要价值。

什么时候应该停下来先澄清，而不是继续硬推

源说明里明确提到：如果从代码库或提示词中无法看清以下信息，就应该先停下来提问：

• 核心用户目标是什么
• 什么是必要的，什么只是锦上添花
• 哪些内容可以删除、隐藏或合并

这是一个很有意义的边界。如果你的团队连这个页面的核心任务都无法达成一致，那么 distill 不会神奇地替你解决问题，它只会把这种产品层面的模糊暴露出来。

首次使用 distill 的最佳目标

适合拿来第一次尝试的目标：

• 一个过于拥挤的设置页
• 一个卡片太多的 dashboard
• 一个一开始就展示了太多可选字段的表单
• 一个承担了多个任务的 modal
• 一个有多个 CTA 互相竞争的 landing section

不适合作为第一次目标的场景：

• 高度受监管、几乎不能删减内容的流程
• 没有具体页面对象的 design systems 工作
• 已经很简洁，但问题主要出在交互逻辑上的页面

可以期待 distill 输出什么

当 distill skill 发挥得比较好时，你通常会得到：

• 对复杂性来源的诊断
• 更清晰的内容与操作层级
• 关于删除、合并或渐进披露的建议
• 更聚焦的用户路径

但不要指望单靠这个技能就产出代码转换、自动化审计，或可直接落地的组件 diff。

distill skill 常见问题

distill 比普通的简化提示词更好吗

通常是的，前提是你需要的是结构化简化，而不是泛泛的“清理一下”。这个技能提供了一套可重复使用的视角来识别复杂性来源，并强制要求只保留一个核心目标。普通 prompt 也许会说“让它更干净”，但 distill 更可能进一步追问：到底什么应该真正消失。

distill 对新手友好吗

友好，但有个前提。它的语言本身并不复杂，而且仓库也很容易检查，因为基本只有一个文件。真正难的不是安装，而是你是否具备足够的 UI 上下文，来把这个技能用好。新手最好从单个页面、加上明确约束开始。

我需要先看完整个 impeccable 仓库吗

你不需要在尝试 distill install 之前读完整个仓库，但你应该尊重文档里写明的依赖关系：先跑 /frontend-design，必要时再跑 /teach-impeccable。这个技能本来就是为这个生态内部设计的，不是要完全替代它。

什么情况下不应该用 distill

如果主要问题是下面这些，就先不要用 distill：

• 交互逻辑损坏，而不是界面杂乱
• 缺少用户研究
• 多个页面层面的产品策略不清晰
• 需要“增加修复”而不是“做减法”的无障碍或合规问题

在这些情况下，单纯追求简化反而可能把方向带偏。

distill 能用于非 UI 任务吗

从仓库现有证据看，它主要面向 UI 和前端设计。无论是措辞、对 /frontend-design 的依赖，还是分析类别，核心都围绕界面简化。如果你想简化的是文案、系统或架构，可以把它当作一种启发，但不要默认它一定适配。

如何改进 distill skill 的使用效果

给 distill 一个页面、一个目标

提升 distill 输出质量最快的方法，就是缩小范围。“Simplify our app” 太大了；“Distill the billing settings page so users can update payment method faster” 才是可执行的。这个技能在目标只有一个主任务时效果最好。

把必须保留和可协商内容分开

一个强提示词应该明确区分：

• 必须存在的内容或操作
• 可以隐藏或删除的可选项
• 可以优先剥离的装饰性元素

否则，distill 很可能会建议删掉一些在政治上或功能上根本不能动的内容，白白浪费一轮评审。

告诉 distill 你想要哪种“简化”

并不是所有简化都等于删除。只要你明确偏好的手段，结果通常会更好：

• remove
• combine
• hide behind progressive disclosure
• downgrade visual emphasis
• sequence across steps instead of showing everything at once

这样就能把 distill usage 从笼统的“做简单一点”，变成更明确的设计操作。

提供真实的复杂性症状

不要只说“这个页面看起来很乱”，而要把“乱”说具体：

• 首屏就有五个按钮
• 指标重复出现
• 有三种没有明确含义的文字样式
• 卡片同时用了阴影、边框和浅色背景
• 用户还没完成主任务就先看到次级设置

这些具体症状能帮助模型更准确地映射到技能自身的复杂性分类。

留意 distill 最常见的失败模式

distill for UI Design 最大的失败模式，是把不该简化的地方简化过头。一个页面视觉上可能更干净了，但如果关键上下文、信任信号或边缘场景控制项被删掉，实际可用性反而会下降。第一轮输出之后，请用真实用户任务去逐项核查每个“建议删除”项。

让输出分阶段进行

更强的提示词会要求分阶段输出：

1. 识别复杂性来源
2. 定义核心任务
3. 列出要删除、合并和隐藏的内容
4. 提出简化后的结构

这种分阶段方法会让 distill guide 更容易审查，也比一上来就要求直接重设计更容易继续优化。

第一轮之后，带着约束继续迭代

如果第一版结果过于激进，或者过于保守，就用更具体的限制条件继续细化：

• “Keep all legal disclosures visible.”
• “Do not add more steps.”
• “We can hide advanced filters behind an accordion.”
• “The primary CTA must remain above the fold.”

这是在不重写整份 brief 的前提下，提升 distill skill 输出质量最实际的方法。

把 distill 和实现评审配合起来

当 distill 帮你识别出哪些内容该删、该弱化之后，接下来仍然要走你正常的前端和产品评审流程。这个技能最擅长的是帮助你框定决策，而不是替团队完成上线前的全部验证。正式交付前，仍需检查状态处理、无障碍、内容清晰度，以及边缘场景。