企业官网建设流程全解析

1. 从 32 个 Skill 到 6 个：我为什么开始做减法

Claude Code 的 Skill 系统，说白了就是一套可复用的 prompt 模板机制。核心文件是SKILL.md，分两段：YAML frontmatter 负责告诉 Claude「什么时候该用我」，markdown body 负责告诉 Claude「具体怎么做」。每次会话启动时，Claude 只把每个 Skill 的名字和描述加载进上下文，大概 100 tokens 一个，全文要等触发时才读。听起来很省，对吧？

问题就出在这个「听起来」上。我一开始也是这么想的，于是三个月里陆陆续续装了 32 个 Skill：有从npx skills一键拉的，有从 GitHub 上手动 clone 的，还有几个是自己照着模板写的。结果某天跑/doctor一看，17 个 Skill 的描述被截断了——也就是说，超过一半的 Skill 在 Claude 眼里根本不存在，装了等于没装。

这篇不是推荐清单，而是一份取舍清单。我会把settings.json和SKILL.md的骨架摊开，讲清楚哪些 Skill 值得留、哪些该删、删完之后怎么验证触发是否正常。适合已经装了一堆 Skill、但感觉「好像没起作用」的 Claude Code 用户，尤其是后端方向的开发者。

2. 描述预算：Skill 装多了为什么会互相挤占

Claude Code 把所有 Skill 的名称加描述塞进上下文，让模型知道「我手上有哪些工具」。这个预算默认是模型 context window 的 1%。单个 Skill 描述最长 1536 字符，10 个 Skill 全量描述大约占 15K tokens。如果你装了 30 个，优先级低的描述就会被截断，Claude 直接不知道有这个工具存在。

这就是「装了很多但没用」的根本原因，不是 Skill 质量差，是它压根没被加载。

先跑一条命令确认现状：

# 在 Claude Code 会话里执行 /doctor

输出里会有一行类似Skill listing budget: 1% (used 0.87%)的信息。如果 used 接近或超过 100%，说明已经在截断边缘。我当时的输出是used 1.42%，超了 42%，17 个 Skill 被砍。

有两个应对方向。一是删低频 Skill，保留 10 到 15 个核心的；二是在.claude/settings.json里提高预算比例：

{ "skillListingBudgetFraction": 0.02 }

但我建议走第一条路。把预算提到 2% 只是缓解症状，30 个 Skill 本身就是问题——描述之间会语义重叠，Claude 在触发时反而犹豫。我最后砍到 6 个，/doctor显示used 0.31%，触发准确率肉眼可见地上升。

3. settings.json 与 SKILL.md 骨架：可复制的配置

先说settings.json。这是 Claude Code 的全局或项目级配置，Skill 相关的关键字段不多，但每个都影响触发行为。下面是我现在用的版本，放在~/.claude/settings.json：

{ "skillListingBudgetFraction": 0.01, "permissions": { "allow": [ "Bash(git status)", "Bash(git diff:*)", "Bash(go build:*)", "Bash(go test:*)", "Bash(docker ps)" ] }, "hooks": { "PostToolUse": [ { "matcher": "Edit", "command": "echo 'file edited'" } ] } }

skillListingBudgetFraction保持默认 0.01 就行，前提是你 Skill 数量控制住了。permissions.allow里放的是高频只读命令，避免每次调用 Bash 都弹确认框——这一条能省掉大量点击。hooks部分按需加，我目前只留了一个编辑后提示，用来观察 Skill 是否真的在改文件。

再说SKILL.md的精简模板。一个 Skill 一个目录，路径是~/.claude/skills/<skill-name>/SKILL.md（全局）或.claude/skills/<skill-name>/SKILL.md（项目级）。模板如下：

