Spots 去年底，我看到 GitHub 上一个叫 antigravity-awesome-skills 的仓库冲上了 Trending，37K stars，1400+ Skills，还有人在评论区喊"装完这个直接满级"。 一口气装了三十多个 Skill，Superpowers 全家桶、各种 lark-xxx 套件、前端设计工具、浏览器自动化…… 结果用了两个礼拜，Claude Code 打开巨慢、上下文预算经常被 Skill 描述撑爆、/skills 列表长得根本找不到自己想要的。 现在留下 10 个，在后端日常开发里高频使用。这篇文章就是把这个筛选过程复盘一遍——我会先说清楚 Skill 生态到底怎么回事，再从后端工程师视角给出我实测觉得值得装的那 10 个，附完整安装命令。
Claude Code 的 Skill 系统本质上是一种可复用的 prompt 模板机制，核心就是一个 SKILL.md 文件，分两部分：YAML frontmatter 告诉 Claude 什么时候用这个 Skill，markdown body 告诉 Claude怎么做。Claude 在每次会话里只加载 Skill 的名字和描述（约 100 tokens/个），全文只有被触发时才载入——所以理论上你装几十个 Skill 性能影响很小，但理论归理论，描述预算是有限的，装太多会互相挤占（后面专门讲这个坑）。 以下是截至 2026 年 5 月，Skill 生态的主要仓库现状（数据已实时核验）：
这套生态在 2026 年初基本形成了一个标准：SKILL.md 格式已经成为一个跨平台开放标准，同一个 Skill 文件可以在 Claude Code、Cursor、Gemini CLI、Codex CLI 上通用。这是个值得关注的变化——你写一个 Skill，全平台通用。 安装方式有三种，最简单的是用 npx skills CLI： 也可以手动把 SKILL.md 放到 ~/.claude/skills/<skill-name>/SKILL.md（全局）或 .claude/skills/<skill-name>/SKILL.md（项目级）。 图：后端工程师 10 个精选 Skill 分三组，按使用频率分类 在说推荐清单之前，必须先讲这个坑，因为很多人装完 Skill 觉得没用，根本原因是触发失效。 Claude Code 把所有 Skill 的名称 + 描述加载到上下文里，让模型知道可以用哪些工具。这个预算默认是模型 context window 的 1%。听起来很多，实际上： 10 个 Skill 全量描述约占 15K tokens 如果你装了 30 个，优先级低的 Skill 描述会被截断，Claude 直接不知道有这个工具 我当时装了 32 个 Skill，用 /doctor 一看，17 个 Skill 的描述被截掉了。那些 Skill 等于白装。 删掉低频 Skill，保留 10-15 个核心 Skill 在 .claude/settings.json 里提高预算比例： 建议按第一个方案来——预算提高解决了症状，但 30 个 Skill 本身就是问题。 图：Skill 触发机制与描述预算警示，装多了描述会被截断 以下 10 个是我实测三个月后留下的。按使用场景分三组。
这套东西我一开始以为是噱头，用了才发现是真正改变工作节奏的。Superpowers 不是一个 Skill，是一套 Skill 工作流，把「想清楚→写 Spec→拆任务→多 Agent 并行实现→TDD→Code Review→收尾分支」这条链路用 Skill 的方式串起来。 它在 GitHub 上有 40.9K stars、3.1K forks，是目前社区里最成熟的 AI 辅助开发工作流框架。 对我来说，最有用的是两个子 Skill：brainstorming（强制在写代码前先想清楚需求，防止大量返工）和 systematic-debugging（调试不再靠猜，强制你给出假设、验证步骤、排除方向）。 用了三个月，估计减少了 40% 的"写完才发现方向不对"的返工。 这个是 Claude Code 官方 bundled skill，直接 /simplify 触发。功能是对你最近改动的代码做一轮 review，找出可以复用、精简、提升质量的地方，然后直接修。 跟 Code Review 不同的是，它不只指出问题，它会直接改。我现在每次功能做完、提 PR 前必用一次，减少了很多"代码能跑但不够优雅"的毛病。 ③ go-coverage-improvement（如果你写 Go 的话） 这个是我最近加的，顾名思义，是专门用来提升 Go 项目测试覆盖率的。它会分析当前项目的覆盖率缺口，自动生成针对未覆盖路径的测试用例，还会帮你检查 table-driven test 的完整性。 我们有个 go-zero 的微服务项目，当时测试覆盖率只有 52%，用了这个 Skill 一个下午提到了 78%，而且生成的 test case 质量比较高，不是那种只为了覆盖率而覆盖率的废测试。 这个是我自己安装的 skill 套件里的一个，专门用于技术选型和横向对比研究。你输入一个问题（比如"go-zero 和 gin+GORM 在微服务场景下怎么选"），它会自动做横向/纵向两个维度的调研，给出对比简报。 以前做这种技术选型研究要花半天，现在 15 分钟出一份比较扎实的参考材料。 ⑤
claude-api（如果你在开发 AI 应用） Anthropic 官方出的，给你在写调用 Claude API 的代码时提供深度上下文：prompt caching 怎么用、thinking 模式的参数、batch API 的最佳实践、token 成本控制…… 我在做一个内部 AI 辅助工具的时候，靠这个 Skill 把 API 调用成本降了大约 60%（主要是正确配置了 prompt cache）。 ⑥ web-design-guidelines（前后端都要对接 UI 的话）
Vercel 出的，22K stars，133K 周下载量。专门用来 review 你写的 UI 代码是否符合可访问性标准、UX 最佳实践。对纯后端的人来说平时用不太到，但如果你偶尔要写 dashboard 或者内部工具的前端，这个很有用，能防止你写出那种"功能正常但用起来很难受"的界面。 这个 Claude Code 自带，/security-review 触发。会对你当前改动的代码做一轮安全扫描：SQL 注入风险、敏感信息硬编码、不安全的反序列化、权限校验缺失…… 我们团队的规范是：涉及用户数据处理或外部接口的 PR，合并前必须跑一次。大概两个月时间，真的帮我们抓到了一个权限校验漏洞（一个接口在某个 case 下可以越权查询别人的数据）。 ⑧ fewer-permission-prompts
这个解决一个具体痛点：Claude Code 频繁弹出权限确认（每次调用 Bash 都要点 Allow），用多了很烦。这个 Skill 会扫描你的操作历史，把高频的只读命令自动加入白名单，写进 .claude/settings.json，之后就不再弹了。 新建项目或者接手老项目时用。/init 命令会扫描你的代码库，自动生成一份 CLAUDE.md 文件，把项目的架构、依赖、关键配置都沉淀进去。这样 Claude 在后续对话里就有足够的上下文，不用每次都从头解释"这个项目是干什么的"。 用来管理 Claude Code 的设置文件，包括 settings.json 里的各种配置（权限、hooks、环境变量等）。不需要手动改 JSON，告诉 Skill 你想做什么，它帮你改。 对我来说主要用来管理权限白名单和 hook 配置。后端开发里，经常需要给一些 Bash 命令（git、go build、docker）提前开白名单，这个 Skill 省了很多翻文档的时间。 这里专门对比一下三个主流 Skill 来源，因为很多人一上来就问"我应该用哪个仓库"： 图：三大 Skill 生态仓库对比，后端工程师选型参考 antigravity-awesome-skills（sickn33，37.1K stars）： 优点：数量最多（1450+），npm 安装方便，跨平台支持好 缺点：质量参差不齐，很多 Skill 是 AI 批量生成的，没有经过真实场景验证 VoltAgent/awesome-agent-skills（21.2K stars）： alirezarezvani/claude-skills（14.4K stars）： Anthropic 官方 skills（稳定性第一）+ Superpowers（工作流框架）+ 按需从 antigravity 精选 2-3 个。不要无脑全装。 Anthropic 官方 skills（稳定性第一）+ Superpowers（工作流框架）+ 按需从 antigravity 精选 2-3 个。不要无脑全装。 图：后端工程师 Skill
安装决策路径，按技术栈分叉 有人跟我说"我装了 Superpowers，但 Claude 从来不主动用"，通常是以下几个原因：
描述关键词不匹配：比如你说"帮我想一想这个需求"，但 Skill 的 description 写的是"when user wants to brainstorm"，中文请求触发不了英文描述的 Skill。解决方法：直接 /brainstorming 手动触发，或者编辑 Skill 的 description 加上中文关键词。 Skill 名称冲突：同名 Skill 优先级是 Enterprise > Personal > Project。如果你在项目级装了一个跟全局同名的 Skill，全局的会被覆盖，不是叠加。 看列表里有没有你期望的 Skill。没有的话基本就是预算问题或者安装路径问题。 Q1：Skill 会不会拖慢 Claude Code 的响应速度？ 理论上不会，Skill 内容只有被触发时才载入。但如果你装了 30+ 个 Skill，描述加载本身会消耗上下文预算，间接影响可用 context 长度。保持 10-15 个核心 Skill 是比较合理的数量。 Q2：Skill 跟 CLAUDE.md 有什么区别，什么时候用哪个？ CLAUDE.md 是持久的项目/全局上下文，每次会话都加载，适合放稳定的约束（代码规范、架构说明、团队规范）。Skill 是按需加载的工具，适合放可复用的操作流程。简单说：规范放 CLAUDE.md，流程放 Skill。 Q3：可以自己写 Skill 吗？写了能给团队用吗？
完全可以。一个最简单的 Skill 就是在 .claude/skills/<name>/ 下放一个 SKILL.md，写清楚 description 和步骤就行。放到项目的 .claude/skills/ 目录并提交到 git，团队成员 clone 之后就可以共用。我们团队内部有几个自己写的 Skill：统一的 commit 格式模板、我们自己 API 设计规范的 review checklist、部署前的 checklist 检查。 Q4：antigravity 那个 1400+ Skills 的仓库值得全装吗？ 不值得。大量 Skill 是批量生成的，质量参差不齐，装完 Skill 描述预算直接爆掉。正确做法是浏览分类、按需安装，不要一键全装。 Q5：后端工程师用 Skill 最容易忽视的收益点是什么？ 代码审查和测试覆盖率。我见过很多同学用 Claude Code 主要是写代码，但用它做 security review 和测试补全往往有更高的 ROI——发现一个生产安全漏洞的价值，远超节省几个小时的编码时间。 说到底，Skill 生态的核心价值不是数量，是把你反复做的事情变成可复用的流程。1400 个 Skill 里，真正适合你工作场景的可能就 8-10 个。先把这几个用熟，比装一堆用不起来要强得多。
去年底，我看到 GitHub 上一个叫 antigravity-awesome-skills 的仓库冲上了 Trending，37K stars，1400+ Skills，还有人在评论区喊"装完这个直接满级"。 一口气装了三十多个 Skill，Superpowers 全家桶、各种 lark-xxx 套件、前端设计工具、浏览器自动化…… 结果用了两个礼拜，Claude Code…