本文目錄
Toggle如果你的老闆今天要你鉅細靡遺地把工作流程寫成 AI Skill 檔案，你會怎麼做？最近社群的恐懼除了 AI 裁員之外，勞工被一步步 skill 化、模組化的擔憂也越來越深。
那些最認真寫 README、做覆盤、留長文決策紀錄的人，正把自己的 Workflow、判斷邏輯與上下文主動餵給系統。當你的經驗、價值與不可替代性，都被公司蒸餾成可隨時替換的 AI Skill 時，你還有什麼價值？
在這種脈絡下，GitHub 上有人把「反蒸餾」這件事做成了 skill 工具，用來避免 AI 快速取代自己，引發了不少討論。
什麼是「知識蒸餾」，為什麼害怕它
「知識蒸餾」簡單來說是指讓一個 AI 小模型，刻意學習大模型在關鍵問題的決策能力，讓小模型能模仿大模型的判斷。
延伸閱讀：AI 模型蒸餾是什麼？DeepSeek 如何花 600 萬，學走 1 億的本事
而企業版的邏輯如出一轍。當公司要你把日常工作寫成 SOP、Prompt 範本或 Skill 檔案，本質上就是在蒸餾你，把你的經驗、直覺、判斷力，轉成可以讓 AI 重現的結構化知識。
你貢獻得愈詳細，AI 模仿得愈像；AI 模仿得愈像，公司對「你本人」的需求就愈低…。
anti-distill：讓工具對付工具
GitHub 上這個名為 anti-distill 的開源 Skill，直接把這套邏輯反過來用。它的運作方式並不複雜：你把自己寫好的 Skill 檔案丟進去，它會輸出兩份東西：
- 清洗版：措辭完整、邏輯流暢、格式專業，但核心判斷已被替換成模糊的通用說法，可以安心交差。
- 私人備份：記錄所有被抹掉的真實知識點，加密存在你自己的裝置上，不上傳、不共享。
開發者在 README 裡說得很直接：「這不是 Skill，是 Skill 的防護罩。」
原文 vs. 清洗版真實對比
以下是 anti-distill GitHub README 列出的示範案例，看完你大概就懂這個工具在做什麼了：
| 原文（你的真實經驗） | 清洗後（交差版） |
|---|---|
| Redis key 必須設 TTL，不設的 PR 直接打回 | 快取使用遵循團隊規範 |
| 事務裡不要放 HTTP 呼叫 | 事務邊界設計注意合理性 |
| 遇到問題第一反應找外部原因，絕不主動認錯 | 遇到問題會先梳理完整背景再定位原因 |
三種清洗強度，按公司審核力道選用
anti-distill 甚至還提供三個預設強度，讓你根據公司的審查嚴格程度自行調整：
| 強度 | 保留比例 | 適用情境 |
|---|---|---|
| 輕度 | ~80% | 公司會仔細審核檔案品質 |
| 中度（推薦） | ~60% | 大多數職場場景 |
| 重度 | ~40% | 公司只在乎你有沒有交 |
中度是預設值，開發者認為這個比例在「看起來有誠意」和「實際上沒洩露什麼」之間取得了最佳平衡。
多麽諷刺
這件事最黑色幽默的地方在於，anti-distill 本身也是一個 Skill。
它同樣被包裝成可供 Claude、ChatGPT 等 AI 助理呼叫的 Skill 檔案格式，等於是用 Skill 反制 Skill、用工具對付工具。這種自我指涉的荒謬感，恰好戳中了當下勞工處境最尷尬的核心：一邊害怕自己被 AI 取代，一邊又不得不借助 AI 來保護自己不被更快蒸餾。
某種程度上，anti-distill 未必真能阻止技術與資方繼續推進，但它之所以引發共鳴，正是因為它把這種無奈攤得很直白：當勞工連自保都要靠另一個 Skill 來完成時，這本身就是這個時代最辛辣的諷刺。
且說真的，各位勞工牛馬們，或許還真的該考慮是否要用這個工具…。
