夜雨聆风84.6k Star。作者是 Addy Osmani。
这个名字你可能不熟，但只要你写过前端，你大概率用过他的东西，他参与过 Chrome 团队，写过一堆前端经典书，算是那种把青春都献给浏览器的人。
一个在 Google 干了十几年的老工程师，现在干了一件事，把他脑子里那套「怎么把软件做对」的经验，一条一条编译成了 24 个 skill，装进 AI 编程助手里。
我读完了。
怎么说呢，读的时候我一直在想一个问题，我们天天吐槽 AI 写代码没谱，但有没有人认真想过，问题到底出在哪。
我觉得，不在模型。
这个问题我想了很久，后来发现一个特别贴切的比喻，让 Agent 干活，就像带一个聪明但毛躁的实习生。
你肯定也遇到过这种情况。
让 Claude Code 加个功能，几十秒交差，代码能跑，看着还挺像样。你挺高兴，顺手改了个字段名，结果整个 CSV 列错位了。更离谱的是，它连跑都没跑，就直接告诉你，改好了。
我见过太多这种事了，不是我一个人，你跟任何一个用 Agent 写过正经项目的人聊，他都能给你讲出至少一个这种故事。
以前我总以为是模型不够聪明，后来我发现，根本不是。
是它太快了。快到没有流程。
你想想，一个真人工程师接到需求，脑子里有一套根深蒂固的流程，先确认需求，再想方案，再动手，写完自己测一遍，找个人 review，才敢交付。这套流程不是他天生会的，是他师傅带的，是他踩坑踩出来的，是公司制度逼出来的。
Agent 没有这套东西。它把「完成任务」理解成「把代码写出来」，而不是「把一件事做对」。
所以问题从来不是它没能力，是它没规矩。
我们缺的不是更聪明的 AI，是给 AI 上规矩。
聪明但毛躁的实习生
那我们缺的这套规矩，从哪儿来呢，今天这个仓库，干的就是这件事。
Addy Osmani 出的这个 agent-skills，说到底就是把 Google 那套工程文化，编译成了 AI 能读的指令。
不是给你加功能，是给你加规矩。这句话我读到的时候，愣了一下，就是这个。
整个仓库装了 24 个 skill，排成一条六阶段流水线，Defining，Planning，Building，Verifying，Reviewing，Shipping。定义需求，规划任务，写代码，做验证，审代码，发上线。
每一阶段都有对应的 skill，一共 24 个，你可以按需启用。
六阶段工程纪律流水线
我刚开始看的时候觉得，这不就是把开发流程写了一遍吗，有什么稀奇的。直到我看到它内部的设计，我才明白这东西为什么能拿 84.6k Star。
它内部最让我服气的设计，是那张反合理化表格。
每个 skill 的文档里，几乎都有一张表，左列写着「Agent 想这么干的时候」，右列写着「其实应该这么干」。
比如，Agent 想「写完全部代码再统一测试」，表里对应写，应该每写完一小块就验证。Agent 想「代码能跑就行」，表里对应写，还要考虑边界和错误处理。
反合理化表格
我当时就愣住了。
这不就是活人带实习生那点事吗。实习生最擅长的就是找理由偷懒，代码能跑就算完事，测试最后再说，反正也没人盯着。你作为师傅，得预判他每一个偷懒的借口，提前堵住。
这张反合理化表格干的事，就是把 Agent 会找的每一句借口，全部提前拆穿。
我特别喜欢它设计里的另一句话，验证不可协商。
Agent 一旦跳过验证步骤，就算输出再漂亮，也算任务失败。Red Flags 红旗清单一列，不照做就不算完成。它把「过程」和「结果」焊死了，不是不许出错，是不许跳过检查。
这个设计思路，说实话，比很多人类团队的管理制度都先进。
还有更狠的，它让 Agent 写完代码，先怀疑自己。
24 个 skill 里，有一个名字特别反常，doubt-driven-development，怀疑驱动开发。
它让 Agent 写完代码之后，主动怀疑自己。我这个假设成立吗，有没有我没验证的边界，我是不是偷懒了。然后交叉检查，对质，直到没有疑问才收工。
怀疑驱动开发
你品品这个设计。
正常人类的开发流程里，谁会有这一套。写完代码，自己先当一遍喷子，把自己刚写的东西往死里挑毛病。这太反人性了，但是太特么有用了。
我一开始觉得这有点矫枉过正，后来我想通了，对 Agent 来说，这一步恰恰是必要的。因为它没有羞耻心，它不会因为自己写的东西烂而脸红，它需要被程序化地强制怀疑。
你说它严格吗，严格。但正是这个强制的怀疑，能逼出那些你根本没想到的边界 case。
说了这么多，你是不是也心动了，怎么装呢，其实比你想的简单。
装进 Claude Code 里，比我想象的简单，三步。
第一步，添加插件市场。
/plugin marketplace add addyosmani/agent-skills
第二步，安装插件。
/plugin install agent-skills@addy-agent-skills
第三步，直接甩需求让它干活。
/spec 帮我做一个定时导出 CSV 的功能
装完你会多出 8 个斜杠命令，/spec，/plan，/build，/test，/review，/webperf，/code-simplify，/ship。还有 4 个专职人格，代码评审员，测试工程师，安全审计员，Web 性能审计员，全给你配齐了。
这个设计也有意思，它不逼你背一堆命令，你只需要记住一个 /spec，让 Agent 先跟你把需求聊清楚，剩下的流程它会自己带着你走。
不过装之前，有几个坑，我得提前跟你说。
第一，别 24 个全装。
我之前就干过这种蠢事，看到好东西就想全上，结果把上下文和响应速度全拖垮了。这套东西的设计哲学是按需加载，用到哪个开哪个，别贪多。
第二，Spec 阶段别跳。
我刚开始图快，直接让 /build，结果它按自己脑补的需求写，返工了两次。后来老实先跑 /spec，一次过。过程省不得，这条我觉得放到任何方法论里都成立。
第三，它严格起来是真严格。
走 test-driven-development 的时候，Agent 会坚持先看到测试失败。我一度觉得啰嗦，但正是这个强制的失败，逼出了几个我没想到的边界 case。
还有一件事我得多嘴一句，这套东西的底色，其实是 Google 那套工程文化。Software Engineering at Google 这本书里的东西，Hyrum 定律，切斯特顿栅栏，主干开发，左移测试，80 15 5 的测试金字塔，等于把一本 Google 工程手册，编译成了 Agent 能读的指令。
一个在 Google 写了十几年代码的人，把自己觉得对的东西，全部沉淀成了制度。这个事本身，就挺打动我的。
这个事让我想得比较多的，是更远一点的东西。
说实话，我写这篇文章的时候，脑子里一直在绕一个更大的问题，纪律和创造力，到底是什么关系。
我们这个行业，尤其是做 AI 内容的，天天把创造力挂在嘴边，好像纪律是创造力的敌人，好像越散漫越有才气。但你去看那些真正做出东西的人，米开朗基罗画西斯廷天顶，先画了四年的素描。贝多芬的手稿，改得密密麻麻。伟大的创造力底下，全是纪律打的地基。
Agent 也是一样的。它不是不聪明，它是没规矩。你给它装上规矩，它才能把聪明用在正地方。
我甚至觉得，这才是 AI 编程的下一个阶段，不是模型更聪明，是流程更成熟。就像当年软件开发从个人英雄主义，走到工程化，靠的不是更厉害的程序员，是流程、制度、checklist，是 CI，是 code review，是把「靠谱」变成可以复制的东西。
我挺期待 Agent 也走一遍这条路。
差不多了，最后再掏几句心里话。
回到开头那个问题，AI 写代码为什么总翻车。我现在有了一个更确定的答案，不是它笨，是它没有流程，没有规矩。
agent-skills 给我的感觉，不是多了一个工具，是把一个聪明但毛躁的实习生，带成了有工程师样子的同事。装上之后我第一次觉得，这个 AI，终于有工程感了。
这套东西现在 84.6k Star，MIT 开源，不要钱，装一下只要三分钟。如果你也在跟「Agent 写完但没做对」较劲，我真的建议你给它一个周末。
反正，我装上了，也还在摸索。你说它是不是万能药，那肯定不是，它解决不了模型本身的问题，也解决不了需求没说清楚的问题。但至少，它让 Agent 干活的时候，多了一分敬畏。
这分敬畏，值很多个星标。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～ 谢谢你看我的文章，我们，下次再见。
关注Agent技能库，每天认识一个可用的AI Agent Skill。
