网上有很多介绍 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 依然非常值得使用！
