做完 50+ 個 Claude Skill 之後，我發現一個反直覺的事實：越私有越值錢

如果你做過 Skill 然後放棄了，這篇文章可能解釋為什麼

先講一個你可能會跳起來反駁的事情。

Anthropic 官方《The Complete Guide to Building Skills for Claude》在介紹 Skill 用途時，原文是這樣寫的：

"Skills are a way to package expertise that Claude can use for yourself, your team, or for the community."

注意這個順序——yourself 排第一。不是 community first、不是 team first，是 yourself first。

但社群討論 skill 時，幾乎所有聲音都壓在後兩個：怎麼做能跨團隊用、怎麼上 Marketplace、怎麼累積 stars。Anthropic 自己把「為你自己做」放在第一位，反而被當成過渡段跳過去。

我做完 50+ 個 skill、砍掉一半重寫之後得到的結論很簡單：

Anthropic 那個順序是對的。越綁死你個人環境、越不能分享的 skill，ROI 越高。

你不孤單：8 萬個公開 skill，多數是壞的

2026 年 3 月 6 日，Anthropic 推出 Claude Marketplace。一個多月後，公開 registry 累積到 8 萬多個 skill。

聽起來繁榮。但你實際翻一輪會發現另一個畫面。X 上開發者 @RockportAI 4 月 11 日這樣講：

"80,000 Claude Skills in the registry. Most are broken — not because builders don't understand Claude, but because they skip 5 structural patterns..."

Power user @svpino 更直白：「Skills 不可靠，maintenance 就是 cat-and-mouse game。」

GitHub 上「Silent Skill never fires」issue 一抓一大把——裝了，Claude 就是不叫它出來。

這不只是 skill 圈的問題。Stack Overflow 2025 開發者調查顯示 46% 開發者不信任 AI tool 的輸出，S&P Global 報告指出 42% 企業 AI 專案已被放棄或正在放棄。「AI tool 看起來很多，能持續用的很少」是整個產業現象。

你做過幾個 Claude Skill 然後就丟了，對嗎？你不孤單。多數人放棄的理由是這三個：

1. 觸發不到——花 40 分鐘寫的 skill，Claude 就是不叫它出來
2. 做完發現手動還比較快——傳參數的時間夠你自己做完了
3. 做一做發現這工作流不是每天在跑——做了沒地方用

如果你中了任一個，大概率你的 skill 方向走錯了。

反直覺的事實：私有 > 通用

官方指南主推 Composability、Portability、Shareability——能跨專案、跨團隊、最好開源放 Marketplace。

對 Anthropic 來說這方向是對的，他們要做生態系。

但對你來說不一定。我做完 50+ 個 skill 之後，最常被觸發、ROI 最高的，全是寫死我環境的那批：路徑寫死、API key 寫死、workflow 順序寫死。拿給任何人都跑不動。

這不是我自己摸出來的怪結論。HCI（人機互動）學界早就有名字叫這件事。

• End-User Development (EUD) 從 1990 年代就在研究：使用者自己做工具，比廠商做的通用工具更貼合需求
• Geoffrey Litt（MIT, Ink & Switch） 2024 提出 Malleable Software 框架，主張「軟體應該被使用者自己捏」，AI agent 正好是讓非工程師都能捏軟體的關鍵技術
• Andrej Karpathy 提出的 Software 3.0 / Vibe Coding 同一個方向：寫軟體的成本降到極低之後，每個人都該有自己的軟體
• Paul Graham 《How to Do Great Work》最常被引用的一句："build the tool you want to use"

這些大方向學界談 30 年、業界 leader 講十年，但落到 Claude Skill 這個具體載體時，大多數人還是慣性地往「做給別人用」去想。

我只是把這個觀察落地成一個更具體的版本：做 skill 朝「越私有越好」走，比朝「越通用越好」走 ROI 高一個數量級。

這篇文章不教你寫 SKILL.md（教學 Anthropic 已經寫得很好），告訴你的是：做 skill 該朝哪個方向走。

先做一個自我診斷

先不要動手寫。先問自己這三題：

