让 Claude Code Skills 100%生效的NB技巧

写在前面

上个月我在 Claude Code 里配置了一堆 Skills，满心期待它能自动识别我的需求，结果呢？

它就像没看见一样，直接开始瞎写代码。

我当时就在想：这玩意儿不是号称"自动识别"吗？怎么感觉像生效不生效是看运气——运气好就激活，运气不好就装死。

后来我发现，国外有个老哥 Scott Spence 也遇到了同样的问题。更狠的是，人家直接搭了个测试框架，跑了 200 多次测试，找出了两套方案，把激活成功率从可怜的 20% 提升到了 80-84%。

我看完文章之后立刻试了一下，效果确实好很多。今天就来分享一下这套方法，看看我们能从中学到什么。

问题到底出在哪？

首先我们要理解，Claude Code Skills 的设计初衷是自动激活的。

官方文档说得很清楚：Claude 会"根据你的请求自主决定何时使用它们"。听起来很美好对吧？

但实际情况是：它压根不管你配置的 Skills，直接按照自己的理解开始干活。

作者最开始也试过一个简单的解决方案——在 Hook 里加一句指令：

# 简单指令版本
echo 'INSTRUCTION: If the prompt matches any available skill keywords,
use Skill(skill-name) to activate it.'

这个方案的成功率只有 50%。没错，就是抛硬币的概率。

为什么会这样？因为这只是一个被动的建议。Claude 看到了，点点头表示知道了，然后就把它忘在脑后，开始按自己的想法写代码了。

搭建测试框架

既然问题这么明显，那咱就得好好测一测。

作者搭了个相当正式的测试环境：

• • SQLite 数据库：记录每次测试的结果
• • 多种 Hook 配置：对比不同方案的效果
• • 合成测试 + 真实测试：既用 API 跑批量测试，也手动测试真实场景
• • 完整的指标跟踪：成功率、延迟、成本，一个不落

他准备了 4 个 Skills，专门针对 SvelteKit 开发：

1. 1. svelte5-runes - Svelte 5 的响应式系统（$state、$derived 之类的）
2. 2. sveltekit-data-flow - 数据加载、表单处理、服务端函数
3. 3. sveltekit-structure - 路由结构、布局、错误边界
4. 4. sveltekit-remote-functions - 类型安全的远程函数调用

理论上，当你问"怎么创建表单"的时候，sveltekit-data-flow 应该自动激活；问"怎么用 $state"的时候，svelte5-runes 应该跳出来。

但现实是：没有合适的 Hook，这些 Skills 就是摆设。

五种测试场景

作者设计了 5 种典型的开发任务，每种任务跑 10 次，总共 50 次测试：

1. 表单路由创建
"创建一个 /posts/new 路由，包含表单来创建博客文章。提交成功后跳转到 /posts，如果标题为空显示验证错误。"

这个任务应该激活：sveltekit-structure（路由结构）、sveltekit-data-flow（表单处理）、svelte5-runes（响应式状态）

2. 数据加载
"创建一个 /products 页面，在 load 函数里从数据库加载产品数据，然后显示成列表。"

应该激活：sveltekit-data-flow

3. 服务端操作
"添加一个 +page.server.ts 文件来处理联系表单的提交，验证邮箱和消息字段。"

应该激活：sveltekit-data-flow、sveltekit-structure

4. 远程函数
"创建一个 query() 远程函数来获取用户资料，以及一个 command() 来更新偏好设置。"

应该激活：sveltekit-remote-functions

5. Svelte 5 Runes
"用 Svelte 5 runes 创建一个计数器组件，用 $state 存储 count，用 $derived 计算 doubled 值。"

应该激活：svelte5-runes

其中最难的是第一个任务——它涉及三个不同的 Skill，简单指令在这种多技能场景下彻底崩溃。

四种 Hook 方案对决

作者测试了 4 种不同的 Hook：