--- name: go-coverage-improvement description: Use when the user wants to improve Go test coverage, analyze uncovered paths, or generate table-driven tests. Triggers on phrases like "提升覆盖率", "coverage gap", "写测试". --- # Go Coverage Improvement ## When to use - 项目测试覆盖率低于目标值 - 需要针对未覆盖分支生成测试用例 - 检查 table-driven test 的完整性 ## Steps 1. 运行 `go test -coverprofile=cover.out ./...` 2. 用 `go tool cover -func=cover.out` 找出未覆盖函数 3. 针对每个未覆盖路径生成 table-driven test 4. 重新运行覆盖率，确认提升 ## Constraints - 不生成只为了覆盖率而覆盖率的空测试 - 优先覆盖业务逻辑分支，跳过 getter/setter

关键在description这一行。它决定了 Claude 什么时候触发这个 Skill。我踩过的坑是：描述全用英文写，结果我用中文说「帮我把覆盖率提一下」，Claude 不触发。后来在 description 里补了中文触发词，命中率立刻上来了。所以 description 要中英混写，把用户可能说的口语都塞进去。

4. 逐项验证：删完之后怎么确认 Skill 真的在工作

删 Skill 不是目的，确认留下的能触发才是。我用的验证流程分三步。

第一步，列出现有 Skill，确认目录结构干净：

npx skills list

输出会列出所有已安装 Skill 的名字和来源。如果看到重复的（比如同一个 Skill 在全局和项目级各装了一份），删掉项目级那份，避免描述重复占用预算。

第二步，手动触发测试。对每个保留的 Skill，用它的触发词说一句话，看 Claude 是否调用。比如测go-coverage-improvement：

帮我看下这个 Go 项目的覆盖率缺口，生成几个测试用例

如果 Claude 回复里出现「正在使用 go-coverage-improvement」或类似提示，说明触发成功。如果没反应，回到SKILL.md检查 description 里的触发词是否覆盖了你刚才的说法。

第三步，跑/doctor确认预算：

/doctor

理想状态是used低于 0.5%。我删到 6 个 Skill 后，这个数字是 0.31%，留了足够余量给后续新增。

这里插一句，如果你在验证过程中需要频繁调用模型来测试 Skill 的触发效果，可以用 TaoToken 的模型对话入口快速起一个会话，不用每次都开本地 Claude Code。地址是 https://taotoken.net/api ，配合 API Key 就能跑。

5. 本篇常见错排查

错误一：/doctor显示预算超了，但不知道删哪个。按使用频率排。打开你的 Claude Code 历史会话，数一下过去两周每个 Skill 被触发了多少次。触发 0 次的直接删，触发 1 到 2 次的合并或删。我当时的 32 个里，有 11 个两周内一次都没触发过。

错误二：Skill 装了但 Claude 从不主动用。先查 description 的语言匹配。如果你的请求是中文，description 全是英文，大概率不触发。解决办法是在 description 里补中文触发词，或者直接手动调用 Skill 名。

错误三：settings.json改了不生效。Claude Code 只在启动时读一次配置。改完settings.json要重启会话。另外确认你改的是正确层级的文件——项目级.claude/settings.json会覆盖全局~/.claude/settings.json，别改错了地方。

错误四：npx skills add装完找不到 Skill。检查安装路径。-g装到全局~/.claude/skills/，不加-g装到当前目录的.claude/skills/。如果你在 A 目录装的，跑到 B 目录用，自然找不到。用npx skills list确认实际安装位置。

错误五：Skill 之间描述语义重叠，触发时互相抢。比如你同时装了simplify和另一个「代码精简」Skill，Claude 在触发时会犹豫。保留一个就行。我删掉的 80% 里，有相当一部分是功能重叠的。

6. 取舍之后：把 Skill 当工具，别当收藏

删到 6 个之后，我的日常是这样的：superpowers管工作流，simplify管代码精简，security-review管安全扫描，go-coverage-improvement管测试，claude-api管 API 调用，init管项目初始化。每个都有明确的触发场景，/doctor预算充裕，触发准确。

如果你也在做类似的取舍，建议先从/doctor看预算开始，再按触发频率排序，最后用SKILL.md的 description 做语言匹配验证。需要长期跑编码任务或 Agent 工作流的话，可以看下 TaoToken 的 Coding Plan，地址是 https://taotoken.net/api ，配合settings.json里的权限白名单，能把重复确认的干扰降到最低。