Q1：你每天 / 每週是不是有某個工作流做過 3 次以上還要「想一下」？

每次部署到 VPS 要跑哪些 pre-check？每次發完 blog 要同步到哪些地方？每次 commit 要想 message 怎麼寫？

「還要想一下」= 你腦袋裡有隱性 SOP，但還沒被自動化。 這是 skill 最值錢的起點。

Q2：你有沒有一個「只有我會這樣排」的流程？

流程本身不罕見——部署、備份、發文、偵錯誰都會——但排列順序、判斷規則、失敗怎麼接，每個人不一樣。

如果答案是「有，但說不清楚」，那更該做 skill——做的過程會逼你說清楚。

Q3：這工作流的輸入 / 輸出 / 環境會不會變來變去？

如果會，你需要的不是 skill，是 slash command。
如果不會（每次都在同一台機器、同一組工具、同一個目的），這就是私有 skill 的完美候選。

三題 at least 兩題是 yes，繼續讀。三題都 no，關掉文章去做別的事。

三個活生生的案例——你的版本應該長什麼樣

案例 1：pipeline-retry — 為什麼 generic retry 沒用

我的情境：Mac mini 上跑一條影像處理 pipeline，失敗原因有 5 種：API 429、OOM、NAS 斷線、輸入檔毀損、下游 Ghost 發文失敗。每種處理方式不一樣。

Generic retry skill 只會傻傻重跑全部。我的 pipeline-retry 會先讀 ~/pipeline/logs/latest.log 判斷失敗類型，再決定 retry 策略。

省下的時間：每次失敗從 10 分鐘人工 debug → 30 秒一句話觸發。

你的版本可能長這樣：

• 你是 data engineer？→ etl-retry，綁死你的 Airflow DAG 命名規則
• 你跑爬蟲？→ scraper-retry，綁死你 anti-bot 的 backoff 策略
• 你做 CI/CD？→ ci-retry，綁死你 GitLab / GitHub Actions 的 job 結構

重點不是「做 retry」。是把你判斷失敗類型的大腦封裝進去。

案例 2：handoff — 官方找不到對應的 skill

我的情境：跨 session 接續狀態。昨天做到哪、今天要接哪件。

Anthropic 官方沒有對應的通用 skill，因為這本質上就是個人化的。我的 handoff 做的事：讀我指定路徑的 handoff 檔 → 搜我的 mem0 namespace → 掃我主要 10 個 repo 的 git log → 合成摘要。

省下的時間：每天早上 9 點 session 開場從 20 分鐘 recall → 3 分鐘進入狀況。一年 85 小時。

你的版本可能長這樣：

• 自由工作者同時跑 3-5 個客戶專案？→ context-switch，綁死你怎麼區分客戶目錄
• 在大公司跨多個 squad？→ sprint-recall，綁死你 Jira / Linear / Slack 的 workspace
• 寫小說 / 論文，章節之間要接？→ chapter-resume，讀你上一章結尾 + 角色設定

重點不是「接續狀態」。是把**「你是誰、你昨天在幹嘛」的上下文組裝規則**封裝進去。

案例 3：ghost-publish — 寫死 = Feature

我的情境：發 blog 到 blog.chibakuma.com。

Ghost Admin API 的通用腳本 GitHub 一搜一大把。我不用，因為它們不知道：我 feature image 存哪、我分類只有三個、我每篇都要自動塞固定的 SEO meta、發完要同步 LinkedIn。

省下的時間：發 1 篇從 15 分鐘 → 2 分鐘。

你的版本可能長這樣：

• 寫 Substack + Medium + Hashnode 同步發？→ multipost，綁死你的 canonical URL 規則
• 發 Shopify 商品？→ product-publish，綁死你 SKU 命名、圖片命名、SEO 模板
• 做報表？→ weekly-report，綁死你的資料源、版型、收件人清單

重點不是「發 API」。是把**你日積月累養出來的「眉眉角角」**寫進 skill。通用版幫你完成 60%，剩下 40% 你每次都要手動補——那不是省時間，是換個方式浪費時間。

「那 Anthropic 不是剛推出 Marketplace 嗎？」

