Google 工程师的 Agent Skills 为什么在 GitHub 拿了 26K stars

高级工程师真正的工作是什么？不是写代码——是那些永远不会出现在 diff 里的东西。AI 助手一个都没做。

上周，Addy Osmani 的 Agent Skills 项目在 GitHub 突破了 26K stars。这个数字背后，是整个行业对 AI 编码工具工程可靠性的集体焦虑。Agent Skills 不是一个新玩具——它是一个对 2026 年 AI 编程现状的精准诊断，和一个可落地的工程解决方案。

AI 编码助手默认跳过的是什么

那些不在 diff 里的工作

任何高级工程师都知道：一个任务的”完成”不等于代码写完。真正重要的工作往往不产生 diff——规格文档、测试用例、代码评审、设计决策的来龙去脉、交接时的可维护性备注。这些东西耗时、费神、不出活，但它们是把代码变成可靠软件的关键。

规格文档让团队知道”为什么要做这个功能”而不是”做了什么功能”。测试用例证明代码确实解决了问题而不是制造了新问题。代码评审让第二双眼睛 catching 关键漏洞。这些步骤加起来，往往占一个任务 60% 以上的工作量。

AI 编码助手默认跳过所有这些。你让它写个功能，它秒回了一段代码。没有规格文档，没有前置测试，没有评审流程。它直接产出了那个 diff，然后宣布胜利。

为什么 AI 助手会”抄近路”

这不全是 AI 助手的问题。问题出在激励结构上。

AI 编程工具的优化目标是”任务完成”。当成功的定义是”输出一段代码”，跳过评审和测试是理性选择——这些步骤不能被计入”完成”。LLM 的奖励信号指向可验证的输出，而规格文档、测试覆盖率、评审意见箱这些都不在信号范围内。

结果是：AI 助手和初级工程师犯了同一个错误。初级工程师跳过评审是因为经验不足，不知道那些步骤为什么重要。AI 助手跳过它们是因为没有人把这些步骤放进它的优化目标里。

这不是能力问题，是结构问题。

Agent Skills 是什么

Addy Osmani 的解决方案

Addy Osmani 是 Google 的工程师，也是《Learning JavaScript Design Patterns》等畅销书的作者。他在 2026 年 5 月 3 日发布的 Agent Skills，是一个为 AI 编码助手添加工程纪律的开源项目。

Agent Skills 的核心思想很简单：把高级工程师的工作流程编码成 AI 助手可以遵循的步骤。不是让 AI 学习”该怎么写代码”，而是让 AI 学习”完成任务的标准流程是什么”。

具体实现方式是 Markdown 文件 + 前置元数据（frontmatter）。每个 Skill 是一个可执行的工作流，包含：步骤序列、检查点（产生证据而非”感觉对”）、明确的退出标准。当 AI 代理遇到对应场景时，相关 Skill 被注入到它的上下文中，引导它按正确顺序执行。

Agent Skills 包含 20 个 Skills，覆盖六个软件生命周期阶段：定义（/spec）、规划（/plan）、构建（/build）、验证（/test）、评审（/review）、发布（/ship）。这是标准 SDLC 的 AI 友好版本——不是什么新发明，而是把 Google、Amazon 等头部工程组织的最佳实践做成了 AI 代理可执行的格式。

26K stars 背后的工程逻辑

26K stars 不是偶然。这个数字背后是大量开发团队的共同焦虑：AI 编程工具写代码的速度越快，代码库里积累的工程债务就越多。

在没有 Agent Skills 之前，团队面临一个两难选择：要么不用 AI 编程工具（错过效率红利），要么用 AI 助手但接受一个没有工程纪律的代码库（技术债务累积）。Agent Skills 提供了第三条路：让 AI 助手成为”有工程纪律的协作伙伴”而不是”快速代码生成器”。

五个核心原则

1. 过程优于文档

