企业官网建设流程全解析

1. 先说清楚：Skills 到底是解决什么问题的东西

我用 Claude Code 也大半年了，从最早只会写写 prompt、贴贴代码，到后来逐渐摸到门道，中间踩过不少坑。最近群里讨论最多的话题就是 Skills——有人捧上天，说有了它 Claude Code 才算真正好用；有人一肚子火，说写完 Skills 之后不仅没省时间，反而被自己的规则捆住手脚。

两种说法都有道理，但根源不在 Skills 本身，而在使用时机。

先给还没用过的朋友做个基础说明。Claude Code 里的 Skills，简单说就是把一整套行为规范、操作流程、检查清单打包起来，让 Claude 在碰到特定场景的时候，自动按照这套东西来执行。它不是简单的 prompt 拼接，而是结构化的行为指令，相当于给 Claude 装上了一个"领域插件"。

举个例子。你希望 Claude Code 每次提交代码之前都要跑一遍测试、检查代码风格、按规范格式写 commit message。你把这三件事写进一个 Skill 里，它的名字可以叫code-review或者pre-commit-check。之后只要你跟 Claude 说"帮我把这周的改动提交一下"，它会自动调用这个 Skill，按里面的规则一步步来，不需要你反复复述要求。

听起来很美好对吧？但问题是：并不是所有任务都适合装进 Skills 里。有些任务装了 Skills 反而拖慢速度、增加出错概率，甚至让 Claude 的行为变得不可控。

我这篇文章就想把这个问题讲透：什么时机该做 Skills，什么时机该忍住。全是基于我自己实际项目里的经验，配了具体的场景和判断方法，你可以直接拿去对照自己的项目做判断。

2. 什么时机该做 Skills：三个信号，同时满足再做

先别急着动手写 Skills。我建议你把下面三个条件当作一道门槛，三个都满足了，才值得投入时间做。缺任何一个，我都建议你先缓一缓。

2.1 信号一：同一类任务，你发现自己已经重复做了三次以上

这是最直接的信号。

我自己的判断标准很简单：如果一件事，我在过去两周之内已经要求 Claude Code 用同样的流程做过三次以上，我就会开始考虑把流程固化成一个 Skill。

举个例子。我手头有个项目，每次合入新的功能分支之前，都要做一轮完整的回归检查：拉取最新代码、跑单元测试、检查依赖版本、确认数据库迁移脚本没有遗漏、再按项目模板更新变更日志。这套流程我在半个月里做了不下十次，每次都要打一大段 prompt 才能让 Claude 明白我要做什么。更烦的是，有一天我漏说了一句"检查依赖版本"，Claude 就真的跳过了这一步，结果合并之后测试环境直接崩了。

后来我把整套流程整理成一个叫做release-check的 Skill，把所有步骤、检查项、输出格式都写进去。从那以后，每次我只要说"做一次发版检查"，Claude 就会自动执行全套流程，再也没出现过漏环节的情况。

但这里的"重复三次"不是说数量上的机械判断。三次重复意味着你已经把流程充分磨过了——该踩的坑踩过、该补的步骤补过、输出格式稳定下来了。如果只重复了两三次就急着固化，流程本身可能还在变，做出来的 Skill 过两天就得大改。

2.2 信号二：这个流程里的关键步骤，必须是"稳定不变的规则"

这一点很多人会忽略。Skills 的本质是固化流程，固化的前提是流程本身足够稳定。

什么叫稳定？就是"这个任务的正确做法，在可预见的未来内不会变"。比如代码提交规范、项目目录结构约定、接口文档格式、测试命名规范，这些都属于相对稳定的规则。而像"这次要检查的性能指标阈值""当前版本的发布策略""这次迭代的优先级排序"，这些就属于不稳定的信息。

判断方法很简单：你把这个 Skill 写出来之后，假设三个月都不去动它，里面的规则还有效吗？如果答案是"存疑"，那这些规则就不该进 Skill。

我自己在某个项目里就吃过亏。当时项目组定了一套接口错误码的规范，我把完整的错误码表写进了 Skill 里。结果两个月后规范调整，错误码新增了几十个，旧码也有废弃的，Skill 里的表已经过时了。最尴尬的是，Claude 严格按照旧规范生成的代码，跟新的后端逻辑对不上，白白返工。

从那以后我给自己定了一条规矩：Skill 里只放"做事的方式"，不放"当前的数据"。方式相对稳定，数据总是在变。

2.3 信号三：这些任务不做标准化，造成的损失是真实存在的

