企业官网建设流程全解析

如果你也玩 Claude Code，大概率见过这种状态：看到一个 Skill 觉得“这不就是我需要的吗”，装；群里有人发了个新 Skill 链接，装；官方文档提了一句最佳实践，装。三个月前我差不多把社区里热门的 Skill 都塞进了自己的环境，前前后后加起来有三十多个。三个月过去，我删掉了其中 80%，留下的不到十个。这篇文章不是劝你别装 Skill，而是把我从“装到停不下来”到“删到只剩骨干”的完整过程、判断标准、删除顺序和踩过的坑都复盘一遍，给同样在跟这堆插件缠斗的人做个参考。

先说清楚两个概念。Claude Code 是跑在终端里的 AI 编程助手，你可以在命令行里让它读代码、改文件、跑测试、解释日志。Skill 是给它追加的“能力包”，一个 Skill 通常由说明文档、脚本和约定组成，在对应任务出现时被自动或手动调用。Skill 本身不神秘，装多了以后真正的问题也不是磁盘空间，而是注意力、上下文和协作方式的失控。

1. 三个月前我为什么装了一堆 Skill

1.1 从第一条 Skill 开始：效率焦虑与尝鲜心理

我装的第一条 Skill 是终端命令解释器。当时的需求很朴素：我经常忘记一些非常规命令的感受，干脆让 Claude 根据我的意图给出一串命令并解释每个参数。这个 Skill 确实好用，但也是从这里开始，我走上了一条“看见 Skill 就想装”的路。

复盘那个阶段的心理，我总结出三个驱动力。

第一是效率焦虑。总觉得自己手动做某些重复操作太慢，看到别人说“这个 Skill 能一口气完成代码审查、生成 PR 描述、补测试”，就会立刻觉得不装就落后了。第二是社区热度带来的从众感。热门仓库、高赞帖子、朋友圈里的截图，都会让人产生“大家都在用，我也得试试”的错觉。第三是安装太容易。大部分 Skill 就是一个文件夹，克隆、放目录、改个配置就能用，零门槛导致决策成本极低，装错了也不心疼。

现在回头看，效率焦虑是真的，但热度和从众感完全是噪音。工具的价值应该由使用频率和产出质量决定，而不是由下载量决定。这个道理写出来很浅白，实际操作中我就是花了三个月才真正接受。

1.2 我都装了哪些类型的 Skill

当时我的 skills 目录里大致是这么几类，每一类都对应我某个阶段自以为刚需的场景：

• 命令类：终端命令解释、Bash 脚本生成、Git 提交信息生成、Git 历史分析。
• 代码类：代码审查、单元测试补全、正则表达式生成、重构建议、依赖升级检查。
• 文档类：README 生成、PR 描述模板、Changelog 生成、日报/周报起草。
• 调试类：日志分析、错误栈解读、性能排查、数据库查询优化。
• 工作流类：前端组件搭建、API 接口调试、Docker 命令整理。
• 还有一批“尝鲜型”：小说生成、打斗动作提示词、备课文案、职场沟通话术等。

数一下就能发现，光代码审查类的我就装了三个不同来源的版本，日志分析类的也装了两个。同一类能力重复安装，本身就是一种资源浪费，更不用说这些 Skill 之间还存在潜在的指令冲突。到了清理阶段，这一批重复和近似项是最先被淘汰的。

2. 时间一长，这堆 Skill 的真实账单出来了

2.1 用得最多的 20%：高频场景画像

三个月后我做了个简单的使用统计，就是把 Claude Code 的会话记录和调用日志翻出来，看每个 Skill 实际被触发或手动调用的次数。结果非常符合二八定律：真正被反复使用、并且每次都能稳定产出好结果的 Skill，不超过总数的 20%。

我用得最多的是这几类场景：终端里的难命令解释、Git 提交信息的整理、日志错误快速定位、小范围代码重构建议。这四个场景有一个共同点——它们都是“短平快”的任务，一个 Skill 能在十几秒内给出可执行的答案，而且答案质量可以立刻判断。

