企业官网建设流程全解析

1. 从“能跑就行”到“越用越顺手”：我为什么开始折腾 Skill

刚上手 Claude Code 那阵子，我的用法特别朴素：打开终端，敲一句需求，等它吐代码，复制粘贴，收工。能用吗？能用。但用久了总觉得哪里不对劲——每次都要重新交代项目背景，每次都要提醒它“这个仓库用 pnpm 不用 npm”，每次让它写测试它都按自己的喜好来。我一度以为这就是 AI 编程工具的常态，直到我把 Skill 这个概念真正吃透，才意识到之前那些重复劳动全是白费。

先说清楚 Skill 到底是什么。你可以把它理解成给 Claude Code 预置的“操作手册”或者“岗位说明书”。它不是模型本身的能力，而是你在模型外面套的一层行为约束和知识注入。打个比方：Claude Code 是一个刚入职的聪明新人，脑子好使但不懂你们公司的规矩；Skill 就是你递给他的那本《团队开发规范》，里面写清楚了代码风格、目录结构、提交信息格式、测试框架选型。没有这本手册，他也能干活，但干出来的活你得反复返工。

我前后给自己的工作流装了大概 40 个 Skill，覆盖的范围从代码规范、测试生成、文档撰写，到数据库迁移、API 设计审查、甚至提交信息自动生成。装完之后最大的感受不是“功能变多了”，而是“我终于不用每次都当复读机了”。这篇文章就把我这段时间踩过的坑、总结出来的方法、以及哪些 Skill 真正值得装，一次性讲透。

如果你现在还在用最原始的方式跟 Claude Code 对话，每次都要手动补上下文，那这篇内容大概率能帮你省下大量重复沟通的时间。如果你已经用过几个 Skill 但觉得效果一般，那问题很可能出在写法上，后面我会专门拆解。

2. Skill、CLAUDE.md、MCP、Agent：先把这四个概念理清楚

很多人一上来就急着装 Skill，结果概念没搞明白，装了一堆互相打架的配置，最后效果还不如不装。我刚开始也是这样，所以这一节先把几个最容易混淆的概念掰开讲。

2.1 Skill 和 CLAUDE.md 的分工到底在哪

CLAUDE.md 是项目级的全局说明文件，放在仓库根目录，Claude Code 每次启动都会读它。它适合放那些“整个项目通用”的信息：项目是干什么的、用什么技术栈、目录结构长什么样、有哪些全局约定。你可以把它当成新人的入职须知。

Skill 则更细粒度，它是按需触发的。比如你有一个专门用来生成数据库迁移脚本的 Skill，只有当你的需求涉及数据库变更时它才会被调用。Skill 的好处是它可以封装一套完整的操作流程，包括前置检查、执行步骤、后置验证，而不只是一段静态说明。

我自己的做法是：CLAUDE.md 放“不变的东西”，Skill 放“会变的东西和流程性的东西”。比如“这个项目用 TypeScript 严格模式”放 CLAUDE.md；“新增一个 API 端点时需要同步更新 OpenAPI 文档、写集成测试、更新 changelog”这种流程，封装成 Skill。

2.2 MCP 是另一层东西，别跟 Skill 混着用

MCP 全称是 Model Context Protocol，它解决的是“Claude Code 怎么跟外部工具通信”的问题。比如你想让 Claude Code 直接读 Figma 的设计稿、直接操作浏览器做端到端测试、直接查数据库，这些都需要通过 MCP Server 来桥接。

Skill 和 MCP 的关系是：Skill 定义“做什么、怎么做”，MCP 提供“用什么工具做”。举个例子，你有一个 Skill 叫“根据设计稿生成页面组件”，这个 Skill 里会写清楚步骤：先用 Figma MCP 拉取设计稿的图层信息，然后按项目的组件规范生成代码，最后用 Playwright MCP 跑一遍视觉回归。Skill 是流程编排，MCP 是能力扩展。

我见过有人把 MCP 的配置直接写进 Skill 里，结果换个环境就崩了。正确的做法是 MCP 配置放在 Claude Code 的配置文件里，Skill 里只引用工具名称，不硬编码连接信息。

2.3 Agent 和 Skill 不是一回事