第三点想说的是"有没有必要"。有些任务重复归重复，但每次也花不了两分钟，漏一步也无伤大雅。这种情况可以不做 Skill，给 Claude 打个简短的 prompt 就够了。

但有些任务不做标准化，代价是实打实的。比如：

• 生成的文件格式不符合规范，下游工具直接报错
• 代码风格不一致，Code Review 被同事反复挑刺
• 流程里有安全项或合规项，漏一步就可能出事故
• 团队成员各自写 prompt，Claude 给出的结果五花八门

这些场景下，失败成本远大于 Skill 的维护成本，该做就得做。

我自己的经验：如果一件事做错之后需要花 20 分钟以上去补救，而做 Skill 只需要一个小时，那这件事几乎无条件值得做成 Skill。性价比摆在那里，不用纠结。

3. 什么时机不该做 Skills：这五种情况，建议你管住手

说完了该做，再来聊更关键的部分——不该做的情况。我自己判断失误的案例，几乎都集中在这一块。

3.1 需求还在高频变动期，流程没定型

这是我最想强调的一条。

你可能会觉得："这个任务的规则现在很乱，我正好做个 Skill 把它规范化。"但我的经验是，如果任务规则本身还没稳定，你现在做的 Skill 大概率是"用昨天的理解，固化了明天就要推翻的流程"。

举个反面案例。我有个同事，接到一个任务：帮项目组实现一套自动化测试脚本的生成。他跑了两遍流程之后觉得有必要做个 Skill，于是花了半天时间，把生成测试文件的目录规范、文件头注释格式、命名规则全写进了 Skill 里。

结果项目进行到第三周，组里换了测试框架，所有规则都得重写。那半天时间全白花了，而且因为旧 Skill 还会被 Claude 自动加载，他有段时间不得不频繁提醒"别用那个 Skill"，非常烦躁。

判断方法也简单：你回头看看过去几周，这个任务的执行方式变过几次？如果变过两次以上，说明还没有稳定下来。这时候与其做 Skill，不如把当前这轮执行方式写成一次性的 prompt，等流程跑顺了再固化。

3.2 任务本质上是一次性的，做完就再也不碰

这个情况看起来最明显，但实际中特别容易踩坑。因为"一次性的任务"有时候披着"以后还会用到"的外衣。

我经常看到有人把某个特定项目的部署说明做成了 Skill。问题是，这个项目的部署流程只用了那一次，之后再也没部署过第二次——因为项目本身已经进入维护期了。

浪费时间的程度还好，更麻烦的是给了自己一个错误的信号："我已经有 Skill 了，以后部署不用愁。"真到要用的时候，Skill 里的信息早就过时了，还不如重新查文档。

判断标准可以问自己三个问题：

• 这个任务会不会在另外的项目里碰到？
• 如果会，任务的规则和当前项目是否一致？
• 如果不一致，这个 Skill 还有多大价值？

如果三个答案都不太乐观，那这个 Skills 的投入产出比就很差了。

3.3 规则可以用一句话说清楚，做成 Skill 反而更高成本

这是另一个极端：任务经常遇到、规则也很稳定，但简单到不需要做成 Skill。

有些人（包括早期的我）进入到"手里有锤子，看什么都像钉子"的状态，遇到任何重复任务第一反应都是"做个 Skill 吧"。但说实话，一个只有两句规则的东西，你用 prompt 写也就十秒钟的事，何必搞成一个结构化的 Skill？

比如"帮我写代码的时候注意用 2 空格缩进"——这种规则直接写在 conversation 里就够了，或者写在项目内在的 CLAUDE.md 里更好。做成 Skill 反而引入了一套额外的加载、匹配、上下文开销，完全得不偿失。

判断标准也很直接：如果这个任务的规则可以用不超过三句话讲清楚，且不需要任何复杂的执行步骤、检查清单、输出模板，那就不要做 Skill。

3.4 你对任务的"最优做法"还没把握，不能贸然固化

做 Skill 的前提是你已经知道"怎么做最好"。但有时候，我们只是知道"现在怎么做"，并不知道"怎样做更好"。

我做过一个 Code Review 的 Skill，当时是按自己的想法写的规则：要检查哪些点、用什么顺序查、输出什么格式。用了两周之后发现，效果并不好，因为我对"到底什么才是有效的 Code Review"本身还没有想清楚。规则写得太琐碎，Claude 输出了一堆冠冕堂皇但没有实际价值的建议；写得太笼统，又等于没写。

