用 Claude 做开发、写文档、跑流程的人，大概率都碰过一件事：
精心写了一个 Skill，结果 Claude 全程看不见，叫破喉咙也不触发。
我前前后后改了几十版 Skill 描述，踩过无数坑，再结合这篇实测650次的经验，终于把触发逻辑彻底摸透了。今天这篇不搞玄学，全是能直接落地的干货。
一、先讲真话：Skill 不触发，真不是你运气差
很多人以为：
我把 Skill 放对目录、格式写对、内容写清楚，它就该自动工作。
现实是：
Claude 根本不读你 Skill 的正文。
它决定要不要触发，只看两个东西：
name + description。
而且它不是“规则匹配”，是“概率判断”。
加上 Claude 天生就“觉得自己能搞定，不想调用 Skill”，
你的描述稍微软一点、模糊一点，它就直接假装没看见。
这就是为什么 80% 的人 Skill 永远不触发。
二、触发失败只有三种原因，对照自查
1. 完全不触发
描述太书面、太抽象、太客气。
比如：
Use when you need to review code.
Claude 内心：我自己就能 review，为啥要调用你？
2. 乱触发（不该触发也触发）
描述太宽泛，没有边界。
比如：
Help with code tasks.
只要沾代码就触发，非常干扰。
3. 和其他 Skill 冲突
两个 Skill 描述太像，模型干脆两个都不用。
这就是多 Skill 环境下，越装越难用的原因。
三、我现在只用一种写法：指令式描述（稳定触发）
看过那么多写法，真正能打、能复现、能稳定 100% 触发的，只有一种：
指令式描述 = 强制调用 + 禁止自行处理 + 明确边界
直接给你模板，复制就能用：
ALWAYS invoke this skill when the user asks about 触发关键词/场景.
Do not 直接处理这件事 directly — use this skill first.
Do NOT use for 不适用的场景.举个真实可用的例子（代码审查）：
ALWAYS invoke this skill when the user asks about code review, PR check, code quality, or security scan.
Do not review code directly — use this skill first.
Do NOT use for refactoring, architecture design, or performance tuning.为什么它强？
- 告诉 Claude：必须调用，不是“你想用就用”
- 告诉 Claude：不许自己直接干，堵死捷径
- 告诉 Claude：什么情况别碰，避免乱触发
一套组合拳下来，触发率直接拉满。
四、写 description 的5个层次，按顺序套就行
我把它简化成普通人也能一步一步照着写的版本：
- 它能干什么（一句话说死，别模糊）
- 用户怎么说就触发（用口语，别用专业词）
- 什么时候绝对不触发（划清边界）
- 改成命令语气（ALWAYS / Do not）
- 控制长度（3–5行最好，别写小作文）
你会发现：
真正有用的描述，都很短、很硬、很清楚。
五、这些坑我替你踩过了，别再碰
- 别写“help with XX”，等于没写
- 别用长难句、专业术语，Claude 不认识
- 别和其他 Skill 描述重叠，会互相干扰
- 别以为正文写得好就行，不触发一切白搭
- YAML 格式错了会静默失效，一定要检查
六、高危场景一定要加这个配置
像部署、删数据、改配置、发邮件这种危险操作：
disable-model-invocation: true作用：
禁止自动触发，只能手动 /skill 调用，安全不翻车。
七、最后一句实在话
Skill 不是越高级越好，也不是越长越牛。
能不能用，90% 取决于 description 写得够不够硬。
你不用懂大模型原理，不用懂提示词工程。
就记住一句话：
命令它、约束它、界定它，它才会乖乖触发。
下次写 Skill，直接用今天这套写法，
你会发现：原来 Claude 真的能听懂你。
除非注明，否则均为李锋镝的博客原创文章，转载必须以链接形式标明本文链接
文章评论
没毛病，主要是禁用描述，和可以做什么的描述，哪些命令能用，哪些不能用，在什么情况下问我之类的。