distill

distill skill 概覽

distill 的用途

distill skill 是一套聚焦於 UI 設計簡化的工作流程，目標是把畫面收斂到「最核心的任務」。當介面看起來過於繁雜、吵雜、裝飾過多，或選項堆疊到讓人分心，而你想要的是更乾淨、更有力的方向，而不是再加更多功能時，這個 skill 特別適合。

distill for UI Design 最適合的使用情境

當你手上已經有某個畫面、流程或元件，且需要把它變得更沉穩、更清楚時，就很適合使用 distill for UI Design。它適合設計師、前端工程師、產品團隊，以及 AI agents 處理以下工作：

• 幫 dashboard、表單、設定頁、明細頁去除雜訊
• 減少彼此競爭的操作
• 簡化視覺層級
• 移除裝飾性噪音
• 把「功能很多」的版面，轉成以任務優先的版面

真正要解決的核心問題

使用者安裝 distill skill，不是只為了得到一句「做得更簡單一點」。他們真正想回答的是更難的問題：

• 什麼應該保留？
• 什麼應該拿掉？
• 什麼應該隱藏、合併，或延後呈現？
• 這個畫面唯一的主要使用者目標是什麼？

也因此，distill 比一般「把它弄乾淨一點」的 prompt 更有用。它的價值在於：在重設計之前，先強迫你做優先順序判斷。

關鍵差異點

distill 最大的差異，在於它不是一個可以單獨使用的風格化 prompt。這個 skill 明確依賴上游的設計脈絡：

• 先執行 /frontend-design
• 如果目前還沒有任何設計脈絡，先執行 /teach-impeccable
• 如果主要目標或限制條件不清楚，就先停下來問澄清問題

這個依賴關係對是否採用很重要：distill 放在更完整的 impeccable 設計系統裡會更強，不太適合被當成一次性、孤立使用的 prompt。

安裝前要先知道的事

這是一個相當輕量的 skill，主要只有一個檔案 SKILL.md，沒有附帶 scripts、範例或參考資產。這代表它很好檢查，但也表示輸出品質會很仰賴你提供的脈絡。如果你想找的是一套自成一體、腳手架很多的 distill guide，那這個 repository path 比較偏原則導向，而不是工具導向。

如何使用 distill skill

distill 的安裝情境

上游的 SKILL.md 沒有提供安裝指令，所以請照你平常的 Claude Skills 安裝流程安裝整個 repository，並指定 pbakaus/impeccable 裡的 distill skill。如果你是從 repo 安裝，對應路徑是：

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

由於這個 skill 可由使用者直接呼叫，且參數提示為 [target]，實務上最好的用法是讓 distill 對準某個具體畫面、流程或元件，而不是丟一個模糊的產品層級需求。

先讀這個檔案

先從這個檔案開始：

• SKILL.md

這個 skill 資料夾裡沒有額外的 README.md、metadata.json、rules/ 或 references/ 檔案，所以幾乎所有有用的行為定義都集中在這一個檔案。對安裝評估來說，這反而是好事：你可以很快看完並判斷整個 distill skill 是否適合。

多數人會忽略的必要依賴

在使用 distill 之前，skill 本身要求先呼叫 /frontend-design。這個上游步驟包含設計原則、反模式，以及 “Context Gathering Protocol”。如果目前還沒有設計脈絡，預期流程是先跑 /teach-impeccable。

這點很重要，因為弱結果通常就出在跳過這段前置設定。如果你只拿一張截圖或一句模糊抱怨，直接叫 distill 處理，模型很可能會拿掉錯的東西。

distill 需要什麼輸入

高品質的 distill usage，起點是明確的 target，加上足夠的脈絡，讓它能辨識 UI 的主要任務。好的輸入通常包含：

• 精確指出是哪個畫面或元件
• 主要使用者任務是什麼
• 目前有哪些問題，例如操作太多、層級太弱
• 硬性限制，例如法規要求、必須保留的控制項、工程限制
• 這次簡化希望透過移除、合併、隱藏，或漸進揭露來達成

一個弱的輸入：

• 「把這頁簡化一下。」

一個更強的輸入：

• 「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.」

如何把模糊目標變成完整 prompt

一個實用的 distill guide prompt 結構如下：

1. 指出 target 是什麼。
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 usage 流程如下：

1. 先透過 /frontend-design 蒐集脈絡。
2. 確認主要使用者目標只有一個。
3. 對單一畫面執行 distill，不要一次處理整個產品。
4. 檢查它建議移除、合併或隱藏哪些東西。
5. 驗證那些「建議拿掉」的元素，是否其實受政策、客服或商業邏輯要求而必須保留。
6. 用更明確的限制條件再迭代一次。
7. 之後才進到視覺細修或實作階段。

這個順序很重要，因為 distill 本質上是優先順序判斷工具，不是最後的 polish 工具。

distill 可能會分析哪些問題

從 skill 文字來看，distill 主要會檢查：

• 元素過多
• 視覺變化過度
• 資訊過載
• 視覺噪音
• 層級混亂
• 功能膨脹