这就是典型的"把不确定性固化成了规则"。如果你的任务做法还在探索阶段，我建议先多观察几次 Claude 的自然表现，甚至手动干预几次，找到你觉得"对了，就该这么做"的版本，再把它写成 Skill。

3.5 这套规则只对你自己有效，团队没人会用

除非个人项目，否则大部分开发工作都是团队协作。Skil ls 的维护其实是隐性的团队成本：谁来更新？谁负责验证效果？如果只有你一个人在用，其他同事不认这套规则，那 Skill 的价值就大打折扣。

这不是说团队项目就不能做 Skill。恰恰相反，我认为最能体现 Skills 价值的就是团队场景——大家共享一套项目规范，Claude 在任何人的会话里表现一致。但前提是这套规范真的被团队认可，而不是你单方面定的。

我合作过的一个项目组，某位同事花了大力气做了一套非常精细的代码生成 Skill。在他看来那套规则是完美的，但组里其他人一问三不知，也没人愿意用。最后 Skill 沦为那个同事的专属工具，那笔投入基本打了水漂。想避免这种结局，做之前先跟团队聊一聊，确认规则达成共识。

4. 一套能落地的判断框架：三分钟决定做不做

前面讲了很多"信号"和"情况"，但我知道大家需要的是——快速做决策的方法。我自己在实践中总结了一套三分钟决策框架，每次犹豫要不要做某个 Skill 的时候，就按这个流程过一遍：

第一步，看频率。过去两周内，同类任务有没有做三次以上？没有，不做。

第二步，看稳定性。任务的核心执行规则，三个月内会不会变？会变，不做。拿不准的，默认不做。

第三步，看成本。做错的后果是不是需要十分钟以上的补救时间？不是，不做。

第四步，看复杂度。规则是否超过三句话？是否有多个步骤、多个检查项、有输出格式要求？都没有，不做。

第五步，看共识。团队里其他人是否认同这套规则？个人项目跳过此项；团队项目有人不认同，先沟通，不要硬做。

这五步走完，结论其实已经很明显了。我可以负责任地说，按照这个框架筛下来的结果，真正做到后期没后悔过的 Skill，比例相当高。

这套框架也解决了另一个问题：很多人在"要不要做"的纠结中消耗了大量时间。你真的不用想太多，拿这个框架过一遍，该做的做，不该做的果断放下。

5. 两个完整的实操案例：从判断到落地

光讲框架有点干，我分享两个自己做过的完整案例，一个成功收尾、一个中途叫停，把判断和实操串起来。

5.1 案例一：团队规范的代码提交检查 Skill

背景是我们项目组有段时间 code review 效率特别低，主要原因是每个人的提交风格都不一样——commit message 有的写中文、有的写英文，有的按功能描述、有的直接放一堆数字编号。加上提交之前经常忘了跑测试，导致 CI 反复挂。

判断过程走一遍框架：频率，基本每天都要提交；稳定性，提交规范是组里讨论确认过的，短期不会变；做错成本，CI 挂一次加上流水线排队，至少耽误二十分钟；复杂度，涉及多个检查步骤；共识，组里开会确认过的规范。

五步全过，就做了。

Skill 的具体内容我写了三个部分：

第一部分是输入检查。Claude 需要先确认当前分支、检查是否有未提交的改动、确认目标分支是否合理。

第二部分是自动执行。按顺序跑 lint、跑测试、检查依赖版本变动。每一步都要在控制台输出结果，失败就中止，不往下走。

第三部分是提交生成。按照团队定的格式生成 commit message，格式大概是type(scope): description——type 范围限定在feat、fix、refactor、docs、test里，scope 写模块名，description 用英文写且小于 80 字符。

最开始我还在 Skill 里加了"输出检查报告"的要求，但后来发现那一步没什么人看，白白浪费 tokens，就把它删了。这也是一个经验：Skill 不是越完整越好，而是越贴合真实使用场景越好。写完用两周回头看，没用的步骤及时砍掉。

这个 Skill 上线之后最大的变化不是速度，而是一致性。组里每个人用 Claude Code 提交代码，出来的都是统一格式。即便有人对 Skill 规则有不同意见，讨论也有了具体的"文案"可以对着说，而不是各凭感觉。

5.2 案例二：中途叫停的测试数据生成 Skill

另一个例子恰好反过来。

我之前想做一个 Skill，用来辅助生成测试数据。需求是：项目里经常要造一批符合数据库表结构的假数据，每次都要写一大段 seed 脚本。听起来挺适合做 Skill 的，频率高、规则看起来也固定。

