Google Chrome 总监开源的 AI 编码工作流：agent-skills 实战

发表于 分类于
Addy Osmani 把 Google 高级工程师的工作流打包成 23 个 SKILL.md，今天 GitHub 一天涨 2,656 stars。我装了试了一周，发现 AI 写代码"偷工减料"的老毛病被治好了。

我用 AI 写代码的最大痛点

说出来不怕丢人。

我用 Claude Code 写项目，AI 干完活提交代码，我一 review 心率就上来了 —— 单元测试？跳过了。错误处理？漏了边界情况。文档？一个字没动。我问它为什么不写测试，它回我一句：

“I focused on the core implementation. We can add tests in a follow-up if you’d like.”

翻译一下就是” 我懒得写，你看着办”。

过去一年，这种情况我遇到不下五十次。AI 编码 agent 的通病：它默认你的项目是一个 demo，不是 production。它不写测试、不验证边界、不主动 review、不写 commit message，因为它心里没有” 完成” 这个概念。

直到我刷到 GitHub trending，看到 addyosmani/agent-skills 一天涨了 2,656 stars。

点进去一看，作者是 Addy Osmani——Google Chrome 工程总监，《Learning JavaScript Design Patterns》的作者。这哥们把他脑子里” 高级工程师应该怎么写代码” 的工作流，打包成了 23 个 SKILL.md 文件，AI agent 加载之后就会自动按这套流程干活。

装上试了一周，我服了。

agent-skills 是什么

一句话：它不是 prompt 模板，而是工程纪律。

你给 AI 一段 prompt，它理解后会自由发挥。你给 AI 一段 SKILL.md，它会按里面规定的步骤、验证关口、反自欺话术去执行。

项目结构非常清晰：

1
2
DEFINE  → PLAN → BUILD → VERIFY → REVIEW → SHIP
/spec    /plan  /build   /test   /review  /ship

对应 7 个 slash command，每个 command 激活对应的 skills。比如 /build 会自动加载 incremental-implementation、test-driven-development、context-engineering 等 5 个相关 skill。

最让我惊艳的不是命令，是每个 skill 里都有一张 anti-rationalization table（反甩锅表）。

举个例子，test-driven-development 这个 skill 里写着：

AI 常用的借口 反驳
“I’ll add tests later” 测试是设计工具，不是验证工具。现在不写，逻辑边界会一直模糊
“This is too simple to test” 简单代码正是测试的最佳对象，写一次永远受益
“The framework handles testing” 框架处理的是工具，不是意图。你仍然需要表达” 什么算完成”
“Tests will slow down the demo” 跳过测试的代价是 5 倍的 debug 时间

看到第三行的时候我笑出声了 —— 这不就是我每天和 AI 吵架的台词吗？Addy 把 AI 的嘴替都写进 skill 里了。

怎么装

我用的是 Claude Code，官方推荐路径：

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

如果你没配 SSH key 报错，用 HTTPS URL 强制：

1
2
/plugin marketplace add https://github.com/addyosmani/agent-skills.git
/plugin install agent-skills@addy-agent-skills

除了 Claude Code，Cursor、Gemini CLI、Windsurf、GitHub Copilot、Codex、Kiro 都能用 —— 基本覆盖了主流 AI 编码工具。Skills 本质上就是带 frontmatter 的 Markdown 文件，往各家 agent 的规则目录里塞就行。

装完之后，你工程的根目录会多出一个 AGENTS.md，里面写明：什么时候该激活哪个 skill。比如用户说” 做个新功能”，自动走 spec-driven-development；说” 这个 bug 修了”，自动走 debugging-and-error-recovery。

我用它写了一个真实功能

光说不动手是纸上谈兵。说一下我这周用它做的真事。

我那个博客系统要加一个” 相关文章推荐” 功能。需求很明确：根据文章标签匹配度推荐 3 篇相关文章，按相似度排序，缓存 10 分钟。

按以前的工作流，我会直接 /build 一把梭，让 AI 帮我写完。然后验收时发现一堆坑。

这次我按 agent-skills 的纪律来：

第一步 /spec：先让 AI 用 spec-driven-development 这个 skill 写 PRD。它不会上来就写代码，而是先问我问题 —— 缓存用 Redis 还是文件？匹配算法用 tag 交集还是 TF-IDF？要不要考虑阅读量加权？问完它把答案整理成一份 200 字的 spec，确认后才往下走。

第二步 /plan：用 planning-and-task-breakdown 把 spec 拆成 4 个原子任务，每个任务都有验收标准。比如第三个任务是” 实现匹配算法”，验收标准写的是” 对 1000 篇博客跑测试，最相似的 3 篇里至少有 1 篇共享 2 个以上 tag”。

