企业官网建设流程全解析

1. 从“装了一堆”到“删掉八成”：一个真实的使用轨迹

去年秋天我开始认真用 Claude Code 做日常开发，那时候的心态跟很多人一样——看到社区里有人分享一个 Skill，觉得有用，装；看到另一个能自动生成测试用例的，也装；再刷到一个能帮我写周报的，顺手也装。三个月下来，.claude/skills目录里塞了四十多个文件夹，每个里面都躺着一份SKILL.md。结果呢？真正每天在用的，掰着手指头数得过来，不超过八个。

这个标题说的“删掉 80%”，不是夸张。我最后清理完，四十多个 Skill 只留了七个。剩下的要么功能重叠，要么触发条件太模糊根本轮不到它上场，要么就是当初装的时候觉得“以后可能会用”，结果三个月一次都没被调用过。

如果你也在用 Claude Code，或者刚开始接触 Skill 这套机制，正在纠结“到底该装哪些”“怎么管理这些 Skill”，那这篇就是写给你的。我会把自己踩过的坑、删掉的那些 Skill 到底为什么被删、留下来的七个又凭什么活下来，全部拆开讲清楚。涉及到的SKILL.md写法、settings.json配置、npx skills的用法，都会给到可以直接抄的示例。

先说一个核心判断：Skill 不是越多越好，每多一个 Skill，你的上下文里就多一份“噪音”。Claude Code 在决定调用哪个 Skill 的时候，需要读取所有 Skill 的描述信息来做匹配。Skill 越多，匹配的准确率反而会下降，因为相似描述之间会互相干扰。这跟你在一个塞满工具的抽屉里找螺丝刀是一个道理——工具越多，找起来越慢，还容易拿错。

2. Skill 机制到底怎么工作的：先搞懂原理再谈取舍

2.1 SKILL.md 的加载逻辑与触发条件

很多人装 Skill 的时候根本没看过SKILL.md里面写了什么，直接复制粘贴就完事了。但你要做取舍，就必须先理解它是怎么被触发的。

Claude Code 启动时，会扫描.claude/skills目录下的所有子文件夹，读取每个文件夹里的SKILL.md。这个文件通常包含两部分：元信息（名称、描述、触发关键词）和正文内容（具体的指令、步骤、示例）。元信息部分会被加载到上下文里，用于判断“当前这个任务要不要调用这个 Skill”；正文内容只有在 Skill 被真正调用时才会完整加载。

这就意味着一个关键结论：元信息的质量直接决定了 Skill 会不会被用上。我见过太多SKILL.md的描述写得含糊其辞，比如“帮助处理代码相关任务”——这种描述等于没写，Claude 根本判断不出来什么时候该用它。

一个写得好的描述应该是这样的：

--- name: api-test-generator description: 当用户需要为 REST API 接口生成单元测试时使用，支持 Express、FastAPI、Spring Boot 三种框架，输入接口定义文件路径即可生成对应的测试代码 trigger: 生成接口测试、写 API 测试、接口单测 ---

对比一下那种“帮助生成测试代码”的模糊描述，上面这个明确说了什么时候用（为 REST API 生成单元测试）、支持什么（三种框架）、怎么用（输入接口定义文件路径）。Claude 在匹配的时候，命中率完全不是一个级别。

2.2 上下文窗口的“隐性成本”

这是很多人忽略的一点。每个 Skill 的元信息虽然不长，但四十多个 Skill 加起来，光描述信息就能占掉一两千个 token。这些 token 是每一轮对话都要消耗的，不管你这次有没有用到那个 Skill。

我做过一个粗略的测算：一个中等复杂度的SKILL.md，元信息部分大约 50 到 80 个 token。四十个 Skill 就是 2000 到 3200 个 token 的固定开销。听起来不多？但当你上下文窗口用到后期，这几千个 token 可能就是“还能不能塞下一整个文件”的区别。

更关键的是干扰效应。当你有五个 Skill 的描述里都出现了“代码审查”这个词，Claude 在匹配的时候就会犹豫，可能选了 A 但其实 B 更合适，或者干脆一个都不选。删掉冗余的 Skill 之后，剩下那个“代码审查”Skill 的调用准确率会明显上升。

2.3 npx skills 与手动管理的区别

社区里有个工具叫npx skills，可以快速安装和管理 Skill。用法很简单：

npx skills install <skill-name> npx skills list npx skills remove <skill-name>

但我要说的是，不要完全依赖工具来管理。npx skills帮你做的是下载和放置文件，它不会帮你判断“这个 Skill 跟已有的有没有冲突”“描述写得够不够好”。我早期就是无脑npx skills install，装了一堆功能重叠的，后来手动整理的时候才发现，光“生成 commit message”这个功能就有三个不同的 Skill，描述还都差不多。

