把時間拉回到大模型剛開始會寫程式的那陣子。你叫它幫你接 Google Cloud，它寫得飛快，語法也漂亮，你複製貼上，跑——炸了。它用了一個半年前就被標 deprecated 的 google-cloud-aiplatform SDK，順手還給你掰了一個根本不存在的 model 名稱。

這個場景，從那時候到現在，幾乎沒怎麼變過。換了幾代模型，分數一代比一代高，但你叫它接雲端 API，它還是有不小機率給你一段「看起來對、跑起來錯」的程式碼。問題不在它笨。問題在一個更結構性的地方：它的記憶有個截止日，而雲端產品沒有。

一個追不上的時間差

想清楚這件事，得先承認一個落差。

一個 AI 模型的知識，是在某個時間點凍結的。它訓練完那一刻，腦袋裡的 Google Cloud 就停在那個版本——那時候的 SDK、那時候的 model 名稱、那時候的最佳實踐。然後它被部署出來，開始服務你好幾個月、甚至一年。

而這段期間，Google Cloud 那邊在幹嘛？Gemini 的 model 名稱每幾個月換一輪，SDK 大改版，認證方式推陳出新，昨天的 golden path 今天就被標成不建議。雲端產品是活的，它每天都在往前走。

於是你得到一個很尷尬的結構：一邊是凍結的記憶，一邊是流動的現實，中間那條縫每過一天就裂得更開一點。模型越強，這條縫反而越騙人——因為它錯得越來越有自信，語法越來越像真的，你越來越難一眼看出哪裡過期了。

以前，大家是這樣湊合的

縫擺在那裡，總得有人去填。回頭看這兩年，工程師填這條縫的方法大概演化過三代。

第一代最土法煉鋼：人腦記。你自己知道 aiplatform 已經不用了，所以 AI 一寫出來你就手動換成 google-genai。問題是這把整件事的價值砍掉一半——你請 AI 來是想少記點瑣事，結果變成你得比 AI 更熟才能幫它擦屁股。

第二代是貼文件。每次要它寫雲端程式碼之前，先去官網把最新的 quickstart 整段複製，塞進對話框，跟它說「照這個寫」。有效，但累，而且每個專案、每次對話都要重貼一遍。你等於每天都在手動同步那條時間差。

第三代開始有人寫 CLAUDE.md、寫 rules 檔，把「這個專案要用哪個 SDK、哪個 model」固定下來。這已經很接近答案了，但每個人各寫各的，你維護你的、我維護我的，沒有一份是 Google 官方背書、跟著產品更新的。本質上還是各自在跟那條縫搏鬥。

講到這你會發現，三代方法都在做同一件事：把最新的正確知識，想辦法塞進 AI 執行當下的視野裡。 差別只在塞得多手動、多累、多容易過期。

轉捩點：把知識本身標準化

真正的轉折，是有人決定不再各自塞，而是把「該塞什麼」這件事做成一個標準。

Google 在 2026 年 4 月開源了一個叫 Skills 的 repo。它最反直覺的地方是：這東西不是 SDK、不是框架、甚至沒幾行可執行的程式碼。它就是一疊 Markdown 檔案。

每個檔案叫 SKILL.md，最上面一段 YAML frontmatter 寫 metadata——這個 skill 叫什麼、什麼情況該用、相容哪些 agent。AI agent 讀到這段，就知道「喔，使用者現在要碰 BigQuery，我該把這份指引調出來看」。底下則是經過 Google 內部驗證的操作指引：用哪個 SDK、選哪個 model、怎麼認證、function calling 的最新格式長怎樣。

它走的是一個叫 Agent Skills 的開放標準，Claude Code、Gemini CLI、Cursor 都吃得下。換句話說，這不是 Google 自己關起門搞的格式，而是一份大家都讀得懂的共通語言。

這裡藏了一個很值得停下來想的設計。為什麼是 Markdown，而不是一個更「正式」的 API 或外掛？因為對一個會讀文件的 AI 來說，Markdown 就是它最自然的介面。你不需要教它怎麼呼叫一個新工具，你只要把知識寫成它本來就讀得懂的樣子，放在它伸手就拿得到的地方。最簡單的形式，往往就是最對的形式。

一份不想塞爆你 context 的設計

光把知識寫對還不夠，還得解決一個老問題：知識一多，context window 就被吃光。

Skills 的處理方式是分層。SKILL.md 只放入口——快速上手加一份參考目錄，細節全部丟到 references/ 底下。AI agent 平常只讀入口那薄薄一層，真的需要某個細節時，才順著目錄把對應的文件抓進來。