第三步 /build auto：这是我最喜欢的模式。它会先生成完整的任务列表，让你一次性确认，确认之后它自己跑完所有任务，每个任务都走 test-driven-development—— 先写失败的测试，再写实现，再重构。它不是无脑往前冲，每个 task 之间会暂停让你 review。

我看完 plan，按了确认。AI 跑了大概 12 分钟，中间有两次它想” 算了不写测试”，被 anti-rationalization table 怼回去老老实实写了。完成后我 review，4 个 task 全部一次通过。

以前同样的功能，我至少要 review + 重做 2 轮。

三个最有价值的 skill

装都装了，我把 23 个 skill 都翻了一遍。三个我觉得最值得展开说：

1. doubt-driven-development

这个 skill 设计非常反直觉。它要求 AI 在做关键决策时，主动开一个 fresh-context 的 sub-agent 来挑刺。流程是 CLAIM → EXTRACT → DOUBT → RECONCILE → STOP。

意思是：你做了一个技术决策，AI 会让另一个” 干净上下文” 的 agent 来挑战你的判断。它不知道你之前怎么想的，只能看证据。这样能避免确认偏误 —— 你自己做的方案，自己看哪儿都觉得对。

我用它在数据库选型上挑了一次。原本想用 MongoDB 存文章，fresh-context agent 看了我的查询模式后说：你的查询 80% 都是按 tag 和时间过滤，Postgres 的复合索引效率高两个数量级，而且你已经有 Postgres 了。我就改了。

2. context-engineering

AI 编码最怕的就是”context poisoning”—— 上下文窗口里塞了一堆不相关的东西，AI 注意力被分散，写出来的代码越来越歪。

这个 skill 规定了一套规则：

  • 规则文件分三层：AGENTS.md（核心原则）、domain 规则（具体技术栈）、task 规则（当前任务）
  • 给 AI 的上下文要” 打包”，相关文件一起给，别东一榔头西一棒子
  • 输出质量下降时，主动清空上下文重做比继续补充便宜

我之前总舍不得 /clear，怕丢掉” 上下文”。看完这个 skill 才知道：垃圾上下文比没有上下文更贵。

3. source-driven-development

让 AI 在用某个框架的 API 时，必须先抓官方文档，引用源，再写代码。如果抓不到或抓到的内容和已知 API 不一致，要明确标记 unverified。

这解决了一个我经常踩的坑：AI 凭” 印象” 写 API 调用，参数名都是错的，传统 AI 经常 hallucinate API。现在它写之前先 fetch 文档，写完后会告诉你” 这段引用自 React 18.2 官方文档第 X 节”。

它不是万能解药

说点反面的。

agent-skills 是纪律，不是智能。如果你的需求本身就是模糊的，它会按纪律逼你把需求说清楚 —— 但不会替你思考。如果你的代码基础太差，它会忠实地在烂代码上加更多烂代码。

还有，它的 commands 是” 动词式” 的（/build、/test、/ship），不是” 目标式” 的（” 帮我加个推荐功能”）。这意味着你得学会把目标翻译成动作。如果你连” 我要先写 spec 再 plan” 这个意识都没有，agent-skills 救不了你。

另外它默认是英文社区，文档和 skill 内容全是英文。如果你团队是中文环境，要么自己翻译，要么让 AI 翻译，但翻译会损失一些” 反 AI 借口” 的精髓。

我的工作流现在长这样

简单总结一下我现在的日常：

早上 10 点起来，咖啡机开机的功夫，我打开 Claude Code，加载 agent-skills。接 Hermes Agent（我之前介绍过的那个本地 AI 助手）派下来的任务 —— 比如” 给博客加个 sitemap”。

我的开场白变了。以前是” 帮我做个 sitemap”。现在是：

/spec 我要给博客加个 sitemap。技术栈是 Hexo，部署在 GitHub Pages，文章数 30+。

AI 会按 spec-driven-development 走，先问我目标是什么（SEO？爬虫友好？缓存友好？），确认完写 spec，我 review，再 /plan，再 /build auto。

一上午能跑完 2-3 个 feature，质量比我自己写还稳 —— 因为 AI 不会偷懒，agent-skills 不让它偷懒。

最后

agent-skills 不是新框架，不是新模型，它是一套工作纪律的封装。

它解决的问题不是”AI 不够聪明”，而是”AI 不会自己定义什么是完成”。Addy Osmani 把他在 Google 带工程师团队的 know-how，打包成 AI 能读懂的 Markdown—— 这件事本身就很优雅。

如果你也是每天和 AI agent 一起写代码的人，我建议你装上试一周。不用 23 个 skill 全开，先开三个：spec-driven-development、test-driven-development、code-review-and-quality。

你会发现你和 AI 的对话质量会上一个台阶。

相关链接