手动管理的核心工作是两件：定期审查SKILL.md的描述质量，以及合并功能重叠的 Skill。这两件事工具替你做不了。

3. 我删掉的 80% 都长什么样：五类典型“僵尸 Skill”

3.1 第一类：功能重叠的“多胞胎”

这是数量最多的一类。我装了三个跟“代码格式化”相关的 Skill，分别来自不同的作者，功能大同小异，都是读取文件、按规则格式化、写回。区别只在于一个支持 Prettier 配置，一个支持 ESLint 配置，还有一个两个都支持。

这种“多胞胎”Skill 的危害在于：它们互相干扰，导致 Claude 在需要格式化的时候反而不知道该调哪个，最后可能一个都不调，直接用自己的默认行为处理了。我删掉两个，只留了那个两个配置都支持的，调用成功率立刻上来了。

判断标准很简单：如果两个 Skill 的描述里，有超过 60% 的关键词是重叠的，那大概率只需要留一个。留哪个？留描述更具体、覆盖场景更广的那个。

3.2 第二类：触发条件模糊的“万金油”

有一类 Skill 的描述写得特别宽泛，比如“帮助提升代码质量”“辅助代码重构”“优化项目结构”。这种 Skill 的问题在于，Claude 根本判断不出来什么时候该用它——因为几乎所有编程任务都可以算作“提升代码质量”。

我删掉的一个典型例子是一个叫“code-helper”的 Skill，描述是“帮助处理各种代码相关问题”。装了一个月，一次都没被调用过。因为 Claude 在面对具体任务时，会优先匹配描述更精确的 Skill，这种“万金油”永远排在后面。

注意：如果你在写自己的 Skill，描述里一定要包含具体的触发场景和明确的输入输出。宁可写窄一点，也不要写宽。窄了可以后续扩展，宽了等于没有。

3.3 第三类：低频使用的“偶尔用一次”

这类 Skill 最让人纠结——它确实有用，但使用频率极低。比如我装过一个“生成数据库迁移脚本”的 Skill，三个月里只用了两次。还有一个“生成项目 README”的，用了一次。

这种 Skill 要不要删？我的判断标准是：如果一个月用不到一次，就删掉。需要的时候再装回来就是了，npx skills install几秒钟的事。留在那里，它每天都在消耗你的上下文资源，而收益是一个月才兑现一次。

有人可能会说“删了万一要用怎么办”。我的实际经验是：真正需要的时候，你花两分钟重新装一个，比让它在那里躺三个月只为了省这两分钟，划算得多。

3.4 第四类：质量不过关的“半成品”

社区里分享的 Skill 质量参差不齐。我装过几个，用的时候才发现SKILL.md里的指令写得模棱两可，示例代码跑不通，甚至有的连基本的错误处理都没写。

这类 Skill 的危害不只是“没用”，而是会误导 Claude 产生错误的输出。一个写得不好的 Skill，比没有 Skill 更糟糕。因为 Claude 会认真执行里面的指令，但指令本身有问题，结果就是产出垃圾。

我删掉的一个典型是一个“自动生成 API 文档”的 Skill，它的指令里说“读取所有路由文件，提取注释生成文档”，但没有说明注释的格式要求。结果 Claude 把代码里所有的//注释都提取出来了，包括那些“TODO”“FIXME”之类的，生成的文档完全不能用。

3.5 第五类：跟当前项目无关的“外来户”

我同时维护着几个不同类型的项目——有 Node.js 后端、有 Python 数据处理脚本、还有一个纯前端的 React 项目。早期我把所有项目相关的 Skill 都装在全局目录里，结果就是：写 Python 的时候，一堆 Node.js 相关的 Skill 在干扰匹配；写前端的时候，Python 的 Skill 又在旁边“凑热闹”。

后来我改成了按项目配置 Skill。Claude Code 支持在项目根目录下放.claude/skills，这样每个项目只加载自己需要的 Skill。全局目录只留那些真正跨项目通用的，比如“生成 commit message”“代码审查”这种。

这个改动带来的效果非常明显：每个项目的 Skill 数量从四十多个降到了五到十个，调用准确率大幅提升。

4. 留下来的七个 Skill：凭什么它们能活下来

4.1 高频刚需：每天至少用一次

留下来的第一个标准就是高频。我统计了一下，最终留下的七个 Skill 里，有四个是每天至少用一次的：

