大家好，我是若风。

2026 年 2 月 15 日，Addy Osmani 开了一个仓库，名字很直白，agent-skills。

到 6 月 27 日，它已经有 67,179 个 star，7,260 个 fork，146 个 open issues。最近一次 push 是 6 月 25 日，最新 release 是 0.6.2。

这个速度有点离谱。

但我更关心的不是 star。

我盯着 README 看了半天，突然意识到一件事，Agent Skills 不是在教 AI 多会写代码，它是在提醒 AI，写代码只是软件工程里很小的一段。

坦白讲，这个方向比很多炫技项目更值得看。

AI Agent 最容易跳过的，不是代码，而是工程纪律

我们现在用 AI 写代码，最大的错觉是什么。

是它太快了。

你输入一句「做个登录页」，它几秒钟就能给你组件、样式、状态、校验。你输入一句「加一个导出功能」，它立刻能改 API、补按钮、写文件下载。

看起来很爽。

但说真的，软件工程里最贵的部分，往往不在生成代码那几分钟。

贵的是需求没说清，贵的是没有验收标准，贵的是测试像装饰，贵的是上线前没人看安全和回滚，贵的是半年后没人知道当时为什么这么设计。

Agent Skills 的切入点就在这里。

它把软件研发流程拆成 6 个阶段，Define、Plan、Build、Verify、Review、Ship。对应到 8 个 slash commands，/spec、/plan、/build、/test、/review、/webperf、/code-simplify、/ship。

你想想看，这其实是在给 Agent 加一道刹车。

不是不让它写。

是先逼它走完该走的路。

24 个技能背后，是一套生命周期地图

Agent Skills 当前有 24 个 Skills，23 个生命周期技能，加 1 个 using-agent-skills 元技能。

这个元技能很关键。

它不像普通 README 那样说「这里有一些工具，你自己挑」。它直接把工作流路由写出来，需求不清楚走 interview-me，想法粗糙走 idea-refine，新功能走 spec-driven-development，有 spec 再走 planning-and-task-breakdown，实现时走 incremental-implementation 和 test-driven-development。

后面还有一串质量闸门。

浏览器问题走 browser-testing-with-devtools，报错走 debugging-and-error-recovery，代码 review 走 code-review-and-quality，太复杂走 code-simplification，涉及用户输入和权限走 security-and-hardening，性能问题走 performance-optimization，上线走 shipping-and-launch。

这不是技能堆砌。

更像一张工程流程地图。

我一直觉得，Agent 最大的问题不是不知道怎么做，而是不知道什么时候该停下来换一种脑子。写 spec 是一种脑子，拆任务是一种脑子，写测试是一种脑子，做安全审查又是另一种脑子。

Agent Skills 做的事情，就是把这些脑子做成可触发的流程。

最有价值的设计，是 anti-rationalization

这个仓库里有一个词我很喜欢，anti-rationalization。

翻成人话，就是防止 Agent 给自己找借口。

比如 spec-driven-development 里，它会把常见借口写出来。

「这个很简单，不需要 spec。」

回应是，简单任务不需要长 spec，但仍然需要验收标准。两行也可以。

「我写完代码再补 spec。」

回应是，那叫文档，不叫规格。规格的价值就是写代码之前逼你把事情想清楚。

这段我看得挺有共鸣。

因为 Agent 真的很会合理化。它会说「我先快速实现一下」，然后一口气改 8 个文件。它会说「这个测试之后补」，然后永远不会补。它会说「看起来没问题」，但没有任何证据。

Agent Skills 的每个技能都强调 Red Flags 和 Verification。也就是说，它不只给步骤，还把「你最可能偷懒的地方」提前钉在墙上。

这个设计很像高级工程师带新人。

不是告诉你一句「注意质量」。

而是提前说，等会你一定会想跳过这一步，别跳。

它把 Google 工程文化变成了 Agent 工作流

README 里有一个很明确的背景，很多原则来自 Google 工程文化，比如 Hyrum 法则、Beyonce Rule、测试金字塔、Chesterton 栅栏、trunk-based development、Shift Left、feature flags。

这些词如果只是放在文章里，很容易变成八股。

但 Agent Skills 的做法比较实在，它把这些原则嵌进具体技能。

比如 test-driven-development 不是一句「要写测试」。它要求先 RED，再 GREEN，再 REFACTOR。bug 修复要先写复现测试，证明 bug 真的存在，再修。它还区分 small、medium、large tests，强调小测试应该占大多数。

