從 API 文件地獄到 LLM Skills 生態系：Google Gemini 也端出官方 Skills 了

當 API 文件不再雖然只是 PDF 與 Word，而是變成 LLM 看得懂的 Skills，什麼服務會先被選用，其實就有了全新的排序方式。

這幾天 Google Gemini 正式推出自己的官方 Skills，repo 還熱騰騰地只有一百多顆 ⭐，但我覺得它背後代表的，其實是「開發者怎麼選服務供應商」這件事，正在被重排。

我們這一代工程師，大概都被 PDF／Word 版的 API 文件傷過：難搜尋、版本混亂、範例不完整，甚至連錯字都會跟著一路複製到 production。串一個第三方服務，常常像踩地雷，一邊 debug 一邊跟客服對答案。

現在 LLM 變成日常工具之後，很明顯感受到一件事：誰先願意整理出「給 LLM 用的 skills 文件」，誰的服務就更容易被選進技術堆疊裡。

為什麼傳統 API 文件這麼痛苦？

先回到大家最熟悉的情境：要串一個新的金流、CRM 或行銷工具。

• 文件是 200 頁的 PDF，裡面塞滿截圖與表格。
• 範例程式碼只有 PHP 舊版，沒有 TypeScript、Python。
• 參數命名不一致，merchantId、merchant_id 混在一起。
• 文件版本跟實際 API 完全不同步，試到第三次 400 error 才發現是文件寫錯。

這些東西，人類工程師還可以靠經驗與耐心硬撐過去，但對 LLM 來說幾乎是 不可讀的噪音：

• PDF 解析出來充滿錯行、分頁符號、亂掉的表格。
• Word 轉成文字之後，章節階層與語意全部扁平化。
• 想問「如何建立訂單」時，模型只能在一大坨文字裡模糊搜尋。

結果就是：明明有 AI 協助，串接體驗還是停留在「靠蠻力翻文件」的年代。

LLM Skills 是什麼？先看 Claude 跟早期玩家

Claude 把「Skills」這件事講明白之後，等於幫大家定義了一種新的技術文件格式：寫給 LLM 看的「操作說明書」。

一個好的 skill，通常會長這樣：

• 描述這個服務能幫使用者完成什麼事（不是只列 API path）。
• 清楚列出輸入、輸出欄位與限制。
• 提供具體的 prompt 範例，示範怎麼跟這個服務「聊天」。
• 搭配工具或 MCP server，就能在對話中直接呼叫。

社群上很快就出現幾個先行者：

• Recur Skills：把自家服務整理成一整套 Claude-friendly skills，讓 LLM 很自然地理解「這個服務可以幫你做什麼」。
• 台灣第三方金流 Skills：社群自發整理，把常見金流的串接行為包成一個又一個 skill，不用再翻原廠難懂的 PDF。

這些東西實際用起來的感覺是：
你不是在「查文件」，你是在「請一個懂那套 API 的助理幫你寫程式」。

而且這些 skill 其實不只幫工程師，也幫了 BD 與 PM：

• Demo 時不用再開一堆 Postman tab，直接在對話裡示範串接流程。
• 合作方要試接，只要把 skill 丟給自家 LLM agent，看幾個 prompt 範例就能動手。

Google Gemini 官方 Skills 上線，代表什麼訊號？

在這個背景下，Google Gemini 終於也推出官方 Skills 生態系，就很有意思了。

短期內我覺得有幾個關鍵訊號：

• 技能生態系成為平台標配：從 Claude、OpenAI 的工具，到 Gemini Skills，「你家 LLM 有沒有好用的 skills」，會變成評估平台的第一關。
• 服務供應商被迫思考 LLM DX（Developer Experience）：不是只有「人類 DX」，還有「LLM DX」——你的服務好不好被模型理解、好不好被 agent 使用。
• 文件格式從「給人看」變成「給人＋機器一起看」：PDF／Word 不會完全消失，但一定要多一層 structured text 或 skill spec，讓 LLM 能安全地解讀。

從這一刻開始，沒有 skills 的服務，會自然往「被優先淘汰」那一邊滑去。

因為工程師在 Cursor、Claude、Gemini 裡面開發時，最自然的流程變成：

1. 問模型：「有沒有現成的金流／股市／CRM skill 可以用？」
2. 模型列出幾個 skill＋簡介。
3. 開始寫 code，完全不用自己翻官網文件。

沒有被整理成 skill 的服務，就等於 永遠不會出現在這份清單裡。

Recur、金流 Skills：早一步整理好的人，搶到什麼位置？

回到上面幾個實際例子，我覺得它們剛好代表了「早一步行動的人搶到的關鍵位置。

幾個我特別有感的點：

• Recur Skills：當競品還在貼「我們有 REST API 文件」時，它已經可以說「我們有一整套 LLM-ready skills，可以直接拿去用」。這在 BD pitch 裡優勢超大。
• 台灣第三方金流 Skills：原本各家金流的 PDF、Word 各自為政，現在多了一個「社群版一站式入口」。對想做金流聚合、訂閱服務的人來說，啟動成本瞬間下降。
• Google Gemini Skills：身為平台，它可以把上面這些東西收進一個統一的 Registry。只要你被收進去，就享有平台「預設推薦流量」。

簡單講：誰先把自己整理成 LLM Skills，誰就先在新的「推薦位」上卡位。

開發與 BD 的遊戲規則，正在一起被改寫

以前我們談 BD 或技術合作，重點會放在：

• 你們 API 功能多完整。
• 文件寫得夠不夠清楚。
• 有沒有 SDK、範例專案。

現在要多加幾條新的 checklist：

• 有沒有官方 skills 或 llm.txt 類型的文件？
• 是否有 MCP server、OpenAPI／JSON schema 等結構化描述？
• 在主流 IDE／Agent 生態系裡，能不能被「一鍵搜尋到」？

對團隊來說，這會改變很多日常工作的優先順序：

• 技術文件不再只是寫給人看的 Wiki，而要多一層「讓 LLM 可以安全調用的 spec」。
• 新功能上線時，不只是更新 API 路由，還要更新 skills、llm.txt、示範 prompt。
• BD 在談合作時，可以直接給對方一份 skills repo，請他們丟進自己的 agent 裡試跑。

我會預期，未來幾年內各家公司技術選型的討論裡，會多出一段：

• 「這家有官方 Gemini Skills／Claude Skills，串起來會快很多。」
• 「那家只有 PDF 文件，而且沒有 llm.txt，串起來風險太高。」

這些都會實際影響：你家的 API 會不會被選進別人的產品裡。

結論

LLM Skills 不是「多一份文件」，而是你把產品變成「AI 可以直接合作的夥伴」的關鍵一步。

從 Claude 提出 skills 概念，到 Recur、台灣第三方金流這些先跑的玩家，再到 Google Gemini 正式推出官方 Skills，我覺得訊號已經很明確：開發與 BD 的遊戲規則正在同步升級。

如果你的產品本來就仰賴 API 讓別人串接，現在很值得花時間想一件事：
「我要怎麼把這些能力包成一組好用的 skills，讓 LLM 可以自然地帶著開發者來用我？」

當下一輪生態系洗牌開始時，那些已經準備好 skills 的服務，很可能會被 LLM 自然地「帶路」，成為預設選項。

References

1. Recur Skills
2. 台灣第三方金流 Skills
3. Google Gemini Skills

關鍵字

Google Gemini Skills, Claude Skills, LLM Skills 生態系, API 文件地獄, 第三方金流串接, Recur Skills, 開發者體驗 DX, AI 技術文件, llm.txt, 技術選型