Google 工程师开源20款AI Agent技能，助我工作流大变革

Google 工程师开源了 20 个 AI Agent Skills，我把它们融合进了自己的工作流

Info 项目地址：https://github.com/addyosmani/agent-skills 作者：Addy Osmani（Google Chrome 团队工程负责人） 协议：MIT 支持平台：Claude Code / Cursor / Gemini CLI / Kiro / Copilot / Windsurf

核心观点： AI 编码代理最大的问题不是写不出代码，而是不知道什么时候该停下来写规范、什么时候该先写测试、什么时候该做代码审查。这个项目把 Google 内部的工程纪律编码成了 AI agent 可以遵循的 20 个结构化工作流，覆盖从构思到上线的完整生命周期。

你有没有遇到过这些情况：

• • 让 AI 写代码，它一口气写了 500 行，没有测试，没有分步验证

• • 让 AI 修 bug，它靠猜，不先复现问题

• • 让 AI 做架构决策，它不记录为什么选了这个方案

• • 让 AI 开发新功能，它跳过规范直接开干，做到一半发现方向错了

这些都不是 AI 能力的问题，而是方法论的缺失。

AI 编码代理默认走最短路径——跳过规范、跳过测试、跳过安全审查、跳过代码审查。这些恰恰是资深工程师不会跳过的步骤。

Addy Osmani 的 agent-skills 项目，本质上就是把这些「不能跳过的步骤」编码成了 AI agent 可以遵循的结构化工作流。

20 个 Skills 全景图

这 20 个 skills 按软件开发生命周期排列，形成一个完整的闭环：

Define — 搞清楚要做什么

Skill

做什么

idea-refine

用发散-收敛思维把模糊想法变成可执行方案

spec-driven-development

写代码之前先写规范，定义成功标准

Plan — 拆解任务

Skill

做什么

planning-and-task-breakdown

把规范拆成小的、可验证的任务，每个任务有验收标准

BUIld — 写代码

Skill

做什么

incremental-implementation

薄切片开发：实现一块→测试→验证→提交→下一块

test-driven-development

先写失败的测试，再写代码让它通过（TDD）

context-engineering

给 agent 喂正确的上下文，不多不少

source-driven-development

每个框架决策都要查官方文档验证，不靠记忆

frontend-ui-engineering

生产级 UI：无障碍、响应式、设计系统一致性

api-and-interface-design

稳定的 API 设计：契约优先、Hyrum's Law、错误语义

Verify — 证明它能用

Skill

做什么

browser-testing-with-devtools

用 Chrome DevTools MCP 在真实浏览器中验证

debugging-and-error-recovery

五步排错法：复现→定位→最小化→修复→防护

Review — 合并前的质量门

Skill

做什么

code-review-and-quality

五轴代码审查：正确性、可读性、架构、安全、性能

code-simplification

简化代码但不改变行为（Chesterton's Fence 原则）

security-and-hardening

OWASP Top 10 防护、输入验证、三层边界系统

performance-optimization

先测量再优化，Core Web Vitals 达标

Ship — 安全上线

Skill

做什么

git-workflow-and-versioning

原子提交、trunk-based 开发、commit 即存档点

ci-cd-and-automation

自动化质量门：lint→类型检查→测试→构建→安全审计

deprecation-and-migration

代码是负债：废弃旧系统、安全迁移用户

documentation-and-adrs

记录决策（ADR），不只是记录代码

shipping-and-launch

上线清单、灰度发布、回滚计划、监控

⭐ 5 个最值得关注的设计亮点

1. 反合理化表（Anti-Rationalization Tables）

这是整个项目 最独特、最有价值 的设计。

AI agent 非常擅长「合理化」自己跳过步骤的行为。比如它会说"这个太简单了不需要测试"、"我先写代码后面再补规范"。这些听起来都很合理，但都是错的。

每个 skill 都有一张反合理化表：

Agent 的借口

现实

"I'll add tests later"

You won't. 事后写的测试测的是实现，不是行为。

"This is simple, I don't need a spec"

简单任务不需要长规范，但仍然需要验收标准。两行规范也是规范。

"Tests slow me down"

测试现在让你慢，但以后每次改代码都让你快。

"I tested it manually"

手动测试不持久。明天的改动可能破坏它，而你无从知晓。

这张表的存在，让 agent 在想跳过步骤时有了一个「内心的反驳声音」。

2. Prove-It Pattern（Bug 修复的铁律）

修 bug 时， 不要先尝试修复 。先写一个能复现 bug 的测试：

Bug 报告到达
↓
写一个测试来复现 bug（必须 FAIL）
↓
确认测试失败（证明 bug 存在）
↓
实现修复
↓
确认测试通过（证明修复有效）
↓
运行完整测试套件（无回归）

这个模式确保了：

• • 你真的理解了 bug（不是猜的）

• • 修复是有效的（有测试证明）

• • 同样的 bug 不会再出现（回归测试守护）

项目中嵌入了大量来自 Google 工程文化的原则：

• • Hyrum's Law （API 设计 skill）：API 的所有可观察行为都会被用户依赖，包括未文档化的 bug 和时序

• • Beyonce Rule （TDD skill）：如果你喜欢它，就该给它写测试。基础设施变更不负责帮你发现 bug

• • Chesterton's Fence （代码简化 skill）：看到一段不理解的代码，先搞清楚它为什么存在，再决定是否删除

• • Code as Liability （废弃迁移 skill）：代码是负债不是资产，每行代码都有持续的维护成本

• • Shift Left （CI/CD skill）：在流水线中尽早发现问题。lint 阶段发现的 bug 成本是分钟级，生产环境发现的是小时级

