distill

distill skill 概覽

distill 是做什麼的

distill skill 是一套用來簡化 UI 的工作流程，目的是把設計收斂到真正核心的任務上。它特別適合用在介面看起來過於繁雜、吵雜、裝飾過多、功能堆疊，或難以快速掃讀的情境。和一味腦暴更多 UI 不同，distill 走的是反方向：持續移除、合併、隱藏與釐清，直到主要使用者目標變得一目了然。

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

當你已經有一個畫面、元件或流程，想把它變得更乾淨俐落、又不犧牲實用性時，就適合用 distill for UI Design。它很適合設計師、前端工程師與產品開發者，尤其當你正在面對以下問題時：

• 儀表板資訊過度擁擠
• 表單選項太多
• 多個 CTA 彼此競爭
• 視覺層級不明確
• 顏色、樣式或表面處理過多
• 功能逐漸膨脹，反而掩蓋主要任務

真正要解決的工作

distill skill 的實際任務不是「把畫面做得更漂亮」，而是找出 UI 唯一最重要的目標，然後削減所有會干擾這個目標的東西。實務上，這代表你要判斷哪些內容該完全移除、哪些適合改成漸進式揭露、哪些應該合併，以及哪些需要被更明確地強調。

distill 和一般提示詞有什麼不同

一般像「幫我簡化這個 UI」這種提示，往往只會得到模糊的建議。distill 比較實用，原因在於它把簡化當成一套有意識的稽核流程：

1. 先判斷複雜度是從哪裡來的
2. 找出真正核心的任務
3. 移除不必要的元素與變化
4. 在保留可用性的前提下提升清晰度

這個結構，就是它比起臨時拼湊提示詞更值得安裝的主要原因。

採用 distill 前要先知道的限制

最大的限制是 distill 並不是可獨立運作的 skill。它自己的指示明確要求你先呼叫 /frontend-design，如果當下還沒有設計脈絡，則要先跑 /teach-impeccable 再繼續。若你想找的是一個能單獨直接使用的 skill，這條相依鏈會是最需要先評估的採用門檻。

如何使用 distill skill

distill 的安裝脈絡

這個 skill 位於 pbakaus/impeccable 的 .agents/skills/distill。常見安裝方式如下：

npx skills add pbakaus/impeccable --skill distill

由於目前可見的 repository 內容只有 SKILL.md，因此應把這個檔案視為最權威的使用來源，並預期這個 skill 會依賴同一個 repo 內的其他輔助 skill。

先讀這個檔案

請先從這裡開始：

• SKILL.md

對 distill 使用方式 來說，這個檔案比 README 更重要，因為它包含實際的呼叫契約、工作流程，以及前置步驟。

請遵守必要的相依流程

在使用 distill 之前，請依照這個順序操作：

1. 呼叫 /frontend-design
2. 依照它的方式收集設計脈絡
3. 如果還沒有設計脈絡，就先執行 /teach-impeccable
4. 最後才執行 distill

這不是可有可無的潤飾步驟。這個 skill 明確依賴先前建立好的設計脈絡，跳過這一步，會大幅提高產出流於表面或任意刪減的風險。

distill 需要什麼輸入

當你提供一個具體目標，並附上足夠的脈絡讓它判斷什麼才是必要時，distill skill 的效果最好。理想輸入通常會包含：

• 明確指定的畫面、元件或流程
• 主要使用者任務
• 目前的痛點，例如畫面太擠、操作太多、層級太弱或視覺噪音太重
• 限制條件，例如必填欄位、法務文案、平台限制，或既有 design system 規則

最小化的目標範例：

• distill checkout sidebar
• distill onboarding modal
• distill analytics dashboard header

把模糊需求改寫成有效的 distill 提示

較弱的提示：

• 「簡化這個頁面。」

更好的 distill guide 風格提示：

• 「Use distill on the settings screen. The main goal is helping users change notification preferences quickly. Current issues: too many card sections, repeated labels, three competing save actions, and decorative borders everywhere. Keep required compliance copy and email/SMS toggles. Recommend what to remove, combine, hide, or restyle.」

這種寫法之所以有效，是因為它：

• 指出唯一主要目標
• 直接揭露可能的複雜來源
• 標示哪些內容不能移除
• 要求的是可執行的簡化決策，而不是泛泛而談的評論

distill 會特別檢查什麼

根據原始內容，distill 會主動稽核以下問題：

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

如果你已經知道自己的問題屬於哪幾類，請直接說明。當 skill 不必從有限脈絡中自行推測所有問題時，它通常能給出更果斷的判斷。

實務上建議的 distill 工作流程

一套好用的實務流程通常是：

1. 先用 /frontend-design 收集畫面脈絡
2. 明確說出唯一主要使用者目標
3. 對特定目標執行 distill
4. 檢視它對移除與整併的建議
5. 再要求一版新的版面理由說明或實作計畫
6. 驗證簡化後的版本是否仍支援必要的邊界情境

這一點很重要，因為簡化本身很容易做過頭。distill 最好的用法，通常是一輪先去除噪音，再一輪確認關鍵任務沒有被一起刪掉。

可以期待 distill 輸出什麼

你大致可以期待它提出以下類型的建議：

• 哪些東西應該完全移除
• 哪些內容應改成漸進式揭露
• 哪些控制項或區塊應整併為一個
• 哪些視覺處理應該收斂
• 如何圍繞主要操作強化視覺層級

除非你有再追問，否則不要預期這個 skill 單靠一次輸出就會給你像素級的實作細節。

會直接影響輸出品質的實用技巧

若想提升 distill 使用效果：

• 一次只給一個畫面，不要一次丟整個產品
• 用一句話說清楚主要任務
• 把必要元素與可選元素分開
• 說明哪些商業關鍵操作必須保持可見
• 可以的話，附上截圖、元件清單或程式碼結構

