驾驭Skill市场：从3000+技能包中筛出真正能打的20个
GitHub Copilot Extensions 上架数量突破 800，Cursor Rules 社区贡献超过 2000 条，Claude Code 的 /slash 命令生态刚过 500 大关——三个月前我带队做一个存量系统的架构重构，团队 8 个人，每人装了十几个 Skill，结果发现真正高频使用的不超过 5 个，剩下的不是互相冲突就是拖慢响应速度。花了两周时间做 Skill 梳理和标准化，构建效率反而比"装满插件"时提升了 40%。
这件事让我意识到一个被忽略的问题：Skill 市场正在经历和十年前 npm 生态一样的野蛮生长期，数量爆炸但质量参差不齐。大多数开发者还停留在"看到推荐就装"的阶段，缺少一套筛选和搭配的方法论。
这篇文章是我踩完坑之后整理的实战手册。
当前三大 Skill 生态的真实现状
我在重构项目中实际使用过三个平台的 Skill 生态，直接说结论和体感。
GitHub Copilot Extensions：大厂背书，但封闭
Copilot 的 Extension 走的是 GitHub Marketplace 的路子，审核严格，质量下限高。我们团队用过的 @docker、@azure 这类官方 Extension，调用稳定，响应速度在 2-3 秒。
但问题也明显：你没法自定义它的行为逻辑。比如 @docker 生成的 Dockerfile 默认用 node:18-alpine 作为基础镜像，我们的项目因为依赖了一些 native addon，必须用 node:18-bullseye。在 Copilot 的体系里，你只能在每次对话时手动指定，没有持久化配置的入口。
实测数据：Copilot Extensions 市场上架 800+ 个，其中官方/大厂维护的约 120 个，社区贡献的 680+ 个里，超过 3 个月没更新的占 62%。
Cursor Rules：社区驱动，灵活但混乱
Cursor 的 .cursorrules 是目前最灵活的 Skill 机制。它其实就是一个放在项目根目录的文本文件，AI 在每次对话时会自动读取。社区贡献了超过 2000 条 Rules，覆盖从 React 到 Rust 的几乎所有技术栈。
灵活的代价是质量波动大。我在 GitHub 上的 cursor-rules-collection 仓库里随机抽了 50 条 Rules 做测试：
| 质量等级 | 占比 | 典型问题 |
|---|---|---|
| 可直接使用 | 24% | — |
| 需要小改 | 38% | 版本过时、规则冲突 |
| 基本不可用 | 38% | 过于笼统、互相矛盾 |
最典型的问题是"大而全"。有个 Star 数很高的 fullstack-nextjs-rules，一个文件写了 400 多行规则，从数据库选型到 CSS 命名规范全塞进去了。结果 AI 在处理简单需求时也要加载全部上下文，响应时间从 1.5 秒飙到 4.8 秒，而且规则之间经常打架——前面说"优先使用 Server Components"，后面又说"表单交互统一用客户端组件处理"，AI 生成的代码在两种模式之间反复横跳。
Claude Code CLAUDE.md：约定式，上限最高
Claude Code 的方案是在项目根目录放一个 CLAUDE.md 文件，加上 ~/.claude/ 目录下的全局配置。没有市场的概念，完全靠自己写或者从社区搬运。
这个方案看着最原始，用下来上限最高。因为 CLAUDE.md 就是普通的 Markdown，你可以用自然语言描述任何规则，不受 YAML schema 的限制。我们重构项目时最终选了这个方案，把团队规范写成了一份 1200 字的 CLAUDE.md：
# 项目上下文
- 这是一个 B2B SaaS 平台的前端，Vue 3.4 + TypeScript 5.4
- 构建工具 Vite 5.x，包管理 pnpm 9.x
- 后端 API 规范遵循 OpenAPI 3.1，接口定义在 /api-specs 目录
# 代码规范（优先级从高到低）
1. 类型安全：禁止 any，联合类型必须穷举处理
2. 组合优于继承：用 composables 代替 mixins
3. 副作用隔离：API 调用只允许出现在 /services 目录
# 重构专用规则
- 改动已有文件时，先跑该文件关联的单元测试
- 单次重构范围不超过 3 个文件
- 如果涉及公共组件改动，必须列出所有调用方
这份文件让 AI 的行为变得可预测。团队成员反馈最多的一句话是："终于不用每次都教 AI 我们的规矩了。"
五个高频踩坑场景：你装的 Skill 可能正在拖后腿
在重构的两个月里，我们踩过的 Skill 相关的坑，归纳起来就这五类。
坑一：规则冲突导致 AI 输出"精神分裂"
场景是这样的：前端同事小王装了两个 Cursor Rules，一个是 typescript-strict 要求所有函数必须显式声明返回类型，另一个是 react-hooks-best-practice 里有一条"自定义 Hook 让 TypeScript 自动推断返回类型以保持灵活性"。
结果 AI 生成自定义 Hook 时，一会儿加返回类型一会儿不加，同一个文件里风格不统一。小王花了半天排查，一开始还以为是 AI 模型的问题，最后才定位到是两条规则互相打架。
解决方案：我们建了一个规则优先级机制。在 CLAUDE.md 顶部写明：
# 规则冲突处理
当以下规则发生冲突时，按此顺序执行：
1. /CLAUDE.md 中的显式规则（本文件）
2. 当前文件所在目录的 .claude 局部规则
3. 全局 ~/.claude/CLAUDE.md 规则
同一层级内，后声明的规则覆盖先声明的规则。
坑二：过时的 Skill 引入废弃 API
这个坑最隐蔽。我们用了一个社区 Star 数 1.2k 的 vue3-composition-api-rules，看起来很专业，实际上里面有几条规则还在引导 AI 使用 @vue/composition-api 这个 Vue 2 时代的兼容包。生成的代码能跑，但引入了完全不必要的依赖，而且和 Vue 3.4 的某些响应式优化冲突，导致 watchEffect 的触发次数异常。
排查过程：先是发现某个页面的接口被重复调用了 3 次，用 Vue DevTools 追踪 reactivity 链路，发现 watchEffect 在不该触发的时候触发了。最后 git blame 发现是 AI 生成的代码里多了一层 toRefs 的不必要转换，而这个写法正是那个过时 Skill 里推荐的模式。
解决方案：对每个引入的 Skill，做一次版本审计。我写了一个简单的检查脚本：
#!/bin/bash
# check-skill-freshness.sh
# 检查 Skill 文件中引用的包名是否在 package.json 中存在
SKILL_FILE=$1
grep -oP '`[a-z@][a-z0-9@/-]*`' "$SKILL_FILE" | tr -d '`' | while read pkg; do
if ! grep -q "\"$pkg\"" package.json 2>/dev/null; then
echo "[WARN] Skill 引用了项目中不存在的包: $pkg"
fi
done
坑三：Skill 堆叠导致上下文溢出
AI 模型的上下文窗口是有限的。当你同时加载了 5 个 Skill，每个 Skill 有 300-500 token 的规则描述，光 Skill 就占掉了 1500-2500 token。对于 Claude 这种 200k 上下文的模型来说似乎不多，但问题在于——Skill 规则在每一轮对话中都会重复注入。我们做过一个测试：一个包含 8 轮对话的重构任务，加载 5 个 Skill 和不加载 Skill 的对比：
| 指标 | 无 Skill | 5 个 Skill |
|---|---|---|
| 平均响应时间 | 1.8s | 3.2s |
| 最终上下文占用 | 12k tokens | 31k tokens |
| AI 忘记前文概率 | 低 | 中（第6轮开始遗忘） |
说人话就是：Skill 不是免费的，它在持续消耗你的上下文预算。装得越多，AI 能记住你前面说的话就越少。
解决方案：精简到只保留 3 个以内的核心 Skill，其余需求用单次 prompt 注入。我们团队最后收敛到这个配置——一个项目级 CLAUDE.md（约 800 token）、一个全局代码风格规则（约 300 token）、一个重构专用流程规则（约 400 token），总计不超过 1500 token。
坑四：Skill 写了"做什么"，没写"不做什么"
这条反直觉，但踩过坑的人都知道：告诉 AI 不要做什么，比告诉它要做什么更重要。
我们有个规则写的是"使用 Zustand 状态管理"一下。AI 确实用了 Zustand，但它同时在某些组件里用了 useState 管理本该放在 store 里的状态。从字面上看，它没违反规则——规则说的是"使用 Zustand"，没说"不能用 useState 管应该共享的状态"。
改成下面这个写法之后问题消失了：
# 状态管理
- 跨组件共享的状态：必须使用 Zustand store，文件放在 /stores 目录
- 组件内部 UI 状态（如 modal 开关、表单输入）：使用 useState
- 禁止：在组件内用 useState 管理需要跨组件共享的业务数据
- 禁止：在一个组件中直接修改另一个 store 的状态，必须通过 action
经验提炼：写 Skill 规则的时候，用"情景-指令-禁止"三段式。先描述适用场景，再给出要怎么做，最后明确列出不允许做什么。规则的精确度直接决定 AI 输出的可控性。
坑五：盲目搬运大V推荐，水土不服
这个不需要太多技术分析，直接说现象：团队里有同事看到某个技术博主推荐了一套 Cursor Rules，说"用了之后效率翻倍"，直接整个 copy 到项目里。那套 Rules 是给 Next.js 14 App Router + Prisma + tRPC 技术栈写的。
这就像拿着北京地铁图在上海坐地铁一样——工具是好工具，但前提是适配你的场景。
解决方案：所有外部引入的 Skill，必须经过"本地化"改造，核心步骤就三个：删掉和当前技术栈无关的规则、把示例代码换成自己项目的真实代码片段、加上项目特有的约束条件。
精选 Skill 推荐：按场景分类的实战清单
下面这份清单是从我们实际使用过的 Skill 中筛出来的，筛选标准就两条：用了之后确实减少了重复劳动，以及不引入额外的认知负担。
场景一：代码审查与质量把关
推荐 Skill：code-review-checklist
这是我在整个重构中使用频率最高的一个。它不是一个现成的社区 Skill，而是我们根据团队的 Code Review 标准自己写的。核心思路是让 AI 在生成代码后自动执行一遍 Review：
# Code Review 自检规则
每次生成或修改代码后，自动检查以下项目：
1. 类型安全：是否有隐式 any？联合类型是否穷举？
2. 错误处理：API 调用是否有 try-catch？错误是否上报？
3. 性能：是否有不必要的 re-render？computed 是否被合理使用？
4. 安全：用户输入是否做了 XSS 过滤？SQL 拼接是否用了参数化？
5. 可测试性：函数是否可被单独测试？是否依赖了全局状态？
检查完毕后，在代码末尾以注释形式输出检查结果。
如果有不通过项，不要直接给出代码，先说明问题并提供修改建议。
我们统计了使用这个 Skill 前后的 Code Review 通过率：第一次提交就通过 Review 的比例从 34% 提升到 71%。最大的收益不是 AI 写的代码变好了，而是它帮团队成员养成了"先自查再提交"的习惯。
场景二：重构与迁移
推荐 Skill：safe-refactor-guard
重构最怕的不是改错，是改漏。这个 Skill 的核心是强制 AI 在重构前做影响分析：
# 重构安全规则
当收到重构类指令时，执行以下流程：
1. 先列出当前文件被哪些文件 import
2. 列出改动会影响的公共接口（导出的函数、类型、组件）
3. 如果影响超过 5 个文件，暂停并让用户确认范围
4. 执行改动后，给出需要同步修改的文件清单
5. 如果项目有测试，改动后自动运行相关测试文件
实际效果：在两个月的重构周期里，因为"改了 A 忘了 B"导致的线上 bug 从每周平均 3.2 个降到了 0.4 个。这个 Skill 本身很简单，但它把"人容易忘记的步骤"固化成了 AI 的默认流程。
场景三：API 接口对接
推荐 Skill：api-contract-first
前后端协作中最浪费时间的环节就是接口联调。这个 Skill 让 AI 基于 OpenAPI 规范生成类型安全的请求代码：
# API 对接规则
- 接口定义文件位于 /api-specs/*.yaml
- 生成 API 调用代码时，必须从 spec 文件读取参数类型
- 请求函数统一放在 /services 目录，按业务模块分文件
- 返回类型必须和 spec 中的 response schema 完全一致
- 错误处理：HTTP 4xx 走业务错误处理，5xx 走全局兜底
- 禁止手写接口 URL，必须从统一常量文件导入
搭配这个 Skill 之后，AI 生成的接口调用代码基本可以一次跑通。之前我们每个接口的联调时间平均要 25 分钟（包括改类型、调路径、处理边界情况），现在降到了 8 分钟左右。
场景四：测试生成
推荐 Skill：test-writer-pragmatic
注意名字里的 pragmatic（务实），这是和市面上大部分测试生成 Skill 的核心区别。大部分测试 Skill 会让 AI 追求覆盖率数字，生成一堆测试 undefined、null、空字符串的边界 case。这些测试写了不出错，但也没什么价值。
我们的做法是：
# 测试生成规则
优先级排序（从高到低）：
1. 业务核心路径：用户最常触发的操作流程
2. 金额/权限相关：涉及钱和权限的逻辑必须测
3. 已知 bug 回归：修复过的 bug 必须补回归测试
4. 边界条件：仅测试真实场景中可能出现的边界值
不要测的：
- getter/setter、纯展示组件的渲染测试
- 第三方库的功能（那是别人该测的）
- 只为提升覆盖率而存在的测试
这个 Skill 配合 Vitest 使用效果最好。AI 生成的测试用例命中实际 bug 的概率比之前提升了大约 3 倍——不是因为它写了更多测试，而是因为它写的测试更贴近真实的出 bug 场景。
场景五：文档与注释
推荐 Skill：doc-as-code
很多团队的文档和代码是脱节的。这个 Skill 的思路是让 AI 在生成代码的同时维护文档：
# 文档同步规则
- 新增公共函数时，同步更新 /docs/api.md
- 修改组件 Props 时，同步更新组件目录下的 README.md
- 文档格式：一句话说明用途 + 参数表格 + 一个最小使用示例
- 禁止写"待补充""TODO"类占位符，要么写完要么不写
这条规则看着简单，实际用下来我们项目的文档完整度从不到 30% 提升到了 85%。关键在于最后那条"禁止占位符"——它逼着 AI（也逼着人）在写代码的当下就把文档补齐，而不是留个 TODO 然后再也不管。
如何构建你自己的 Skill 体系
上面推荐的都是"别人的经验"，但 Skill 的价值在于适配你自己的项目。分享一下我们建立团队 Skill 体系的完整过程。
第一步：收集高频 prompt
让团队成员记录一周内和 AI 对话时重复说过的话。我们收集到的 top 5 是：
- "我们用 Vue 3 + TS，不要给我 React 代码"（出现 47 次）
- "样式用 CSS Modules"（出现 31 次）
- "错误处理要用我们封装的
useRequest"（出现 28 次） - "这个接口的类型定义在 /types/api 目录"（出现 22 次）
- "测试用 Vitest 不用 Jest"（出现 19 次）
这些重复出现的 prompt 就是你的 Skill 素材。
第三步：版本化管理
Skill 文件必须进 Git。我们在 .git/hooks/pre-commit 里加了一个检查：
#!/bin/bash
# 检查 CLAUDE.md 的改动是否经过团队 Review
CHANGED=$(git diff --cached --name-only | grep "CLAUDE.md")
if [ -n "$CHANGED" ]; then
echo "检测到 Skill 规则文件改动: $CHANGED"
echo "请确保已经过团队 Review 后再提交"
echo "如果已 Review，使用 git commit --no-verify 跳过此检查"
exit 1
fi
为什么这么严格？因为 Skill 规则的改动影响的是整个团队每个人的 AI 行为。一个人随手改了一条规则，可能让其他 7 个人的 AI 都开始输出不符合规范的代码。这比改公共组件的影响面还大。
第四步：定期淘汰
每两周做一次 Skill 回顾，标准很简单——过去两周有没有人因为这条规则而受益？如果没有，删掉。我们第一次回顾就删掉了 40% 的规则。
好的规则一定是违反 AI 默认行为的。如果一条规则删掉之后 AI 的输出没有变化，那它从一开始就不该存在。
