别再让 AI 写代码了！Addy Osmani 这套生产级 Skills 强制走完整工程流程
配套媒体
本页对应的 PPT 与演示视频
下载没反应？点这里复制直链
侧边栏预览窗口（Electron webview）会拦截下载，把下面的链接复制到 Chrome / Edge 地址栏打开即可保存。
../../agent-skills-recommend.pptx../../agent-skills-recommend.mp4本文目录
别再让 AI 写代码了！Addy Osmani 这套生产级 Skills 强制走完整工程流程
核心价值：Chrome 工程副总裁把 Google 那套资深工程师纪律编译成 24 个 AI 可执行的工作流，AI 写代码终于不能跳过 spec、测试和 code review 了。
你有没有过这种翻车现场？
让 Claude Code「帮我加一个用户导出功能」，Agent 噼里啪啦 30 秒写完，潇洒地说 "Done!"。你打开 diff 一看：导出格式没考虑旧版本兼容、没写测试、没做权限边界、提交一个 diff 200 行没人 review——它甚至还会跟你说「我稍后补测试」。
这不是 AI 工具的 Bug，这是设计优先级的问题：AI 的优化目标是「功能正确」，而不是「工程健康」。
在 AI 看来，一个能跑但没测试、提交混乱、没文档的项目，和一个测试完整、提交规范、文档齐全的项目，在"能否完成任务"这个维度上没区别。但对一个真实团队来说，这种"省掉"的工程步骤，会形成系统性质量塌陷。
addyosmani/agent-skills —— Google Chrome 团队的工程主管 Addy Osmani 开源的 AI 编码工程纪律集 —— 就是来解决这个问题的。
今天 GitHub 上线不到半年，已经拿到 70,000+ Star，GitHub Trending 霸榜多日，每天新增 7,000+ Star。
🔥 它到底是什么？
Agent Skills 不是新 IDE，也不是新模型，它更像是给 AI 编码助手准备的一套**「工程作业指导书」**。
每个 Skill 是一个带 YAML frontmatter 的 Markdown 文件，里面告诉 AI：
| Skill 元素 | 内容 |
|---|---|
| When to Use | 触发条件和具体场景 |
| Process | 步骤 1 → 步骤 2 → 步骤 3 ... |
| Examples | 代码示例和模式 |
| Rationalizations | Agent 借口 + 反驳论据 |
| Red Flags | 警告信号 |
| Verification | 证据要求（必须通过什么才能结束） |
听起来像 Prompt 模板？不一样。Skill 把任务拆成检查点，例如性能优化 Skill 是：先建基线 → 再定位瓶颈 → 再提改动 → 再验证收益 → 再写回滚策略。「看起来差不多」不能结案，必须有运行数据才算。
🧩 24 个 Skill 覆盖完整生命周期
Agent Skills 把 24 个核心 Skill 映射到软件开发的 6 个阶段：Define → Plan → Build → Verify → Review → Ship。
每个阶段的 Skill 解决一类典型问题：
- Define（定义）：
idea-refine发散收敛模糊需求；spec-driven-development强制 Agent 先出 PRD，列出它正在做的所有假设，让你纠正。「先 15 分钟讲清楚 spec，胜过事后 15 小时 debug」。 - Plan（计划）：
planning-and-task-breakdown把 feature 拆成一个个可独立验证的薄切片（thin vertical slice），而不是一口气 1000 行。 - Build（构建）：
incremental-implementation一次只做一个切片；api-and-interface-design贯彻 Hyrum 定律——"任何可观测的 API 行为都会被人依赖"；test-driven-development强制红绿重构循环；browser-testing-with-devtools集成 Chrome DevTools MCP。 - Verify（验证）：调试时的 Prove-It Pattern——必须先写一个能复现 bug 的失败测试，再去修。
- Review（评审）：五维度 code review 框架、
code-simplification（带 Chesterton's Fence 原则——不要拆掉你不知道为什么存在的栅栏）、安全和性能审计。 - Ship（交付）：trunk-based development、CI/CD、feature flag、文档与 ADR、专门的废弃迁移流程。
每个 Skill 文件的统一解剖结构：
---
name: skill-name
description: 指导 AI 完成[任务]。当[某些条件]时使用。
---
# Overview → 这个 Skill 做什么
## When to Use → 触发条件和场景
## Process → 步骤 1、步骤 2、步骤 3 ...
## Examples → 代码示例
## Rationalizations → 借口表 + 反驳 ← 最有特色的部分
## Red Flags → 警告信号
## Verification → 退出标准 checklist
其中最有意思的是 Common Rationalizations（常见借口）——这是整套 Skill 设计最独特的地方。
🛡️ 这个项目最聪明的设计：Anti-Rationalization（反合理化表）
每个 Skill 文件里都有一节叫「Common Rationalizations」——也就是 Agent 用来跳过重要步骤时常说的借口，每一条配一个反驳。
举几个真实例子（来自 test-driven-development/SKILL.md）：
| Agent 的借口 | Skill 里写的反驳 |
|---|---|
| 「这次很简单，先不写 spec 了」 | 简单任务确实不需要长 spec，但仍然需要验收标准。两行 spec 也是 spec。 |
| 「原型代码先不写测试，回头补」 | 原型会变成生产代码。Day 1 就写测试，避免后期"测试债危机"。 |
| 「我先静默选一个解释往下走」 | 不要做 yes-machine。遇到模糊点要 STOP，把困惑说出来再继续。 |
| 「再跑一次测试以防万一」 | 测试通过后，没改代码再跑毫无意义。改完再跑，不要靠重复运行获得心理安慰。 |
| 「代码是自解释的，不用测了」 | 测试就是规范，它们说明代码应该做什么，不是说明它实际做了什么。 |
这种设计的精妙之处在于：它对抗的不是知识缺乏，而是行为漂移。
一个前沿模型在训练数据里读过 Hyrum 定律，但它在凌晨 3 点设计你的 API 时不会应用它。Anti-Rationalization 的存在，就是让模型在准备开溜时，能撞上一面写着「不行，你说过这话，但是……」的墙。
Addy 在自己的博客里说，这个模式即使不用 AI，团队里也值得借鉴：把团队常说的自欺欺人的话写下来，配上反驳。"我们 launch 后再修测试"——错，因为 launch 后没人会回来修。
🏛️ 三层架构：Skill / Persona / Slash Command
理解这套系统还需要分清它的三层架构：
- Skills（怎么做）：带步骤和退出条件的工作流，是必经之路。
- Personas（谁来做）：带视角和输出格式的角色——
code-reviewer（高级工程视角）、security-auditor（OWASP 风格审查）、test-engineer（QA 专家，覆盖率分析）。 - Slash Commands（什么时机）：用户层入口，是真正的编排者。
最经典的组合是 /ship —— 它会并行扇出到三个 persona，分别独立审查代码，最后由主 agent 合成一份 go/no-go 决策报告。Addy 在文档里特别强调，这是该 repo 唯一推荐的多 persona 编排模式：不要建造 router persona，编排是 slash command 的工作。
🎯 8 条斜杠命令，自然语言激活
Agent Skills 为 Claude Code 和 Gemini CLI 提供了 8 条斜杠命令，每条命令自动激活对应的 Skill 包：
/spec # 激活 spec-driven-development（先出 PRD）
/plan # 激活 planning-and-task-breakdown（拆成可验收小任务）
/build # 激活 incremental-implementation + 相关领域 Skill
/test # 激活 test-driven-development（红绿重构）
/review # 激活 code-review-and-quality（五轴 Review）
/code-simplify # 激活 code-simplification（Chesterton's Fence）
/webperf # 激活 performance-optimization（Core Web Vitals）
/ship # 激活 shipping-and-launch + 并行 3 persona 审查
这意味着 Claude Code 用户只需要说「帮我用 /spec 的方式来规划这个功能」，AI 就会自动激活结构化需求分析流程——目标定义、边界划分、验收标准制定，完整步骤。
不是聊天框里「我会注意的」，而是 Agent 加载 Skill 后按步骤走，每步末尾有 Verification，「看起来对」不算数。
🌐 跨 8+ AI 编程平台，一个 Skills 多处用
Agent Skills 的野心不止 Claude Code。它通过纯 Markdown + frontmatter 设计 + npx skills CLI 安装，支持以下平台：
| 平台 | 安装方式 | 备注 |
|---|---|---|
| Claude Code | /plugin marketplace add addyosmani/agent-skills |
原生 8 条斜杠命令 |
| Cursor | 复制 SKILL.md 到 .cursor/rules/ |
支持 Rule Type: Agent Decides |
| Gemini CLI | gemini skills install ... --path skills |
原生 skills 命令 |
| Antigravity | 仓库自带 plugin.json |
一键激活 |
| OpenCode | symlink 到 .opencode/ |
完整兼容 |
| Windsurf | rules 配置 | 支持 |
| GitHub Copilot | system prompt 注入 | 通用 Markdown 兼容 |
| Kiro IDE | 原生插件 | 支持 |
| Codex CLI | system prompt 注入 | 通用兼容 |
协议的胜利：因为 Skill 就是带 frontmatter 的 Markdown 文件，任何支持 system prompt 注入的 AI 编程工具都能用。这不是某个平台的专属工具，而是 AI 编程 Agent 技能的事实标准雏形。
📊 跟另外两个热门 Skills 集合对比
社区里另外两个常被拿来对比的 Skills 集合是 Superpowers（obra/jesse）和 Matt Pocock 的 skills。三者都很好，但定位完全不同：
一句话总结：agent-skills 覆盖整个产品生命周期（Define → Ship），带 review personas 和反合理化守卫；Superpowers 押注长程自主推理 + 子 agent 驱动 + worktree 隔离；Matt Pocock 的 skills 是一套 Claude Code 单兵工具集，以「grilling」质询循环闻名。
🛠️ 5 分钟上手：装上就能用
Claude Code（推荐）
# 方式 1：Marketplace 安装（一行搞定）
/plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills
# 方式 2：本地开发模式
git clone https://github.com/addyosmani/agent-skills.git
claude --plugin-dir /path/to/agent-skills
Cursor
mkdir -p .cursor/rules
cp -r agent-skills/skills/test-driven-development .cursor/rules/
# 在 Cursor Settings → Rules 中引用 skills/ 目录路径
Gemini CLI
gemini skills install https://github.com/addyosmani/agent-skills.git --path skills
/skills list # 检查安装结果
⚡ 真实使用效果对比
任务描述：写一个 validateEmail(email: string): boolean 函数。
没装 Skill 之前（默认行为）
// 不使用 TDD，直接生成
function validateEmail(email: string): boolean {
const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
return regex.test(email);
}
没有测试、没有边界条件分析、没有任何验证。
装上 Skill 之后（/test 激活 TDD 流程）
Step 1: 明确验收标准
[AI 列出所有边界情况、明确范围豁免、记录到验证清单]
Step 2: 编写失败的测试（Red 阶段）
[AI 写出 validateEmail.test.ts，先确保全部失败]
Step 3: 实现代码（Green 阶段）
[AI 写出最简实现，跑测试，全部 pass]
Step 4: 重构（Refactor 阶段）
[AI 优化命名、抽取常量、添加 JSDoc，再跑测试确保仍 pass]
同样的需求，行为完全不同——这不是工具的差异，是纪律的差异。
🎯 写在最后
Addy Osmani 在博客里写了一段我很喜欢的话：
Anti-rationalization as a team practice. Write down the lies your team tells itself. "We'll fix the tests after launch." "This change is too small for a design doc." Pair each with the rebuttal.
这套 Skills 最值得抄的不是 AI 工作流，而是**「把团队常说的借口写下来，配上反驳」**这个实践——不管用不用 AI 编程助手，都值得贴在团队 wiki 顶端。
数据截至 2026 年 7 月 21 日，最新信息请以 GitHub 仓库 为准。
GitHub 仓库：addyosmani/agent-skills 作者：Addy Osmani（Google Chrome 团队工程主管） 协议：MIT License Star 数：70,000+（截至发稿）