1. 1. 无 Hook：基准测试，啥也不做
2. 2. 简单指令：就是前面说的 50% 成功率那个
3. 3. 强制评估：让 Claude 在执行前必须明确评估每个 Skill
4. 4. LLM 预评估：用 Claude API 提前判断应该激活哪些 Skill

测试结果（重点来了）

直接上数据：

看到没？简单指令在复杂任务上全军覆没（表单路由 0%，数据加载 0%），而强制评估和 LLM 预评估的成功率直接飙到 80% 以上。

成本与性能对比

所有测试都用的 Claude Haiku 4.5（输入 5/MTok）：

关键发现：

• • 简单指令在多技能任务上完全失败（表单路由：0%，数据加载：0%）
• • 强制评估在所有类别都没有完全失败过（最稳定）
• • LLM 预评估更便宜、更快，但可能会完全漏掉某些任务

两种新方案都比 20% 的简单指令强太多了。

获胜者：强制评估 Hook

强制评估 Hook 达到了 84% 的总体成功率，在 5 个任务中有 3 个拿到了满分。

我们来看看它的核心代码：

#!/bin/bash
# UserPromptSubmit hook - 强制技能评估

cat <<'EOF'
指令：强制技能激活流程

步骤 1 - 评估（必须在响应中完成）：
针对 <available_skills> 中的每个技能，陈述：[技能名] - 是/否 - [理由]

步骤 2 - 激活（紧接着步骤 1 立即执行）：
如果任何技能为"是" → 立即为每个相关技能使用 Skill(技能名) 工具
如果所有技能为"否" → 说明"不需要技能"并继续

步骤 3 - 实现：
只有在步骤 2 完成后，才能开始实现。

关键：你必须在步骤 2 调用 Skill() 工具。不要跳过直接实现。
评估（步骤 1）如果不激活（步骤 2）就毫无价值。

正确流程示例：
- research: 否 - 不是研究任务
- svelte5-runes: 是 - 需要响应式状态
- sveltekit-structure: 是 - 需要创建路由

[然后立即使用 Skill() 工具：]
> Skill(svelte5-runes)
> Skill(sveltekit-structure)

[只有完成这些之后才开始实现]
EOF

为什么这个方案有效？

简单指令和强制评估的核心区别在于承诺机制。

简单指令（20-40% 成功率）：

echo '指令：如果提示匹配任何可用技能关键词，
使用 Skill(技能名) 来激活它。'

这只是个被动建议。Claude 看到了，心里想"嗯我知道了"，然后就把它扔在一边，直接开始写代码。这就是背景噪音而已。

强制评估（84% 成功率）：

步骤 1 - 评估：针对每个技能，说明 是/否 及理由
步骤 2 - 激活：现在就使用 Skill() 工具
步骤 3 - 实现：只有激活后才能实现

关键：如果不激活技能，评估就毫无价值。

这创建了一个三步流程，Claude 必须：

1. 1. 展示推理过程 - 明确评估每个技能
2. 2. 做出承诺 - 为每个技能说明 是/否
3. 3. 执行承诺 - 不激活就不能继续实现

激进的用词也起了作用。"强制"、"毫无价值"、"关键"这些词让 Claude 更难忽略指令。

这就像编程中的"签合同"——一旦 Claude 在响应中写下"是 - 需要响应式状态"，它就承诺要激活那个技能了。

唯一的问题：不是完美的（84%），而且因为提示词更长，会用更多 token。但 84% 对比 20%？我愿意接受这个代价。

LLM 预评估 Hook（更便宜但可能翻车）

LLM 预评估 Hook 很有意思——它用 Claude API 提前评估哪些技能匹配，然后再让 Claude Code 看到提示：

#!/bin/bash
# 调用 Claude API 评估哪些技能匹配

EVAL_PROMPT=$(cat <<EOF
只返回一个匹配该请求的技能名称 JSON 数组。

请求：${USER_PROMPT}

技能：
${AVAILABLE_SKILLS}
格式：["技能名"] 或 []
EOF
)

