企业官网建设流程全解析

1. 从"装Skill上瘾"到"删到只剩骨架"：一个真实的心路历程

三个月前，我的 Claude Code 配置目录里躺着四十多个 Skill。每次看到社区里有人分享新的 SKILL.md，我就忍不住 clone 下来塞进~/.claude/skills/。那段时间我的状态可以用四个字概括——收藏即学会。直到某天我让 Claude Code 帮我改一个正则表达式，它居然先调用了一个"代码风格检查 Skill"，又触发了一个"文档生成 Skill"，最后还试图用一个"Git 提交规范 Skill"来给我写 commit message。一个本该三十秒解决的问题，硬是绕了两分钟。

那一刻我意识到：Skill 不是越多越好，而是越精准越好。于是我花了整整一个周末，把四十多个 Skill 逐一审查、测试、归类，最终只保留了 8 个。删掉的 80% 里，有的是功能重复，有的是触发条件过于宽泛导致误触发，有的纯粹是我当时"觉得有用"但三个月一次都没真正用上。

这篇文章就是那次大清理的完整复盘。我会讲清楚：Skill 的触发机制到底是怎么回事、为什么装多了反而会互相干扰、怎么判断一个 Skill 该留还是该删、保留下来的那 8 个分别解决了什么问题，以及settings.json和SKILL.md里那些容易被忽略但极其关键的配置细节。如果你也在用 Claude Code 并且 Skill 目录已经开始膨胀，这篇内容应该能帮你省下不少试错时间。

2. Skill 的触发机制：为什么装多了会互相打架

2.1 SKILL.md 的 description 字段才是真正的"开关"

很多人以为 Skill 是靠名字来匹配的，其实不是。Claude Code 在决定是否调用某个 Skill 时，主要依据的是SKILL.md文件头部 YAML frontmatter 里的description字段。这个字段的写法直接决定了 Skill 的触发范围。

我举个真实的例子。之前我装了一个叫code-review的 Skill，它的 description 写的是"帮助审查代码质量"。看起来没问题对吧？但实际使用中，只要我让 Claude Code 看任何一段代码，它都会触发这个 Skill。因为"看代码"和"审查代码"在语义上太接近了，模型无法区分我只是想让它读一下代码还是要做质量审查。

后来我把 description 改成了"当用户明确要求进行代码审查、检查代码规范、或寻找潜在 bug 时使用"，触发频率立刻降到了合理水平。description 的写法本质上是在给模型划边界——你划得越模糊，误触发就越多。

2.2 多个 Skill 同时命中时的优先级混乱

当你装了多个 Skill，且它们的 description 存在语义重叠时，Claude Code 并不会智能地"选一个最合适的"，而是可能同时加载多个 Skill 的上下文。这就导致了一个严重问题：上下文窗口被大量 Skill 指令占据，真正用于处理你任务的 token 反而变少了。

我实测过一组数据。在装 40 个 Skill 的情况下，一次简单的"帮我写个 Python 脚本读取 CSV"请求，Claude Code 加载了 3 个 Skill 的完整内容，消耗了大约 4000 个 token 在 Skill 指令上。删到 8 个之后，同样的请求只加载了 0 到 1 个 Skill，token 消耗降到 500 以内。这意味着留给实际任务的上下文空间多了 3500 token，对于复杂任务来说，这个差距非常明显。

2.3 那些"看起来有用"但实际从不触发的 Skill

删掉的 32 个 Skill 里，有将近一半属于"装了但从没被触发过"的类型。比如我装过一个"生成 API 文档"的 Skill，但我平时写文档都是用专门的文档工具，根本不会在 Claude Code 里做这件事。还有一个"数据库迁移脚本生成"的 Skill，我三个月里只做过一次数据库迁移，而且那次用的还是手写 SQL。

这类 Skill 的问题在于：它们占据了我的认知带宽，却没有产生实际价值。每次打开 Skill 目录看到它们，我都会想"这个以后可能会用到"，但"以后"从来没有来过。判断标准很简单：如果一个 Skill 在过去一个月里没有被触发过，且你也想不出下周会在什么场景下用到它，那它就该被删掉。

3. 我保留的 8 个 Skill 及各自的不可替代性

3.1 代码格式化与 lint 修复 Skill

这是使用频率最高的一个。它的 description 我写得很窄："当用户要求格式化代码、修复 lint 错误、或统一代码风格时使用"。触发场景非常明确，不会误触发。