這問題該回答。

Marketplace 3 月 6 日上線，支援 /plugin marketplace add 一鍵安裝。看起來是在推「分享生態系」。

但你仔細看它的實際定位——上面活躍的是 Replit、GitLab、Harvey 這類企業級夥伴賣的 plugin / connector，是商業合作生態。跟個人 workflow skill 是不同物種。

而散落在 registry 的 8 萬個公開 skill？大多壞掉、沒維護。為什麼？因為 skill 本質上綁定環境。環境變了 skill 就壞——你做的你會修，別人做的他通常不會修。

這呼應 Geoffrey Litt 對 Malleable Software 的核心論點：通用軟體有「最大公約數」的詛咒——為了服務所有人，誰的需求都只服務 60%。剩下 40% 每個人都要自己補。

私有 skill 的價值就在這 40%。

連 Anthropic Claude Code 團隊的 @bcherny、@swyx、@HamelHusain、@geoffreylitt 這些每天重度用 Claude Code 的人，公開貼文裡都在分享他們自己客製的 workflow，不是在推某個熱門 Marketplace skill。@geoffreylitt 還直接說 Claude Code skill 生態「feels fragmented」——但他每天還是用，用的是自己的那套。

回到 Paul Graham 那句："build the tool you want to use"。Skill 是這句話 2026 年版本的最佳載體。

設計私有 Skill 的 4 條原則

1. Description 寫給 Claude 看，不是給人類讀

Description 唯一目的是觸發。別寫華麗介紹，寫清楚「什麼情境叫我」。

❌ 「A comprehensive tool for managing deployment workflows with advanced error handling」
✅ 「部署到 VPS chiba.tw / ranran.tw / n1k.tw 時使用。處理 git pull → build → health check → 失敗自動 rollback」

觸發不到的 skill 等於沒做。@JulianJenkins 的 "Silent Skill never fires" 抱怨，90% 都是 description 寫壞了。

2. 路徑寫死、工具寫死、workflow 寫死

不要為了通用性做參數化。skill 的存在理由就是省掉每次傳參數的麻煩。

3. 命名綁工作流動詞

wrap-up / handoff / start / deploy / audit / cleanup——全部動詞。讀到名字就知道什麼時候用。
不要 xxx-helper / xxx-manager 這種抽象名詞。

4. 3 個月沒觸發就砍

定期 audit。3 個月沒觸發多半是：工作流變了、description 寫壞、或當初做錯方向。

留著是負債——每多一個沒在用的 skill，就多一份觸發干擾。

可以直接抄的工具包

🔧 Tool 1：60 秒「工作流值不值得做 skill」測試

• 4-5 分 → 立刻做
• 2-3 分 → 緩一緩，先寫成 slash command 觀察
• 0-1 分 → 別做，手動就好

🔧 Tool 2：Description 觸發模板

{動詞 + 情境}。{做什麼 + 關鍵 artifact}。{不做什麼（可選）}。

範例：
部署到 VPS chiba.tw 時使用。
跑 git pull → docker build → health check → 失敗自動 rollback。
不處理 Cloud Run 部署（那是 deploy-cloud-run）。

第一段給觸發詞，第二段給 Claude 明確流程，第三段排除近義 skill 干擾。

🔧 Tool 3：Skill Audit Checklist（每季跑一次）

□ 過去 3 個月被觸發幾次？（< 3 次 → 考慮砍）
□ Description 能否一句話說出「什麼情境觸發」？（不行 → 重寫）
□ 路徑 / API key / workflow 是否還對？
□ 有沒有跟其他 skill 功能重疊？（有 → 合併或砍一個）
□ 如果今天從零做，我還會做一樣的嗎？（不會 → 重寫或砍）

🔧 Tool 4：10 個你今晚就能做的「一鍵」私有 Skill

給所有開發者（最高頻）

1. gcp（一鍵 git commit + push）
git add -A → AI 依 diff 產 commit message（照你團隊格式）→ push。
省時間：每天 5-10 次 commit，每次省 1 分鐘，一週 1 小時。