这四个是真正的“日用品”，每天都要用，而且用起来确实省时间。比如commit-writer，我只需要说“帮我写个 commit”，它就会读取当前 git diff，按照 Conventional Commits 规范生成消息，我确认一下就能提交。整个过程不到十秒，比我自己想 commit message 快多了。

4.2 描述精准：Claude 一匹配一个准

留下来的 Skill，SKILL.md的描述都写得非常精准。以test-runner为例，它的描述是这样的：

--- name: test-runner description: 当用户要求运行测试、检查测试结果、或排查测试失败原因时使用。支持 Jest、Pytest、Go Test 三种测试框架，自动识别项目使用的框架并执行对应命令 trigger: 跑测试、运行测试、测试失败了、看看测试结果 ---

这个描述的好处是：触发词覆盖了用户可能说的各种表达方式（“跑测试”“运行测试”“测试失败了”），同时明确了支持的范围（三种框架）和自动识别的能力。Claude 在匹配的时候，只要用户提到跟测试相关的内容，基本都能命中。

4.3 维护活跃：作者还在更新

这一点可能有点主观，但确实是我考虑的因素之一。留下来的 Skill 里，有几个是社区里比较活跃的作者维护的，SKILL.md会随着工具版本更新而调整。而那些装完就没人管的 Skill，用着用着就可能因为 Claude Code 版本升级而失效。

我的做法是：每隔一个月，检查一下留下来的 Skill 有没有更新。如果有，就npx skills update一下；如果发现某个 Skill 已经半年没更新了，而且用起来开始出问题，就考虑替换或删除。

4.4 可组合：能跟其他 Skill 配合使用

留下来的 Skill 还有一个特点：它们之间可以组合。比如我先用code-reviewer审查代码，发现问题后用test-runner跑测试验证，最后用commit-writer提交。这三个 Skill 形成了一个完整的工作流，互相之间的输出可以作为对方的输入。

这种组合能力是单个 Skill 不具备的。当你有一组能配合的 Skill 时，它们产生的价值是 1+1>2 的。而那些孤立的、跟其他 Skill 没有交集的，往往就是最先被删掉的。

5. 实操：如何给你的 Skill 做一次彻底“瘦身”

5.1 第一步：盘点现状，列出所有 Skill

先看看你现在装了多少：

# 查看全局 Skill ls ~/.claude/skills/ # 查看项目级 Skill ls .claude/skills/ # 如果用 npx skills 管理 npx skills list

把所有的 Skill 名称和描述列到一个表格里。这一步的目的是可视化——当你看到四十多个 Skill 排在一起的时候，那种“太多了”的感觉会非常直观。

5.2 第二步：按使用频率分类

接下来做一件事：回顾过去一个月的使用记录。Claude Code 本身不提供调用统计，但你可以手动记录一周。每次调用 Skill 的时候，在笔记里记一笔。一周下来，你就能清楚地看到哪些 Skill 被用过，哪些一次都没出现。

根据我的经验，一周的记录就足够做出判断了。那些一周都没被调用过的 Skill，大概率一个月也不会被调用。

5.3 第三步：合并重叠，删除低频

分类之后，按以下规则处理：

• 功能重叠的：只留一个，选描述最精准、覆盖最广的
• 一周没用过的：直接删，需要时再装
• 描述模糊的：要么重写描述，要么删掉
• 质量差的：果断删，不要犹豫
• 跟当前项目无关的：移到项目级目录，或者删掉

我自己的清理过程花了大约一个小时，从四十多个删到七个。删完之后重启 Claude Code，明显感觉到响应速度变快了，Skill 调用的准确率也上来了。

5.4 第四步：优化 settings.json 配置

清理完 Skill 之后，顺便检查一下settings.json的配置。这个文件控制着 Claude Code 的各种行为，包括 Skill 的加载路径、权限设置等。一个典型的配置是这样的：

{ "skills": { "paths": [ "~/.claude/skills", ".claude/skills" ], "autoLoad": true }, "permissions": { "allowFileWrite": true, "allowTerminalCommand": true } }

重点检查paths里有没有多余的路径，以及autoLoad是否开启。如果你像我一样按项目配置 Skill，可以把全局路径里的项目相关 Skill 清理掉，只留通用的。

提示：修改settings.json之后需要重启 Claude Code 才能生效。建议修改前先备份一份，万一出问题可以快速回滚。

6. 写一个“能活下来”的 Skill：从描述到测试

6.1 描述怎么写才精准

如果你要自己写 Skill，描述部分是最关键的。我的经验是遵循“三要素”原则：

1. 什么时候用：明确触发场景，比如“当用户要求生成 API 文档时”
2. 支持什么：明确能力范围，比如“支持 OpenAPI 3.0 和 Swagger 2.0”
3. 怎么用：明确输入输出，比如“输入路由文件路径，输出 Markdown 格式文档”

