企业官网建设流程全解析

1. 从“装了一堆”到“删掉八成”：一个 Skill 管理思路的转变

去年秋天我开始认真用 Claude Code 做日常开发，那时候的心态跟很多人一样——看到社区里有人分享 Skill，就忍不住往~/.claude/skills目录里塞。三个月下来，我的 Skill 目录里躺着四十多个文件夹，从代码审查、提交信息生成、文档翻译，到“狗头军师”式的决策辅助、像素动画提示词生成，甚至还有一个专门用来给变量起名的。每次启动 Claude Code，它要扫描全部 Skill 的SKILL.md，加载元数据，再根据当前对话匹配。结果是启动变慢、匹配变飘、我自己的注意力也被分散了。

后来我做了一次彻底清理，删掉了大约 80% 的 Skill，只留下真正高频、真正能改变工作流的几个。这篇文章就把这次“断舍离”的完整思路拆开讲——Skill 到底是什么、为什么装多了反而坏事、怎么判断一个 Skill 该留还是该删、留下的那几个具体怎么配置、以及我在这个过程中踩过的坑。如果你刚开始接触 Claude Code，或者已经装了一堆 Skill 但感觉越用越乱，这篇应该能帮你省下不少试错时间。

先明确一下本文说的 Skill 是什么。在 Claude Code 的体系里，Skill 是一个带SKILL.md的目录，里面用 Markdown 描述这个能力的触发条件、执行步骤、可用工具和注意事项。Claude Code 在运行时读取这些描述，判断当前任务是否匹配某个 Skill，匹配上就按里面的指令去执行。它跟传统的插件不太一样——Skill 更像是一份“给模型看的操作手册”，而不是一段独立运行的代码。这个区别很关键，后面讲删除逻辑时会反复用到。

适合读这篇的人有三类：一是刚装好 Claude Code、正准备大规模收集 Skill 的新手；二是已经装了很多但发现效果不稳定的中级用户；三是想自己写 Skill、但不确定什么样的 Skill 才值得写的开发者。三类人的关注点不同，我会在对应章节里分别展开。

2. Skill 装多了到底会发生什么：四个真实副作用

2.1 启动扫描变慢，元数据加载成为隐性成本

Claude Code 启动时会扫描 Skill 目录，读取每个SKILL.md的头部元数据，包括名称、描述、触发关键词、依赖工具等。单个 Skill 的读取很快，几十毫秒级别，但四十多个叠加起来，再加上部分 Skill 的描述写得又长又模糊，扫描和索引的时间就会明显上升。我实测过，从二十个 Skill 增加到四十五个之后，冷启动到可交互状态的时间大概多了两到三秒。这个数字单看不大，但如果你一天要开关十几次 Claude Code，累积起来就是实打实的时间损耗。

更麻烦的是元数据加载不只是“读文件”这么简单。Claude Code 需要把这些描述组织成可供模型检索的结构，描述越长、越相似，索引构建的负担就越重。我有一段时间装了好几个功能重叠的代码审查 Skill，它们的描述里都包含“review”“check”“audit”这类词，结果索引里出现大量近义条目，模型在匹配时反而更容易犹豫。

2.2 匹配精度下降，模型开始“乱点技能”

这是最要命的问题。Skill 的触发依赖描述与当前任务的语义匹配。当你只有五六个 Skill 时，每个 Skill 的职责边界清晰，模型很容易判断该用哪个。但当目录里有四十多个 Skill，其中不少功能相近、描述措辞雷同，模型就会在多个候选之间摇摆，甚至触发一个完全不相关的 Skill。

我遇到过一次典型情况：我在让 Claude Code 帮我写一个数据库迁移脚本，结果它触发了一个叫“book to skill”的 Skill——那个 Skill 本意是把书籍内容整理成 Skill 格式，跟数据库迁移八竿子打不着。原因就是那个 Skill 的描述里写了“将结构化内容转换为可执行步骤”，而迁移脚本的请求里也出现了“步骤”“转换”这类词。这种误触发一旦发生，轻则浪费一轮对话，重则让模型按错误的指令去操作文件，造成实际损害。

