谷歌工程師開源，超強 Skills 讓AI編程從原型走向生產級

大家好，我是 Ai 學習的老章

你有沒有這種感覺——用 AI 寫代碼速度飛快，但寫出來的東西總像"能跑就行"的原型？測試沒寫、安全沒考慮、代碼 Review 形同虛設，跟真正上生產的代碼差了十萬八千里

今天介紹一個讓我眼前一亮的項目——Agent Skills，來自 Google Chrome 工程經理 Addy Osmani，5.5 萬星，一句話總結：把資深工程師的工作紀律，打包成 AI Agent 可以執行的結構化工作流

Addy's Agent Skills 簡介

Agent Skills 要解決的問題很直接：AI 編程 Agent 默認走最短路徑——跳過規格說明、跳過測試、跳過安全審查、跳過代碼 Review。這些正好是讓軟件從"能跑"變成"能用"的關鍵環節

這個項目把整個軟件開發生命周期拆成了 6 個階段，覆蓋了從需求定義到生產部署的完整鏈路：

DEFINE          PLAN           BUILD          VERIFY         REVIEW          SHIP
┌──────┐      ┌──────┐      ┌──────┐      ┌──────┐      ┌──────┐      ┌──────┐
│ Idea │ ───? │ Spec │ ───? │ Code │ ───? │ Test │ ───? │  QA  │ ───? │  Go  │
│Refine│      │  PRD │      │ Impl │      │Debug │      │ Gate │      │ Live │
└──────┘      └──────┘      └──────┘      └──────┘      └──────┘      └──────┘
/spec          /plan          /build        /test         /review       /ship

核心功能與特點：

• 24 個結構化 Skill ：不是籠統的 prompt，每個 Skill 都是有步驟、有檢查點、有退出標準的完整工作流。從需求訪談（interview-me）到部署上線（shipping-and-launch）全覆蓋

• 反合理化機制（Anti-rationalization） ：這是我最欣賞的設計——每個 Skill 都內置了一張"借口 vs 反駁"對照表。Agent 想偷懶說"測試后面再補"？直接被堵死。相當于給 AI 裝了個"良心"

• 7 個斜杠命令 ：一鍵觸發對應階段的工作流，/spec 寫規格、/plan 拆任務、/build 寫代碼、/test 跑測試、/review 代碼審查、/ship 上線部署

• 4 個專家人設（Agent Personas） ：高級 Staff 工程師做代碼審查、QA 專家做測試策略、安全工程師做漏洞掃描、性能工程師做 Web Vitals 審計

• 兼容幾乎所有主流 AI 編程工具 ：Claude Code（推薦）、Cursor、Gemini CLI、Windsurf、GitHub Copilot、Kiro IDE、Antigravity CLI——只要你的 Agent 能讀 Markdown，就能用

說實話，AI 編程領域的 prompt 工程項目我見過太多了，但 Agent Skills 有幾個讓我覺得"這玩意兒是真懂工程"的地方：

1. 來自 Google 工程文化的硬核實踐

這不是拍腦門寫的最佳實踐。項目明確引用了《Software Engineering at Google》和 Google 工程實踐指南里的核心概念：

• Hyrum's Law 在 API 設計里

• Beyonce Rule 和測試金字塔在測試策略里

• Chesterton's Fence 在代碼簡化里

• Trunk-based Development 在 Git 工作流里

• Shift Left 和 Feature Flag 在 CI/CD 里

這些不是抽象原則，而是直接嵌在 Agent 的每一步操作中

2. "懷疑驅動開發"——對 AI 自信的糾偏

這是我覺得最有創意的一個 Skill：doubt-driven-development

核心邏輯是：AI 給出的"自信答案"不等于"正確答案"。長時間對話會讓假設悄悄變成"事實"。這個 Skill 強制要求在關鍵決策點召喚一個"對立面審查者"——專門來挑刺的

流程是這樣的：

Doubt cycle:
- [ ] Step 1: CLAIM — 寫明你的決策 + 為什么重要
- [ ] Step 2: EXTRACT — 剝離推理過程，只留結論
- [ ] Step 3: DOUBT — 召喚全新上下文的審查者，帶對抗性提示
- [ ] Step 4: RECONCILE — 逐條核實每個發現
- [ ] Step 5: STOP — 滿足終止條件才放行

什么時候用？當決策涉及生產環境、安全邏輯、不可逆操作，或者你對不熟悉的代碼"感覺沒問題"的時候——恰恰是最需要懷疑的時候

3. Context Engineering——給 Agent "喂"對信息

另一個我特別認同的 Skill。上下文就是 Agent 輸出質量的最大杠桿：太少就幻覺，太多就失焦

它設計了一個 5 層上下文層級：

┌─────────────────────────────────────┐
│  1. Rules Files (CLAUDE.md等)       │ ← 始終加載，項目全局
├─────────────────────────────────────┤
│  2. Spec / Architecture Docs        │ ← 按功能/會話加載
├─────────────────────────────────────┤
│  3. Relevant Source Files            │ ← 按任務加載
├─────────────────────────────────────┤
│  4. Error Output / Test Results      │ ← 按迭代加載
├─────────────────────────────────────┤
│  5. Conversation History             │ ← 持續累積、定期壓縮
└─────────────────────────────────────┘

最持久的信息放頂層（比如技術棧、代碼規范），最臨時的放底層（比如報錯信息）。這個分層思維，做 AI 編程的都該記住

24 個 Skill 全景圖

階段

Skill

干什么

Define

interview-me

一問一答挖需求，直到 95% 確信才停

Define

idea-refine

