Google Gemini團隊開源Agent Skills：讓Claude Code、Antigravity等“按規矩寫代碼”
整理版優先睇
Google 總監開源 Agent Skills，將 Google 頂尖工程紀律轉化為 AI 可執行的 20 個標準化工作流。
這篇文章介紹了由 Google 總監 Addy Osmani 發起的開源項目 agent-skills。作者觀察到 AI 編程助手雖然開發速度極快，但往往缺乏工程紀律，容易產生架構混亂、缺乏測試或忽略安全性的代碼。為了提升 AI 產出的質量，Addy 將 Google 內部的工程文化與實踐經驗，轉化為一套 AI 必須遵守的規範。
這套工具集不僅是簡單的 Prompt，而是涵蓋了從需求定義、開發、測試到發佈的完整生命週期。它旨在解決 AI 在編程時「只求能跑，不求質量」的痛點，讓 Claude Code、Cursor 等 AI 工具能像資深工程師一樣思考與運作。
整體的結論是：AI 的輸出質量取決於你賦予它的工程規範。透過這套 Skills，開發者可以將 AI 從一個單純的代碼生成器，提升為一個具備 Google 級別工程素養的虛擬隊友，確保代碼在快速迭代的同時，依然保持高標準的穩定性與安全性。
- 核心理念：將 Google 工程文化（如海勒姆定律、Beyoncé Rule）轉化為 AI 可執行的 20 個標準化技能，強調工程紀律大於生成速度。
- 規格驅動開發：強制執行「超過 30 分鐘的任務必須先寫 Spec」，明確定義 AI 的決策邊界，區分哪些操作需請示、哪些可自行決定。
- 測試與調試規範：引入「測試金字塔」比例與「停止生產線（Stop-the-Line）」原則，要求 AI 遇到阻塞性錯誤必須立即修復，而非繞道而行。
- 上下文工程：優化 AI 的信息獲取優先級，強調官方文檔優於訓練記憶，並透過 Chrome DevTools MCP 讓 AI 具備真實瀏覽器的調試能力。
- 代碼審查與安全：從正確性、可讀性、架構、安全及性能五個維度進行強制審查，嚴禁將密鑰提交至倉庫或將敏感數據寫入日誌。
agent-skills 開源項目
由 Google 總監 Addy Osmani 開源，包含 20 個技能文件、3 個專家角色及 7 個斜槓命令，支持 Claude Code、Cursor 等工具。
規格文檔 (Spec) 六個核心區域
包含目標、常用腳本、項目結構、代碼風格示範、測試策略及明確的 AI 決策邊界規則。
將 Google 工程靈魂注入 AI
這套 Skills 充滿了 Google 內部工程實踐的影子，將抽象的哲學原則具象化為 AI 的操作指令：
覆蓋全生命週期的 20 個技能點
項目將開發流程拆解為五個階段，確保 AI 在每個環節都有據可依：
定義階段 (Define)：利用 idea-refine 將模糊想法轉化為可行方案，並堅持規格驅動開發。
構建階段 (Build)：強調增量實現，防止 AI 一次改動過多代碼導致無法調試，並引入文檔驅動開發。
審查階段 (Review)：嚴格執行五個維度的代碼審查，確保安全性與性能達標。
修正 AI 的「美學偏見」
AI 在前端開發中常有一些「偷懶」或「過時」的默認行為，這套 Skills 明確要求 AI 避免這些陷阱：
| AI 默認行為 | 為什麼要避免 | 應該怎麼做 |
| :--- | :--- | :--- |
| 喜歡用過度飽和的紫色/藍色漸變 | 看起來像廉價的 SaaS 模板 | 使用品牌定義的調色盤或中性色調 |
| 默認使用 Lucide 圖標庫 | 缺乏品牌辨識度 | 優先使用項目指定的圖標系統 |
| 喜歡用極大的圓角 (Rounded-full) | 顯得不夠專業、太過卡通 | 遵循 4px/8px 的幾何規範 |
| 忽略 Loading 狀態 | 用戶體驗中斷 | 必須設計 Skeleton 或 Spinner |一鍵激活：7 個斜槓命令
在支持的 AI 工具（如 Claude Code）中，可以直接調用以下命令來觸發特定的工作流：
大家用 AI 寫 code 嗰陣應該都遇過呢種情況：
叫佢寫一個功能，佢好快就幫你生咗一大堆 code 出嚟，但係 test 又冇寫、安全又冇考慮、邊界情況（edge cases）又冇處理、架構仲要一塌糊塗，雖然行得通，亦都冇報錯。
呢個就係 AI 編程助手嘅特點：快、流暢，但係缺乏工程紀律。
最近，Google 總監 Addy Osmani（以前長期深耕 Chrome 團隊，而家負責 Gemini 同 Google Cloud 方向），為咗解決呢個問題，開源咗一個叫 agent-skills 嘅項目，呢個項目嘅目的係要令 AI 跟返 Google 工程師嘅標準嚟寫 code。
地址：github.com/addyosmani/agent-skills
呢個 Agent-Skills 集到底係啲咩？
一句話：一套令 AI 編程助手好似資深工程師咁思考嘅工作流手冊。
項目入面有 20 個 Skill（技能文件）、3 個專家角色、7 個斜槓命令（slash commands），覆蓋咗由寫需求到上線發佈嘅完整開發生命週期。
支援晒所有主流 AI 編程工具，例如 Claude Code、Cursor、Antigravity 等等。
點解話呢個係 Google 工程文化嘅產物？
呢套 Skills 入面充滿咗嚟自 Google 內部工程實踐嘅影子，幾個核心概念直接出自《Software Engineering at Google》呢本書：
海勒姆定律（Hyrum's Law），嚟自 Google 工程師 Hyrum Wright：
一旦 API 有足夠多嘅用戶，所有觀察得到嘅行為——包括 bug，都會有人依賴。
呢條定律直接影響咗 Skills 入面 API 設計同遷移嘅成套做法。
Beyoncé Rule，嚟自 Google 內部文化：
「如果你鍾意佢，就幫佢加返個測試。」
呢條原則喺測試驅動開發（TDD）嘅 Skill 入面被直接引用。
Chesterton's Fence，哲學原則，喺 Google 工程師之間廣泛流傳：
改 code 之前，先理解佢點解會存在。
呢條原則係防止 AI 亂咁刪 code。
呢套 Skills 嘅核心理念係：將高級工程師嘅決策過程，轉化做 AI 可以執行嘅工作流。
呢套 Skills 集同 Superpowers Skills 有咩唔同？
一句話，呢套 Skills 集係 AI 必須遵守嘅規範，Superpowers 係對 Agent 能力嘅擴展
兩者都有重疊，但係側重點唔同：
20 個 Skill 全解析
成個庫係跟住軟件開發嘅五個階段嚟組織：定義 → 計劃 → 構建 → 驗證 → 發佈。
DEFINE 階段：定義要做啲咩
Skill 1：idea-refine — 諗法精煉
場景：你有個好模糊嘅諗法，需要將佢變成清晰可行嘅方案。
Skill 2：spec-driven-development — 規格驅動開發
場景：任何超過 30 分鐘嘅開發任務，寫 code 之前都要先寫好規格文件（spec document）。
規格文件要包含嘅六個核心部分：
目標：做啲咩、點解要做、邊個用、成功標準係咩
常用 Script：項目嘅 build、test、start 等指令（例如 npm run build、npm test）
項目結構：source code、test cases、文件分別喺邊度
代碼風格：用真實嘅 code snippet 嚟示範，好過淨係用文字描述
測試策略：用咩 framework、coverage（覆蓋率）要求係點
邊界規則：講清楚 AI 喺咩情況下可以自己話事，咩情況下一定要問咗先
- 自己話事：行 test、跟返命名規範
- 問咗先做：改 database schema、加 dependency
- 絕對唔准做：commit 啲 secrets（密鑰）、刪除 fail 咗嘅 test
PLAN 階段：點樣構建
Skill 3：planning-and-task-breakdown — 規劃同任務分解
場景：將規格文件拆解成可以同時進行、做完之後有明確驗收標準嘅細任務。
每個細任務都要寫清楚：任務描述、3-5 條可以驗收嘅完成標準、驗證方法、前置依賴、涉及邊啲文件、工作量估算。
BUILD 階段：寫 code
Skill 4：incremental-implementation — 增量實現
場景：費事 AI 一口氣寫幾百行 code 之後 debug 唔到。
每完成一步，項目一定要可以正常 compile；只係改任務要求改嘅文件，唔好郁無關嘅 code；功能未做完但又要 merge 嗰陣，就用 Feature Flag 埋藏咗佢先。
Skill 5：test-driven-development — 測試驅動開發
場景：實現核心業務邏輯，或者 fix 啲有明確重現路徑嘅 Bug。
測試金字塔：80% unit test + 15% integration test（API + 測試 database）+ 5% E2E test（模擬真實用家完整操作流程）。
Skill 6：context-engineering — 上下文工程
場景：當 AI 開始亂噏、無視項目現有約定嗰陣，就要檢查下 context 嘅質量。
AI 輸出嘅質量，好大程度上取決於你俾佢嘅 context 質素。
資訊載入優先次序：
Skill 7：source-driven-development — 文檔驅動開發
場景：需要 framework 最新、最準確嘅寫法嗰陣。
要求 AI 唔可以憑訓練記憶嚟寫某個 framework 專有嘅 code，一定要查完官方文檔先至寫，仲要標註返文檔來源。可信來源優先次序：官方文檔 > 官方 blog 或更新日誌 > Web 標準。
Skill 8：frontend-ui-engineering — 前端 UI 工程
場景：構建或者修改用家界面。
呢個 Skill 有個特別有趣嘅表格，列出咗 AI 嘅「美學預設值」，同埋點解要避免用佢哋：
幾有意思嘅表格，列出咗 AI 嘅美學預設值，同埋點解要避開佢哋：
Skill 9：api-and-interface-design — API 同介面設計
場景：設計對外開放嘅介面，或者劃分 module 之間嘅職責邊界嗰陣。
三個核心原則：
海勒姆定律（Hyrum's Law）：就算你冇明確承諾過某個行為，只要用戶觀察到佢，就會有人開始依賴佢。API 設計要為穩定性負責。
單一版本原則：介面只做擴展，唔好另起新版本，唔好強迫用戶同時維護幾套介面。
協議優先：先定義好介面協議（protocol），再寫具體實作。
Skill 10：browser-testing-with-devtools — 瀏覽器測試
場景：debug 前端問題，驗證 UI fix 係咪真係有效。
透過 Chrome DevTools MCP，AI 可以直接連入瀏覽器，觀察頁面結構啱唔啱、console 有冇報錯、network request 有冇 fail、頁面 loading 性能有冇達標。
Skill 11：debugging-and-error-recovery — 除錯同問題修復
場景：測試失敗、build 唔到、行為唔符合預期。
核心原則係 Stop-the-Line Rule——遇到令項目行唔落去嘅錯誤嗰陣，要即刻停低修復，而唔係兜路行繼續夾硬推。呢條規則嚟自豐田生產線：流水線上任何一個工人發現質量問題，都有權叫停成條生產線。Google 將同樣嘅思路引入咗工程文化。
REVIEW 階段：合併前嘅質量審查
Skill 12：code-review-and-quality — 代碼審查
場景：任何 code 合併之前都一定要過呢關，冇例外。
五個維度嘅審查：
正確性：實作係咪同 spec 一致？edge cases 同異常輸入處理咗未？測試係咪真係驗證到正確嘅行為？
可讀性：命名清唔清晰？可以用 100 行寫清楚嘅嘢，寫咗 1000 行就係失敗。
架構：有冇跟隨現有嘅 code pattern？有冇引入 circular dependency？封裝（encapsulation）嘅粒度合唔合適？
安全性：用戶輸入做咗 validation 未？secret、密碼呢啲敏感資訊擺放得安全嗎？SQL query 有冇做防注入（anti-injection）處理？
性能：有冇 N+1 query 問題？返 list 數據嘅 API 有冇做 pagination？有冇唔必要嘅重複 render？
Skill 13：code-simplification — 代碼簡化
場景：功能正常、測試 pass，但啲 code 臃腫冗餘。
改 code 之前，先搞清楚兩件事：呢段 code 嘅作用係咩？當時點解咁寫？（性能考慮？平台限制？歷史遺留問題？）理解咗之後先郁手，而唔係憑感覺直接刪改。
Skill 14：security-and-hardening — 安全加固
場景：構建任何接受用戶輸入、涉及登入驗證或權限控制、處理敏感數據嘅功能。
以下呢啲嘢，一律禁止：將 secret、密碼等敏感資訊 commit 上 code repo；將敏感數據寫入 log；將 client-side 驗證當成安全邊界；將登入憑證擺喺瀏覽器嘅 localStorage 入面；將 server-side 嘅報錯 stack trace 直接返俾用戶。
Skill 15：performance-optimization — 性能優化
場景：Core Web Vitals（Google 網頁體驗核心指標）分數唔達標，或者有明顯嘅性能樽頸。
Core Web Vitals 目標值：
先測量，再修復，後驗證——冇數據支持嘅優化純粹係靠估。
SHIP 階段：有信心咁發佈
Skill 16-20：Git 工作流 / CI/CD / 舊功能下線遷移 / 架構決策記錄 / 上線發佈
發佈唔只係撳個 deploy 掣——呢五個 Skill 確保每一步都有據可查、可以 rollback、可以追溯。
7 個斜槓命令，一掣啟動工作流
喺 Claude Code 等 AI 編程工具入面，直接輸入命令就可以觸發相應嘅 Skills
寫喺最後
有咗呢套 AI 編碼工作流手冊，AI 就唔單止係幫你寫 code，更加係模擬緊一個工程師。你俾咩規範佢，佢就會成為一個點樣嘅工程師。
呢個就係 Addy Osmani 想傳遞嘅理念：我哋唔係要令 AI 更聰明，而係要俾 AI 工程紀律。
大家用AI寫代碼時應該都遇到過這種情況：
讓它寫一個功能，它很快就給你生成了一大堆代碼，但測試沒寫、安全沒考慮、邊界情況沒處理、架構一塌糊塗偏，但是能跑起來，也沒報錯。
這就是 AI 編程助手的特點：快速、流暢，但缺乏工程紀律。
最近，Google 總監 Addy Osmani（曾長期深耕 Chrome 團隊，現負責 Gemini 與 Google Cloud 方向），為了解決這個問題，開源了一個叫做 agent-skills 的項目，這個項目的目的是讓 AI 按照 Google 工程師的標準寫代碼。
地址：github.com/addyosmani/agent-skills
這個Agent-Skills 集到底是什麼？
一句話：一套讓 AI 編程助手像資深工程師一樣思考的工作流手冊。
項目裏有 20 個 Skill（技能文件）、3 個專家角色、7 個斜槓命令，覆蓋了從寫需求到上線發佈的完整開發生命週期。
支持所有主流 AI 編程工具，如Claude Code、Cursor、Antigravity等等。
為什麼說這是谷歌工程文化的產物？
這套 Skills 裏充滿了來自谷歌內部工程實踐的影子，幾個核心概念直接來自《Software Engineering at Google》這本書：
海勒姆定律（Hyrum's Law），來自 Google 工程師 Hyrum Wright：
一旦 API 有足夠多的用戶，所有可觀察的行為——包括 bug，都會被人依賴。
這條定律直接影響了 Skills 裏 API 設計和遷移的整套做法。
Beyoncé Rule，來自 Google 內部文化：
"如果你喜歡它，就給它加測試。"
這條原則在測試驅動開發 Skill 裏被直接引用。
Chesterton's Fence，哲學原則，在 Google 工程師裏廣泛流傳：
改代碼之前，先理解它為什麼存在。
這條原則防止 AI 莽撞地刪代碼。
這套 Skills 的核心理念是：把高級工程師的決策過程，轉化為 AI 可以執行的工作流。
這套Skills集和 Superpowers Skills 有什麼不同？
一句話，這套Skills集是AI必須遵守的規範，Superpowers 是對Agent能力的擴展
兩者也有重疊，但側重點不同：
20 個 Skill 全解析
整個庫按軟件開發的五個階段組織：定義 → 計劃 → 構建 → 驗證 → 發佈。
DEFINE 階段：定義要做什麼
Skill 1：idea-refine — 想法精煉
場景：你有一個模糊的想法，需要把它變成清晰可行的方案。
Skill 2：spec-driven-development — 規格驅動開發
場景：任何超過 30 分鐘的開發任務，編碼前先寫規格文檔。
規格文檔要包含的六個核心區域：
目標：做什麼、為什麼、誰用、成功標準是什麼
常用腳本：項目的構建、測試、啓動等命令（如 npm run build、npm test）
項目結構：源碼、測試用例、文檔各在哪
代碼風格：用真實代碼片段示範，比文字描述更清晰
測試策略：用什麼框架、覆蓋率要求
邊界規則：明確 AI 在什麼情況下可以自行決定，什麼情況下必須先確認
- 自行決定：運行測試、遵循命名規範
- 先問再做：改數據庫 Schema、添加依賴
- 永遠不做：提交 secrets、刪除失敗的測試
PLAN 階段：如何構建
Skill 3：planning-and-task-breakdown — 規劃和任務分解
場景：把規格文檔拆解成可以同時推進、完成後能明確驗收的子任務。
每個子任務都要寫清楚：任務描述、3-5 條可驗收的完成標準、驗證方式、前置依賴、涉及哪些文件、工作量估算。
BUILD 階段：寫代碼
Skill 4：incremental-implementation — 增量實現
場景：防止 AI 一口氣寫幾百行後無法調試。
每完成一步，項目必須能正常編譯；只改任務要求改的文件，不動無關代碼；功能還沒做完就需要合併時，用 Feature Flag 把它隱藏起來。
Skill 5：test-driven-development — 測試驅動開發
場景：實現核心業務邏輯，或修復有明確復現路徑的 Bug
測試金字塔：80% 單元測試+ 15% 集成測試（API + 測試數據庫）+ 5% E2E 測試（模擬真實用戶完整操作流程）。
Skill 6：context-engineering — 上下文工程
場景：AI 開始編造內容、無視項目已有約定時，檢查上下文質量。
AI 輸出質量很大程度取決於你給它的上下文質量。
信息加載優先級：
Skill 7：source-driven-development — 文檔驅動開發
場景：需要框架最新、最準確的寫法時。
要求 AI 不能憑訓練記憶實現某個框架專有的寫法，必須查閲官方文檔後再實現，並標註文檔來源。可信來源優先級：官方文檔 > 官方博客或更新日誌 > Web 標準。
Skill 8：frontend-ui-engineering — 前端 UI 工程
場景：構建或修改用戶界面。
這個 Skill 有一個特別有意思的表格，列出了AI 的美學默認值，及為什麼要避免：
別有意思的表格，列出了AI 的美學默認值，及為什麼要避免：
Skill 9：api-and-interface-design — API 與接口設計
場景：設計對外暴露的接口，或劃定模塊之間的職責邊界時。
三個核心原則：
海勒姆定律：就算你沒有明確承諾某個行為，只要用戶能觀察到它，就會有人開始依賴它。API 設計要為穩定性負責。
單一版本原則：接口只做擴展，不另起新版本，不要強迫用戶同時維護多套接口。
協議優先：先定義好接口協議，再寫具體實現。
Skill 10：browser-testing-with-devtools — 瀏覽器測試
場景：調試前端問題，驗證 UI 修復是否真的有效。
通過 Chrome DevTools MCP，AI 可以直接接入瀏覽器，觀察頁面結構是否正確、控制枱有沒有報錯、網絡請求有沒有失敗、頁面加載性能是否達標。
Skill 11：debugging-and-error-recovery — 調試與問題修復
場景：測試失敗、構建出錯、行為不符合預期。
核心原則是 Stop-the-Line Rule——遇到讓項目無法繼續推進的錯誤時，立即停下來修復，而不是繞過它繼續推進。這條規則來自豐田生產線：流水線上任何一個工人發現質量問題，都有權叫停整條生產線。谷歌把同樣的思路引入了工程文化。
REVIEW 階段：合併前的質量審查
Skill 12：code-review-and-quality — 代碼審查
場景：任何代碼合併前都必須過這一關，沒有例外。
五個維度的審查：
正確性：實現是否和規格文檔一致？異常輸入和極端情況處理了嗎？測試是否真的驗證了正確的行為？
可讀性：命名清晰嗎？能用 100 行寫清楚的東西，寫了 1000 行是失敗。
架構：是否遵循了現有的代碼模式？有沒有引入循環依賴？封裝的粒度合適嗎？
安全性：用戶輸入做了校驗嗎？密鑰、密碼等敏感信息存放安全嗎？SQL 查詢有沒有做防注入處理？
性能：有沒有 N+1 查詢問題？返回列表數據的接口有沒有做分頁？有沒有不必要的重複渲染？
Skill 13：code-simplification — 代碼簡化
場景：功能正常、測試通過，但代碼臃腫冗餘。
改代碼之前，先搞清楚兩件事：這段代碼的作用是什麼？當時為什麼這麼寫？（性能考慮？平台限制？歷史遺留問題？）理解之後再動手，而不是憑感覺直接刪改。
Skill 14：security-and-hardening — 安全加固
場景：構建任何接受用戶輸入、涉及登錄驗證或權限控制、處理敏感數據的功能。
以下這些事，一律禁止：把密鑰、密碼等敏感信息提交到代碼倉庫；把敏感數據寫進日誌；把客戶端驗證當作安全邊界；把登錄憑證存在瀏覽器本地存儲（localStorage）裏；把服務端的報錯堆棧直接返回給用戶。
Skill 15：performance-optimization — 性能優化
場景：Core Web Vitals（谷歌網頁體驗核心指標） 分數不達標，或者有明顯性能瓶頸。
Core Web Vitals 目標值：
先測量，再修復，再驗證——沒有數據支撐的優化只是猜測。
SHIP 階段：有信心地發佈
Skill 16-20：Git 工作流 / CI/CD / 舊功能下線遷移 / 架構決策記錄 / 上線發佈
發佈不只是點擊部署按鈕——這五個 Skill 確保每一步都有據可查、可回滾、可追溯。
7 個斜槓命令，一鍵激活工作流
在 在 Claude Code 等 AI 編程工具裏，直接輸入命令即可觸發相應的Skills
寫在最後
有了這套AI編碼工作流手冊，AI 就不僅僅是在幫你寫代碼，更是在模擬一個工程師。你給它什麼樣的規範，它就會成為什麼樣的工程師。
這就是 Addy Osmani 想傳遞的理念：我們不是在讓 AI 更聰明，而是在給 AI 工程紀律。