2.3 上下文被稀释，真正重要的指令被淹没

每个被加载的 Skill 都会占用一部分上下文预算。Claude Code 的上下文窗口是有限的，Skill 描述、系统提示、对话历史、当前任务文件都要共享这个预算。当你装了四十多个 Skill，即使只有少数被激活，它们的元数据仍然可能以某种形式存在于上下文中，挤占本该留给实际代码和任务描述的空间。

我做过一个对比：在装满 Skill 的环境里让 Claude Code 重构一个三百行的 Python 模块，它给出的方案明显比清理后要粗糙，遗漏了好几个边界条件。清理到只剩八个 Skill 之后，同样的任务，它能把异常处理、类型标注、日志埋点都考虑进去。差别不在于模型本身，而在于可用上下文的质量。

2.4 维护成本被严重低估

这一点很少有人提，但实际影响很大。每个 Skill 都需要维护：Claude Code 版本更新后，部分 Skill 的指令可能失效；依赖的外部工具升级后，Skill 里的命令可能要改；团队协作时，别人拉取你的配置，还得理解每个 Skill 是干什么的。四十多个 Skill 的维护成本，远超大多数人的预期。

我有个 Skill 是用来调用本地模型做离线翻译的，依赖一个特定的命令行工具。那个工具升级后改了参数格式，Skill 里的命令全部报错。我过了两周才发现，因为平时很少用到它。这种“装了但不用、坏了也不知道”的 Skill，就是纯粹的负债。

3. 判断一个 Skill 该留还是该删：我的四象限法

3.1 第一象限：高频且高价值，必须留

这类 Skill 的特征是：每周至少用到三次，每次使用都能明显节省时间或提升质量，而且触发稳定、几乎不会误触发。我留下的 Skill 里，代码审查和提交信息生成属于这一类。代码审查 Skill 我几乎每次提交前都会跑一遍，它能按我预设的检查清单逐项过，比我自己肉眼扫要可靠。提交信息生成则是每次git commit前必用，省去了组织语言的时间。

判断标准很直接：如果删掉它，你会立刻感到不方便，那它就属于这一象限。注意“立刻”这个词——不是“以后可能会用到”，而是“明天就会用到”。

3.2 第二象限：低频但高价值，酌情留

有些 Skill 使用频率不高，比如一个月才用一两次，但每次用的时候价值极大，自己手动做要花很多时间。我保留了一个用于生成数据库迁移回滚脚本的 Skill，一个月可能就用一两次，但每次都能帮我省下半小时以上的查文档和试错时间。这类 Skill 值得留，但要控制数量，因为它们的维护成本依然存在。

我的做法是给这类 Skill 设一个“观察期”：如果连续三个月一次都没用到，就删掉。需要的时候再重新装，成本并不高。

3.3 第三象限：高频但低价值，果断删

这是最容易被忽视的一类。有些 Skill 你确实经常触发，但触发之后并没有带来实质帮助，甚至还不如自己直接写指令。我删掉的一个“变量命名建议”Skill 就属于这类——它确实经常被触发，但给出的名字往往还不如我自己想的，而且每次触发都要多一轮交互，反而拖慢了节奏。

判断这类 Skill 的方法是：记录它触发后你实际采纳其输出的比例。如果采纳率低于三成，那它就是在消耗你的时间，而不是节省。

3.4 第四象限：低频且低价值，第一时间删

这类 Skill 通常是“看到别人分享觉得有意思就装了”的产物。比如那个“狗头军师”Skill，本意是在做决策时提供多角度建议，但我实际用下来发现，它给出的建议往往泛泛而谈，不如直接问模型。还有“像素动画提示词生成”Skill，我根本不做像素动画，装它纯粹是因为当时觉得好玩。这类 Skill 没有任何保留理由，看到就删。

下面这张表是我清理时用的判断矩阵，可以直接参考：

4. 我最终留下的 Skill 清单与配置细节

4.1 留下的八个 Skill 及其职责边界

