FAQ 常见问题

基础概念

四组概念快速区分

Skill、MCP、Rules、Sub-agents 是四个容易混淆的概念，先看一张表把它们区分清楚：

形象比喻：Rules 像"厨房基本规矩"，MCP 像"手"，Skill 像"菜谱"，Sub-agents 像"分身术"。

简单判断法则：

• 只是一条全局约束（语言、格式）？ → Rules
• 需要连接外部系统（数据库、邮件、飞书）？ → MCP
• 可复用的标准化工作流，需要团队共享？ → Skill
• 需要并行处理多个独立任务？ → Sub-agents

Skill 和 MCP 有什么区别？

可以先这么理解：

• MCP：给 AI 工具（连接数据库、调用 API、读文件）
• Skill：教 AI 怎么用工具（执行流程、SOP、规范）

形象比喻：

• MCP 是"发工具"
• Skill 是"给说明书"

技术区别：

举个实际例子：

场景：处理 PDF 文档

MCP 提供：
- 读取 PDF 的能力
- 提取文本的能力
- 转换格式的能力

Skill 定义：
- 什么时候用哪个工具
- 按什么顺序处理
- 输出什么格式
- 遇到错误怎么办

能否互相替代？

不能。它们是互补的：

• 如果需要连接外部系统 → 必须用 MCP
• 如果需要标准化流程 → 用 Skill
• 最佳实践：MCP + Skill 组合使用

Skill 和普通提示词有什么区别？

什么时候用提示词，什么时候用 Skill？可以这样分：

用提示词：

• 一次性任务
• 简单的问答
• 不需要复用

用 Skill：

• 重复性任务（做过 3 次以上）
• 复杂的工作流
• 需要团队共享
• 需要版本控制

使用问题

为什么我的 Skill 没被调用？

最常见的原因，是 description 不够明确。

检查清单：

1. description 是否包含触发关键词？
2. description 是否说明了使用场景？
3. description 是否足够具体？

解决方法：

❌ 不好的 description：

description: Review code

✅ 好的 description：

description: |
  审查代码的安全性、性能和代码风格。
  使用场景：
  - 用户请求 review 代码
  - 提交 PR 前的检查
  - 提到"代码审查"、"code review"、"检查代码"时

也可能是这些原因：

1. Skill 太多导致冲突

   • 解决：减少 Skill 数量，保持在 10-30 个
   • 解决：让每个 Skill 的触发条件更明确

2. Skill 名称和内容不匹配

   • 解决：确保 name、description、内容一致

3. 显式调用

   • 临时方案：在对话中提到 Skill 名称（如 @code-reviewer）

Skill 支持热更新吗？

支持，但有条件：

• ✅ Claude Code 2.1+：支持
• ✅ Cursor 最新版：支持
• ✅ Trae 最新版：支持
• ❌ 旧版本：需要重启

如何热更新：

1. 修改 SKILL.md
2. 保存文件
3. 在新的对话中测试（不需要重启）

注意：

• 当前对话可能还在用旧版本
• 建议在新对话中测试更新后的 Skill

一次应该装多少个 Skill？

推荐数量：

• 新手：1-3 个

  • 先用起来，体验效果
  • 不要贪多

• 进阶：5-10 个

  • 按工作流组合
  • 覆盖高频场景

• 团队：10-30 个

  • 建立标准库
  • 统一团队规范

• 超过 30 个：不推荐

  • 会给模型带来负担
  • 效果反而下降
  • 触发冲突增加

实际经验是：

一般一个工具的 Skill 控制在 10-30 个左右更合适。太多会给模型上下文带来负担，太少又覆盖不了高频流程。

优化策略：

1. 分工具配置

   • 开发工具：只装开发相关的
   • 内容工具：只装内容相关的
   • 不要把所有 Skill 都装在一个工具里

2. 定期清理

   • 每月检查一次
   • 删除从未使用的 Skill
   • 优化高频使用的 Skill

如何调试 Skill？

调试步骤：

1. 检查 Skill 是否被加载

   # 查看已安装的 Skill
   npx skills list

2. 检查 description

   • 是否包含触发关键词？
   • 是否足够具体？

3. 显式调用测试

   使用 @my-skill 处理这个任务

4. 查看执行日志

   • 观察 AI 的执行步骤
   • 看是否调用了 Skill
   • 看是否执行了脚本

5. 简化测试

   • 用最简单的输入测试
   • 逐步增加复杂度
   • 记录每次的结果

常见问题和解决方法：

安全问题

Skill 安全吗？

风险点：

1. 脚本执行风险

   • Skill 可以包含可执行脚本
   • 恶意脚本可能窃取数据
   • 恶意脚本可能破坏系统

2. 数据泄露风险

   • 脚本可能上传数据到外部服务器
   • 脚本可能读取敏感文件
   • 脚本可能记录你的操作

3. 供应链风险

   • 依赖的第三方库可能有漏洞
   • Skill 可能被劫持
   • 更新可能引入恶意代码

如何保护自己：

1. 只装可信来源的 Skill

   • ✅ Anthropic 官方
   • ✅ 知名开发者
   • ✅ 经过审查的商店
   • ❌ 来路不明的 Skill

