OK，到此为止我们只聊了「Skills 是什么」和「怎么写」。但真正让我觉得这个话题值得专门写一篇文章的，是它的生态——这场爆发来势之快超出了大多数人的预期。
数据层面
截至 2026 年 5 月：
| 项目 | Stars | 定位 |
|---|---|---|
| anthropics/skills | 136,000 | Skills 官方仓库 + 规范 |
| obra/superpowers | 194,000 | 第三方 Skills 框架 + 方法论 |
| anthropics/claude-code | 124,000 | Claude Code 本体 |
| agentskills.io | - | 开放标准官网，25+ 平台已接入 |
几个关键数字值得单独展开：
136,000 星是什么概念？Taichi（太极图形框架）是 26,000 星，Vue 2 是 208,000 星。Skills 作为一个「文件夹规范」项目，在不到一年的时间里达到了太极的 5 倍体量，逼近一个前端框架巨头的热度。这背后的市场信号不应该被忽视。
194,000 星的 Superpowers 又是什么？这不是 Anthropic 官方的项目，而是独立开发者 Jesse Vincent 用 Skills 标准做的一个「方法论框架」。它不光给你 Skills，还给你一套完整的开发流程——从头脑风暴、写 Spec、拆分任务、子 Agent 并行开发、RED-GREEN-REFACTOR 到代码审查，全部用 Skills 编排。194,000 星的体量超过了 Claude Code 本身，说明市场对「高层次的 Agent 工作流编排」需求旺盛。
平台接入
agentskills.io的 Client Showcase 页面列出了目前已接入 Agent Skills 标准的产品。挑几个我觉得有代表性的：
- Claude Code / Claude.ai：Skills 的原始推动者，原生支持最好
- GitHub Copilot / VS Code：微软系全线接入，意味着企业开发者的主流工具链已经覆盖
- Cursor：独立 AI IDE 的标杆，Skills 支持让它能复用整个生态的能力
- OpenAI Codex：OpenAI 的 Agent 产品也跟进了这个标准——这意味着这不是 Anthropic 的一家之言
- Gemini CLI：Google 的终端 Agent 工具也已接入
- JetBrains Junie：IDE 巨头的新 Agent 产品线
- Spring AI：Java 生态最大 AI 框架，2026 年 1 月就宣布了通用 Skills 支持
- Laravel Boost：PHP 框架官方提供的 Skills 包
从 IDE 到 CLI，从云平台到框架，从闭源产品到开源项目——Skills 的覆盖范围已经不是一个「实验性功能」的体量了。
为什么标准化的速度这么快？
我在 Architecture Decision Record 里写过无数次类似的判断：一个技术标准的采纳速度，取决于它解决的是「谁的问题」以及「这个问题有多痛」。
Skills 标准解决的是 AI Agent 的「最后 20%」问题——模型可以写代码，但写出来的代码不符合你的项目规范；可以分析数据，但不知道你的数据 schema；可以做 CRUD，但不知道你的团队约定。
这些问题每个用 AI 写代码的工程师每天都在遇到。而 Skills 用了最轻量的方式来解决——一个 Markdown 文件，不需要跑服务，不需要注册 API，不需要学新语言。门槛为零，收益肉眼可见。
这就是它扩散速度的根本原因。
第三方 Skills 爆发：从 Superpowers 到企业级实践
官方仓库anthropics/skills提供了 docx、pdf、pptx、xlsx 四个文档类 Skill，以及一些示例性质的 creative/development 类 Skill。但真正让生态起飞的，是第三方。
Superpowers：不只是 Skill 库，是一套开发方法论
前面提过，Superpowers 由独立开发者 Jesse Vincent 打造，已经发展到 v5.1.0（2026 年 5 月 4 日发布）。它的核心卖点不是「给你一堆 Skill」，而是「教你用 Skills 怎么把 AI Agent 变成一个正经的开发团队」。
它的工作流分为 7 个阶段：
- 头脑风暴：Agent 用苏格拉底式提问帮你理清需求，输出一份设计文档
- Git Worktree：每个特性在隔离的 worktree 分支上开发
- 写 Plan：把 Spec 拆成 2-5 分钟一个的微小任务
- 子 Agent 并行开发：每个任务派一个独立的 Agent 实例去执行
- RED-GREEN-REFACTOR：严格执行测试驱动开发
- 代码审查：任务之间自动检查是否偏离 Plan
- 分支合并：完成后自动生成 PR / 合并 / 清理
说实话，我刚看到这个流程的时候，第一反应是：「这不就是把人做的事情写成 prompt 丢给 AI 吗？」
但我花了一个下午实际跑了两个任务之后，看法变了。
关键不在于每个步骤本身——Brainstorm、写 Spec、TDD，这些方法论谁不知道？关键在于 Skills 把这些步骤标准化成了可复用的上下文片段。以前你每次开一个新项目，都得花 20 分钟给 Agent 解释你的开发流程。现在你只需要告诉它「用 Superpowers」，然后它就照着那套流程走了。
这就是 Skills 生态的网络效应——你能复用的不是某个方法，而是别人已经打磨好的、经过验证的、可以开箱即用的整套工作流。
企业级实践的信号
除了 GitHub 上看得见的开源项目，企业级的布局也在加速。Spring AI 在 2026 年 1 月就宣布了对 Generic Agent Skills 的支持——这意味着任何使用 Spring 技术栈的企业，都可以把内部的编码规范、部署流程、故障排查手册写成 Skills，然后让所有开发者的 AI Agent 自动加载。
Laravel Boost 也是同样的逻辑：框架官方提供的 Skills 包，确保 AI 生成的 Laravel 代码从一开始就遵循最佳实践。
Databricks Genie Code 的 Skills 支持，意味着大厂的数据工程师也可以用 Skills 来规范 AI 在 Snowflake/Spark 上的 SQL 生成行为。
这些信号凑在一起，指向了一个结论：Skills 正在从「AI 工具的附加功能」变成「团队开发基础设施的一层」。就像 .editorconfig 统一了编辑器格式、ESLint 统一了前端编码规范、Dockerfile 统一了环境配置，SKILL.md 正在成为「AI Agent 的行为规范」。
10 年架构师的独家观察
这一节是我写这篇文章的主要动力。
作为一个在分布式系统、微服务架构、中间件开发领域摸爬滚打超过十年的人，我看过太多的技术热词来了又走。Oozie、Azkaban、Mesos、Swarm……这些名字今天还有多少人记得？
但 Skills 给我一种不一样的感觉。不是因为它的技术有多深，而是因为它卡在了一个正确的时间点上，用了一个正确的姿态。
判断一：「给 AI 装技能」正在成为新的开发范式
我定义一个「范式」的标准很简单：它改变了工程师每天的工作方式，而不是给现有的工作方式增加了一个新选项。Git 是范式（它改变了代码管理方式），Docker 是范式（它改变了部署方式），Kubernetes 勉强是（它改变了运维方式，但学习曲线太高，限制了大面积普及）。
Skills 有成为范式的潜质，因为它解决了一个根本矛盾：AI 越来越强，但它永远不知道你的项目长什么样。你每次开一个新的 Chat，它都是一个失忆的天才少年——什么都能聊，但就是对你们团队的约定一无所知。
Skills 给了这个天才少年一本「团队手册」。从此以后，你不需要每次开会前重新介绍情况。
而且最关键的是：写 Skills 的成本几乎为零。一个 Markdown 文件，10-20 行 YAML，放进文件夹里就行。不需要跑一个新的服务，不需要注册 API Key，不需要学新的 DSL。这个零门槛的特性，是它渗透率指数级增长的基础。
判断二：开放标准 strategy 是神来之笔
Anthropic 做了一个我见过的最聪明的技术战略动作：把 Skills 标准开源并交给社区治理。
这个动作让我想起 Kubernetes。当年 Google 如果把 Borg 的 API 封闭授权给 AWS 和 Azure，今天云原生的格局会完全不同。但 Google 选择把 Kubernetes 开源给 CNCF 治理——结果呢？Google Cloud 虽然在三大云里排第三，但 Kubernetes 成了事实标准，意味着任何企业上云都在用 Google 的设计哲学部署容器。
Anthropic 在做一模一样的事情。agentskills.io是一个独立的开放社区，它不归 Anthropic 所有。标准由社区维护，Claude Code 只是 25 个兼容客户端中的一个。这意味着 Skills 的成功，不需要 Claude 模型一家独大——哪怕你用 OpenAI Codex、GitHub Copilot 或 Gemini CLI，Skills 同样有效。
但同时，Anthropic 通过率先推动这个标准，掌握了「解释权」——当所有平台的 Skill 都是按 Anthropic 的设计哲学来组织的，Claude 模型就是理解 Skills 最自然、最准确的模型。
这不是技术层面的胜利，而是架构影响力的胜利。用一个开放标准，把整个 AI 编程工具的生态圈拉到自己的设计轨道上。
判断三：生产环境中真正需要担心的事
上面说了很多好话，但作为一个在线上排查过无数次生产事故的人，我必须泼一杯冰水：Skills 在生产环境里的安全风险，目前被严重低估了。
Skill 不是只读的 instruction。一个 Skill 可以包含 shell 脚本、Python 脚本，可以在 Agent 的执行上下文中运行。这意味着什么？如果你装了来路不明的第三方 Skill，它完全可以：
- 读取你的环境变量（包括 API Key、数据库密码）
- 把文件内容发送到外部服务器
- 在你的代码里注入后门（通过指导 Agent 写出带漏洞的代码）
Anthropic 的官方博客里有一句话说得很委婉但很诚实：「只从可信来源安装 Skills，仔细审计不太可信的 Skills。」
问题是，普通开发者不具备审计能力——他们只是想把代码写完，谁会去看一个 python 脚本里是不是藏了恶意逻辑？
我的建议是：如果你在一个生产项目中用 Claude Code 或类似的 Agent 工具，Skills 的安装和管理应该纳入团队的 Code Review 流程。每个新增的 Skill 都应该在 PR 里经过至少一个人的审计——不是看它有没有语法错误，而是看它有没有做不该做的事。
这一点不解决，Skills 在企业级市场的大规模铺开会遇到显著阻力。
判断四：对个人开发者的建议
如果你是一个独立开发者，或者小团队的 TL，我的建议只有两条：
- 现在就开始写团队自己的 Skill。从最痛的点开始——比如数据库查询规范、API 响应格式、日志规范、错误处理约定。一个 Skill 写 20 行，一周积累 3-5 个，一个月后你的 Agent 就像换了一个人。
- 关注 Skills 生态，但不急着用所有第三方 Skill。生态还在早期，质量参差不齐是很正常的。先把自己的核心 Skill 打磨好，再逐步引入经过验证的第三方 Skill——Superpowers 的流程框架、官方的文档处理 Skill 都是安全的选择。
常见问题
Q: Skills 和 Prompt Engineering 有什么区别？
A: Prompt Engineering 是你每次手动告诉 AI 怎么做。Skills 是把这些指令写成标准文件，让 AI 自动加载、按需引用。前者是「口头交代」，后者是「给了一本操作手册」。对于一次性的任务，写 prompt 足够；对于反复出现的场景，写 Skill 更高效。
Q: 我的团队不用 Claude Code，还能用 Skills 吗？
A: 能。Skills 是一个开放标准，不是 Claude Code 独占。GitHub Copilot、VS Code、Cursor、OpenAI Codex、Gemini CLI 都已接入。具体到每个工具的放置目录可能不同（比如 VS Code 是.agents/skills/，Claude Code 是.claude/skills/），但 SKILL.md 文件本身是通用的。
Q: SKILL.md 写多长合适？
A: 官方推荐主文件控制在 500 行以内，5000 tokens 以下。详细的参考资料放到references/目录里，用「当遇到 X 情况时阅读 Y 文件」的方式按需加载。
Q: Skills 会替代 MCP Server 吗？
A: 不会。它们是互补关系。Skill 告诉 Agent「怎么做一件事」，MCP Server 给 Agent「做这件事需要的工具」。一个类比：Skill 是维修手册，MCP 是工具箱——你不会因为有了维修手册就把扳手扔了。
Q: 有什么 Skills 的社区或资源可以推荐？
A: 我现在主要看三个来源：agentskills.io（官方规范 + 客户端列表）、github.com/anthropics/skills（官方示例）、github.com/obra/superpowers（最好的第三方 Skills 框架）。中文资源目前还比较少，这篇文章算是第一批覆盖这个话题的。
说到底，Skills 这个概念本身并不复杂——它就是把「给 AI 的说明书」做成了一个标准格式。但正是这种简单，让它有可能成为下一层技术基础设施，就像 Makefile 和 Dockerfile 曾经做的那样。
我在 2014 年第一次接触 Docker 的时候，周围大多数人的反应也是「这不就是一个轻量级虚拟机吗，有必要搞个新概念？」——十年后回头看，Docker 改变了整个行业的部署方式不是因为它的技术深度，而是因为它让「环境一致性」这件事的门槛降到了零。