2. worklog（一鍵寫今日工作日誌）
掃所有 repo 的今日 git log + 改動檔案 + 完成 task → 合成「今日 XX 我做了這些事」。格式綁你公司 / 自己的模板。
省時間：每天 20 分鐘 → 2 分鐘。一年多賺出 10 個工作天。

3. repo-check（一鍵檢查 GitHub repo）
丟 repo URL 進去，自動掃 dependencies 過期、commit 活躍度、open issues、CI 狀態、README 完整度、授權。產出「值不值得用」報告。

給常在多 repo / 多專案切換的人

4. morning-brief — 讀昨天 Slack / Email / Calendar + 未完成 task → 5 分鐘摘要
5. sprint-recall — 開會前從 Linear / Jira + Slack threads 拉出上次討論到哪

給主管 / 團隊 Lead

6. weekly-report — git log + PR 合併記錄 + 團隊 Slack → 本週成果
7. 1on1-prep — 1:1 前自動拉下屬近兩週 PR + commit 語氣 + 上次 1:1 筆記

給會 ship 東西的人

8. release-notes — 從最近 N 個 commit 自動產 release notes 草稿
9. pre-push-check — push 前跑 lint + 測試 + diff self-review + commit message 再檢查

給有寫作習慣的人

10. draft-from-thread — 從 Slack / Twitter / 讀書筆記 thread → 部落格草稿

注意：這 10 個都不通用。每個都要寫死你的工具、格式、習慣。做出來別人用不了，但你每天都會用。

最高頻是前三個。任何開發者都適用，今晚做完，明天開始省時間。

結語：你的工作流就是你的護城河

Anthropic 官方寫的順序是 for yourself, your team, or for the community——yourself 排第一，是有道理的。

8 萬個公開 skill 多數壞掉、46% 開發者不信任 AI 輸出、42% 企業 AI 專案被放棄——這是 2026 年的現實。

但這不代表 Claude Skill 是假議題。它代表你該做的不是去 registry 挖別人的，而是建自己的。

HCI 學界叫這 End-User Development、Geoffrey Litt 叫 Malleable Software、Karpathy 叫 Software 3.0、Paul Graham 叫 build the tool you want to use——學界談 30 年、業界 leader 講十年的事，AI agent 終於讓它變得對個人實際可行。

你要做的 skill 本來就應該是別人拿去沒用的——因為它封裝的是你的判斷、你的 workflow、你的 agent 架構、你的資料路徑。

下次要做 skill 之前，先問一個問題：

「這個工作流，只有我會這樣做嗎？」

如果答案是「對」，那就值得做。
如果答案是「別人也這樣做」——registry 裡已經有 50 個做過了，其中 45 個是壞的，你寫只是貢獻第 51 個。

做私有 skill 不是走捷徑，是把你多年養出來的隱性知識變成資產。這件事沒有別人能幫你做。

關於作者：Maki（江中喬），AI / Agentic PM + Tech Lead，目前在 91APP 做 AI 應用落地。經營 blog.chibakuma.com、card.chiba.tw，業餘維護自己的 multi-agent 架構。

資料來源 / 延伸閱讀

Anthropic 官方

• The Complete Guide to Building Skills for Claude（33 頁官方指南）
• Claude Marketplace 2026-03-06 上線（VentureBeat 報導）

學界 / 思想框架

• Geoffrey Litt et al., Malleable Software（Ink & Switch, 2024）
• Andrej Karpathy, Software 3.0 / Vibe Coding（YC AI Startup School 2025）
• Paul Graham, How to Do Great Work（"build the tool you want to use"）
• HCI: End-User Development 文獻（1990s 起）

產業數據

• Stack Overflow Developer Survey 2025（46% 開發者不信任 AI 輸出）
• S&P Global Market Intelligence 2025（42% 企業 AI 專案被放棄或正在放棄）

X 社群聲量

• @RockportAI（2026-04-11）、@svpino、@JulianJenkins
• @bcherny、@HamelHusain、@geoffreylitt、@swyx
• GitHub: awesome-claude-skills、obra/superpowers（合計 150k+ stars）