Agent 是一个更上层的概念，它指的是一个能自主规划、自主调用工具、自主完成多步任务的智能体。Skill 是 Agent 可以调用的能力单元。你可以把 Agent 想成一个项目经理，Skill 是他手下的各个专员——有人负责写代码，有人负责跑测试，有人负责写文档。

在实际使用中，你不需要自己去“创建 Agent”，Claude Code 本身就是一个 Agent。你要做的是给它配置好 Skill，让它在需要的时候能调用正确的“专员”。

理清这四个概念之后，你再去装 Skill 就不会盲目了。你知道每个 Skill 应该放在哪一层，跟其他配置怎么配合。

3. 40 个 Skill 里，真正每天都在用的是这几类

装得多不等于用得好。我一开始也是看到什么装什么，结果有将近一半的 Skill 一个月都用不上一次。后来我按使用频率重新梳理了一遍，发现真正高频的其实就几类。下面按类别说，每类挑几个代表性的讲。

3.1 代码规范类：让输出风格一次到位

这类 Skill 解决的是“每次生成的代码风格不一致”的问题。比如你团队用 ESLint 加 Prettier，但 Claude Code 默认生成的代码可能不符合你的规则。你可以写一个 Skill，在里面明确要求：生成代码后必须按项目根目录的 ESLint 配置自检，如果有冲突以项目配置为准。

我自己的代码规范 Skill 里还加了一条：所有新生成的函数必须带 JSDoc 注释，参数和返回值都要写清楚。这条规则写进去之后，我再也没手动补过注释。

具体写法上，我建议把规范拆成“硬性规则”和“软性偏好”两部分。硬性规则是必须遵守的，比如“不允许使用 any 类型”；软性偏好是尽量遵守的，比如“优先使用函数式写法”。这样 Claude Code 在执行时知道哪些不能妥协，哪些可以灵活处理。

3.2 测试生成类：从“写完再说”到“写完即测”

以前我让 Claude Code 写测试，它总是按自己的理解来——有时候用 Jest，有时候用 Vitest，mock 的方式也每次不一样。后来我写了一个测试 Skill，把测试框架、断言库、mock 策略、覆盖率要求全部固定下来。

这个 Skill 里最关键的一条是：生成测试之前，先读一遍被测文件的导出内容，确保每个导出函数都有对应的测试用例。这条规则加上之后，测试覆盖率肉眼可见地提升了。

还有一个细节：我要求测试文件的命名必须跟被测文件对应，比如userService.ts对应userService.test.ts，放在同级目录的__tests__文件夹里。这种一致性看起来是小事，但项目大了之后找测试文件会方便很多。

3.3 文档与提交信息类：把“事后补”变成“顺手做”

提交信息格式不统一是我之前的另一个痛点。有时候写“fix bug”，有时候写“修复了登录问题”，有时候干脆空着。后来我写了一个提交信息 Skill，要求每次提交必须遵循 Conventional Commits 格式，并且正文里要说明变更的原因而不只是变更的内容。

这个 Skill 的效果立竿见影。现在我的提交历史看起来非常规整，用工具自动生成 changelog 的时候直接就能用。

文档类 Skill 我主要用来生成 API 文档和 README。关键是要在 Skill 里定义好文档模板，包括必须包含的章节、每个章节的写作要求、示例代码的格式。模板定好之后，生成的文档质量稳定很多。

3.4 数据库与迁移类：危险操作加一道保险

数据库相关的操作是我最谨慎的地方。我写了一个迁移 Skill，里面强制要求：任何 schema 变更必须先检查现有迁移文件，确保没有冲突；生成的迁移脚本必须包含回滚逻辑；执行迁移之前必须先在测试环境跑一遍。

这个 Skill 帮我避免过一次事故。有一次我让 Claude Code 加一个字段，它生成的迁移脚本里没有默认值，如果直接在生产环境跑会导致现有数据出问题。因为 Skill 里要求了“必须检查现有数据兼容性”，它在生成脚本之前先提醒了我这个问题。

提示：涉及数据库、文件删除、生产环境配置的 Skill，一定要加上“执行前确认”的步骤。让 Claude Code 在动手之前先把计划列出来，你确认之后再执行。

4. 写 Skill 的几个关键决策：我踩过的坑和后来改对的写法

装 Skill 容易，写好 Skill 难。我前前后后重写了大概十几版，才慢慢摸到门道。这一节讲几个我认为最关键的决策点。