清理之后，我的~/.claude/skills目录里只剩八个文件夹。每个都有明确的职责边界，描述里写清楚了“什么时候用”和“什么时候不用”，避免误触发。这八个分别是：代码审查、提交信息生成、单元测试生成、文档字符串补全、依赖升级检查、迁移脚本生成、日志埋点建议、以及一个用于读取项目规范的 Skill。

这里重点说三个最常用的。代码审查 Skill 的SKILL.md里，我明确写了触发条件：“当用户要求审查代码、检查提交、或提到 review/audit 时触发”，同时写了排除条件：“不用于生成新代码，不用于重构”。提交信息生成 Skill 则限定在git commit相关场景，并且规定了输出格式必须遵循约定式提交。单元测试生成 Skill 里写明了优先使用项目已有的测试框架，不擅自引入新依赖。

4.2 SKILL.md 的写法要点：描述要窄，指令要具体

我踩过最大的坑就是SKILL.md描述写得太宽。早期我写的代码审查 Skill 描述是“帮助审查代码质量”，结果它经常在我不需要的时候被触发。后来改成“当用户明确要求审查代码或检查提交时触发，不主动触发”，误触发率立刻降下来了。

指令部分要具体到可执行。比如提交信息生成 Skill 里，我写了完整的步骤：先运行git diff --cached获取暂存区变更，再按变更类型归类，然后按约定式提交格式生成信息，最后询问用户是否确认。每一步都写清楚用什么命令、判断依据是什么。这样模型执行时不会自由发挥。

4.3 settings.json 里的关键配置

Claude Code 的settings.json里可以配置 Skill 的加载行为。我做了两处调整：一是关闭了自动加载全部 Skill 的选项，改为按需加载；二是设置了 Skill 描述的最大长度，防止某个 Skill 的描述过长挤占上下文。具体配置项名称各版本可能不同，建议对照官方文档确认。我自己的做法是先在测试环境验证配置生效，再同步到日常环境。

提示：修改settings.json前先备份，Claude Code 对配置格式比较敏感，一个多余的逗号就可能导致启动失败。

4.4 用 npx skills 管理 Skill 的实操

社区里有个npx skills工具，可以用来列出、安装、删除 Skill。我主要用它做批量清理。基本用法是npx skills list查看当前所有 Skill，npx skills remove <name>删除指定 Skill。批量删除时可以先导出列表，确认哪些要删，再逐个执行。注意这个工具操作的是 Skill 目录，删除前务必确认没有正在使用的 Skill 被误删。

我清理时的流程是：先npx skills list导出全部 Skill 名称，对照四象限法逐个标记，然后分批删除，每删一批就重启 Claude Code 验证启动速度和匹配是否正常。这样即使删错了，也能及时发现并恢复。

5. 清理之后：启动速度、匹配精度与心态的变化

5.1 可量化的改善

清理前，我的 Claude Code 冷启动到可交互大约需要五到六秒；清理后降到两秒左右。匹配精度方面，我做了个简单统计：清理前一周内发生了七次误触发，清理后一周内零次误触发。上下文质量的变化更明显，同样的重构任务，清理后模型给出的方案在边界条件处理上完整了很多。

这些改善不是线性的，而是有一个临界点。我的体验是，当 Skill 数量降到十个以内时，改善最明显；从十个降到八个，边际收益就不大了。所以不必追求“越少越好”，找到适合自己的数量就行。

5.2 心态上的变化：从收集到克制

比技术指标更重要的是心态。以前我看到新 Skill 就想装，现在我会有意识地先问自己：这个 Skill 解决的是我真实存在的问题吗？我每周会用几次？它的描述是否足够窄以避免误触发？如果三个问题里有两个答不上来，我就不装。

这种克制带来的好处是，我对留下的每个 Skill 都了如指掌，知道它们什么时候触发、执行什么、输出什么格式。这种掌控感是装四十个 Skill 时完全没有的。

5.3 一个反直觉的发现

删掉大量 Skill 之后，我发现自己写指令的能力反而提升了。以前遇到问题第一反应是“有没有对应的 Skill”，现在会先想“我该怎么把需求描述清楚”。很多时候，一段清晰的指令比一个 Skill 更有效，因为指令是针对当前任务的，而 Skill 是通用的。Skill 的价值在于把重复性的、有固定流程的任务固化下来，而不是替代思考。

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