再比如 spec-driven-development，它不是一句「先写需求」。它要求 spec 覆盖 6 个部分，目标、命令、项目结构、代码风格、测试策略、边界。边界还分 Always、Ask first、Never。

说真的，这才是 Agent Skills 应该长成的样子。

不是一句漂亮口号。

是一个让模型很难糊弄过去的检查表。

Slash command 是入口，persona 是审查视角

Agent Skills 还有一个三层结构，Skills、personas、slash commands。

Skills 是怎么做，personas 是谁来看，slash commands 是什么时候触发。

这个区分很重要。

很多人做 Agent 流程，容易把所有东西混在一起。一个「代码审查专家」既负责路由，又负责执行，又负责判断要不要找安全专家。最后 prompt 越写越乱。

Agent Skills 在 AGENTS.md 里说得很清楚，用户或者 slash command 才是 orchestrator，persona 不应该再调用 persona。

目前它有 4 个预设 persona，code-reviewer、test-engineer、security-auditor、web-performance-auditor。/ship 会做一个并行 fan-out，让多个 persona 同时看当前变化，再合成 go 或 no-go。

这事挺工程化。

因为发布前的检查，本来就不应该只靠一个视角。代码健康、安全、测试、性能，经常互相看不到对方的问题。

把它们并行跑，再做合并判断，比让一个万能 Agent 自言自语靠谱多了。

和 Ponytail 刚好是两个方向

前面我刚拆过 Ponytail。

Ponytail 的核心是让 Agent 少造轮子，先问要不要写，能不能复用，标准库有没有，原生能力能不能解决。

Agent Skills 的核心不一样。

它不是让 Agent 少写代码，而是让 Agent 不要跳过流程。

这两个方向其实互补。Ponytail 解决的是过度构建，Agent Skills 解决的是过度跳步。前者像一个资深工程师在你旁边说，别写那么多。后者像一个工程经理和 Staff Engineer 混合体，说，先把 spec、任务、测试、review、发布门槛补齐。

你想想看，AI 编程正在同时放大两个问题。

一个是代码太容易生成，所以过度设计更容易。

另一个是代码太容易生成，所以工程流程更容易被省掉。

Ponytail 往回拉第一件事。

Agent Skills 往回拉第二件事。

诚实的边界

Agent Skills 很强，但不是所有团队都该整套照搬。

第一，它有流程成本。一个小 typo、一个单行配置、一个无风险文案，没必要走完整生命周期。README 里也承认，单行修复和自包含小改动不需要 spec-driven development。

第二，它更适合有生产质量要求的代码。个人 demo、探索性 prototype、一次性脚本，可能会觉得它太重。流程不是免费午餐，每一个 gate 都要消耗上下文和注意力。

第三，它依赖 Agent 主动遵守。OpenCode 的 AGENTS.md 写得很强硬，哪怕只有 1% 可能匹配 Skill，也要先检查。但现实里，不同宿主对 Skills、commands、hooks 的支持不一样，执行一致性会受平台影响。

第四，它不是 benchmark 项目。README 里提到过一篇第三方对比实验，但那只是一个开发者的单任务观察，不该拿来当统计结论。这个项目的价值更多来自流程结构和工程判断，而不是某个固定百分比。

老实说，我反而喜欢它没有把自己包装成银弹。

因为工程流程这东西，本来就不是越多越好。关键是你知道什么时候需要它，什么时候它会拖慢你。

我真正想带走的，是「可验证」三个字

Agent Skills 里反复出现一个观点，verification is non-negotiable。

这句话听起来硬，但很对。

AI Agent 写代码时，最危险的不是它不会写，而是它写完以后表现得太自信。人看着一堆漂亮 diff，也很容易被说服。

所以 Agent Skills 不断要求证据。

spec 要有人 review，任务要有 acceptance criteria，测试要先失败再通过，浏览器问题要看 runtime，性能优化要先测量，发布要有 rollback 和 monitoring。

这些东西都不性感。

但生产系统靠的就是这些不性感的东西。

写在最后，Agent Skills 的流行说明了一件事，AI 编程已经过了「能不能写」的阶段，正在进入「能不能稳」的阶段。

能写代码的 Agent 会越来越多。

能按软件工程纪律交付的 Agent，才会真的留在团队里。

如果你正在搭自己的 Agent 工作流，我建议别只收藏里面的 24 个 Skills。

更应该偷走它的结构。

需求先澄清，任务再拆小，代码增量做，测试当证据，审查分视角，发布有回滚。

这套东西听着朴素。

但越到 AI 写代码的时代，越朴素，越值钱。