前几天逛GitHub的时候，发现有个仓库短短两天就涨了5000多颗星，总星数直接冲到了57k。项目名字叫agent-skills，作者是Addy Osmani。
Addy Osmani这个名字，做前端的估计都不陌生。他可是Google Chrome团队的工程主管，还写过那本被大家翻烂了的《Learning JavaScript Design Patterns》。一个在Google搞了十几年工程的人，忽然间给AI编程Agent弄了一套技能包，这事儿本身就挺耐人寻味的，
他干的事儿用一句话就能说明白，就是把高级工程师开发软件的整套工作流，拆解成了24个标准化技能，然后喂给AI编程Agent。
你可能心里会想，这不就是又搞了一套Prompt模板嘛？
还真不是这么回事，这24个技能把从定义需求一直到上线的完整流程全都覆盖了。/spec帮你把产品需求文档写好，/plan负责拆解任务，/build用来写代码，/test负责跑测试，/review做代码审查工作，/code-simplify把代码进行简化，/ship则是部署上线。七个斜杠命令，一条线给串联了下来。
每个技能内部可不是寥寥几句话的提示词，而是非常完整的流程文档。就拿测试驱动开发这个技能来说吧，它把红-绿-重构的循环给定义了下来，规定了测试金字塔80/15/5的比例分配方式，要求去写DAMP而不是DRY的测试代码，并且还引用了一条叫做Beyonce Rule的原则，要是你看不明白代码某一行到底在测什么，那就说明这行代码压根就不需要存在。
这种细节上的精度，真不是随手写个Prompt就能比得上的。
更让我比较在意的是，每个技能里面都包含着一张anti-rationalization表，翻译过来就是反合理化表，专门把AI Agent偷懒时经常说的借口给列出来，然后逐条给出反驳的理由。
比如在测试技能里有这么一条，Agent会说“测试太耗费时间了，我先去写功能然后再加测试”，反驳则是“每次跳过测试都会导致技术债的积累，修复bug所需的成本是写测试的10倍”。
再比如在代码审查技能里，Agent会说“这个改动非常小不需要进行审查”，反驳则是“小改动同样也能引入大bug，系统的韧性取决于它的薄弱环节”。
这张表让我意识到一件事，Osmani不是在教AI怎么去写代码，他是在教AI怎么做到不偷懒。
这件事背后存在着一个很容易被忽略的信号。AI编程Agent目前头号问题并非写不出代码，而是它太急于写了，你让它搭个项目，它上来就是一顿输出，需求还没对齐，边界也没厘清，测试没写，安全没查，代码倒是跑起来了，但技术债堆得跟山一样高，agent-skills的价值恰恰就在这儿，它不是为了让AI变得更强，而是为了让AI变得更有纪律性。
我借助一个具体的场景来解释一下这套流程跟直接让AI写代码的区别在哪。假设你要开发一个用户登录功能，直接跟AI说“帮我写个登录”，它会立刻给你输出一段处理表单提交的代码，可能连密码加密都忘记加了，更别提去做CSRF防护和登录失败次数限制了。
但要是你按照agent-skills的流程来走，先执行/spec，它会先询问你登录方式到底是邮箱还是手机号，需不需要运用第三方OAuth，密码策略是什么，登录失败该如何处理，然后这才开始撰写文档，接着/plan把这份文档拆解成原子任务，每个任务都有了验收标准，到了/build的时候，每个任务都要求先写测试然后再写实现。/review负责检查安全漏洞和代码规范。/ship在部署前还要确认回滚方案和监控告警。
同一件事情，快和稳完全是两种不同的路径，项目里面还藏着一些Google工程文化的痕迹。Hyrum's Law说的是当你的API拥有足够多用户的时候，你的所有实现细节都会被依赖，哪怕你根本没打算暴露这些细节。api-and-interface-design技能直接把这个定律给写进去了。
Chesterton's Fence出现在了code-simplification技能里，意思就是如果一条围栏立在那儿你不知道是因为什么，千万别急着去拆，先搞明白它的用途再说。trunk-based development被写进了git-workflow技能里，Shift Left则写进了ci-cd技能中。
这些并非什么新鲜概念，在Google内部已经运用了十几年了。但它们头一回被系统地打包成了AI Agent的工作流程，这才是不同的地方所在，以前这些知识都藏在几百页的工程实践手册里面，读的人都很少，更别提被机器执行了。现在有些东西正在发生变化，工程经验从一份需要人去理解的文档，变成了一套机器可以直接遵循的流程。
还有一点值得注意，这套技能包支持的工具非常多。Claude Code、Cursor、Gemini CLI、Antigravity、Windsurf、OpenCode、GitHub Copilot、Kiro IDE、Codex都能够使用。Osmani并没有把它绑定在任何一个平台上面，而是做了一个通用的适配层。这个选择挺聪明的，同时也是开源项目能短时间爆到57k星的原因之一。程序员烦的就是被绑死在某个工具上面，你给我自由度，我就给你Star。
除了24个技能之外，项目还带了四个专家Agent角色。code-reviewer就像一个高级工程师在做代码审查工作，test-engineer专门负责搞测试策略，security-auditor搞安全审计，web-performance-auditor则搞性能审计。每个角色都有着自身的视角和专业判断标准，这就相当于给AI团队配了四个不同方向的资深同事。你写完前端代码，可以让web-performance-auditor跑一遍Core Web Vitals检查，让它给你报LCP和CLS的优化建议。你写完接口，可以让security-auditor按OWASP Top 10逐条扫描一遍。
我自己运用AI编程工具有一段时间了，感触比较深的一点就是，AI写代码的速度远远超过了它验证代码的速度。你让它写个功能，三秒钟就输出了，你让它跑测试看看这个功能到底对不对，它反而磨磨唧唧的。结果就是大量代码堆积在那里，表面上看跑得通，底下却全是隐式依赖和未处理的边界条件。
agent-skills的思路是对的，把验证前置了。/build的每一个步骤都要求去写测试，/review在合并前强制进行检查，/ship部署前有清单校验。整个流程里面，证明代码能够工作的权重，丝毫不低于写代码本身。
当然也不是没有可以吐槽的地方。24个技能加上4个Agent角色再加上4份参考清单，全部塞进一个项目里面，信息量其实挺大的。对于刚开始运用AI编程的人来说，可能光搞清楚每个技能该在什么时候触发就需要花费不少时间。项目虽然有meta技能（using-agent-skills）来做引导，但上手门槛依然是存在的。
另外这些技能的设计更多的是凭借大型项目的工程实践，要是你只是想写个个人小工具或者做原型验证，全套流程跑下来可能会有点重。当然你可以只挑选需要的技能来用，但这就需要你自己去判断哪些该用哪些该跳过，而判断力恰恰是新手所欠缺的。
说到底，agent-skills解决的是一个什么时候才会被认真对待的问题。AI编程工具发展到今天，写代码已经不是瓶颈所在了，怎么写得靠谱、写得可维护、写得能上线，才是真正的挑战。
你去翻看agent-skills的Issues和Discussions，能看到不少人在讨论怎么把这些技能适配到自己的团队里面，有人已经开始在公司内部做定制版的仓库了，把Osmani定义的验收标准替换成自己团队的规范，把反合理化表里面的借口换成自己团队常犯的错。这种二次开发本身就说明了一件事，这套流程并非某个工具的卖点，它更像是一份可以被复用的工程方法论。Osmani凭借他在Google十几年的工程经验给出了一个答案，一套可供AI遵循的工程纪律，57k颗星说明很多人认同这个方向。
工具在变快，流程可不能变糙。
