今天 GitHub 热榜有一个很扎眼的信号：Agent Skills 集体冒头。

日榜里，obra/superpowers 排到第 2，主打 agentic skills framework 和软件开发方法论；K-Dense-AI/scientific-agent-skills 排到第 3，给科研、工程、分析、金融、写作准备了一组可直接使用的 Agent Skills。月榜更夸张，mattpocock/skills、multica-ai/andrej-karpathy-skills、ComposioHQ/awesome-codex-skills、addyosmani/agent-skills、NousResearch/hermes-agent、zilliztech/claude-context、rohitg00/agentmemory 一起出现。

这不是普通的“又一批提示词模板”。我更愿意把它看成 AI 编程进入第二阶段的标志。

第一阶段是 Prompt：你怎么问，它怎么答。

第二阶段是 Skills：你把一套可重复的工作方法交给 Agent，让它在合适的时候自己调用、自己检查、自己把事情做完。

说白了，Prompt 是一次性沟通，Skills 是长期资产。

Skills 到底是什么？

不同项目叫法不完全一样，但核心很接近：把人类工程师的经验、流程、约束、检查清单和命令封装成 Agent 可以执行的能力单元。

一个 Skill 通常会包含几类东西：

  • 什么时候触发，比如写计划、做 code review、修 bug、跑测试、发版；
  • 应该遵守什么原则，比如先写规格、改动要小、不要乱重构、测试必须通过；
  • 具体怎么做，比如读哪些文件、跑哪些命令、怎样拆任务、怎样验证；
  • 有哪些坑，比如不要把临时假设写成长期规则，不要跳过失败测试，不要把无关代码顺手“优化”掉。

这听起来朴素，但很有用。因为编程 Agent 最大的问题往往不是“不会写代码”，而是“没有稳定的工作习惯”。它今天认真写测试，明天又偷懒；这个项目知道先读 README，另一个项目直接开改；这次知道小步提交，下次又一次性改 20 个文件。

Skills 的价值，就是把这些习惯从人的脑子里拿出来，变成 Agent 每次都能看到、能执行、能复用的东西。

CLAUDE.md、Claude Skills、Codex Skills，有什么区别？

热榜上这些项目容易让人看晕。其实可以按层级理解。

1. CLAUDE.md：给 Agent 的项目说明书

CLAUDE.md 最像“写给 AI 同事的入职手册”。

multica-ai/andrej-karpathy-skills 的核心就是一个 CLAUDE.md 文件，里面写了很多降低 LLM 编程错误的行为准则：先想清楚再写代码，优先简单方案，只做必要改动，定义成功标准，循环验证结果。

我很喜欢这一类文件，因为它便宜、直接、立刻有效。你不需要上复杂框架，只要把项目里的关键约定写清楚，Agent 的行为就会稳定很多。

但它也有上限。CLAUDE.md 更像一份全局规则，适合告诉 Agent “在这个项目里怎么做人”。如果你想把 code review、TDD、发布、调试、文档写作分别做成可调用流程，光靠一个文件会越来越臃肿。

2. Claude Code Skills：可复用的任务模块

Claude Code 的 Skills 更像模块化能力包。每个 Skill 负责一种场景，带着自己的说明、步骤、约束和可能用到的脚本。Agent 不需要每次都把所有规则塞进上下文，而是在任务相关时加载对应能力。

这点很关键。

上下文不是垃圾桶。把所有经验一股脑塞进去，Agent 只会越来越迷糊。Skills 的方向是把知识分层：项目级规则放在 CLAUDE.md，通用工作流做成 Skill，临时任务留在当前对话里。

这才像一个能长期维护的系统。

3. Codex Skills：把工作流带到另一个 Agent 生态

ComposioHQ/awesome-codex-skills 代表的是另一条线：Codex 也需要自己的 Skills 清单。

这说明 Skills 不是 Claude Code 独有的小功能，而是所有 Coding Agent 都会遇到的共同需求。只要 Agent 能读代码、改文件、跑命令，它就需要工作方法。否则模型越强，越可能把错误放大得更快。

强模型像马力更大的车。Skills 像方向盘、刹车和驾驶习惯。只追马力，不管驾驶方式，迟早撞墙。

4. Agent Skills：把资深工程师的流程打包

addyosmani/agent-skills 的定位很清楚：把生产级工程技能打包给 AI coding agents。它把开发生命周期拆成 /spec、/plan、/build、/test、/review、/code-simplify、/ship 等命令，每个阶段有对应原则。

这类项目的重点不是“让 Agent 写更多代码”，而是让 Agent 按软件工程的节奏走。先定义要做什么，再拆小任务，再增量实现，再测试，再审查，再发布。

听起来像常识。但常识最容易被 Agent 忽略。

我看完 6 个仓库后的判断

这波热度背后有三个变化。

第一，开发者不再满足于“会生成”

过去大家试 AI 编程，最兴奋的是它能不能一口气写出一个功能。现在大家更关心：它能不能少犯错？能不能稳定遵守项目规范？能不能自己验证？能不能在大型代码库里不迷路？

这就是从玩具到工具的分界线。

一个 Demo 可以靠灵感。一个真实项目靠流程。

mattpocock/skills 的 README 里说得很直白：这些 skills 是他每天做真实工程会用的，不是 vibe coding。这个表述挺狠，也挺准。大家对“AI 随便写一坨”的耐心正在变少。