把这三要素写进description字段，Claude 的匹配准确率会高很多。

6.2 正文指令的写法与避坑

正文部分是指令的具体内容。我踩过的坑包括：

• 指令太笼统：“读取文件并处理”——处理什么？怎么处理？
• 缺少错误处理：“如果文件不存在就报错”——报什么错？怎么报？
• 示例代码跑不通：写示例的时候一定要实际跑一遍

一个好的正文应该像一份操作手册：第一步做什么、第二步做什么、遇到什么情况怎么处理，全部写清楚。

6.3 测试 Skill 是否被正确调用

写完 Skill 之后，一定要测试。测试方法是：用不同的表达方式触发它，看看是不是每次都能被正确调用。

比如你写了一个“生成 commit message”的 Skill，测试的时候不要只说“帮我写 commit”，还要试试“提交代码”“生成提交信息”“写个 commit message”等各种说法。如果某些说法触发不了，说明描述里的触发词覆盖不够，需要补充。

我自己的测试清单通常包括：

• 直接说功能名称（“用 commit-writer”）
• 描述需求（“帮我写个提交信息”）
• 间接表达（“代码改完了，准备提交”）
• 混合其他任务（“先跑个测试，然后帮我提交”）

四种方式都能正确触发，才算通过测试。

7. 常见问题与排查技巧实录

7.1 Skill 不触发怎么办

这是最常见的问题。排查顺序如下：

1. 检查文件位置：SKILL.md是否在正确的目录下？全局是~/.claude/skills/<name>/SKILL.md，项目级是.claude/skills/<name>/SKILL.md
2. 检查文件格式：元信息部分的 YAML 格式是否正确？---分隔符有没有写对？
3. 检查描述质量：描述是否足够具体？触发词是否覆盖了你的表达方式？
4. 检查冲突：是否有其他 Skill 的描述跟它相似，导致匹配被抢走？

我遇到过一次，Skill 死活不触发，排查了半天发现是SKILL.md的 YAML 里description字段前面多了一个空格，导致解析失败。这种细节问题最容易忽略。

7.2 Skill 触发太频繁怎么办

反过来，有些 Skill 触发太频繁，不该用的时候也跳出来。解决办法是收窄描述。比如把“处理代码相关任务”改成“当用户明确要求重构指定函数时使用”，触发频率立刻降下来。

7.3 多个 Skill 冲突怎么处理

当两个 Skill 的描述高度相似时，Claude 可能会随机选一个，或者两个都不选。处理方法是合并：把两个 Skill 的功能整合到一个里面，用一个更全面的描述覆盖两个场景。

如果确实无法合并（比如两个 Skill 来自不同作者，功能有细微差别），那就删掉一个。留着的那个不一定是“更好”的，但一定是你更常用的。

7.4 如何判断一个 Skill 该不该删

我总结了一个简单的判断流程：

这个流程走一遍，基本就能做出决定了。

7.5 删错了怎么恢复

删之前先备份：

# 备份整个 skills 目录 cp -r ~/.claude/skills ~/.claude/skills-backup # 或者只备份要删的 mv ~/.claude/skills/<name> ~/.claude/skills-backup/

这样万一删错了，直接从备份目录移回来就行。我自己的习惯是先移到备份目录，观察一周，确认真的不需要了再彻底删除。

8. 一些关于 Skill 管理的个人体会

三个月从四十多个删到七个，最大的感受是：Skill 的价值不在于数量，而在于匹配精度。一个精准的 Skill，比十个模糊的 Skill 有用得多。

我现在每个月会花十分钟做一次“Skill 审查”：看看有没有新的需求需要装 Skill，看看现有的 Skill 有没有更新，看看有没有哪个 Skill 这个月一次都没用过。这个习惯让我的 Skill 列表始终保持在一个精简、高效的状态。

另外一点体会是：不要为了“以后可能用”而装 Skill。我删掉的那些里面，至少有一半是当初觉得“以后可能会用到”才装的，结果三个月一次都没碰过。真正需要的时候再装，完全来得及。

最后分享一个我最近在用的技巧：给 Skill 加版本号。在SKILL.md的元信息里加一个version字段，每次修改都递增。这样当 Claude Code 升级导致某些 Skill 失效时，你能快速定位到是哪个版本出的问题，回滚也方便。

--- name: commit-writer version: 1.3.0 description: ... ---

这个习惯看起来不起眼，但在排查问题的时候能省不少时间。尤其是当你同时维护多个项目、每个项目有不同 Skill 配置的时候，版本号能帮你快速理清哪个是哪个。