6.1 Skill 不触发怎么办

先检查SKILL.md的触发描述是否足够明确。如果描述里全是“帮助”“辅助”这类模糊词，模型很难判断何时该用。改成具体的场景描述，比如“当用户要求生成提交信息时触发”。其次检查 Skill 目录位置是否正确，Claude Code 默认读取~/.claude/skills，放在别处不会被加载。最后确认settings.json里没有禁用该 Skill。

6.2 Skill 误触发怎么排查

误触发通常是因为描述太宽或与其他 Skill 重叠。排查方法是查看 Claude Code 的日志，确认是哪个 Skill 被触发、触发时匹配了哪些关键词。然后针对性收窄描述，或者直接删掉重叠的 Skill。我处理误触发的原则是：如果一个 Skill 一周内误触发超过两次，就考虑删掉重写，而不是反复微调。

6.3 删除 Skill 后配置报错

有时候删掉 Skill 目录后，settings.json里还留着对应的引用，导致启动报错。解决方法是同步清理配置文件里的相关条目。我现在的习惯是删除 Skill 后立刻检查配置文件，确保没有悬空引用。

6.4 常见问题速查表

6.5 我踩过的一个大坑

有一次我为了图省事，直接批量删除了十几个 Skill 目录，没有先备份。结果发现其中一个 Skill 里存着我自定义的代码审查检查清单，那个清单是我花了不少时间整理的。删掉之后只能凭记忆重建，漏了好几条。从那以后，我删除任何 Skill 之前都会先看一眼它的SKILL.md里有没有值得保留的内容，有的话先复制出来。

7. 给不同阶段使用者的具体建议

7.1 刚入门：先别急着装

如果你刚装好 Claude Code，我的建议是先用两周原生功能，不装任何 Skill。这两周里记录下哪些任务你反复做、每次都要重复描述。两周后，针对这些重复任务，最多装三个 Skill。这样装进来的每个 Skill 都是真正需要的，而不是“看起来有用”的。

7.2 已装很多：做一次彻底盘点

如果你已经装了一堆，找个周末做一次盘点。用npx skills list导出全部，对照四象限法逐个判断。判断时问自己三个问题：过去一个月用过几次？用的时候采纳了它的输出吗？删掉它我会不会立刻不方便？三个问题答完，该删的自然就清楚了。

7.3 想自己写：从窄场景开始

自己写 Skill 时，不要一上来就写通用的。先写一个只解决某个具体问题的窄 Skill，比如“生成符合项目规范的提交信息”。跑通之后再考虑扩展。窄 Skill 的好处是触发精准、维护简单、不容易误触发。我写的第一个 Skill 就是提交信息生成，到现在还在用，几乎没改过。

7.4 团队协作：统一 Skill 清单

如果是团队一起用 Claude Code，建议维护一份共享的 Skill 清单，写清楚每个 Skill 的用途、触发条件、维护人。新成员加入时直接按清单配置，避免各自收集导致环境不一致。我们团队现在就是这份清单制，新人上手时间从半天缩短到半小时。

8. 关于 Skill 数量与效率的几点个人体会

我现在的 Skill 目录稳定在八个，偶尔会临时装一个试用，但试用期不超过一周，不合适就删。这个数量对我来说是平衡点：足够覆盖高频重复任务，又不会拖慢启动或干扰匹配。

有个体会值得单独说：Skill 的价值不在于数量，而在于每个 Skill 是否真正嵌入了你的工作流。一个嵌入工作流的 Skill，你会条件反射地用它；一个没嵌入的 Skill，装再多也只是躺在目录里。判断标准很简单——如果你需要刻意提醒自己“我还有个 Skill 可以用”，那它就没真正嵌入。

最后分享一个我最近在用的技巧：给每个保留的 Skill 在SKILL.md开头加一行注释，写明“最后使用日期”和“本月使用次数”。每次用的时候顺手更新。这样过一段时间回头看，哪些 Skill 在吃灰一目了然，清理时不用再凭记忆判断。这个习惯帮我省去了很多纠结的时间。