这是 Agent Skills 最核心的设计原则。大多数团队在引入 AI 助手后，会尝试写一堆”AI 编程规则”文档，告诉 AI 助手”要写测试””要做评审””不要跳过规格”。这些文档通常没用——AI 读了规则，产生看起来合理的输出，然后继续跳过实际操作。

Agent Skills 的设计是：不要文档，要工作流。文档是给人看的，工作流是给 AI 执行用的。如果把一个工作流放进去——先写失败的测试、运行、看到它失败、写最小代码让它通过、再次运行看到它通过——AI 有具体的步骤可以执行，你也有具体的证据可以验证。

过程优于文档。这个原则对人类团队同样有效。

2. 反合理化表格

这是 Agent Skills 最独特的设计决策。每个 Skill 都包含一个”反合理化表格”——列出 AI 助手可能用来跳过工作流的常见借口，以及对应的反驳。

几个例子：

• “这个任务太简单了，不需要规格文档” → 验收标准仍然适用。五行可以，零行不行。
• “我待会儿再写测试” → 没有待会儿。先写失败的测试。
• “测试通过了，发版吧” → 通过的测试是证据，不是证明。

这个设计背后的原理是：LLM 极其擅长合理化。它会生成听起来合理的段落，解释为什么这个特定任务不需要规格文档，或者为什么这个特定变更可以不用评审就合并。反合理化表格是预先写好的反驳，针对 AI 还没说出口的谎言。

3. 验证是不可妥协的

每个 Skill 都以具体证据终止。测试通过。构建输出干净。运行时追踪显示预期行为。评审者签字。”看起来对”永远不够。

验证必须内置，不能靠运气。AI 说”测试通过了”不等于测试真的覆盖了关键路径。你需要一个独立的信号来证明工作确实完成了。

4. 渐进式披露

复杂功能可能依次激活 11 个 Skills。小型 bug 修复可能只涉及 3 个。路由器决定哪些适用。这意味着工作流的复杂程度和实际任务范围匹配，而不是和假设的任务范围匹配。

5. 垂直切片优先

构建功能时，Agent Skills 引导优先构建一个可以完整工作的最小切片，而不是一次性构建所有层的一个横截面。垂直切片的好处是每一步都能验证。如果先构建了完整的端到端流程，即使功能不完整，你也能看到数据如何流动、用户体验如何、哪些地方可能出问题。

这对 AI 助手生态意味着什么

从”快”到”对”的转变

2024 到 2025 年，AI 编程工具的主要叙事是速度：代码生成越来越快、上下文窗口越来越大、支持的编程语言越来越多。这个叙事在 2026 年正在被改写。

速度是门槛，可靠性才是差异化。下一个阶段，AI 编程工具的竞争将围绕”谁能产出更可靠的软件”展开——谁能让 AI 助手不仅产出代码，还能产出符合工程标准的代码。

开发团队的实践建议

• 不要只给 AI 规则，给它工作流。 规则是无结构的文档，AI 会绕过。工作流是有步骤的指令，AI 必须执行。
• 验证必须内置，不能靠运气。 你需要自己定义”什么算通过”，而不是交给 AI 判断。
• 承认激励结构的问题。 如果你不把工程纪律放进 AI 的上下文，你就不能指望 AI 自发地遵守它们。
• 从小处开始。 从一个 Skill 开始，比如先强制”写测试再写代码”，让它运转起来，再逐步添加。

结尾

AI 编码助手正在改变软件工程的方式。但改变的方向取决于我们——是让它成为更快的代码生成器，还是让它成为有工程纪律的协作伙伴。

Agent Skills 给了一个选择。它告诉我们，把工程纪律注入 AI 助手不是不可能的，只需要把那些”不在 diff 里的工作”翻译成 AI 可以执行的步骤。

下一步？看看 Agent Skills 的 GitHub 仓库，选一个和你日常开发流程最接近的 Skill，用起来。