發散→收斂，把模糊想法變成具體方案

Define

spec-driven-development

寫 PRD，覆蓋目標、命令、結構、測試

Plan

planning-and-task-breakdown

把規格拆成小任務，帶驗收標準和依賴排序

Build

incremental-implementation

薄切片開發：實現→測試→驗證→提交

Build

test-driven-development

紅→綠→重構，金字塔比例 80/15/5

Build

context-engineering

給 Agent 喂對的信息

Build

source-driven-development

每個決策都要有官方文檔出處

Build

doubt-driven-development

對抗性審查：CLAIM→DOUBT→RECONCILE

Build

frontend-ui-engineering

組件架構、設計系統、WCAG 2.1 AA

Build

api-and-interface-design

Contract-first、Hyrum's Law、邊界校驗

Verify

browser-testing-with-devtools

Chrome DevTools MCP 實時調試

Verify

debugging-and-error-recovery

五步分診：復現→定位→縮小→修復→防護

Review

code-review-and-quality

五軸審查、~100 行變更、嚴重級別標簽

Review

code-simplification

Chesterton's Fence、Rule of 500

Review

security-and-hardening

OWASP Top 10、密鑰管理、三層邊界

Review

performance-optimization

先測量再優化、Core Web Vitals

Ship

git-workflow-and-versioning

Trunk-based、原子提交、commit-as-save

Ship

ci-cd-and-automation

Shift Left、Feature Flag、質量門

Ship

deprecation-and-migration

Code-as-liability 思維、僵尸代碼清理

Ship

documentation-and-adrs

ADR 架構決策記錄、記錄"為什么"

Ship

observability-and-instrumentation

結構化日志、RED 指標、OpenTelemetry

Ship

shipping-and-launch

發布清單、灰度發布、回滾方案

Meta

using-agent-skills

元技能：路由到正確的 Skill

安裝

Claude Code 用戶（推薦）直接 Marketplace 安裝：

/plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills

本地開發方式：

git clone https://github.com/addyosmani/agent-skills.git
claude --plugin-dir /path/to/agent-skills

Gemini CLI 用戶：

gemini skills install https://github.com/addyosmani/agent-skills.git --path skills

Cursor 用戶直接把 SKILL.md 復制到 .cursor/rules/ 就行。其他工具（Windsurf、Copilot、Kiro、Codex）都有對應的接入文檔

其實本質上，Skills 就是純 Markdown 文件——任何能接受系統提示詞或指令文件的 Agent 都能用

Skill 的結構設計

每個 Skill 都遵循統一的"解剖結構"：

SKILL.md
├── Frontmatter        → name + description（Agent 自動發現的觸發條件）
├── Overview           → 這個 Skill 干什么
├── When to Use        → 什么時候該觸發
├── Core Process       → 一步步怎么做（核心！）
├── Rationalizations   → 借口 + 反駁表（防偷懶！）
├── Red Flags          → 哪些跡象說明做錯了
└── Verification       → 退出標準：拿證據說話

四個關鍵設計決策我給滿分：

• Process not Prose ：是流程，不是文檔。有步驟、有檢查點、有退出標準

• Anti-rationalization ：每個可能被跳過的步驟都有對應的"防偷懶"條目。這招太聰明了——直接堵死 AI"等會兒再補"的退路

• Verification non-negotiable ：每個 Skill 最后都要求"用證據說話"。測試通過了？構建成功了？截圖呢？"感覺沒問題"不算數

• Progressive disclosure ：SKILL.md 是入口，補充材料按需加載，不浪費 token

這是個殺手級功能：當 Spec 寫好之后，輸入 /build auto，Agent 會自動生成計劃、逐個任務執行，每個任務依然走 TDD 流程、單獨提交。你只需要批準一次計劃，后面全自動

去掉的是人在任務之間的"點擊下一步"，保留的是每個任務內部的驗證紀律。在失敗或高風險步驟時自動暫停。既快又穩

我的看法

優點：

• 這是目前最系統化的 AI 編程工程規范項目，沒有之一

• 作者 Addy Osmani 在 Google 做了十幾年工程，這些 Skill 背后有真實的工程判斷

• "反合理化表"的設計堪稱天才——AI 最大的問題就是太"聽話"，給它裝個批判性思維模塊剛剛好

• 覆蓋全生命周期，從需求到上線一條龍

• 純 Markdown 實現，零依賴，任何 Agent 都能用

局限：

• 24 個 Skill 一次性全加載會占大量上下文窗口，需要按需加載

• 主要面向 Web 開發場景（前端 + Node.js 后端），其他技術棧可能需要自行擴展

• 目前英文內容為主，中文開發者需要一定的英文閱讀能力

• 對于快速原型場景可能顯得太"重"——不是每個項目都需要走完整套流程

適合誰用：

• 正在用 AI Agent 做生產級項目的開發者

• 希望規范化團隊 AI 編程實踐的技術 Lead

• 想從"能跑就行"升級到"生產就緒"的個人開發者

• 對 AI 編程 Skill 設計有興趣的工程師——想自己寫 Skill 的話，這套格式規范可以直接抄

Agent Skills 解決了 AI 編程領域一個核心矛盾：AI 追求速度，工程追求可靠。通過把高級工程師的工作紀律編碼成結構化工作流，它讓 AI Agent 在保持速度優勢的同時，不再跳過那些"看起來可以省略但實際上不能省"的關鍵步驟

如果你正在認真用 AI 寫生產代碼，這個項目值得花時間研究。最少加載三個核心 Skill 就能覆蓋最關鍵的質量缺口：spec-driven-development + test-driven-development + code-review-and-quality