这个 Skill 的核心价值在于它内置了我团队的代码规范——缩进用 2 空格还是 4 空格、import 排序规则、命名约定等。每次触发时，Claude Code 会按照这些规则直接修改代码，而不是给我建议让我自己改。省掉的是"它说一句我改一句"的来回确认时间。

3.2 Git 提交信息生成 Skill

这个 Skill 我犹豫了很久要不要留。最终留下的原因是：它解决了一个我每天都要做但每次都要想一下的问题——写 commit message。

它的 description 是"当用户要求生成 git commit message 或准备提交代码时使用"。触发后，它会读取 staged 的 diff，按照 Conventional Commits 规范生成提交信息。关键细节是：我在 SKILL.md 里明确写了"不要生成 body 部分，只生成一行 subject"，因为我的团队不需要详细的 commit body。这种个性化配置是通用工具做不到的。

3.3 终端命令安全审查 Skill

这个 Skill 的触发条件我设置得比较特殊——它不是靠 description 匹配的，而是在settings.json里配置了 hook，当 Claude Code 准备执行某些危险命令（如rm -rf、git push --force、DROP TABLE）时强制触发。

它的作用是：在命令真正执行前，弹出确认提示并解释这条命令的影响范围。我承认这有点"过度谨慎"，但自从有一次它拦住了一条我手滑写错的rm命令之后，我就决定永久保留它。

3.4 项目上下文加载 Skill

这个 Skill 比较特殊，它不执行任何具体操作，而是在我打开一个新项目时，自动读取项目根目录下的CLAUDE.md、README.md和package.json（或pyproject.toml），把关键信息注入到对话上下文中。

它的价值在于省掉了我每次都要手动告诉 Claude Code"这个项目用什么框架、用什么包管理器、测试怎么跑"的时间。description 写的是"当用户打开新项目或切换工作目录时使用"，触发时机很明确。

3.5 测试用例生成 Skill

这个 Skill 我设置了一个硬性约束：只在用户明确说"写测试"或"生成测试用例"时触发。它内置了我常用的测试框架模板（pytest、jest、vitest），并且会根据被测代码的导入关系自动推断需要 mock 的依赖。

删掉的其他测试相关 Skill 有 3 个，它们的功能分别是"测试覆盖率分析""测试重构建议""测试数据生成"。删掉的原因很简单：这三个功能我三个月里一次都没用过，而"生成测试用例"每周至少用两次。

3.6 文档字符串生成 Skill

这个 Skill 专门用来给函数和类生成 docstring。它的 description 写得很具体："当用户要求为函数或类添加文档字符串、或要求生成 API 文档注释时使用"。

我保留它的原因是：写 docstring 是一件"我知道该写但懒得写"的事情。有了这个 Skill，我只需要选中代码说一句"加 docstring"，它就会按照 Google Style 生成完整的参数说明、返回值说明和异常说明。它解决的不是技术问题，而是心理阻力问题。

3.7 依赖版本检查 Skill

这个 Skill 会读取项目中的依赖文件，检查是否有已知的安全漏洞或版本冲突。触发条件是"当用户要求检查依赖版本、更新依赖、或排查依赖冲突时使用"。

我保留它是因为它帮我避免了一次生产事故——它在一次例行检查中发现某个间接依赖的版本存在已知问题，而这个问题在我手动检查时被忽略了。这种"定期体检"类的 Skill，价值不在于频繁使用，而在于关键时刻能兜底。

3.8 自定义代码片段插入 Skill

这是我自己写的一个 Skill，功能非常简单：当我输入特定的触发词（如@snippet:react-component）时，它会把预定义的代码模板插入到当前文件中。模板包括 React 函数组件、Python 类定义、FastAPI 路由等。

它的不可替代性在于完全个性化——这些模板是我根据自己项目的实际结构定制的，任何通用工具都无法替代。description 写的是"当用户输入 @snippet: 开头的指令时使用"，触发条件精确到不可能误触发。

4. 删掉的那 32 个 Skill 都长什么样

4.1 功能重复型：同一件事有三个 Skill 在做

删掉的 Skill 里，有 6 个属于功能重复。比如"代码审查"这个功能，我同时装了code-review、code-quality-check和lint-review三个 Skill。它们的 description 都涉及"检查代码质量"，导致每次我让 Claude Code 看代码时，三个 Skill 都有可能被触发，互相干扰。

类似的还有"文档生成"——我装了doc-generator、api-doc-writer和readme-builder三个。实际上我只需要一个能生成 docstring 的 Skill 就够了，README 我都是手写的。

