但紧接着我又打开了一个页面agentskills.io一个 Skills 生态的官方网站。上面密密麻麻地列着 25 个已接入 Agent Skills 标准的产品——Claude Code、Cursor、GitHub Copilot、VS Code、OpenAI Codex、Gemini CLI、JetBrains Junie、Spring AI……这个名单还在以肉眼可见的速度增长。坦白讲我在技术圈混了这么多年很少看到一个新标准在半年内让这么多竞品同时接入。上一个做到这一点的大概是 Kubernetes。于是我做了一件每个技术人都会做的事花了一周时间把整个 Skills 生态翻了一遍。这篇文章就是这一周的产物——从「Skill 到底是什么」到「怎么写出第一个能用的 Skill」再到我对这场生态爆发的判断。Skill 到底是什么一个文件夹改变 AI 的行为模式先说结论Skill 是一套标准化的、可复用的、跨 Agent 平台共享的「知识包」。它不是系统 prompt 的包装纸不只是给 AI 加一段指令而是一个自带上下文、脚本、参考资料的完整文件夹。一个 Skill 的目录结构长这样my-skill/ ├── SKILL.md # 必需元数据 指令 ├── scripts/ # 可选可执行代码 ├── references/ # 可选参考文档 └── assets/ # 可选模板、图片等资源核心只有一个SKILL.md 文件。它用 YAML frontmatter 声明自己的名字和触发条件正文里写清楚做这件事的步骤和注意事项。一个最简单的 Skill 只需要 10 行--- name: roll-dice description: Roll dice using a random number generator. --- To roll a die, use the following command that generates a random number from 1 to the given number of sides: echo $((RANDOM % sides 1)) Replace sides with the number of sides on the die.就这么简单。但就是这套极简的约定催生了一个 13.6 万星的项目和一个 25 平台的生态系统。为什么「文件夹」这个设计是刻意为之这里有一个设计决策大多数写 Skills 教程的人不会提但我觉得它是整个架构里最聪明的一步渐进式加载Progressive Disclosure。Skill 分三层加载第一层元数据约 100 tokens。Agent 启动时只读取每个 Skill 的name和description够它判断「这个 Skill 能不能用在这里」就行。第二层指令正文推荐 5000 tokens。当 Agent 判断 Skills 匹配当前任务才把完整的 SKILL.md 加载进上下文。第三层附属资源按需加载。scripts/里的脚本、references/里的详细文档只有实际用到的时候才读。这意味着什么意味着你可以在一个项目里放 50 个 SkillAgent 启动时的上下文开销只比放 1 个 Skill 多那么一点点——因为每次只加载元数据。相比之下如果你把同样的 50 段说明书直接塞进系统 prompt上下文早就爆了。这个设计让 Skills 的「可堆叠性」成为现实。你不需要在「功能丰富」和「上下文不够」之间做取舍——这是 MCP Server 和 Plugin 做不到的。一个更贴近真实开发的例子上面那个掷骰子的 Skill 只是一个入门演示。来看看一个真实的、在生产环境里能用的 Skill 长什么样。假设你的团队有一个 Java 项目所有数据库查询都要加deleted_at IS NULL做软删除过滤但新来的 AI Agent 根本不知道这个约定。于是它生成的 SQL 会把已删除的数据也算进来——这种事情在生产环境里发生一次后果不用我说。把这个约定写成 Skill--- name: java-db-query description: Write database queries for our Java project. Use when writing SQL, JPA, or MyBatis queries involving database tables that use soft deletes. --- ## Database Query Conventions ### Soft Delete Rule (CRITICAL) All tables use soft deletes via a deleted_at column. Every SELECT query MUST include WHERE deleted_at IS NULL unless the user explicitly asks for deleted records. ### Gotchas - The users table uses user_id in the DB, but uid in the auth service. Both refer to the same value. Never confuse them. - The /health endpoint returns 200 even if the DB is down. Always use /ready for health checks. ### Example - Correct Query SELECT * FROM orders WHERE user_id ? AND deleted_at IS NULL ORDER BY created_at DESC; ### Example - Wrong (Will Include Deleted Records) SELECT * FROM orders WHERE user_id ?;这个 Skill 放到项目里的.claude/skills/目录下每次 AI 写 SQL 的时候它会自动加载这些约束。一个团队在 CI 里跑了 100 次 SQL 生成的测试有 Skill 的情况下SQL 的正确率从 42% 提升到了 91%。这就是为什么这个「文件夹」值 13.6 万星——它解决的不是一个技术问题而是一个范式问题怎么让 AI 真正理解你的项目而不是每次都从零开始猜。Skill vs MCP vs Plugin三者的本质区别这个话题必须讲清楚因为我在各种技术群里看到太多人在问同样的问题「Skills 和 MCP Server 到底什么关系是不是竞品」答案是它们是不同层面的东西互补关系不是替代关系。打个类比SkillMCP ServerPlugin本质做事的方法论外部工具的接口平台的扩展模块给 Agent 什么「怎么干」的 know-how「能调用什么」的工具能力「多了什么功能」的扩展类比老师傅的操作手册工具箱里的新工具给车装的新零件格式标准SKILL.md开放标准JSON-RPC over stdio/SSE各平台自定义跨平台任意兼容 Agent Skills 的平台任意支持 MCP 的客户端仅限特定平台上下文开销渐进式加载极低每次调用固定开销取决于平台更具体地说Skill 告诉你「怎么把一件事做对」。比如「写 SQL 的时候记得加deleted_at IS NULL」「用 pdfplumber 做 PDF 文本提取」「做 code review 的时候重点看认证检查和安全漏洞」。它是知识层面的东西。MCP Server 给你「能做一件新的事」。比如「去数据库里查这张表」「往 Slack 发一条消息」「调一下 GitHub API 创建 Issue」。它是能力层面的东西——Agent 本来不会连接外部系统MCP 给了它那个连接。Plugin 给平台加「一个新功能模块」。比如 VS Code 的 GitLens 插件、Claude Code 的 plugin marketplace。它是平台层面的扩展。三者可以协同工作一个 Skill 里可以写「用 MCP Server X 去查数据库然后按这个格式输出」。Skill 是大脑MCP 是手Plugin 是装备栏。为什么这件事值得花时间理清因为我在好几个技术群里看到同一个误解「有了 MCP Server 就够了要 Skill 干嘛」——这就像你说「有了扳手就够了要维修手册干嘛」。工具和知识从来不是二选一。开发你的第一个 Skill从零到可用好理论讲够了。这一节我带你从头写一个真实可用的 Skill。场景设定你的项目是一个 Spring Boot 微服务所有 REST API 都有统一的响应格式{ code: 200, message: success, data: { ... } }你希望 AI Agent 在写 Controller 的时候自动遵循这个格式而不是写出五花八门的响应结构。第一步创建 Skill 目录mkdir -p .claude/skills/spring-api-response cd .claude/skills/spring-api-response目录名必须全小写用连字符分隔。这个名字就是 Skill 的name。第二步写 SKILL.md--- name: spring-api-response description: Write Spring Boot REST API controllers with the projects standard response format. Use when creating or modifying REST endpoints in a Spring Boot project. --- ## Standard API Response Format All REST endpoints MUST return ApiResponseT: java Data AllArgsConstructor NoArgsConstructor public class ApiResponseT { private int code; private String message; private T data; public static T ApiResponseT success(T data) { return new ApiResponse(200, success, data); } public static T ApiResponseT error(int code, String message) { return new ApiResponse(code, message, null); } }Controller PatternRestController RequestMapping(/api/users) RequiredArgsConstructor public class UserController { private final UserService userService; GetMapping(/{id}) public ApiResponseUserDTO getUser(PathVariable Long id) { UserDTO user userService.findById(id); return ApiResponse.success(user); } PostMapping public ApiResponseUserDTO createUser(Valid RequestBody CreateUserRequest request) { UserDTO user userService.create(request); return ApiResponse.success(user); } }GotchasNever return rawResponseEntityunless you have a specific reason(like setting custom HTTP headers). TheApiResponsewrapper IS yourHTTP body.Thecodefield follows HTTP status semantics: 200 success,400 bad request, 500 internal error. Dont invent custom codes.All DTOs go indto/subpackage, not in the controller class asinner classes.### 第三步验证 Skill 是否被加载 在 Claude Code 中安装 Skills 后启动时会看到技能列表。或者直接让 Agent 帮你写一个 Controller看它是否自动返回 ApiResponseT。 bash # 在 Claude Code 中测试 帮我写一个查询订单列表的 Controller支持分页如果 Skill 工作正常Agent 生成的代码会自动包含ApiResponsePageResultOrderDTO的返回类型和正确的静态方法调用。第四步迭代优化Skills 不是写一次就完事的。我的建议是每次 Agent 犯了你想纠正的错误就把纠正规则加到 Skill 里。这是 Skill 积累价值最快的方式。比如写了上面那个 Skill 后Agent 还是偶尔忘记在Valid注解的请求体上处理MethodArgumentNotValidException那就加一条 Gotcha### Gotchas (追加) - When using Valid RequestBody, ALWAYS add a global ExceptionHandler for MethodArgumentNotValidException that returns ApiResponse.error(400, fieldErrors). Without this, validation errors return a raw 400 with Springs default HTML error page.这就是 Skills 开发的核心循环发现问题 → 写成 Skill → Agent 不再犯 → 遇到新问题 → 追加规则 → 持续收敛。两周下来你的 Agent 就会比第一天聪明一大截。生态全景从 13.6 万星到 25 平台Skills 正在成为标准OK到此为止我们只聊了「Skills 是什么」和「怎么写」。但真正让我觉得这个话题值得专门写一篇文章的是它的生态——这场爆发来势之快超出了大多数人的预期。数据层面截至 2026 年 5 月项目Stars定位anthropics/skills136,000Skills 官方仓库 规范obra/superpowers194,000第三方 Skills 框架 方法论anthropics/claude-code124,000Claude 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.aiSkills 的原始推动者原生支持最好GitHub Copilot / VS Code微软系全线接入意味着企业开发者的主流工具链已经覆盖Cursor独立 AI IDE 的标杆Skills 支持让它能复用整个生态的能力OpenAI CodexOpenAI 的 Agent 产品也跟进了这个标准——这意味着这不是 Anthropic 的一家之言Gemini CLIGoogle 的终端 Agent 工具也已接入JetBrains JunieIDE 巨头的新 Agent 产品线Spring AIJava 生态最大 AI 框架2026 年 1 月就宣布了通用 Skills 支持Laravel BoostPHP 框架官方提供的 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.02026 年 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 CLISkills 同样有效。但同时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 的时候周围大多数人的反应也是「这不就是一个轻量级虚拟机吗有必要搞个新概念
码哥实测：写了20行SKILL.md，Claude的代码质量提升了一倍
发布时间：2026/6/30 6:20:11
但紧接着我又打开了一个页面agentskills.io一个 Skills 生态的官方网站。上面密密麻麻地列着 25 个已接入 Agent Skills 标准的产品——Claude Code、Cursor、GitHub Copilot、VS Code、OpenAI Codex、Gemini CLI、JetBrains Junie、Spring AI……这个名单还在以肉眼可见的速度增长。坦白讲我在技术圈混了这么多年很少看到一个新标准在半年内让这么多竞品同时接入。上一个做到这一点的大概是 Kubernetes。于是我做了一件每个技术人都会做的事花了一周时间把整个 Skills 生态翻了一遍。这篇文章就是这一周的产物——从「Skill 到底是什么」到「怎么写出第一个能用的 Skill」再到我对这场生态爆发的判断。Skill 到底是什么一个文件夹改变 AI 的行为模式先说结论Skill 是一套标准化的、可复用的、跨 Agent 平台共享的「知识包」。它不是系统 prompt 的包装纸不只是给 AI 加一段指令而是一个自带上下文、脚本、参考资料的完整文件夹。一个 Skill 的目录结构长这样my-skill/ ├── SKILL.md # 必需元数据 指令 ├── scripts/ # 可选可执行代码 ├── references/ # 可选参考文档 └── assets/ # 可选模板、图片等资源核心只有一个SKILL.md 文件。它用 YAML frontmatter 声明自己的名字和触发条件正文里写清楚做这件事的步骤和注意事项。一个最简单的 Skill 只需要 10 行--- name: roll-dice description: Roll dice using a random number generator. --- To roll a die, use the following command that generates a random number from 1 to the given number of sides: echo $((RANDOM % sides 1)) Replace sides with the number of sides on the die.就这么简单。但就是这套极简的约定催生了一个 13.6 万星的项目和一个 25 平台的生态系统。为什么「文件夹」这个设计是刻意为之这里有一个设计决策大多数写 Skills 教程的人不会提但我觉得它是整个架构里最聪明的一步渐进式加载Progressive Disclosure。Skill 分三层加载第一层元数据约 100 tokens。Agent 启动时只读取每个 Skill 的name和description够它判断「这个 Skill 能不能用在这里」就行。第二层指令正文推荐 5000 tokens。当 Agent 判断 Skills 匹配当前任务才把完整的 SKILL.md 加载进上下文。第三层附属资源按需加载。scripts/里的脚本、references/里的详细文档只有实际用到的时候才读。这意味着什么意味着你可以在一个项目里放 50 个 SkillAgent 启动时的上下文开销只比放 1 个 Skill 多那么一点点——因为每次只加载元数据。相比之下如果你把同样的 50 段说明书直接塞进系统 prompt上下文早就爆了。这个设计让 Skills 的「可堆叠性」成为现实。你不需要在「功能丰富」和「上下文不够」之间做取舍——这是 MCP Server 和 Plugin 做不到的。一个更贴近真实开发的例子上面那个掷骰子的 Skill 只是一个入门演示。来看看一个真实的、在生产环境里能用的 Skill 长什么样。假设你的团队有一个 Java 项目所有数据库查询都要加deleted_at IS NULL做软删除过滤但新来的 AI Agent 根本不知道这个约定。于是它生成的 SQL 会把已删除的数据也算进来——这种事情在生产环境里发生一次后果不用我说。把这个约定写成 Skill--- name: java-db-query description: Write database queries for our Java project. Use when writing SQL, JPA, or MyBatis queries involving database tables that use soft deletes. --- ## Database Query Conventions ### Soft Delete Rule (CRITICAL) All tables use soft deletes via a deleted_at column. Every SELECT query MUST include WHERE deleted_at IS NULL unless the user explicitly asks for deleted records. ### Gotchas - The users table uses user_id in the DB, but uid in the auth service. Both refer to the same value. Never confuse them. - The /health endpoint returns 200 even if the DB is down. Always use /ready for health checks. ### Example - Correct Query SELECT * FROM orders WHERE user_id ? AND deleted_at IS NULL ORDER BY created_at DESC; ### Example - Wrong (Will Include Deleted Records) SELECT * FROM orders WHERE user_id ?;这个 Skill 放到项目里的.claude/skills/目录下每次 AI 写 SQL 的时候它会自动加载这些约束。一个团队在 CI 里跑了 100 次 SQL 生成的测试有 Skill 的情况下SQL 的正确率从 42% 提升到了 91%。这就是为什么这个「文件夹」值 13.6 万星——它解决的不是一个技术问题而是一个范式问题怎么让 AI 真正理解你的项目而不是每次都从零开始猜。Skill vs MCP vs Plugin三者的本质区别这个话题必须讲清楚因为我在各种技术群里看到太多人在问同样的问题「Skills 和 MCP Server 到底什么关系是不是竞品」答案是它们是不同层面的东西互补关系不是替代关系。打个类比SkillMCP ServerPlugin本质做事的方法论外部工具的接口平台的扩展模块给 Agent 什么「怎么干」的 know-how「能调用什么」的工具能力「多了什么功能」的扩展类比老师傅的操作手册工具箱里的新工具给车装的新零件格式标准SKILL.md开放标准JSON-RPC over stdio/SSE各平台自定义跨平台任意兼容 Agent Skills 的平台任意支持 MCP 的客户端仅限特定平台上下文开销渐进式加载极低每次调用固定开销取决于平台更具体地说Skill 告诉你「怎么把一件事做对」。比如「写 SQL 的时候记得加deleted_at IS NULL」「用 pdfplumber 做 PDF 文本提取」「做 code review 的时候重点看认证检查和安全漏洞」。它是知识层面的东西。MCP Server 给你「能做一件新的事」。比如「去数据库里查这张表」「往 Slack 发一条消息」「调一下 GitHub API 创建 Issue」。它是能力层面的东西——Agent 本来不会连接外部系统MCP 给了它那个连接。Plugin 给平台加「一个新功能模块」。比如 VS Code 的 GitLens 插件、Claude Code 的 plugin marketplace。它是平台层面的扩展。三者可以协同工作一个 Skill 里可以写「用 MCP Server X 去查数据库然后按这个格式输出」。Skill 是大脑MCP 是手Plugin 是装备栏。为什么这件事值得花时间理清因为我在好几个技术群里看到同一个误解「有了 MCP Server 就够了要 Skill 干嘛」——这就像你说「有了扳手就够了要维修手册干嘛」。工具和知识从来不是二选一。开发你的第一个 Skill从零到可用好理论讲够了。这一节我带你从头写一个真实可用的 Skill。场景设定你的项目是一个 Spring Boot 微服务所有 REST API 都有统一的响应格式{ code: 200, message: success, data: { ... } }你希望 AI Agent 在写 Controller 的时候自动遵循这个格式而不是写出五花八门的响应结构。第一步创建 Skill 目录mkdir -p .claude/skills/spring-api-response cd .claude/skills/spring-api-response目录名必须全小写用连字符分隔。这个名字就是 Skill 的name。第二步写 SKILL.md--- name: spring-api-response description: Write Spring Boot REST API controllers with the projects standard response format. Use when creating or modifying REST endpoints in a Spring Boot project. --- ## Standard API Response Format All REST endpoints MUST return ApiResponseT: java Data AllArgsConstructor NoArgsConstructor public class ApiResponseT { private int code; private String message; private T data; public static T ApiResponseT success(T data) { return new ApiResponse(200, success, data); } public static T ApiResponseT error(int code, String message) { return new ApiResponse(code, message, null); } }Controller PatternRestController RequestMapping(/api/users) RequiredArgsConstructor public class UserController { private final UserService userService; GetMapping(/{id}) public ApiResponseUserDTO getUser(PathVariable Long id) { UserDTO user userService.findById(id); return ApiResponse.success(user); } PostMapping public ApiResponseUserDTO createUser(Valid RequestBody CreateUserRequest request) { UserDTO user userService.create(request); return ApiResponse.success(user); } }GotchasNever return rawResponseEntityunless you have a specific reason(like setting custom HTTP headers). TheApiResponsewrapper IS yourHTTP body.Thecodefield follows HTTP status semantics: 200 success,400 bad request, 500 internal error. Dont invent custom codes.All DTOs go indto/subpackage, not in the controller class asinner classes.### 第三步验证 Skill 是否被加载 在 Claude Code 中安装 Skills 后启动时会看到技能列表。或者直接让 Agent 帮你写一个 Controller看它是否自动返回 ApiResponseT。 bash # 在 Claude Code 中测试 帮我写一个查询订单列表的 Controller支持分页如果 Skill 工作正常Agent 生成的代码会自动包含ApiResponsePageResultOrderDTO的返回类型和正确的静态方法调用。第四步迭代优化Skills 不是写一次就完事的。我的建议是每次 Agent 犯了你想纠正的错误就把纠正规则加到 Skill 里。这是 Skill 积累价值最快的方式。比如写了上面那个 Skill 后Agent 还是偶尔忘记在Valid注解的请求体上处理MethodArgumentNotValidException那就加一条 Gotcha### Gotchas (追加) - When using Valid RequestBody, ALWAYS add a global ExceptionHandler for MethodArgumentNotValidException that returns ApiResponse.error(400, fieldErrors). Without this, validation errors return a raw 400 with Springs default HTML error page.这就是 Skills 开发的核心循环发现问题 → 写成 Skill → Agent 不再犯 → 遇到新问题 → 追加规则 → 持续收敛。两周下来你的 Agent 就会比第一天聪明一大截。生态全景从 13.6 万星到 25 平台Skills 正在成为标准OK到此为止我们只聊了「Skills 是什么」和「怎么写」。但真正让我觉得这个话题值得专门写一篇文章的是它的生态——这场爆发来势之快超出了大多数人的预期。数据层面截至 2026 年 5 月项目Stars定位anthropics/skills136,000Skills 官方仓库 规范obra/superpowers194,000第三方 Skills 框架 方法论anthropics/claude-code124,000Claude 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.aiSkills 的原始推动者原生支持最好GitHub Copilot / VS Code微软系全线接入意味着企业开发者的主流工具链已经覆盖Cursor独立 AI IDE 的标杆Skills 支持让它能复用整个生态的能力OpenAI CodexOpenAI 的 Agent 产品也跟进了这个标准——这意味着这不是 Anthropic 的一家之言Gemini CLIGoogle 的终端 Agent 工具也已接入JetBrains JunieIDE 巨头的新 Agent 产品线Spring AIJava 生态最大 AI 框架2026 年 1 月就宣布了通用 Skills 支持Laravel BoostPHP 框架官方提供的 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.02026 年 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 CLISkills 同样有效。但同时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 的时候周围大多数人的反应也是「这不就是一个轻量级虚拟机吗有必要搞个新概念
![华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
![华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
