Skill 是真有用還是 slop：V2EX 這串討論裡，工程師給出了四種檢驗方法

2026年11月12日晚間，V2EX 網友 grandlq 發了一個問題：怎麼判斷一個 skill 是真正有用，還是 slop（指那些看似完整、實際上空洞無用的 AI 生成內容）。這個問題在開發者社羣裡不算新鮮，但這串討論累積了十幾則回覆，難得地把幾種立場分明的判斷方法擺在一起。一週後回頭看，這串對話的價值在於它沒有收斂成單一答案，而是暴露出 skill 這種東西本身定位還很模糊。

先把名詞講清楚。這裡的 skill 指的是寫給 AI Agent 用的能力包，通常是一段結構化的文字說明，告訴模型在某類任務上該怎麼做。它和 MCP 外掛的差別在於：MCP 是真的接上外部工具，skill 多半只是文字描述。問題就出在這裡，如果 skill 只是文字，那它和直接在對話裡把需求講清楚，到底差在哪？

方法一：讓結果說話

第一則回覆來自標記 PRO 的用戶 sickworm，答案很短：「benchmark 是唯一真理。」也就是說，別管 skill 寫得多漂亮，裝上去跑一輪標準化測試，看輸出有沒有變好。另一位用戶 mokeyjay 給了更省事的版本：直接讓模型載入 skill，然後問它。

這兩個思路方向一致，差別在成本。完整 benchmark 要自己設計評測集，問模型一句話則幾乎零成本，但後者測的是模型「知不知道自己被裝了什麼」，不是任務表現。用日常比喻，前者是實際開車上山路測性能，後者是問業務員這臺車有什麼配備。

方法二：看它能不能活過時間

用戶 minami 拋出了這串討論裡最悲觀的判斷：「長遠來看所有的 skill 都是 slop，有用的早被融進去了。」他的意思是，模型每一代都在進步，真正有價值的做法會被廠商吸收成內建能力，剩下的 skill 遲早變成冗贅。

用戶 jackOff 從另一端補充了觀察：純文字類、不需要外部工具的 skill，會逐漸被 Agent 客戶端自帶，並細分成辦公、編程、音訊等不同角色的專屬技能，以換取更好的專注度與更省的上下文開銷。他點名 DeepSeek harness 的自訂預設 Agent 是這個方向的例子。

這個觀點沒有被全盤接受。用戶 clemente 反問：如果你要 AI 寫出金庸加魯迅風味的小說，這種高度特化的需求，模型的通用知識覆蓋不了，還是需要 skill 來承載。他補了一句很有畫面的話：「未來是奇葩的天下。」模型的知識分布是平均主義的，越是偏門、越是個人或業務特有的需求，越需要使用者自己補上。

方法三：分清楚它到底在固化什麼

用戶 secsilm 的回覆大概是這串討論裡最實用的一條。他區分了兩種東西：如果一段流程能寫成腳本，那就寫成腳本，沒必要讓 LLM 介入；skill 的重點在於流程固化，適合那些「不能寫成腳本的流程」。他同時回應了 minami 的質疑，承認 skill 在有效性上和直接寫提示詞沒有明顯區別，差別在於它是可重複、可版本管理的資產。

用戶 xsonglive491 的實踐和這個立場互相印證：他平常是 skill 加腳本配合使用，很少碰純文字說明類的 skill。

換個生活比喻，這就像料理食譜和廚房電器的差別。能用電子鍋一鍵解決的事，不需要每次重讀一遍煮飯步驟；但「我們家喜歡飯稍微硬一點、水少放一成」這種無法寫進機器的偏好，就得靠文字留下來。

方法四：看它記的是誰的學費

最後一則回覆來自用戶 gybin02，他給出的判斷標準只有一句：這個 skill 能不能替你記住一次你自己交過的學費。他舉例，自己留下的 skill 都是從踩坑裏長出來的，比如針對掘金平臺「文章不能帶連結」的規則，是連續兩次投稿沒過審之後才寫死的。反過來，那種放到哪裡都成立的通用型 skill，他用兩次就扔了。

這個標準把前面的爭論收攏了。通用型的 skill 之所以容易是 slop，是因為它宣稱涵蓋的知識，模型本來就會；而從實際挫敗中提煉出來的規則，是模型訓練資料裡不會有的東西，也正是 clemente 說的「特化 spec」。

所以呢

把四種方法放在一起看，脈絡其實一致。判斷一個 skill 值不值得留，核心問題是它承載了什麼模型原本不會的東西。可能是你自己付過學費的平臺規則，可能是公司內部的特殊流程，也可能是需要外部工具配合的操作。至於那些讀起來四平八穩、放到任何專案都「成立」的 skill，用戶 lithiumii 提供了一個快速過濾法：打開看看是不是 AI 口癖寫的。

這個議題和 Skill 賣能力、Bot 賣結果的商業化落差是同一個問題的兩面：skill 的價值一直難以獨立定價，因為它的可替代性太高。而從 Agent 客戶端逐漸內建常用技能的趨勢看，未來值得維護的 skill，大概只剩那些真的綁著你的坑、你的流程、你的奇葩需求的部分。