反过来看那些低频 Skill，不是质量差，而是触发场景太窄。比如某个“API 接口调试”的 Skill，它要求你按固定格式把请求参数填进去，然后它帮你拼接 curl 命令。但实际开发中，我更多是直接在终端里问一句“帮我用 Python 调这个接口，超时设置 10 秒”，效果也差不多。窄场景 Skill 很容易被自然语言对话替代，这是它们被淘汰的第一个信号。

2.2 被悄悄淘汰的 80% 去哪了

删除不等于这些 Skill 毫无价值。我把它们分成四种情况：

• 一次性尝鲜型：装的时候觉得新鲜，用了一两次就再也没碰过，比如打斗动作提示词、小说生成。
• 自然语言可替代型：与其调用 Skill 的固定模板，不如直接描述需求，AI 给出的结果反而更贴合上下文。
• 质量不稳定型：同一个 Skill 有时候效果好，有时候逻辑混乱，无法建立信任，后来宁可手动处理也不愿意调它。
• 重复冗余型：多个人都写了功能相似的 Skill，最后只留一个维护最好的。

这四类加起来占了绝大多数。真正让我下决心删的，不是它们“不好用”，而是我发现它们会持续产生隐性成本。每一个 Skill 都可能在对话开始时被加载进上下文或者被 Agent 自动扫描，装得越多，模型每次思考时要考虑的“多余分支”就越多。表现就是响应变慢、跑题变多、偶尔还出现两个 Skill 同时对同一个需求给出相反建议的情况。

2.3 删除背后的三大核心原因

长期使用下来，我认为囤 Skill 最大的问题有三个，按破坏力排序：

第一是上下文膨胀。Claude Code 每次会话都带着一堆 Skill 说明，哪怕这些说明只有几 KB，几十个加起来也会挤占模型的注意力。更麻烦的是，很多 Skill 为了让 AI“听懂”，会写很长的触发规则和示例，这些内容在不需要它出场的会话中也占着位置。

第二是指令冲突。不同 Skill 可能对相似场景给出不同处理方式，比如 A 要求 AI 在回答前先列要点，B 要求直接给最终结果。两个 Skill 同时在场时，AI 的行为会变得随机，原本的稳定工作流被打破。

第三是维护成本。Claude Code 版本更新后，一些 Skill 的写法就不兼容了，你得挨个检查要不要改。我三个月里光是在升级后维护这堆模板就花了不少时间，那段时间真的完全抵消了它们带来的效率提升。

这三点加在一起，让“装得多”变成了一种负资产。真正经历过这种失控感的人，应该能明白那句“我删掉了 80%”背后不是嫌弃，而是止损。

3. 我是怎么筛选和判断一个 Skill 值不值得留下

3.1 三条硬指标：可复用、可组合、可解释

开始清理之前，我先给自己定了三条硬指标。一个 Skill 必须同时满足，才能进入“保留观察区”。

可复用，指的是这个 Skill 对应的任务场景至少要在一周内自然出现一次以上。不是“我偶尔会遇到”，而是“我稳定会遇到”。以写周报为例，如果团队的周报频率是每周一次，那这个 Skill 天然满足高频条件；而“写小说”这个场景，对我的日常工作来说根本不成立，直接删。

可组合，指的是这个 Skill 能否跟我已有的工作流搭在一起，而不是孤立存在。我的终端命令解释 Skill 就经常跟 Git 分析、Docker 排错组合使用；而某个“生成表情包文案”的 Skill 跟整个开发流程毫无关系，属于完全孤立的能力，再怎么有趣也留不住。

可解释，指的是我得清楚这个 Skill 内部做了什么。凡是我打开 SKILL.md 看了半天也看不懂它在干什么、为什么这么写的，一律不加信任。我不要求每个人都去读源码，但至少要知道这个 Skill 会给 AI 注入什么规则、会调用什么外部命令。黑盒 Skill 出了问题你连排查方向都没有，这种工具留着是隐患。