它也明確推動你找出「20% 就能帶來 80% 價值」的部分。如果你的團隊總是很難砍功能或收斂範圍，這種框架正是使用這個 skill 最有價值的原因之一。

何時應該停下來釐清，而不是硬做下去

原始指引明確表示：如果從 codebase 或 prompt 看不出以下資訊，就應該先停下來發問：

• 主要使用者目標
• 哪些是必要、哪些只是加分項
• 哪些可以移除、隱藏或合併

這是一條很重要的邊界。如果你的團隊連畫面的核心任務都無法取得共識，distill 不會神奇地幫你解決產品方向的模糊；它只會把這個模糊更明確地暴露出來。

第一次使用 distill 時最適合的 target

適合拿來當第一批練習目標的有：

• 一個很擁擠的設定頁
• 卡片過多的 dashboard
• 一次顯示太多非必要欄位的表單
• 同時做很多事的 modal
• 有多個 CTA 彼此競爭的 landing section

不適合當第一個 target 的有：

• 高度受監管、移除內容空間很小的流程
• 沒有具體畫面的 design systems 工作
• 已經很精簡，但真正問題出在互動設計的畫面

可以期待什麼輸出

當 distill skill 最有幫助時，你通常會得到：

• 對複雜來源的診斷
• 更清楚的內容與操作層級
• 對移除、合併或漸進揭露的建議
• 更聚焦的使用者路徑

但不要期待它單靠自己就提供程式碼轉換、自動化稽核，或可直接實作的 component diff。

distill skill 常見問題

distill 會比一般的簡化 prompt 更好嗎

通常會，前提是你要的是有結構的簡化，而不是泛泛的清理。這個 skill 提供一個可重複使用的視角，幫你找出複雜來源，並強迫收斂成單一主要目標。一般 prompt 也可以說「把它變乾淨」，但 distill 更可能進一步追問：到底哪些東西應該真正消失。

distill 對新手友善嗎

算友善，但有個前提。它的文字不難懂，repo 也很好檢查，因為幾乎就是單一檔案。真正比較難的不是安裝，而是你是否有足夠的 UI 脈絡來把這個 skill 用好。新手最好從單一畫面開始，並明確列出限制條件。

我需要把 impeccable repository 其他部分都看完嗎

你不需要在嘗試 distill install 之前把整個 repo 全讀完，但你應該遵守文件裡寫明的依賴關係：先用 /frontend-design，必要時再加上 /teach-impeccable。這個 skill 原本就是設計來放在那個生態系裡運作的，不是要完全取代它。

什麼時候不該用 distill

如果主要問題是以下情況，就先不要用 distill：

• 問題出在互動邏輯壞掉，而不是畫面雜亂
• 缺少使用者研究
• 產品策略跨很多畫面都還不清楚
• 需要補強的是無障礙或法規遵循，而不是做減法

在這些情況下，單靠簡化很可能會把問題看錯。

distill 能用在非 UI 任務上嗎

從 repository 的證據來看，它主要是給 UI 與 frontend design 使用。它的措辭、對 /frontend-design 的依賴，以及分析分類，都集中在介面簡化。如果你想拿它來簡化文案、系統或架構，最多應該把它當作靈感來源，而不是保證適配的工具。

如何改善 distill skill 的使用效果

給 distill 一個畫面、一個目標

想提升 distill 輸出的最快方法，就是縮小範圍。「Simplify our app」太大了；「Distill the billing settings page so users can update payment method faster」就很可執行。這個 skill 在 target 只有單一主導任務時，效果最好。

把必留項和可協商項分開

一個好的 prompt 應該清楚區分：

• 必須保留的內容或操作
• 可隱藏或可移除的非必要項目
• 可以優先剝除的裝飾性元素

否則，distill 很可能會建議砍掉某些在政治上或功能上根本不能動的東西，白白浪費一輪 review。

告訴 distill 你要哪一種簡化

不是所有簡化都等於刪除。當你明確指定偏好的操作槓桿時，結果通常會更好：

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

這能把 distill usage 從一句「讓它更簡單」，轉成更精準的設計操作。

提供真實的複雜症狀

不要只說這個畫面很亂。請把亂的方式講出來：

• 首屏上方有五個按鈕
• 指標重複
• 有三種沒有明確意義的文字樣式
• 卡片同時用了陰影、邊框和底色
• 次要設定在主要流程完成前就先露出來

這些具體症狀，能幫模型對應到 skill 自己定義的複雜類型。

留意最常見的失敗模式

distill for UI Design 最大的失敗模式，是把不該被簡化的東西過度簡化。畫面可能看起來更乾淨，但如果關鍵脈絡、信任訊號，或少數但重要的控制項被拿掉，實際可用性反而會變差。第一輪輸出後，請把每一個建議移除的項目，都對照真實使用者任務再檢查一次。

要求分階段輸出

更好的 prompt 會要求它分階段產出：

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 幫你找出哪些東西該砍、該弱化之後，接著仍要回到你原本的 frontend 與 product review 流程。這個 skill 最擅長的是幫你框定決策，而不是替團隊做最後驗證。真正上線前，還是要確認狀態處理、無障礙、內容清晰度，以及各種邊界情境。