你不需要 48 個 AI 員工——Skill 膨脹的陷阱與真正值錢的東西

你不需要 48 個 AI 員工——Skill 膨脹的陷阱與真正值錢的東西

一張截圖引爆的幻覺

最近台灣 Claude 社群流傳一組截圖：有人在 Claude Code 裡建了 48 個 Skills，按「部門」分類——翻譯部、內容創作部、研究部、社群部——彷彿在地端架了一間微型公司。

留言區清一色「謝謝分享」，幾百個讚。

我不打算否定這個做法的價值。但我想拆開來看一件事：這組圖到底展示了什麼，又遮蔽了什麼。

因為如果你只看到「48 個 AI 員工」，你可能正在走進一個越來越多人掉進去的陷阱。

先搞清楚：48 Skills 不是 48 個 AI

從留言可以確認的硬體資訊：一台機器，地端運行，VSCode 掛 Claude Code。

這代表實際架構大概率是：

Claude Sonnet 一個模型，加上 48 個 SKILL.md 檔案（本質是指令包），加上若干腳本和 MCP 工具。

不是 48 個模型同時運行。不是分散式系統。不是真正的 multi-agent。

Skill 在 Claude Code 的技術定義很簡單：一個資料夾，裡面放一個 SKILL.md 檔，包含 YAML 前置資料和 Markdown 指令。Claude 開工時讀取所有 Skill 的描述，根據你的指令判斷要不要載入某個 Skill 的完整內容。

它比較像是圖書館裡的書：模型知道書架上有什麼，但只會在需要時把書拿下來讀。

所以「48 個 AI 員工」是一個比喻。問題在於，太多人把比喻當成了現實。

值得肯定的部分

先說清楚，這個做法有真正的價值。

第一，把知識固化成可重複調用的流程。比如「翻譯部」其實是一條 pipeline：分析原文→翻譯→校稿→台灣化→輸出。寫成 Skill 之後，你說一句「翻譯這篇」，它自動走完整條流水線。這是真正的效率提升。

第二，用「部門」的隱喻來組織 Skill，讓整個工作流直覺化。如果你的工作模式固定、產出類型穩定，這種分類法確實能降低認知負擔。

第三，它證明了一件事：Claude Code 最大的優勢不是模型本身，而是模型可以自主判斷要調用哪個 Skill。你說「幫我做一篇分析」，它可能自己決定需要 web search、markdown formatter、infographic、social post，然後逐個調用。這種「主管派工畀部門」的感覺，是 Skill 系統真正有意思的地方。

陷阱在哪裡

但問題出在後面。

Rule 不等於 Skill

「用繁體中文」、「用台灣術語」、「用 Markdown 格式」、「標題要吸睛」——這些是規則（Rules），不是技能（Skills）。

Claude Code 的架構其實分得很清楚。CLAUDE.md 是全域指令檔，每次對話都會載入。Skill 是按需載入的指令包，只在觸發條件符合時才讀取。

如果你把「用繁中」拆成一個獨立 Skill，把「用台灣術語」又拆成另一個 Skill，你做的事情等於把本來只需要寫進 CLAUDE.md 一次的全域規則，變成了每次都要經過載入、匹配、判斷的獨立模組。

這不是分工。這是人為製造摩擦。

數量膨脹的誘惑

社群最近半年出現一種風潮：曬 Skill 數量。「我有 48 個」、「我有 80 個」、「我有 120 個」。

但仔細看，很多其實是這種拆法：translate、translate-v2、translate-tw、translate-tech、translate-tech-v2。

五個 Skill，做的是同一件事的不同版本。數量好看，實際效益未必高。而且每多一個 Skill，就多一層成本。

Token 成本是真實的

這不是抽象的擔憂。Claude Code 的系統提示本身已經包含大約 50 條指令。根據對指令遵循行為的研究，隨著指令數量增加，模型對所有指令的遵循品質會均勻下降——不是只忽略新的，而是開始均勻地忽略所有指令。

每個 Skill 的描述在啟動時都會被讀取。48 個 Skill 的描述，加上 CLAUDE.md 的全域規則，加上系統提示——這些全部佔用 context window。而模型每次還要額外做一次推理判斷：「這 48 個裡面，現在該用哪個？」

這個判斷本身就是推理成本。

當你去到 100、200 個 Skill，模型花在「選擇用哪個工具」上的算力，可能已經超過「實際執行任務」的算力。

真正有價值的設計：Bundle 思維

企業級 Agent 系統怎麼做？

不是 100 個 Skill 永久掛載。

而是一個 Router 先判斷工作類型，然後只載入對應的技能包。翻譯任務載入翻譯包，內容創作載入創作包，其他 95% 的 Skill 根本不會被讀取。

這才是合理的架構。

回到個人層面，比起管理 48 個細碎的 Skill，更有效的做法可能是 5 到 10 個大型 Skill Bundle。

每個 Bundle 裡包含幾十條規則和完整的工作流程。比如一個「漫畫創作包」，內含繁中規則、台灣化規則、漫畫腳本格式、分鏡邏輯、圖片 Prompt 模板、社群貼文格式。

對使用者來說，只需要一句「啟動漫畫包」，整條流水線就跑起來。

不需要 translate-skill + taiwan-skill + markdown-skill + comic-skill + social-skill 逐個載入。

而且——這才是關鍵——當規則需要改版時，你只需要更新一個 Bundle，而不是追著幾十個 Skill 逐個同步。

這件事背後的更大趨勢

退一步看，「48 Skills」之所以引爆社群，不只是因為技術上好不好用。而是它碰到了一個更深層的需求：

人們想要的不是一個聊天機器人。人們想要的是一個能分工的系統。

2025 年大家還在「玩 Prompt」——一句話換一個輸出。2026 年開始進入另一個階段：Prompt → Workflow → Skill → Agent Team。

這類做法的本質，是把 Claude Code 企業化。用 Skill 模擬部門，用 MCP 模擬系統整合，用 pipeline 模擬工作流程。

方向是對的。

但方向對，不代表實作方式沒有優化空間。

就像真正的企業不會設 48 個一人部門。它會設 5 個部門，每個部門有自己的 SOP 手冊。部門數量不是重點，流程的完整性和可維護性才是。

結語：Skill 最值錢的地方

Skill 真正值錢的，從來不是數量。

而是你能不能把自己的知識、判斷、工作慣例，變成一個可重複調用的流程——然後用一句話啟動它。

一個寫得好的 Skill Bundle，比 48 個零散的 Skill 有用得多。

因為前者是系統。後者是收藏。

星忘塵 Nebula WalkerMythogen Engine · 清醒記錄