4.1 触发条件要写窄，不要写宽

我最早写的一个 Skill 叫“代码审查”，触发条件写的是“当用户要求审查代码时”。结果这个 Skill 几乎从来不触发，因为我很少直接说“审查代码”，我通常说的是“帮我看看这段有没有问题”或者“这个函数写得对不对”。

后来我把触发条件改成了具体的场景描述，比如“当用户粘贴了一段代码并询问质量、问题、改进建议时”。这样触发率一下子就上来了。

核心原则是：触发条件要描述“用户在什么情境下会需要这个 Skill”，而不是“这个 Skill 是干什么的”。前者是场景，后者是功能。Claude Code 匹配的是场景，不是功能。

4.2 步骤要具体到可执行，不要写空话

我见过很多 Skill 写的是“确保代码质量”“遵循最佳实践”这种话。这种 Skill 装了等于没装，因为 Claude Code 不知道具体要做什么。

好的 Skill 步骤应该是这样的：第一步，读取项目根目录的.eslintrc文件；第二步，对生成的代码逐行检查是否符合规则；第三步，如果有不符合的地方，自动修复并说明修改原因；第四步，修复后重新检查一遍，确保没有遗漏。

每一步都有明确的动作和对象。这样 Claude Code 执行起来才不会跑偏。

4.3 给输出定格式，减少后期整理

如果你希望 Skill 的输出能直接被其他工具消费，那就在 Skill 里定义好输出格式。比如我有一个 Skill 用来生成 API 变更记录，输出格式固定为 JSON，字段包括endpoint、method、changeType、description。这样我拿到输出之后可以直接喂给文档生成工具，不需要手动整理。

格式定义得越明确，后期返工越少。我建议至少定义清楚：输出的结构（是段落、列表还是 JSON）、必须包含的字段、字段的命名规范。

4.4 版本管理：Skill 也要进 Git

这一点很多人会忽略。Skill 文件本身也是代码资产，应该跟项目一起进版本管理。我现在的做法是在项目根目录建一个.claude/skills文件夹，所有 Skill 文件放在里面，跟代码一起提交。

这样做的好处是：团队其他人拉下代码就能用同一套 Skill，不需要每个人单独配置；Skill 的变更也有历史记录，出问题可以回滚；新成员入职的时候，Skill 本身就是一份很好的操作规范文档。

5. 一个完整 Skill 的拆解：从需求到落地

光讲原则不够直观，这一节我拿一个实际在用的 Skill 来拆解，把每个部分为什么这么写讲清楚。这个 Skill 的功能是“新增 API 端点时的全流程处理”。

5.1 需求分析：这个 Skill 要解决什么问题

在我们团队，新增一个 API 端点不只是写一个路由处理函数那么简单。还需要：定义请求和响应的类型、写参数校验逻辑、添加路由注册、写集成测试、更新 OpenAPI 文档、在 changelog 里加一条记录。这些步骤以前全靠人记，经常漏掉一两项。

这个 Skill 的目标就是把这套流程固化下来，让 Claude Code 在接到“新增一个 API 端点”的需求时，自动按完整流程执行，不遗漏任何一步。

5.2 Skill 结构拆解

这个 Skill 分为四个部分：触发条件、前置检查、执行步骤、后置验证。

触发条件写的是：“当用户要求新增、添加、创建 API 端点或路由时触发。”这里用了多个近义词，是为了提高匹配率。

前置检查部分要求 Claude Code 先做三件事：确认项目的 API 框架类型（Express、Fastify、Koa 等）；读取现有的路由文件了解注册方式；检查是否已存在同名或相似功能的端点。这三步是为了避免重复造轮子和风格不一致。

执行步骤按顺序列出了七步：定义 TypeScript 类型、写参数校验、实现处理函数、注册路由、写集成测试、更新 OpenAPI 文档、更新 changelog。每一步都注明了参考文件，比如“参数校验参考src/validators/目录下的现有写法”。

后置验证要求跑一遍测试、跑一遍 lint、确认 OpenAPI 文档能正常生成。如果任何一步失败，就停下来报告问题，不要继续。

5.3 实际效果和迭代过程

这个 Skill 上线之后，新增端点的平均耗时从原来的四十多分钟降到了十几分钟，而且几乎没有再出现过“忘了写测试”或者“忘了更新文档”的情况。

