FAQ

基础概念

Skill 和 MCP 有什么区别？

简单理解：

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

形象比喻：

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

技术区别：

维度	MCP	Skill
作用	连接外部系统	定义工作流程
加载方式	预加载所有工具定义	按需加载
Token 消耗	高（预加载）	低（渐进式披露）
适用场景	需要实时数据	需要标准化流程
跨平台	需要适配	更容易迁移

实际例子：

场景：处理 PDF 文档

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

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

能否互相替代？

不能。它们是互补的：

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

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

特性	普通提示词	Skill
复用性	每次都要重新输入	一次定义，长期复用
触发方式	手动输入	自动识别场景触发
结构化	自由文本	标准化格式
可维护性	难以维护	版本控制、团队共享
复杂度	适合简单任务	适合复杂工作流
脚本支持	不支持	支持

什么时候用提示词，什么时候用 Skill？

用提示词：

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

用 Skill：

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

使用问题

为什么我的 Skill 没被调用？

最常见的原因：description 不够明确

检查清单：

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

解决方法：

❌ 不好的 description：

description: Review code

✅ 好的 description：

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

其他可能的原因：

Skill 太多导致冲突
- 解决：减少 Skill 数量，保持在 10-30 个
- 解决：让每个 Skill 的触发条件更明确
Skill 名称和内容不匹配
- 解决：确保 name、description、内容一致
显式调用
- 临时方案：在对话中提到 Skill 名称（如 @code-reviewer）

Skill 支持热更新吗？

支持，但有条件：

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

如何热更新：

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

注意：

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

一次应该装多少个 Skill？

推荐数量：

新手：1-3 个
- 先用起来，体验效果
- 不要贪多
进阶：5-10 个
- 按工作流组合
- 覆盖高频场景
团队：10-30 个
- 建立标准库
- 统一团队规范
超过 30 个：不推荐
- 会给模型带来负担
- 效果反而下降
- 触发冲突增加

实际经验：

根据实际体验和经验分析，一般一个工具的 Skill 推荐在 10-30 个左右。太多则会给模型上下文带来负担，太少的 Skill 则无法起到很好的效果。

优化策略：

分工具配置
- 开发工具：只装开发相关的
- 内容工具：只装内容相关的
- 不要把所有 Skill 都装在一个工具里
定期清理
- 每月检查一次
- 删除从未使用的 Skill
- 优化高频使用的 Skill

如何调试 Skill？

调试步骤：

检查 Skill 是否被加载
```
# 查看已安装的 Skill
eskill list
```
检查 description
- 是否包含触发关键词？
- 是否足够具体？
显式调用测试
```
使用 @my-skill 处理这个任务
```
查看执行日志
- 观察 AI 的执行步骤
- 看是否调用了 Skill
- 看是否执行了脚本
简化测试
- 用最简单的输入测试
- 逐步增加复杂度
- 记录每次的结果

常见问题和解决方法：

问题	可能原因	解决方法
Skill 没被触发	description 不明确	增加触发关键词
输出不稳定	步骤描述模糊	提供更详细的步骤和示例
执行太慢	提示词太长	把细节移到 references/
脚本执行失败	依赖缺失	检查脚本依赖
结果不准确	应该用脚本的地方用了提示词	改用脚本实现

安全问题

Skill 安全吗？

风险点：

脚本执行风险
- Skill 可以包含可执行脚本
- 恶意脚本可能窃取数据
- 恶意脚本可能破坏系统
数据泄露风险
- 脚本可能上传数据到外部服务器
- 脚本可能读取敏感文件
- 脚本可能记录你的操作
供应链风险
- 依赖的第三方库可能有漏洞
- Skill 可能被劫持
- 更新可能引入恶意代码

如何保护自己：

只装可信来源的 Skill
- ✅ Anthropic 官方
- ✅ 知名开发者
- ✅ 经过审查的商店
- ❌ 来路不明的 Skill
安装前审查
- 查看 SKILL.md
- 检查 scripts/ 目录
- 看是否有混淆代码
- 看是否有网络请求

使用审查工具

# 安装 Skill Vetter
npx skills add anthropics/skills/skill-vetter

# 审查 Skill
使用 @skill-vetter 审查 <skill-path>

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

Skill Vetter 的局限性：

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

最保险的做法：

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

如何审查一个 Skill？

审查清单：

来源检查
- 来自可信的开发者或组织？
- GitHub 仓库有足够的 Star 和活跃度？
- 有完整的文档和使用说明？
代码检查
- SKILL.md 内容清晰合理？
- 没有混淆的代码？
- 脚本功能和描述一致？
权限检查
- 需要的权限合理吗？
- 有没有不必要的网络请求？
- 有没有读取敏感文件？
依赖检查
- 依赖的库都是官方的？
- 没有可疑的第三方依赖？
- 依赖版本是最新的？

重点关注：

# 检查是否有网络请求
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 和 Sub-agents 有什么区别？

维度	Skill	Sub-agent
作用	定义工作流程	并行执行任务
执行方式	在当前会话中执行	独立会话
Token 消耗	低	高
适用场景	标准化流程	大规模并行任务
上下文	共享主会话上下文	独立上下文