3.2 Skill 的“唯一职责”原则与现实冲突

刚开始囤 Skill 的时候，我特别喜欢那种“一个 Skill 干五件事”的设计，觉得这才是高性价比。后来发现这种设计几乎都有问题。一个 Skill 涉及的命令越多、场景跨度越大，它的提示词就越复杂，AI 在实际使用时就越容易混乱。反而是那种只负责一件小事的 Skill，触发准确、输出稳定。

最典型的是我装过的一个“前端开发全能” Skill，号称能处理组件生成、样式调整、代码检查、构建打包。理想很丰满，现实是它每次触发都会加载一大段前置规则，实际生成的组件代码却很平庸。后来我删掉它，换成一个只负责“按项目现有组件的代码风格生成新组件”的轻量 Skill，效果立刻提升。这个对比让我确定了一件事：Skill 应该像代码里的函数，一个函数最好只做一件事，职责越单一越好维护。

当然，唯一职责也不意味着越短越好。如果某个 Skill 的说明文件只有几十行，但里面全是含糊的“根据情况灵活处理”，那它在实际场景里大概率也会失控。好的 Skill 是在“职责清晰”和“指令明确”之间找到平衡点——告诉 AI 什么时候用、怎么输入、输出什么格式，但不越权去管其他事情。

3.3 成本核算：每一次调用到底花了多少

判断 Skill 值不值得留，一定要算成本账。成本不完全等于 token 数量，还包括“多轮交互成本”。

举个例子，我原来装了一个“自动补测试”的 Skill。它的流程是：先生成测试计划，再让我确认，再逐文件补全，整个过程要来回四五轮。看起来功能很强，但每次用下来消耗的 token 是直接对话方式的三倍，而且遇到复杂项目还得反复纠正它的计划。后来我删掉它，改成直接描述需求，让 Claude 自己决定怎么补测试，反而更快。原因很简单：那个 Skill 把“交互流程”写得太死，限制了 AI 的灵活性。

我建议在清理时都过一遍这个成本账：如果一个 Skill 在你每次使用时，平均要多花 2 轮以上的对话才能完成任务，那它必须带来足够强的质量提升才值得保留。如果它只是为了让 AI 按照一个死板的模板走流程，那大概率是负优化。

4. 我的最终清理方案与落地步骤

4.1 清理前的快照与用量统计方法

我先推大家做一个动作：清理前一定要备份。我当时的做法是先把整个 skills 目录压成一个压缩包，再导出当前的 Claude Code 配置，然后才动手。这不是怂，是给你自己留后路。人的记忆会骗人，三个月前某个 Skill 可能确实帮过大忙，但你已经不记得了，删完第二天又开始懊恼的情况并不少见。

备份之后，我用一个笨办法统计真实用量：翻历史会话，把每个 Skill 名字对应的调用次数记下来。Claude Code 的日志文件里能找到每次调用的记录，虽然不能做到精准统计，但足以区分出“高频使用”“低频使用”“从未使用”三档。对于从未使用的，不用犹豫，第一批就删；对于低频使用的，再结合下面这条路判断。

4.2 先禁用，再删除：一套安全的减法操作法

我的建议是不要一次性把 80% 都删掉，而是分三步。

第一步，把明确无用的先移出目录。什么叫明确无用？三个月调用次数为零的、重复功能的低配版、跟当前项目完全无关的，直接移到一个skills_archive文件夹里，相当于是软删除。

第二步，进入两周的“禁用观察期”。这时候你的环境里已经没有那些大概率不需要的 Skill 了，正常干活两周。过程中如果发现哪个任务明显变难了、或者频繁想起某个被移走的 Skill，就把它放回来；如果没有这种感觉，它基本可以确认不是刚需。