第二，经验开始产品化

以前，一个团队里的好习惯大多靠人传人：资深工程师 code review 时提醒你，测试要这样写；Tech Lead 在评审时说，这个抽象太早了；发布出事之后大家补一条 checklist。

现在这些经验可以被写进 Skills。

这件事的意义不小。因为它让团队的工程品味变得可复制。新来的 Agent 不需要靠运气摸索，也不需要每次都等人纠错。它可以从第一天就知道：这个团队怎么拆任务，怎么写测试，怎么处理风险，怎么判断“完成”。

当然，前提是你真的愿意把经验写清楚。很多团队的问题不是没有 AI，而是连人类新人都看不懂项目约定。AI 只是把这个问题照亮了。

第三，Agent 的竞争点开始从模型转向工作流

模型能力当然重要。但只要模型能力接近，差距就会落到工作流上。

谁有更好的上下文管理，谁更少重复解释；谁有更好的 Skills，谁更少返工；谁有更好的验证流程，谁更敢把任务交给 Agent；谁能把权限、工具、测试、审查串起来，谁就更接近真正的自动化。

这也是为什么 claude-context、agentmemory 这类项目会和 Skills 一起热。Skills 解决“怎么做”，Context 和 Memory 解决“知道什么”和“记得什么”。三者合起来，Agent 才不像每天失忆的实习生。

普通开发者应该怎么用？

我的建议很简单：别一上来就装一堆花哨技能。先从最痛的地方开始。

1. 先写一个项目级 CLAUDE.md

把项目里最容易踩的坑写进去：

  • 技术栈和启动命令；
  • 测试命令和常见失败原因；
  • 代码风格和目录约定；
  • 哪些文件不能乱动；
  • 数据库、生产环境、密钥相关的禁区；
  • 提交前必须做的检查。

不要写成企业制度。越短越好，越具体越好。

“保持代码高质量”这种话没用。“改 API 后必须同步更新 openapi.yaml 并跑 npm run test:contract”才有用。

2. 把重复流程拆成 Skills

如果你发现自己经常对 Agent 说同样的话，就该考虑做成 Skill。

比如：

  • 修 bug：先复现，再写失败测试，再修复，再跑相关测试；
  • Code review：先看需求，再看 diff，再找安全、兼容、测试缺口；
  • 写博客：先查资料，再列观点，再写中英双语，再验证构建；
  • 发版：先看变更，再跑测试，再更新 changelog，再打 tag。

这些都不神秘。真正有价值的 Skill，大多是“老工程师嫌你偷懒时会说的话”。

3. 给 Skills 留维护机制

Skills 不是写完就完事。

项目变了，命令变了，工具变了，坑也会变。如果 Skill 过期，Agent 会稳定地犯旧错误，而且犯得很自信。这比没有 Skill 更烦。

所以我建议把 Skills 当成代码资产维护：有版本，有 review，有使用反馈，有删除机制。别把它变成另一个没人敢动的知识库坟场。

这波热潮也有坑

我对 Skills 很看好，但不建议神化。

第一，Skills 不能替代工程判断。它能提醒 Agent 做检查，但不能保证设计一定对。架构、安全、数据迁移这种事，人还是要认真看。

第二，Skills 写太多会反噬。规则越多，冲突越多，Agent 越容易装作理解了，实际执行得乱七八糟。好的 Skill 应该小、准、可验证。

第三，别把别人的 Skills 原封不动搬进项目。Matt Pocock、Addy Osmani、Karpathy 的习惯当然值得学，但你的项目有自己的约束。照抄一大坨，最后往往像给 Agent 穿了件不合身的西装。

第四，Skills 会暴露团队真实水平。你写不出好 Skill，很多时候不是表达问题，而是团队流程本来就没想清楚。这个有点扎心，但很真实。

我的结论

Claude Code 的 Skills 不是“高级提示词模板”。它更像 AI 编程时代的工作流资产。

以后区分一个团队会不会用 AI 编程，我觉得不只看他们用 Claude、Codex 还是 Cursor，而要看三件事：

  • 有没有清楚的项目上下文；
  • 有没有可复用的任务 Skills；
  • 有没有强制验证的质量门槛。

没有这些，Agent 再聪明也只是一个跑得很快的临时工。有了这些，它才可能变成一个能被信任的异步同事。

今天 GitHub 热榜把这个信号放大了：大家终于开始意识到，真正值钱的不是那一句 prompt，而是你多年工作里沉淀下来的判断、流程和品味。

把这些写成 Skills，可能就是下一阶段 AI 编程最朴素、也最有用的动作。

参考链接

  • Anthropic Claude Code Skills 文档：https://docs.anthropic.com/en/docs/claude-code/skills
  • mattpocock/skills：https://github.com/mattpocock/skills
  • multica-ai/andrej-karpathy-skills：https://github.com/multica-ai/andrej-karpathy-skills
  • ComposioHQ/awesome-codex-skills：https://github.com/ComposioHQ/awesome-codex-skills
  • addyosmani/agent-skills：https://github.com/addyosmani/agent-skills
  • obra/superpowers：https://github.com/obra/superpowers
  • K-Dense-AI/scientific-agent-skills：https://github.com/K-Dense-AI/scientific-agent-skills
  • zilliztech/claude-context：https://github.com/zilliztech/claude-context
  • rohitg00/agentmemory：https://github.com/rohitg00/agentmemory