判断标准：如果你能用一句话描述两个 Skill 的共同功能，那它们就是重复的，留一个就够了。

4.2 触发条件过宽型：什么都能触发，等于什么都触发不了

有一个 Skill 叫general-helper，description 写的是"帮助解决各种编程问题"。这个 Skill 几乎在我每次对话时都会被触发，因为它太"万能"了。但它的内容其实只是一些通用的编程建议，没有任何特异性。

还有一个叫smart-assistant的 Skill，description 是"智能辅助编程"。我到现在都不确定它到底做了什么，因为它的指令内容非常泛化，基本上就是"你要仔细思考、认真回答"之类的废话。这类 Skill 的唯一作用就是浪费上下文窗口。

4.3 场景过于垂直型：三个月用不上一次

我删掉了一个"SolidWorks 插件开发"的 Skill，因为我在装它的那一周确实在做一个 SolidWorks 相关的项目，但项目结束后就再也没碰过。类似的还有"像素动画生成""打斗动作提示词生成""AI 备课"等 Skill——它们都是我在特定场景下装的，场景过去后就成了死重。

这里有一个反直觉的结论：垂直 Skill 的价值密度很高，但适用频率极低。如果你不是每天都在做同一件垂直的事情，那这类 Skill 更适合"用的时候再装"，而不是"先装着备用"。

4.4 质量存疑型：从社区 clone 下来但从未验证

删掉的 Skill 里有 8 个是从社区 clone 下来的，我承认当时只是看了 README 觉得"不错"就装了，从来没有认真读过它们的 SKILL.md 内容。后来清理时打开一看，有的 SKILL.md 只有三行字，有的指令写得含糊不清，还有一个居然引用了不存在的文件路径。

从社区获取 Skill 时，一定要先读一遍 SKILL.md 的完整内容再决定是否保留。一个写得好的 Skill，它的指令应该是具体、可执行、有明确边界的。如果 SKILL.md 里全是"你要认真思考""你要仔细分析"这类空话，那这个 Skill 基本没有价值。

5. 清理 Skill 的具体操作流程

5.1 先做一次"触发日志"审计

Claude Code 本身不提供 Skill 触发日志，但你可以通过settings.json里的 hook 机制来记录。我的做法是在settings.json中添加一个PreToolUsehook，当 Skill 被触发时，把 Skill 名称和时间戳追加写入一个日志文件。

配置大概长这样：

{ "hooks": { "PreToolUse": [ { "matcher": "Skill", "command": "echo \"$(date +%Y-%m-%dT%H:%M:%S) $CLAUDE_TOOL_INPUT\" >> ~/.claude/skill-trigger.log" } ] } }

跑一周之后，打开skill-trigger.log看一眼，哪些 Skill 从没出现过、哪些 Skill 每天触发十几次，一目了然。数据比感觉可靠得多——我原本以为"文档生成" Skill 我经常用，结果日志显示它一周只触发了两次。

5.2 按"最近触发时间"排序，从最久未触发的开始删

拿到日志后，把所有 Skill 按最后触发时间排序。我的删除策略是：

• 超过 30 天未触发：直接删，不要犹豫
• 7 到 30 天未触发：标记为"观察期"，如果接下来两周还没触发就删
• 7 天内触发过：保留，但检查是否有功能重复

这个策略帮我快速砍掉了 20 多个 Skill。剩下十几个进入"观察期"的，两周后又删掉了一半。

5.3 合并功能重叠的 Skill

对于功能重叠的 Skill，不要简单地"留一个删一个"，而是考虑合并。比如我之前有三个和"代码质量"相关的 Skill，我把它们的有用部分提取出来，合并成了一个code-qualitySkill，description 写清楚它覆盖的具体场景（格式化、lint 修复、命名规范检查），这样既保留了功能，又避免了重复触发。

合并后的 SKILL.md 结构大概是：

--- name: code-quality description: 当用户要求格式化代码、修复 lint 错误、检查命名规范、或统一代码风格时使用 --- ## 格式化规则 - 缩进：2 空格 - 行宽：100 字符 ... ## Lint 修复流程 1. 先运行项目配置的 linter 2. 根据输出逐条修复 ... ## 命名规范 - 变量：camelCase - 常量：UPPER_SNAKE_CASE ...

5.4 删完之后重新审视 settings.json

