打开 skills.sh 排行榜，前十名加起来几百万安装量。直觉告诉你：这么多人装了，应该有用吧。装了一圈之后发现，大部分时候它们在干预期以外的事情。

先装一堆别人的 Skill，却没搞清楚系统有什么、自己需要什么。顺序应该反过来：先摸清 Cursor、Codex、Claude Code 各自预置了什么，再判断自己缺什么，薄弱点拿别人的 Skill 临时补上，同时把自己的专长编成 Skill 输出。

补丁性质的skills迟早会被模型原生能力吞并，个人性质的skills才是长期资产。

系统有什么

用 Agent 写代码，背后不止一个聊天窗口。从下到上大致是五层：基座模型决定推理上限；Tool 是模型能调用的外部能力（浏览器、终端、MCP）；Skill 是操作手册（一份 SKILL.md，教 Agent 按什么步骤用什么工具完成任务）；Rules 是项目级背景约束（Cursor 的 .cursor/rules/、Codex 的 AGENTS.md、Claude Code 的 CLAUDE.md）；Hooks 是守门员（脚本层执行，模型绕不过去，也不花推理 token）。还有一层 Subagent，主 Agent 派生子代理并行工作。

搞清楚哪层做什么，才不会装一个 Skill 去做本该是 Hook 的事。

原生指令

三个平台的原生指令覆盖面比大多数人以为的要广：

任务 原生怎么做
代码审查 Claude Code /code-review --comment 直接发 PR 行内评论；Codex /review；Cursor 内置 review-bugbot、review-security
长任务管理 Codex /goal（edit/pause/resume）；Claude Code /goal
释放上下文 Codex /compact；Claude Code /compact [instructions]
并行工作 Claude Code /subtask、/fork、/batch；Codex /agent、/subagents；Cursor Subagent（Task 工具）
规划模式 Codex /plan；Claude Code /plan；Cursor Shift+Tab
初始化仓库说明 Codex /init 生成 AGENTS.md；Claude Code /init 生成 CLAUDE.md
跨平台迁移 Codex /import 可导入 Claude Code/Cursor 设置；Claude Code /import [codex|gemini]

另外还有独有能力：

Claude Code 的 /doctor 按"上下文成本 vs 实际触发率"找出闲置的 Skill 和 MCP，还会把 CLAUDE.md 里能从代码库推导的内容裁掉；/rewind 可以把代码和对话退回检查点；/batch 把大型变更拆成多个 worktree 由后台 Agent 各自实现并开 PR。Codex 的 $imagegen 显式调用内置图像生成，背后是 gpt-image-2。

另外，这些指令的变化速度非常快，可能文章发出去就变了。

筛选框架

启用一个 Skill 的成本有两点。一是常驻占用：description 一直待在上下文里等触发。二是触发打架：两个 Skill 对同一阶段有不同主张时，难以决策。所以要挑的不是"最好的几个"，而是"分工不重叠的几个"。

用阶段来切。 一个任务从模糊到交付大致是想清楚、定方案、写、验收四步，每一步最多留一两个 Skill。把多个 Skill 的 description 并排放在一起读，如果连你自己都说不清什么时候该触发哪个，模型只会更说不清。这个道理同样适用于前后端、数据等任务。

安装量只是声量信号。 supabase/agent-skills 的 GitHub 只有 2.5K stars，安装量却有 33 万。star 数和实际使用量不是一回事，安装量更不代表适合你的技术栈。比如靠前的，不少是前端、展示型的skills，对于更深入的项目，就不适用了。

安全两原则： 装之前自己或者AI读源码（至少过一遍 SKILL.md、scripts/、网络请求和 allowed-tools），固定版本避免远端静默改变行为。涉及流程控制和权限管理的，用 Hooks 而不是 Skill。

按类别的判断

行为矫正类

grill-me（约 81.2 万安装）教模型"动手前要追问假设"，补的是模型够聪明但不够自律这个缺陷。我在上篇文章里就是跳过了需求追问直接想技术方案。这类 Skill 短期有效，但模型在变强，半年前需要矫正的行为，有些已经成了默认行为。

反面例子是 Superpowers 全家桶：有社区案例显示复制 6 张图片也触发了 brainstorm、spec、plan 和额外 commits，5 行文件触发 6 到 7 个 Agent。按需挑单个可以，全套启用太笨重了，它本质把瀑布开发那套拿了过来。

厂商文档类

实质上是一份能被 Agent 检索的版本化文档，技术栈不匹配就一个都别装，因为它给的是具体写法而不是思路，装错了会直接把错误的 API 用法写进代码。

（SWE-Skills-Bench 里让通过率不升反降的三个 Skill，掉分原因正是版本不匹配的指导与项目上下文冲突。）

榜上的代表：supabase-postgres-best-practices（约 33.6 万）、prisma/skills 全家、firebase/agent-skills、microsoft/azure-skills。前端头部是个人作者的方法论，后端头部基本被厂商占满。

一年前还比较火的是MCP context7，用来查询最新文档，解决是基模训练的时候，没掌握最新版本框架用法的问题。现在有不少skills出现，个人体感不走context7也能完成工作。

个人标准类

review-zh-blog（自写）让 Agent 以读者视角审阅中文博客，重点抓 AI 味的反模式。content-matrix（自写）用 3x3 矩阵定位文章角度，给出还能从哪些方向继续写。humanizer-zh 装了但效果不如预期。写作风味需要个人标准，通用的"去 AI 味"规则不够用，最后还是自写了 review-zh-blog 替代。

这类 Skill 模型不会自动学会，因为它们只存在于个人的经验里。

Cursor 的 create-skill 轻量直接，引导写一个 SKILL.md 选好位置就完事。Codex 的 skill-creator 重得多，包含元数据、脚本目录、参考文档和 forward-testing。Claude Code 的 /skill-creator 最重，提供 Create、Eval、Improve、Benchmark 四种模式。同一个 Skill 搬到不同平台，调用方式目前已基本兼容。

什么值得重投入

SWE-Skills-Bench 测了 49 个公共 Skill，39 个没带来通过率提升，平均增益 1.2%。但 7 个专业化 Skill 拿到了最高 30% 的提升。通用的没用，贴合领域的有用。

这和我的体感一致。会被吞掉的是通用流程，留下来的是个人标准和专业知识。通用的那些，装着玩玩可以，但更应关注 Agent 工具本身的迭代情况。

参考来源

研究与规范

平台官方文档

Skills 与素材

关于作者