迭代过程中我改过两次。第一次是发现它有时候会跳过前置检查直接开始写代码，我在触发条件后面加了一句“必须先完成前置检查才能进入执行步骤”。第二次是发现生成的测试用例覆盖不够，我在执行步骤里补充了“测试必须覆盖正常流程、参数缺失、参数类型错误三种情况”。

注意：Skill 不是写完就完了，前几次使用一定要盯着输出，发现偏差就及时调整。一般迭代两三轮之后就能稳定下来。

6. 装完 40 个 Skill 之后，我的工作流发生了什么变化

说几个最明显的变化。

第一是启动成本降低了。以前打开一个新项目，我要花十几分钟跟 Claude Code 交代背景、约定规范、说明偏好。现在这些都在 CLAUDE.md 和 Skill 里了，打开就能干活。

第二是输出一致性提高了。同一个项目里，不管我是上午写代码还是半夜写代码，生成的代码风格、测试写法、提交信息格式都是一样的。这对团队协作来说价值很大。

第三是我对 Claude Code 的信任度提高了。以前它生成的代码我总要逐行检查，现在因为有了规范约束和自动验证，我只需要关注业务逻辑对不对，格式和流程性的东西基本不用操心。

第四是知识沉淀下来了。以前很多“怎么做”的经验只在我脑子里，新人来了要口传心授。现在这些经验都写进了 Skill 文件，变成了可复用的资产。

如果让我给刚接触 Claude Code 的人一个建议，我会说：先别急着装几十个 Skill，先把最常用的三五个写好、用顺，感受到效率提升之后，再逐步扩展。Skill 的价值不在于数量，而在于每一个都真正融入了你的工作流。

7. 关于 Skill 的几个常见疑问

最后集中回答几个我被问得最多的问题。

Skill 会不会拖慢 Claude Code 的响应速度？会有轻微影响，因为每次对话它都要匹配触发条件。但实际体验下来，只要 Skill 数量控制在合理范围内（我目前 40 个左右），延迟几乎感知不到。如果你装了几百个，那确实可能变慢，这时候要考虑合并或删减。

Skill 之间会冲突吗？会。如果两个 Skill 的触发条件重叠，Claude Code 可能不知道该用哪个。我的做法是定期检查触发条件，确保没有语义重复。如果确实需要两个相似的 Skill，就在触发条件里写清楚区别，比如一个针对前端组件，一个针对后端服务。

Skill 能不能跨项目复用？可以。我把通用的 Skill 放在用户级配置目录里，项目特有的放在项目目录里。这样通用规范不用每个项目重复写。

写 Skill 需要编程基础吗？不需要。Skill 本质上是结构化的自然语言描述，你只要能把自己的操作流程写清楚就行。当然，如果你懂一点 Markdown 和 YAML 的格式规范，写起来会更顺手。

Skill 和直接写 prompt 有什么区别？直接写 prompt 是一次性的，下次还要重新写。Skill 是持久化的，写一次之后每次都能自动触发。而且 Skill 可以包含多步流程和条件判断，比单次 prompt 能表达的复杂得多。

怎么判断一个 Skill 该不该装？我的标准是：如果某个操作我一周内重复了三次以上，就值得写成 Skill。如果一个月都用不到一次，那就不值得。

Skill 文件应该写多长？没有固定标准，但我建议控制在 200 到 500 字之间。太短了说不清楚，太长了 Claude Code 可能抓不住重点。如果确实需要很长的流程，考虑拆成多个 Skill 串联。

更新 Skill 之后需要重启 Claude Code 吗？大多数情况下不需要，它会自动读取最新的 Skill 文件。但如果你改了配置文件层面的东西，可能需要重启才能生效。

团队协作时 Skill 怎么管理？我建议把 Skill 文件跟代码放在同一个仓库里，通过 Git 管理。指定一个人负责审核 Skill 的变更，避免每个人按自己的喜好改来改去导致风格混乱。

Skill 写错了会不会导致严重问题？如果 Skill 里包含危险操作（比如删除文件、执行数据库迁移），确实有可能。所以我在所有涉及危险操作的 Skill 里都加了“执行前确认”步骤，让 Claude Code 先把计划列出来，我确认之后才执行。这个习惯帮我避免了好几次潜在事故。