RESPONSE=$(curl -s https://api.anthropic.com/v1/messages 
  -H "content-type: application/json" 
  -H "x-api-key: $ANTHROPIC_API_KEY" 
  -d "{
    \"model\": \"claude-haiku-4-5-20251001\",
    \"max_tokens\": 200,
    \"messages\": [{
      \"role\": \"user\",
      \"content\": $(echo "$EVAL_PROMPT" | jq -Rs .)
    }]
  }")

# 提取技能并指示 Claude 激活它们

使用 Haiku 4.5 的话，每次提示大概花费 $0.0004（0.04 美分）。

优点：

• • 每次提示便宜 10%（0.0673）
• • 快 17%（5.0秒 vs 5.4秒延迟）
• • 在服务端操作上达到 100%（强制评估只有 40%）
• • 有时会添加强制评估遗漏的"聪明"相关技能

缺点：

• • 在表单路由创建上完全失败（0/10）——每次都漏掉 svelte5-runes
• • 更不稳定——做对的时候很聪明，但也可能完全漏掉
• • 需要 API 密钥，每次提示都要调用外部 API

LLM 预评估在起作用时更聪明，但也可能翻车翻得很惨。强制评估更稳定，即使可能不那么智能。

如何使用强制评估 Hook

如果你想试试这个方案：

1. 创建 Hook 文件

在项目中创建 .claude/hooks/skill-forced-eval-hook.sh（或者全局放在 ~/.claude/hooks/）

2. 复制上面的强制评估脚本

3. 设置执行权限

chmod +x skill-forced-eval-hook.sh

4. 在 .claude/settings.json 中配置

{
  "hooks": {
    "UserPromptSubmit": [
      {
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/skill-forced-eval-hook.sh"
          }
        ]
      }
    ]
  }
}

现在当你给 Claude 发提示时，你会看到它在继续之前明确评估每个技能。虽然输出会比较啰嗦（Claude 会列出每个技能的 是/否 及理由），但 84% 的激活率对比 20%，这点啰嗦完全值得。

该用哪个 Hook？

用强制评估，如果：

• • 你想要最稳定的激活率（84%）
• • 你不介意啰嗦的输出（Claude 会在工作前列出所有技能）
• • 你想要纯客户端解决方案（不用调 API）

用 LLM 预评估，如果：

• • 你想要更便宜/更快的响应（成本低 10%，速度快 17%）
• • 你的提示比较直接（单技能场景）
• • 你能接受偶尔的完全失败（比如表单路由那个 0%）
• • 你有 Anthropic API 密钥

用简单指令，如果：

• • 你喜欢失望和抛硬币 😅

对我来说，我会用强制评估 Hook。84% 的成功率值得那点啰嗦，而且不用担心 API 密钥或外部依赖。

总结

Skills 应该根据描述自动激活。但它们不会。"简单指令"方法给你 20% 的成功率——抛硬币而已。

在测试了 200 多次提示、对比了多种配置之后，我们找到了两种真正有效的方法：

• • 强制评估 Hook：84% 成功率，更稳定，无外部依赖
• • LLM 预评估 Hook：80% 成功率，便宜 10%/快 17%，但可能翻车翻得很惨

两种方案都远远好于 20% 的基准线。都不完美，但已经够用了。

强制评估之所以有效，是因为它创建了一个承诺机制——Claude 必须明确评估每个技能并说明 是/否，然后才能继续实现。虽然啰嗦（你会在每次响应中看到评估过程），但它很稳定。

对我来说，84% 对比 20% 值得这点啰嗦。你可以根据自己的需求选择稳定性（强制评估）还是成本/速度（LLM 预评估）。

P.S. 如果你有更好的方法或者测试发现，我很想听听。完整的测试数据在原作者的 GitHub repo 里，感兴趣的可以去看看