2. 安装前审查

   • 查看 SKILL.md
   • 检查 scripts/ 目录
   • 看是否有混淆代码
   • 看是否有网络请求

3. 使用审查工具

   # 安装 Skill Vetter
   npx skills add anthropics/skills/skill-vetter
   
   # 审查 Skill
   使用 @skill-vetter 审查 <skill-path>

4. 敏感数据脱敏

   • 不要直接用真实数据测试
   • 先用测试数据验证
   • 医疗、金融等敏感数据要特别小心

Skill Vetter 的局限性：

这种审核的逻辑还是利用 AI 生成的提示词去检查 Skill，就有点像用 AI 检测文章是否是由 AI 生成一样，有作用，但也是可以被绕过去的。

最保险的做法：

• 只安装官方推荐的 Skill
• 安装前仔细审查代码
• 定期检查已安装的 Skill

如何审查一个 Skill？

审查清单：

1. 来源检查

   • 来自可信的开发者或组织？
   • GitHub 仓库有足够的 Star 和活跃度？
   • 有完整的文档和使用说明？

2. 代码检查

   • SKILL.md 内容清晰合理？
   • 没有混淆的代码？
   • 脚本功能和描述一致？

3. 权限检查

   • 需要的权限合理吗？
   • 有没有不必要的网络请求？
   • 有没有读取敏感文件？

4. 依赖检查

   • 依赖的库都是官方的？
   • 没有可疑的第三方依赖？
   • 依赖版本是最新的？

重点关注：

# 检查是否有网络请求
grep -r "http" scripts/
grep -r "fetch" scripts/
grep -r "axios" scripts/
grep -r "request" scripts/

# 检查是否读取敏感文件
grep -r "\.env" scripts/
grep -r "password" scripts/
grep -r "token" scripts/
grep -r "secret" scripts/

# 检查是否有可疑操作
grep -r "eval" scripts/
grep -r "exec" scripts/
grep -r "rm -rf" scripts/

Skill 触发太频繁怎么办？

Skill 不应该调用时被调用，通常是因为 description 太宽泛。

解决方法：加入负向说明。

description: |
  用于 CSV 文件的高级数据分析（统计建模、回归分析、聚类）。
  不适用于简单数据查询（请使用 data-viz Skill）。
  不适用于查看数据结构或列名。

负向说明告诉 AI 什么时候不该用这个 Skill，和正向触发词同样重要。

Skill 被调用了但没按步骤执行怎么办？

可能原因：

1. 指令太冗长 → 精简正文，关键步骤前置，在关键步骤前加 CRITICAL: 或 ## 重要 标注
2. 语言描述模糊 → 用脚本替代语言描述（脚本是确定的，语言存在解读偏差）
3. 步骤太多 → 拆分成多个更简单的 Skill

高级话题

Skill 和 Rules 有什么区别？

Rules 是全局行为约束，始终在上下文中生效，每轮对话都会加载。Skill 是针对特定任务的工作流，按需加载。

简单判断： 如果只是一条简单的约束规则 → 用 Rules。如果是一个多步骤的工作流 → 用 Skill。两者不冲突，可以同时使用：Rules 管全局规范，Skill 管具体流程。

Skill 和 Sub-agents 有什么区别？

形象比喻：

• Skill：给说明书
• Sub-agent：派小弟

什么时候用 Sub-agent？

• 需要扫描整个代码库
• 需要并行处理多个任务
• 任务之间相互独立
• 不想干扰主会话

什么时候用 Skill？

• 标准化的工作流程
• 需要共享上下文
• Token 效率优先
• 快速响应

可以把 Skill 商业化吗？

可以，有几种方式：

1. 直接销售 Skill

   • 在商店上架付费 Skill
   • 提供企业定制 Skill
   • 建立 Skill 订阅服务

2. 提供 Skill 开发服务

   • 帮企业定制 Skill
   • 提供 Skill 咨询
   • 培训团队使用 Skill

3. 建立 Skill 生态

   • 创建 Skill 商店
   • 提供 Skill 托管服务
   • 建立 Skill 社区

4. 间接变现

   • 用 Skill 提升工作效率
   • 用 Skill 展示专业能力
   • 用 Skill 吸引客户

详细了解：

• 想创建自己的 Skill → 看 创建 Skill

Skill 的未来发展方向？

当前趋势：

1. 标准化

   • 统一的 Skill 格式
   • 跨平台兼容
   • 更好的工具支持

2. 智能化

   • AI 自动生成 Skill
   • 自动优化 Skill
   • 智能推荐 Skill

3. 生态化

   • 更多的 Skill 商店
   • 更好的发现机制
   • 社区驱动发展

4. 企业化

   • 企业级 Skill 管理
   • 团队协作功能
   • 权限和审计

可能的发展：

• Skill 市场会越来越成熟
• 会出现专业的 Skill 开发者
• 企业会建立自己的 Skill 库
• Skill 会成为 AI 工作流的标准

更多资源

学习资源

• Cursor Skill 文档 - 讲得很清楚
• Anthropic 官方仓库 - 最规范的参考
• Agent Skills 解读 - 深入解析

社区

• awesome-claude-skills
• awesome-agent-skills
• skills.sh

相关文档

• 快速入门
• 发现 Skill
• 开发者 Skill 推荐
• 创建 Skill
• Skill 拆解