• • Skills 是 how ——带步骤和退出标准的工作流

• • Personas 是 who ——code-reviewer、security-auditor、test-engineer 三个专家角色

• • Commands 是 when —— /spec 、 /plan 、 /build 、 /test 、 /review 、 /code-simplify 、 /ship

编排规则非常清晰： 用户是编排者，Persona 不调用其他 Persona。 唯一的多 Persona 编排模式是 /ship 的并行扇出——同时启动三个专家角色审查，然后合并报告做 GO/NO-GO 决策。

5. 验证即退出标准

每个 skill 以 checklist 结尾，不是建议，是 必须满足的条件 ：

## Verification
After completing any implementation:
-  Every new behavior has a corresponding test
-  All tests pass: `npm test`
-  Bug fixes include a reproduction test that failed before the fix
-  Test names describe the behavior being verified
-  No tests were skipped or disabled

"Seems right" 永远不够——必须有证据。

实战：如何融合到你自己的工作流

我自己有 36 个 Kiro Skills，覆盖 AWS 运维、内容创作、远程机器管理、SFDC 业务工具等。把 agent-skills 融合进来时，我做了以下分析和决策。

冲突分析：几乎为零

两套 skills 解决的是完全不同层次的问题：

我的 Skills

agent-skills

「怎么连 AWS GPU 机器」

「怎么写规范」

「怎么发公众号文章」

「怎么做代码审查」

「怎么部署到西雅图」

「怎么安全上线」

工具层 vs 方法论层，天然分层，零冲突。

融合方案：分层共存

不合并、不修改原始内容、不破坏任何一方的完整性。

唯一有重叠的是 Git 操作——我有具体的 SSH 代理推送 skill，agent-skills 有 Git 方法论 skill。解决方式：在方法论 skill 中标注"具体操作请参考个人 skills"。

中文触发增强

agent-skills 原始的 description 全是英文。为了在中文对话中也能正确触发，给每个 skill 的 description 追加了中文触发条件：

# 增强后
description: Creates specs before coding. Use when starting a new project...
当开始新项目、新功能或重大变更时使用。用"写规范"、"写spec"触发。

这样说"帮我写个规范"就能自动触发 spec-driven-development 。

融合后的效果

场景

触发的 Skill

"帮我开发一个新功能"

spec-driven-development → planning → incremental-implementation

"这个 bug 怎么回事"

debugging-and-error-recovery（五步排错法）

"review 一下代码"

code-review-and-quality（五轴审查）

"部署到西雅图"

service-deploy（我的个人 skill，不受影响）

"查微信消息"

wechat-cli（我的个人 skill，不受影响）

两套 skills 各司其职，自动按需加载。

对比：agent-skills vs 其他 AI 编码规范

维度

agent-skills

Cursor Rules

.cursorrules 模板

覆盖范围

完整生命周期（20 个 skills）

单个项目规范

单个项目规范

反合理化

✅ 每个 skill 都有

❌ 无

❌ 无

验证标准

✅ 每个 skill 有 checklist

❌ 无

❌ 无

多平台

Claude Code / Cursor / Gemini / Kiro / Copilot / Windsurf

Cursor only

Cursor only

可组合

Skills + Personas + Commands 三层

单层

单层

工程原则

Google 内部文化编码

社区经验

社区经验

我的 3 个核心收获 1. AI Agent 需要的不是更多能力，而是更多纪律

Agent 已经能写出很好的代码了。问题是它不知道什么时候该停下来——停下来写规范、停下来写测试、停下来做审查。agent-skills 提供的就是这种「知道什么时候该停」的纪律。

2. 反合理化表是对抗 AI 偷懒的最佳武器

AI agent 最危险的行为不是写错代码，而是「合理地跳过正确的步骤」。反合理化表让 agent 在想偷懒时有了一个内置的反驳机制。这个设计思路值得所有 AI 工具开发者学习。

3. 工具型 Skills 和方法论型 Skills 是两个不同的维度

我之前只有工具型 skills（怎么连机器、怎么发文章），缺少方法论型 skills（怎么保证质量）。两者结合后，AI agent 不仅知道「用什么工具」，还知道「用什么流程」。这是一个质的提升。

️ 快速上手指南 如果你用 Kiro

git clone https://github.com/addyosmani/agent-skills.git
cp -R agent-skills/skills/* ~/.kiro/skills/
cp -R agent-skills/references ~/.kiro/skills/references/

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

cp agent-skills/skills/test-driven-development/SKILL.md .cursor/rules/
cp agent-skills/skills/code-review-and-quality/SKILL.md .cursor/rules/

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

1. 1. agent-skills GitHub 仓库 [1] — 项目源码和完整文档

2. 2. Software Engineering at Google [2] — 项目中大量原则的来源

3. 3. Google Engineering Practices Guide [3] — 代码审查等实践的参考

4. 4. Kiro IDE & CLI 文档 [4] — Kiro Skills 的官方文档

5. 5. Addy Osmani 的 GitHub [5] — 项目作者，Google Chrome 团队

互动时间 ：

你在使用 AI 编码代理时，最常遇到的「跳过步骤」问题是什么？你觉得反合理化表这个设计有用吗？欢迎在评论区留言讨论！

如果觉得有帮助，别忘了点个"在看"并分享给需要的朋友～

引用链接

[1] agent-skills GitHub 仓库: https://github.com/addyosmani/agent-skills

[2] Software Engineering at Google: https://abseil.io/resources/swe-book

[3] Google Engineering Practices Guide: https://google.github.io/eng-practices/

[4] Kiro IDE & CLI 文档: https://kiro.dev/docs/skills/

[5] Addy Osmani 的 GitHub: https://github.com/addyosmani