第三步，观察期结束后，把skills_archive里剩余的一键删除。这一步我之前也怕，但实际做完之后没有任何一个“复活”需求。删完再看自己的目录，清爽得让人上瘾。

我给这个流程取名叫“先禁后删”，它跟断舍离的逻辑一样：真正重要的东西你不会忘记，会被忘记的往往从一开始就没那么关键。

4.3 留下的 20%：我现在保留的 Skill 组合

清理完以后，我的 SKILLS 目录里长期保留的大概是这样的组合：

这里面没有一个是“全能型”Skill，全是小而准的工具。它们都有一个共同特点：输入很清楚，输出很直接，几乎不需要我再多绕弯子。这个组合支撑了我三个月的日常开发，目前还没出现“缺了某个功能”的焦虑。

5. 清理之后：三个月的反思与改良习惯

5.1 从“囤插件”到“搭积木”的心态转变

清理完 Skill 之后，最大的变化不是环境变快了，而是我调用工具时的思维方式变了。以前我是“先装一堆，期待某个场景下它能自动生效”；现在是“先想清楚这个场景我多久遇到一次，再决定要不要为它加一个固定动作”。

这个转变其实很接近写代码时的模块化思维：你不会为了一个工具类里的某一个函数引入整个框架，同样也不该为了偶尔一次的任务装一个重型的 Skill。Skill 和脚本、提示词、配置项之间应该保持着一种可替换的关系，而不是一劳永逸的依赖。

我现在的原则很简单：能用一次提示词解决的问题，不写 Skill；同样的问题出现第二次，考虑把提示词存成简单的模板；出现第三次，才动手做成一个完整的 Skill。这个“三次原则”帮我拦住了至少一半的剁手冲动。

5.2 我给自己定下的新 Skill 入场标准

经历过这次清理以后，我给新 Skill 设定了一套“准入门槛”，不会再因为看着新鲜就装。

第一，必须填写一个“使用场景说明”，要具体到能说出它会在哪类任务中发挥作用，而不是“可能用得上”。第二，安装前打开它的说明文件完整读一遍，看不懂或者内容空洞的，直接不装。第三，装完先保持默认不启用状态，直到我真正遇到那个场景三次以上，才把它激活。第四，激活后给一个月的试用期，如果这一个月里使用次数少于两次，直接移出。

这套门槛看起来很麻烦，但它把安装这件事从“两秒钟的冲动”变成了“一个需要审慎确认的动作”。门槛高的好处是，能进入你环境的都是已经提前筛过一遍的候选者，而不是抱着试一试心态塞进来的路人。

5.3 给同样在清理 Skill 的人一些实操心得

最后分享几个我踩坑踩出来的小技巧，不一定对所有人都适用，但至少能让你在清理时少走弯路。

第一，别只看 Installation 文档，一定要看 SKILL.md 或者它的核心配置文件。很多 Skill 的问题在安装说明里根本看不出来，只有看内容才知道它给你的 AI 灌了哪些规则。灌得越多的，越要警惕。第二，清理完以后给每个保留的 Skill 写一句“人话注释”，记录它当初是干什么的、为什么留下来。三个月后再看这个注释，你就不会又犯囤新 Skill 的毛病。第三，给整个 SKILLS 目录做版本控制，用 Git 管起来。想试新东西就开分支，不行就丢弃，不用再有“删了后悔怎么办”的心理负担。第四，定期设一个“Skill 回收日”，每两周花十分钟检查一次使用日志。能坚持做这个动作的人，基本不会再回到囤积巅峰的状态。

这套方法执行下来，我自己的感受是：真正好用的 Skill 从来不是靠数量堆出来的。哪怕只剩几个简简单单的工具，只要能精准覆盖日常高频场景，带来的实际效率提升都远超当初三十多个插件互相打架的时候。说到底，Skill 是给人用的设计约束，不是必需品的收藏品。我的建议就是“先删为敬”，删掉那些不真正服务于你的东西，剩下的是什么样，用一段时间自然会有答案。