這個分層不是為了好看。它直接對應到一個現實取捨：你希望 agent 隨時知道「有這份知識可以用」，又不希望它每次都把整本手冊背進腦子裡占位子。所以入口要輕到可以一直掛著，細節要能按需載入。像 GKE 那種設定選項多到爆炸的產品，gke-basics 底下就掛了 networking、security、scaling、cost、observability 二十幾份子文件——全塞進來會直接撐爆 context，分層之後 agent 要看哪份才抓哪份。

目前 repo 裡的 skill 全在 skills/cloud/ 底下，大致三類：產品基礎類（Gemini API、BigQuery、Cloud Run、GKE 這些單一產品的完整指南）、跨產品 recipe 類（新手上路、認證授權這種會橫跨好幾個服務的流程），還有 Well-Architected Framework 類（安全、可靠性、成本三支柱的架構評估，每支柱附一份結構化問卷，不是隨便講講）。

裝起來，跟用起來

安裝只有一條官方路徑，透過 npx skills CLI：

1
npx skills add google/skills

跑完跳一個互動選單，讓你勾要裝哪幾個。本質上就是把對應的 SKILL.md 和 references/ 下載到你的專案，放在 agent 讀得到的地方。你嫌麻煩也可以直接 clone 整個 repo，手動把需要的資料夾複製進 .claude/。

裝完之後，最舒服的一點是：你什麼都不用多做。下次你跟 agent 說「用 Gemini 3 Flash 幫我做個圖片分析功能」，它會自己把 gemini-api 的 SKILL.md 調出來，然後用對的 google-genai SDK、選還沒被 deprecated 的 model、照最新格式寫 function calling。那些瑣碎的版本更新，從你的腦袋移到了 skill 裡。

幾個最有感的場景：Gemini API 開發大概是回報率最高的，因為它的 model 名稱和 SDK 變動最頻繁，沒這個 skill 的 agent 特別容易給你過時範例；GKE 規劃會自動套 Autopilot 的安全預設（private nodes、Workload Identity），偏離最佳實踐時還會跟你說明 trade-off；網路排查則會自動選對 log source，產出能直接跑的 SQL 去撈 VPC Flow Logs。

但別把它當銀彈

有幾件事得先講清楚，不然你會踩到。

最大的限制是：它不收外部 PR。 所有 skill 都得走 Google 內部驗證，你只能提 issue 報問題或建議新 skill，不能自己改。這是雙面刃——好處是內容有人背書，壞處是更新節奏完全捏在 Google 手上。

然後，skill 裡的 model 名稱本身也會過期。像 gemini-3.1-pro-preview 這種，會跟著 Google 的發布節奏變動。它沒有 releases、沒有 tags，只靠 main branch 更新——也就是說，它縮短了那條時間差，但沒有真的把縫補死。它買到的是「比 AI 訓練資料新」，不是「永遠最新」。覆蓋範圍也還很窄，目前只有 Google Cloud，Android、Maps、Workspace 都還沒有；裝它要有 Node.js 環境；連 README 都還有幾個指向舊結構的壞連結（issue #30 已報，還沒修）。

所以它治本了嗎？算治了一半。它把「填那條時間差」這件事，從每個工程師私下手動做的雜活，變成一份公開、標準化、有人維護的東西。但它沒有、也不可能讓那條縫永遠歸零——只要記憶會凍結而產品會更新，這條縫就會一直存在，差別只在誰來填、填得多即時。

一個會擴散出去的形狀

把這件事的格局拉開一點看，會發現重點根本不在 Google Cloud。

真正在發生的事情是：當 AI 變成寫程式的主力，知識的價值正在從「藏在誰腦子裡」轉移到「能不能在 agent 動手那一刻，被準確地遞到它眼前」。Skills 押的就是這個賭注——把領域知識寫成 agent 讀得懂的標準格式，放在它伸手可及的地方。Firebase 已經有自己的一套 agent-skills，幾乎每個 skill 都附了 MCP server 的整合指引。這個形狀會擴散。

下一個問題不是「Google 會不會幫每個產品都寫一份」，而是：當每個雲端、每個框架、每套 SDK 都開始附一疊自己的 SKILL.md，誰來幫你決定，哪幾份該掛進你 agent 的視野裡、哪幾份只會互相打架？那時候，稀缺的就不再是知識本身了。

參考來源：google/skills - GitHub、Agent Skills 開放標準