大家好，我是 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