這個 skill 的核心邏輯是「在不傷害主要目標的前提下，哪些可以移除」，所以若必要元素本身定義模糊，最容易得到無力或失焦的建議。

distill 特別有效的情境

distill skill 最擅長的是那些「其實能用，但就是太擠」的 UI。它尤其適合：

• 累積多年控制項的內部工具
• 可見資料過多的企業系統畫面
• 因資訊密度太高而難以掃讀的行動版畫面
• 產品範圍已固定、但整體清晰度不足的改版階段

distill skill 常見問題

distill 適合新手嗎？

適合，前提是你手上已經有具體可被簡化的東西。這個 skill 提供的簡化視角，比開放式設計評論更清楚。新手最大的門檻通常不是 skill 本身，而是前置工作流程：你必須照著 repo 設定設計脈絡，而不能把 distill 當成一句指令就能解決一切的魔法命令。

distill 只是拿來做視覺整理嗎？

不是。distill skill 也會處理結構上的複雜度：例如操作太多、一次顯示太多資訊、優先順序不清，或功能過度堆疊。它不只是表面樣式整理，同時也關乎互動設計與資訊層級。

什麼情況不該使用 distill？

如果真正的問題是功能缺失、需求不清，或任務流程本身還沒定義好，就不適合用 distill。在還沒弄清楚真實使用者目標之前就先簡化 UI，很可能會刪錯東西。若你現在需要的是大方向發想，而不是收斂與減法，它也不是理想選擇。

distill vs 一般提示詞

distill 相較於一般「把這個做得乾淨一點」提示的優勢，在於它的決策模型更聚焦。它會明確追問：哪些是必要、哪些只是加分、哪些可以移除、隱藏或合併。這讓它在去雜訊、做取捨時，比自由發揮型的視覺探索更可靠。

distill 不搭配 impeccable 其他部分也能用嗎？

不太行。從原始內容看來，distill 預期 /frontend-design，有時還包括 /teach-impeccable，都已經先執行過。如果你的環境無法呼叫這些配套 skill，你仍可以手動模仿這套流程，但會失去部分原本設計好的脈絡建立機制。

distill 適合 code-first 團隊嗎？

適合。對以前端為主的團隊來說，是否安裝 distill 是合理的考量，因為簡化工作往往取決於你是否真的理解程式與產品邏輯中哪些是必需的。當設計債已經反映在上線 UI 中過多的控制項、狀態與視覺處理時，它特別有幫助。

如何改善 distill skill 的使用效果

給 distill 一個唯一的主要目標

最有槓桿的改進方式，就是先明確指出目標 UI 只有一個主要任務。原始內容本身就強調，應該只有 ONE primary user goal。若你同時提供多個地位相等的目標，distill skill 就很難果斷簡化，因為每一項看起來都會變得不可刪。

標出可刪項、必留項與未定項

一個好的 distill 提示，應該清楚區分：

• 必須保留
• 可以安全移除
• 尚未確定、可討論

這樣的框架可以避免兩種常見失敗：一種是太保守，最後什麼都沒刪；另一種是太激進，把必要內容一起砍掉。

直接點出真正的複雜來源

不要只說「看起來很亂」。請直接告訴 distill，混亂感來自：

• 按鈕太多
• 資訊重複
• 視覺樣式太多
• 不必要的邊框或陰影
• 分組不佳
• 同時可見的選項太多

這會提高建議的精準度，因為這些本來就是 skill 已經在判斷的核心類別。

要求它做刪減決策，不要只問泛泛評論

更好的提示是：

• 「Use distill and list what should be removed, combined, hidden, or visually softened.」

較弱的提示則是：

• 「Thoughts on this design?」

前者會產出你真的能落地執行的內容；後者則容易變成廣泛評論，降低 distill guide 工作流程的實際價值。

一輪做簡化，一輪做驗證

第一輪之後，再追問：

• 這樣的簡化會引入哪些可用性風險
• 哪些邊界情境現在可能被藏得太深
• 主要 CTA 是否變得更清楚
• 關鍵次要操作是否仍容易被發現

這種第二輪檢查能提升 distill 使用效果，因為高品質的簡化不只是減少元素，更是保留正確的能力。

提供具體素材，而不只是文字描述

如果可以，請盡量提供：

• 截圖
• wireframe
• 元件盤點清單
• 目前的資訊階層
• 與條件式 UI 有關的程式碼片段

目標越具體，distill 就越能有把握地判斷哪些只是裝飾、哪些屬於重複、哪些在結構上其實沒有必要。

留意常見失敗模式

典型的低品質結果通常出現在以下情況：

• 畫面的主要用途不清楚
• 每位 stakeholder 的要求都被當成同等重要
• 必要限制沒有交代
• 你要求它一次簡化整個產品
• 跳過了 /frontend-design 的脈絡收集

如果 distill 的輸出看起來很制式，通常問題不在 skill，而是輸入規格太模糊。

要求 distill 說明取捨理由

若想提高團隊對輸出的信任感，最有效的方法之一就是要求它說明：

• 每一次移除帶來了什麼使用者價值
• 隱藏功能會付出什麼可發現性成本
• 為什麼合併後的控制項比原本分開更好

這會讓 distill skill 不只是清理工具，更像是協助做決策的工具，對團隊採用也更有價值。

把 distill 接上實作層的後續請求

當 distill 已經找出簡化方向後，建議再接一個第二階段請求，要求它提供：

• 修訂後的版面結構
• 符合 design system 的元件選擇
• 前端實作注意事項
• 簡化後畫面的驗收標準

這個交接步驟，往往才是讓 skill 從「概念上正確」變成「實務上真的有用」的關鍵。