2026 年 6 月 12 日的 GitHub Trending 第二名，是一个叫 agent-skills 的项目：55,231 颗星，单日涨 3,278 颗。它的作者是 Addy Osmani——Google Chrome 团队工程总监，长期负责 Chrome 性能与开发者体验的资深工程师。
他做了一件有点反直觉的事：把《Software Engineering at Google》那本砖头书里沉淀下来的工程实践，拆成 24 个可被 AI 编码 Agent 调用的 Skill，覆盖从需求定义到生产发布的完整软件开发生命周期（SDLC）。
一句话概括：这不是一个「AI 工具」项目，这是一份「Google 工程文化 → AI Agent 工作流」的转译手册。而它真正聪明的地方，不在 Skill 数量（虽然 24 个也很夸张），而在 5 个反人性的工程设计。
项目到底是什么
打开 addyosmani/agent-skills 仓库，你会看到这样一组文件：
agent-skills/
├── skills/
│ ├── using-agent-skills/ # 元技能：决策树路由
│ ├── test-driven-development/ # TDD RED-GREEN-REFACTOR
│ ├── incremental-implementation/# 增量开发
│ ├── writing-skills/ # 写 Skill 的 Skill
│ ├── verification-before-completion/# 完工前自检
│ ├── ... # 还有 19 个，覆盖 SDLC 全流程
│ └── (24 个 Skill 完整覆盖 DEFINE→SHIP 全周期)
├── references/ # 按需加载的参考材料
├── hooks/ # session 生命周期钩子
├── SKILL-STANDARDS.md # Skill 写作标准
└── CONTRIBUTING.md # 贡献指南
每个 Skill 目录下都有一个 SKILL.md，里面用统一的 7 段式结构描述：什么时候用、怎么做、有什么反合理化借口、什么时候算"完成"。
支撑这套 Skill 运转的，是一个 8 平台兼容的安装矩阵：
| 平台 | 安装方式 |
|---|---|
| Claude Code | /plugin marketplace add + 原生 hooks |
| Cursor | 复制到 .cursor/rules/ |
| Gemini CLI | gemini skills install |
| Windsurf | 复制到 rules 配置 |
| OpenCode | AGENTS.md + skill tool |
| GitHub Copilot | .github/copilot-instructions.md |
| Kiro | .kiro/skills/ |
| Antigravity | plugin.json + agy plugin install |
这是 AI 编码工具市场第一个真正的「跨平台 Skill 标准」。一家公司写一次 Skill，多家 AI 工具能用——这件事的工程价值，远超「又一个 GitHub 教程仓库」。
5 大反人性工程实践（核心）
agent-skills 的 5 大设计，几乎每一个都在和「人性偷懒」正面对抗。下面逐一拆解。
实践 1：反合理化表（Anti-Rationalization Table）
每个 Skill 末尾都有一张「常见合理化借口 vs 现实」对照表。这是整套项目最反常识的发明。
以 test-driven-development Skill 为例：
| 合理化借口（Agent 可能说的） | 现实（Skill 强制告诉它的） |
|---|---|
| 「I'll write tests after the code works」 | You won't. Tests written after the fact test implementation, not behavior. |
| 「This is too simple to test」 | Simple code gets complicated. The test documents the expected behavior. |
| 「Tests slow me down」 | Tests slow you down now. They speed you up every time you change the code later. |
| 「I'll add edge cases later」 | Later never comes. Edge cases not tested are bugs waiting to ship. |
这套表的精妙之处在于：它预设 Agent 一定会偷懒。换句话说，作者根本没指望 Agent 「自觉遵守纪律」，而是把纪律编码成 Skill 的一部分，让 Agent 不得不面对这些事先写好的反驳。
同类机制在 incremental-implementation Skill 里有 6 条、在 verification-before-completion Skill 里有 7 条——覆盖「之后再测」「一次写完更快」「看起来对就够了」等几乎所有 Agent 的高频偷懒借口。
借鉴价值：如果你也在做自己的 AI 工作台，最该抄的不是 Skill 内容，而是这种「反合理化表」的设计模式。它是给 AI 立规矩的最有效手段。
实践 2：生命周期阶段路由（Lifecycle Routing）
agent-skills 把 24 个 Skill 按 SDLC 阶段组织成一条决策树：
DEFINE → PLAN → BUILD → VERIFY → REVIEW → SHIP
/spec /plan /build /test /review /ship
任务到达时，系统按阶段路由到对应 Skill，而不是让 Agent 凭「感觉」自己挑：
| 阶段 | 对应 Skill | 核心动作 |
|---|---|---|
| DEFINE | brainstorming / writing-plans |
把模糊需求变成可执行规格 |
| PLAN | writing-plans |
写计划，让 Agent 看到全貌 |
| BUILD | test-driven-development / incremental-implementation |
TDD + 增量提交 |
| VERIFY | verification-before-completion |
完工前自检清单 |
| REVIEW | requesting-code-review / receiving-code-review |
发请求 + 接反馈 |
| SHIP | finishing-a-development-branch |
合并、发布、归档 |
这套分阶段路由最大的好处：把「用哪个 Skill」的决定权从 Agent 手里拿走。Agent 不用判断「我现在到底该用 TDD 还是 incremental-implementation」，系统已经按阶段分发好了。
用户只需要打斜杠命令（/spec、/build、/ship），决策就完成了。这大幅降低了 Agent 选错 Skill 的概率。
实践 3：渐进式信息披露（Progressive Disclosure）
token 消耗是 AI Agent 工程的命门。agent-skills 的解法很优雅：
| 层级 | 文件 | 加载时机 |
|---|---|---|
| L1：入口 | SKILL.md |
总是加载（最小化） |
| L2：核心 | SKILL.md 内部章节 |
按需展开（Agent 触发对应阶段） |
| L3：详情 | references/*.md |
按需加载（深入某个子主题时） |
| L4：脚本 | scripts/*.sh |
执行时调用（不占 context） |
一个 SKILL.md 通常 只有 50-200 行——只写 Overview、When to Use、Core Process（核心步骤）、反合理化表、Verification。详细的模式指导、案例、参考资料都放在 references/ 子目录里，Agent 真要用了才加载。
这种设计的直接收益：同样一个 Skill 体系，token 消耗能比「全塞 SKILL.md」降低 50% 以上。对于需要长上下文（数万 tokens）的复杂任务，这是决定性优势。
借鉴价值：很多团队的 AI 工作台有个常见问题——单个 Skill 文档越写越长，从 200 行膨胀到 2000 行。agent-skills 告诉你：写「长 Skill」是错的，应该「薄入口 + 厚 references」。
实践 4：验证门禁（Verification Gates）
每个 Skill 的最后一节都是「Verification」——一份可勾选的退出标准清单。以 incremental-implementation Skill 为例：
## Verification
- [ ] Each increment was individually tested and committed
- [ ] The full test suite passes
- [ ] The build is clean
- [ ] The feature works end-to-end as specified
- [ ] No uncommitted changes remain
这 5 条不是「建议」，是「门禁」。Agent 跑完这个 Skill 后，必须能逐条勾选证明自己真做了——否则视为没完成。
验证门禁的另一个变体是「Red Flags」（违规信号）。在 test-driven-development Skill 里有 8 条：
| Red Flag（违规信号） |
|---|
| Test passes on the first run（测试第一次就过——往往意味着你没真测） |
| Skipping a test to make the suite pass（删测试让 suite 通过——作弊） |
| >100 lines changed without committing（一次改 100+ 行没提交——失控） |
| Tests that don't actually assert behavior（测试不真断言——形同虚设） |
| Refactor + feature change in same commit（重构和功能改一起提交——分不开责任） |
借鉴价值：这是把「自动化检查清单」从人类工作流平移到 AI Agent 工作流的最优雅做法。给 AI 立规矩时，「做这个」「别做那个」效果有限；「如果你看到 X，说明你已经违规了」效果最好。
实践 5：6 条行为准则（Core Operating Behaviors）
整个项目有一个 using-agent-skills「元技能」，专门定义 6 条所有 Skill 共享的行为准则：
| 行为准则 | 含义 |
|---|---|
| Surface Assumptions | 实现前明确列出假设，不藏着掖着 |
| Manage Confusion Actively | 遇到不一致时停止并澄清，不蒙头做 |
| Push Back When Warranted | 技术上有问题要指出，不做「Yes-machine」 |
| Enforce Simplicity | 能用 100 行不用 1000 行 |
| Maintain Scope Discipline | 只碰任务范围内的代码，不「顺便优化」 |
| Verify, Don't Assume | 「看起来对」永远不够，要测、要检 |
这 6 条翻译成大白话：别装懂、别瞎猜、别堆代码、别超范围、别只看表面。每一条都是 AI Agent 的常见病灶，agent-skills 把它写成了「工作宪法」。
更有意思的是，这 6 条准则里能看到 Google 工程文化里那些老熟人：Hyrum's Law（隐式契约）、Beyonce Rule（「If you liked it then you should have put a test on it」）、Chesterton's Fence（拆围栏前先理解为什么建）。
Addy Osmani 没有发明新东西，他只是把 Google 工程师 20 年的文化沉淀，重新打包成 AI Agent 能听懂的语言。这件事本身就极具价值。
Skill 的标准 7 段解剖结构
agent-skills 强制所有 Skill 使用统一的 7 段结构。打开任何一个 SKILL.md，你都会看到：
---
name: skill-name
description: What + When (max 1024 chars)
---
# Skill Title
## Overview → 一句话概述
## When to Use → 触发条件 + 排除场景
## Core Process → 分步工作流（含代码示例 + ASCII 流程图）
## Techniques → 详细模式指导
## Common Rationalizations → 反合理化表
## Red Flags → 违规信号
## Verification → 可验证的退出清单
这套结构的力量在于「可预测性」——Agent 不需要为每个 Skill 重新学习组织方式，SKILL.md 一打开就知道在哪一节找什么。
对比一下：很多团队的 Skill 文档常常长这样——
# 概述
# 使用场景
# 工作流程
# 注意事项
# 已知陷阱（部分有）看起来差不多，但少 3 段关键的：Common Rationalizations（反合理化表）、Red Flags（违规信号）、Verification（验证清单）。
这 3 段的缺席，意味着：Agent 跳步骤没人拦、Agent 跑偏没人提醒、Agent 自称「完成」没人能验。
agent-skills 的 7 段结构，本质上是一个「Skill 质量的最小完备集」。
几个核心 Skill 速览
test-driven-development
写最经典的 TDD 实践（RED-GREEN-REFACTOR），但加了 4 个独特机制：
- Prove-It Pattern：Bug 修复前必须先写复现测试
- 测试金字塔：80% 单元 / 15% 集成 / 5% E2E
- Beyonce Rule：「如果你喜欢它，就该给它写测试」
- DAMP over DRY：测试中可读性优于去重
配 7 条反合理化、8 条 Red Flags——几乎能堵住所有「之后再写测试」的借口。
incremental-implementation
增量开发循环：Implement → Test → Verify → Commit → Next。
3 种切片策略：垂直切片（按用户场景切）、契约优先（先定义 API）、风险优先（先攻最难的）。
6 条实现规则：简洁优先、范围纪律、一次一事、可编译、特性开关、可回滚。配 6 条反合理化、10 个 Red Flags。
writing-skills
教你怎么写 Skill 的 Skill——meta 到极致。它本身也用 7 段结构，所以是「自举」的最好例证。
Hooks 系统：让 Skill 真正「接进」会话
Skill 写得再好，Agent 不知道什么时候调用也白搭。agent-skills 的解法是 hooks：
hooks/
├── session-start.sh # 会话开始时自动加载 using-agent-skills
├── session-end.sh # 会话结束时归档
└── tool-use.sh # 工具调用前后注入提醒在 Claude Code 里，这些 hook 通过 settings.json 注册后，每次会话开始就会自动触发元技能，决策树先建立起来，再等用户输入。
这是「主动引导 Agent」而非「被动等 Agent 想起来」的范式差异。
项目健康度评估
| 维度 | 评分 | 说明 |
|---|---|---|
| 代码质量 | ⭐⭐⭐⭐⭐ | Google 工程标准，结构清晰 |
| 文档完整度 | ⭐⭐⭐⭐⭐ | Skill Anatomy、Contributing、多平台 Setup 指南 |
| 社区活跃度 | ⭐⭐⭐⭐⭐ | 55K+ stars，日增 3K+ |
| 可维护性 | ⭐⭐⭐⭐⭐ | MIT 协议，标准化 Skill 格式 |
| 创新性 | ⭐⭐⭐⭐ | 反合理化表、渐进式披露是独特创新 |
总结：为什么它值得你花 10 分钟读完
Addy Osmani 用 24 个 Skill 回答了一个本质问题：「如何让 AI 编码 Agent 学会像 Google 工程师一样工作？」
5 大设计模式（反合理化表、生命周期路由、渐进式披露、验证门禁、6 条行为准则）每一个都直指 AI Agent 工程的核心痛点。这些不是炫技，是可立即复用的工程实践。
无论你是在做自己的 AI 工作台、给团队设计 AI 编码规范、还是单纯想了解 AI 编码工具的下一代形态——这个项目都值得你认真看一遍。
📌 仓库地址：github.com/addyosmani/agent-skills
📌 作者：Addy Osmani（Google Chrome 工程总监）
📌 协议：MIT（可商用、可改、可分发）
📌 支持平台：Claude Code / Cursor / Gemini CLI / Windsurf / OpenCode / Copilot / Kiro / Antigravity
💡 落地案例：把 5 大实践搬进自己的 AI 工作台
agent-skills 的设计是开源的（MIT 协议），你完全可以照搬它的方法论来打磨自己的 AI 工作台。给你一个三步落地的参考路径：
第一步：先抄「反合理化表」骨架。把你现有的 AI 工具使用规范翻出来，逐条问「如果 AI 偷懒，它会怎么给自己找借口？」把这些借口和反驳写进规则文档。这是最快见效果的一招——比起「教 AI 守规矩」，不如「提前堵住 AI 的退路」。
第二步：拆 SKILL.md，按需加载 references。把单文件 2000 行的 Skill 拆成「100 行入口 + references 子目录」。Token 消耗立刻腰斩，复杂任务的稳定性会明显提升。
第三步：写 Verification 清单，把它当门禁用。每个工作流结束前，AI 必须能逐条勾选证明自己「真做了」。这一条对内容生产、客服回复、数据分析等场景都通用——不限于编码。
无论你的业务是电商运营、内容创作、还是客户支持——AI Agent 的「偷懒」是普遍问题，agent-skills 的解法是普适解法。把它当作「AI 工作台质量基线」来对照，能少走 6 个月的弯路。