但我走框架的时候卡住了。卡的环节是"稳定性"：我们项目里数据库表结构几乎两三天就变一次，今天多一个字段、明天改一个类型。我意识到，如果 Skill 里写死了表结构和字段类型，那每变一次就要改一次 Skill，维护成本比"每次直接写 seed 脚本"还高。

最后我做了个变通方案：Skill 里不写任何表结构信息，只写"如何生成符合表结构的测试数据的通用方法论"——比如读取 schema 文件、识别字段类型、用对应类型的随机值生成器、处理外键关系这些通用步骤。至于具体有哪些表、哪些字段，让 Claude 每次执行时实时读取。

这个折中方案运行得不错，核心思路是：把稳定的方法论装进 Skill，把易变的数据留给实时读取。这个思路你也可以用到自己的项目里。

6. 常见误区和避坑心得

最后把我在实际使用中遇到的常见问题做一个盘点，都是花钱买来的教训。

6.1 误区一：Skill 写得越详细越好

正相反。Skill 内容太长，Claude 在加载的时候会占用大量上下文窗口，而且重点容易被淹没。

我自己试过写一个包含各种边界情况的超长 Skill，结果 Claude 在处理任务时抓不住重点，经常在无关紧要的规则上纠缠。后来我把 Skill 内容砍掉了接近一半，把真正核心的步骤留在里面，反而效果好很多。

一个参考标准：一个 Skill 的完整内容最好控制在几百个词的量级。超过一千个词，你就该考虑是不是拆分成多个 Skill 更合理了。

6.2 误区二：Skill 是一次性投资，做完就不用管

Skill 是需要迭代维护的"活物"，不是写一次就一劳永逸的死文档。我自己基本上每个 Skill 用上一到两周之后，都会回头审视一遍：

• 有没有哪一步 Claude 执行起来很勉强？
• 有没有哪个规则在实际任务里触发过误解？
• 有没有哪个输出格式在后续流程中根本用不到？

有，就改。这不丢人，改动说明你对这个任务的认知在加深。Skill 是认知的表达，认知更新了表达就跟着更新。

6.3 误区三：一个 Skill 想覆盖所有场景

我给过一个 Skill 取过"什么都管"的名字，希望它覆盖"所有代码相关的任务"。结果自然是失败的——规则要照顾的场景太多，导致每个场景都只照顾到一点点，等于什么都没管。

正确的做法是，把 Skill 按场景切割，每个 Skill 只负责一个明确的职责边界。宁可多建几个 Skill，也别把一堆高内聚的规则堆在一起。就像写代码一样，单一职责原则在 Skill 设计上同样适用。

6.4 技巧分享：给 Skill 建立"先例版本"的习惯

我自己用 Skills 最满意的一个习惯是：每次大改之前，把当前版本完整存档。这样改坏了随时能回退，敢放心大胆地迭代。这个小习惯让我避免了至少三次"改完后悔想恢复"的窘境。

另一个习惯是给 Skill 加使用日志要求，让 Claude 在执行完 Skill 之后简单输出"本次执行了哪些步骤、跳过了哪些步骤"。别小看这个输出，它能帮你快速发现 Skill 规则和实际场景的偏差，是持续改进的直接数据来源。

6.5 技巧分享：新 Skill 先小范围试用，再全量推广

不管是你自己写的还是团队里的，刚写完的 Skill 别直接在核心流程上启用。先在某个小任务上试几轮，观察 Claude 的执行是否完全符合预期。确认没有大问题之后，再逐步放开使用范围。

这一步其实就是程序员眼里的"灰度发布"，降低一次引入整套规则带来的风险。我自己写的很多 Skill 第一版都不尽如人意，往往要改了第三版才顺手。所以给点耐心。

写在最后的个人体会

如果你问我做 Skills 到现在最大的感悟是什么，我会说：Skills 是"把你已经跑通的流程固化下来"的手段，而不是"帮你探索未知流程"的工具。它不是一个提前规划的东西，而是一个水到渠成的东西。

最佳的状态是：某类任务你已经带着 Claude 做顺手了，顺手到你觉得"每次都要重新说一遍这些要求好啰嗦"——那个瞬间，才是做 Skill 的最佳时机。换句话说，让需求来找你，而不是你去找需求。

用我开头的框架再总结一遍决策要点：频率高、规则稳、失败成本真实存在、规则超过三句话、团队有共识——五条全中，放心大胆去做。只要漏掉一条，都值得你再想想。

不要为了用功能而用功能。真正让工具有价值的，是你在正确的场景里，把它放在正确的位置上。这一点，对 Skills 适用，对 Claude Code 适用，对所有开发工具也适用。