Skill 删完后，记得检查settings.json里是否还有引用已删除 Skill 的配置。特别是有 hook 配置的情况下，如果 hook 指向了一个不存在的 Skill，可能会导致 Claude Code 报错或行为异常。

我的settings.json在清理后精简了很多，主要保留了这几块：

{ "skills": { "directory": "~/.claude/skills", "autoLoad": true }, "hooks": { "PreToolUse": [ { "matcher": "Bash", "command": "~/.claude/hooks/command-safety-check.sh" } ] } }

注意：不同版本的 Claude Code 对settings.json的字段支持可能不同，建议先查阅官方文档确认当前版本支持的配置项，不要直接照搬网上的配置。

6. 三个月使用下来总结的 Skill 管理原则

6.1 一个 Skill 只做一件事，description 要窄到不可能误触发

这是最重要的一条原则。好的 Skill 应该像一把手术刀，而不是瑞士军刀。description 的写法要具体到"当用户说 X 的时候使用"，而不是"当用户需要 X 相关帮助时使用"。

我现在的做法是：写完 description 后，自己读一遍，然后问自己"如果用户只是随便聊到相关话题，这个 Skill 会不会被触发？"如果答案是"可能会"，那就继续收窄。

6.2 新 Skill 先"试用期"，两周内没触发就删

我现在装新 Skill 的流程是：先装，然后在日历上设一个两周后的提醒。两周后如果这个 Skill 一次都没触发过，直接删，不给自己"以后可能用到"的借口。

这个习惯帮我避免了很多"收藏即学会"的无效积累。Skill 的价值在于被使用，而不是被拥有。

6.3 定期审计，建议每月一次

Skill 目录需要像衣柜一样定期整理。我现在的习惯是每个月最后一个周五，花半小时做一次 Skill 审计：看触发日志、检查功能重复、删除未使用的。这个投入产出比非常高——半小时的整理能换来接下来一个月更流畅的使用体验。

6.4 不要从社区盲目 clone，先读 SKILL.md 再决定

社区里的 Skill 质量参差不齐。我现在 clone 任何 Skill 之前，都会先在浏览器里打开它的 SKILL.md 看一遍。重点看三个东西：description 写得是否具体、指令内容是否可执行、有没有引用不存在的文件或工具。如果 SKILL.md 读起来像鸡汤，那这个 Skill 大概率没有实际价值。

7. 关于 Skill 编码和插件生态的一些观察

最近社区里出现了很多关于 Skill 编码、Skill 插件的讨论，比如"skill 编码 247""skill 编码 193"这类说法。我理解这指的是某些 Skill 在特定编码体系下的分类编号，但说实话，编号本身并不重要，重要的是这个 Skill 解决的具体问题是否匹配你的实际需求。

我也看到有人在讨论"去 AI 味的 Skill""狗头军师 Skill""workbuddy Skill"这类偏趣味性的 Skill。这些 Skill 不是没有价值——它们能让 Claude Code 的输出更符合个人风格，或者增加一些交互趣味性。但我的建议是：先把功能性 Skill 管理好，再考虑这类风格化 Skill。否则你的 Skill 目录会变成一个"什么都有一点，但什么都不精"的大杂烩。

另外关于npx skills这个命令，它确实提供了一种快速安装 Skill 的方式，但我的经验是：安装越方便，越容易装多。我现在已经不用npx skills批量安装了，而是手动把需要的 Skill 复制到~/.claude/skills/目录下，这样每装一个都会经过一次"我真的需要它吗"的思考。

8. 我个人的一些实操体会

删掉 80% 的 Skill 之后，最直观的变化是 Claude Code 的响应变快了，而且它"跑偏"的概率明显降低。以前它经常在我没要求的情况下触发某个 Skill，然后按照 Skill 的指令做一堆我不需要的事情。现在这种情况基本消失了。

另一个体会是：Skill 的质量远比数量重要。我保留的 8 个 Skill 里，有 3 个是我自己根据实际需求写的，它们的价值远高于从社区 clone 下来的那些。如果你发现现有的 Skill 都不能很好地满足你的需求，不妨自己写一个——SKILL.md 的格式并不复杂，核心就是把"什么时候触发"和"触发后做什么"这两件事写清楚。

最后分享一个小技巧：我会在~/.claude/skills/目录下建一个_archive子目录，把暂时删掉但可能以后会用到的 Skill 移进去。这样既清理了活跃目录，又不会真的丢失。三个月下来，_archive里的 Skill 我一个都没有再移回来过——这反过来验证了当初删掉它们的决定是正确的。