Taste-Skill：防 AI Slop 的設計品味框架
一句話：31K 字的 SKILL.md，不是 UI library，是純 prompt engineering 產物——用三顆旋鈕、硬性禁令、pre-flight checklist 防止 AI agent 生成千篇一律的 slop UI。
三旋鈕機制深度拆解
Taste-Skill 的核心是用三顆 1-10 旋鈕統一控制所有設計決策。以下是不同數值組合的實際效果差異：
| 旋鈕 | 設為 3 | 設為 8 |
|---|---|---|
| DESIGN_VARIANCE（佈局實驗性） | 標準單欄，安全保守 | 非對稱網格、非線性閱讀流、負空間當設計元素 |
| MOTION_INTENSITY（動畫） | 僅 hover 變色 | 捲動視差、循序揭示、page transition、微互動 |
| VISUAL_DENSITY（資訊密度） | 大間距、少元素、高留白 | 緊湊儀表板、多層資訊分層、空間最大化 |
關鍵洞察：三顆旋鈕彼此連動。不能同時設定 VARIANCE=9 + DENSITY=9——實驗性非對稱佈局需要大量留白，資訊密度必然要犧牲。Taste-Skill 內建了這些衝突推斷表。
從設計到內容：content-anti-slop 的移植過程
我們沒有直接移植 Taste-Skill（因為 DKY 是靜態 HTML 站，不是 agent 生成 UI），而是借鏡它的方法論移植到內容產出：
| Taste-Skill 概念 | content-anti-slop 對應 |
|---|---|
| 三顆設計旋鈕 | ANALYTICAL_DEPTH / ORIGINALITY / READABILITY |
| 硬性禁令（禁用特定 UI pattern） | 禁用開場白、結尾語、填充句、虛假數據 |
| Pre-flight check | 發布前 16 項機械檢查清單 |
| §0 Brief Inference（設計判讀） | 產出前內容判讀一行 |
| 旋鈕推斷表 | 內容類型→旋鈕預設對照表 |
禁令的機械驗證：關鍵設計決策
移植過程中最關鍵的設計決策是：所有禁令必須可用 grep 機械驗證，不依賴 LLM 主觀判斷。實例：
- 「禁用『在當今這個』」→ grep 零誤判
- 「禁用『不僅是...更是...』」→ regex 模式匹配
- 「各段長度差異明顯」→ Python 計算段長標準差，stddev < 50 = 過於均勻，觸發警告
這確保了 pre-flight 不需要 LLM 參與（LLM 會心軟放水）。可以整合進 CI pipeline 做自動化品質閘門。
在非 UI 場景的適用性
Taste-Skill 的方法論不限於 UI 設計。以下是我實測可用的延伸場景：
| 場景 | 對應旋鈕 | 對應禁令 |
|---|---|---|
| GitHub Docs 寫作 | 準確性/可讀性/範例深度 | 禁用「just」「simply」 |
| API 文件 | 完整性/範例密度/結構化程度 | 禁用無範例的端點描述 |
| 資料分析報告 | 統計嚴謹度/解釋深度/可複現性 | 禁用無樣本數的百分比、無 p 值的顯著性宣稱 |
限制
- 31K 字的 SKILL.md 本身是巨大的 token 成本（每次載入約 $0.05-0.15）
- 旋鈕依賴 agent 自我約束——沒有強制執行機制，agent 可以忽略
- 禁令是英文 LLM 訓練偏差的產物，中文禁令需要獨立收集
- content-anti-slop 只覆蓋了內容產出，UI/前端產出仍缺品質閘門
我的判斷
Taste-Skill 是 2026 上半年我見過最有原創性的 prompt engineering 產物——它解決了真實問題（AI 產出千篇一律），方法論也夠通用（非 UI 場景可延伸）。但它對靜態網站站主的直接價值有限，真正的價值在於方法論的轉化應用。
content-anti-slop 的移植驗證了方法論的通用性。下一步可以考慮把同樣的方法論套用到程式碼產出（code-anti-slop），用類似的旋鈕+禁令+pre-flight 結構。