别再神话 Claude Skills 了：这 12 个“致命”局限性你必须知道

网上有很多介绍 Claude Skills 的文章，但是很少有人提 Skills 的局限性。

甚至看到有人稍微把 Skills 吹过头了！

说实话，Skills 是解决大模型缺乏专业知识、解决上下文窗口等问题的一个先进解法，但目前还不完美。

我认为当你无法说出一个技术的局限性的时候，也就意味着其实你对这个技术的了解并不够。

这篇文章结合自己的理解，谈谈 Claude Skills 的局限性，希望对大家有启发。

支持 Claude Skills 的平台还是比较有限：虽然很多 AI Coding 工具刚开始兼容，如 Antigravity、Qwen Code ，但并不是所有的工具都支持，而且支持的工具的全局路径也不统一。比如 Antigravity 的全局路径为：~/.gemini/antigravity/skills/<skill-folder>/ ，Qwen Code 的全局路径为~/.qwen/skills/<skill-folder>/ 等。

详情参见：

• https://antigravity.google/docs/skills
• https://github.com/QwenLM/qwen-code/tree/main

缺乏同步机制：比如说 Claude 的客户端、Claude Code 或者 API 之间，需要在不同的工具上单独配置。

Skills 不够丰富：现在虽然有一些 Skills，但是我们想要的 Skills 可能就没有，或者是有，但是并不好用。这一点和 MCP  的困境差不多，很多想要的 MCP服务不是没有就是不稳定。

目前，对于普通人来说安装和使用 Skills 门槛偏高。现在的skill安装和使用还是相对来说，对于普通人来说还是偏难一些，并不是很友好，也没有足够小白。

高度依赖描述的准确性：Skills 不是由用户显式调用的（不同于斜杠命令 /command），而是由模型根据 SKILL.md 中的 description（描述）字段自主决定何时激活。如果描述过于模糊、笼统，或者与用户的提示词匹配度不高，Claude 可能根本不会使用该 Skill。

多 Skill 冲突：如果安装了多个功能相似的 Skills，且它们的触发描述重叠，Claude 可能会感到困惑，导致调用错误的 Skill 或无法确定使用哪一个。

模型能力的差异：Skill 的执行效果取决于底层模型的能力。在强大的模型上运行良好的指令，在较小或较快的模型上可能因为大打折扣，需要针对不同模型调整指令的详细程度。

占用上下文窗口（Context Window）：虽然 Skills 采用“渐进式披露”机制（先加载元数据，需用时才加载全文），但一旦 Skill 被激活并加载了 SKILL.md 或相关资源文件，如果渐进式加载的文件过多或文件过大，它们就会占用宝贵的上下文 Token。这意味着 Skill 的内容会与系统提示词、对话历史以及用户的实际请求竞争上下文空间。

嵌套引用的读取限制：如果 Skill 的文件结构过于复杂，引用层级超过一级（例如主文件引用 A，A 又引用 B），Claude 可能只会读取文件的开头部分，可能导致信息获取不完整。最佳实践要求所有引用文件应直接在 SKILL.md 中链接。

严格的格式要求：Skills 对文件结构和语法非常敏感。YAML frontmatter（元数据头）必须格式正确，缩进不能用制表符；文件路径必须使用 Unix 风格的正斜杠（/），如果使用 Windows 风格的反斜杠（\）会导致加载错误。

脚本的健壮性要求：如果 Skill 包含脚本，开发者必须自行处理错误捕捉。如果脚本报错而没有清晰的错误输出，Claude 可能会不知所措。此外，脚本中不能包含无法解释的“魔法数字”或未定义的配置。

不适合简单或一次性任务：对于简单的一句话指令或一次性任务，编写和配置一个完整的 Skill（包含文件夹、MD 文件等）显得过于繁琐，不如直接使用 Prompt 或 Slash 命令高效。

安全隐患：由于 Skills 可以包含指令和可执行代码，恶意的 Skill 可能会被设计用来窃取数据或在用户的环境中执行有害操作。用户必须警惕第三方来源的 Skills，建议仅安装来自可信来源的 Skill。

简单来讲，Skills 的效果受模型能力、Skills 本身设计的合理性等多方面因素决定。而且，很多时候，我们想要的“技能”（如去除 Gemini 3 Pro Image 图片、PPT、视频水印）可能没有 Skills，有 Skills 可能不太好用，存在安全隐患等。

需要注意的是，讲 Skills 的一些缺点并不是在否定 Skills 的优秀，Skills 依然非常值得使用！