企业官网建设流程全解析

做前端开发和 AI 辅助编程的朋友，最近应该没少被 Claude Code 刷屏。作为 Anthropic 官方推出的终端编码智能体，Claude Code 的强劲能力这两年有目共睹，但真正让它和其他“会聊天的代码助手”拉开差距的，其实是 Skills。打个不严谨的比方：模型本身是“会 Coding 的大学生”，而 Skills 就是你递给他的“标准作业流程手册”。没有手册他也能写，但有手册之后，他遇到特定任务时不会再自由发挥，而是按你约定好的检查清单、工具顺序、输出格式来干活，稳定性和复用性完全是两个档次。这篇文章就把我实际使用 Claude Code Skills 的经验捋一遍，重点讲清楚两件事：怎么装、以及怎么把项目级 Skills 干净利落地切到全局。

1. 先搞清楚：Claude Code 的 Skills 到底是个什么东西，为什么值得装

1.1 我理解的 Skills：不是插件，是一套“行动剧本”

很多人第一次听到 Skills，下意识会把它类比成 IDE 插件或“提示词模板”。其实不太准确。插件往往有独立运行逻辑和 UI；而 Skills 本质上是“一组给 Claude Code 看的指令文件”。它告诉模型：当你遇到某类任务时，不要自己临时想方案，按这套固定的步骤来，并且可以附带脚本、模板、工具调用配置。

举个例子。我写过一套“前端代码审查”的 Skill。没有它的时候，我让 Claude Code 审查一段 React 代码，它每次的做法可能都不一样——有时先讲逻辑、有时先喷格式、有时直接丢建议。而有了 Skill 之后，它会严格按我定义的顺序走：先扫描目录结构，梳理组件职责；再读关键文件，按可维护性、性能、可访问性三个维度分别给结论；最后输出带严重等级的审查报告。整个过程不会漏项，也不怎么会跑偏。对于跨项目重复执行的任务，这就是生产力保障。

从机制上拆解，一个 Skill 的核心由三部分构成：YAML 前置元数据（name、description 等）、SKILL.md 正文（给模型的指令剧本）、以及可选的辅助文件（脚本、模板、示例代码）。Claude Code 会自动扫描可用的 Skills，并根据 description 决定在什么时机唤醒它。这个“按需触发”的设计非常关键，我后面会详细说。

1.2 一套 Skill 的目录结构长什么样

在我见过和实际搭过的项目里，Skill 目录的标准结构基本是这样：

your-skill-name/ ├── SKILL.md ├── scripts/ │ └── check_review.sh └── templates/ └── review_report.md

其中 SKILL.md 是灵魂。它有固定的开头格式，大概长这样：

--- name: frontend-review description: 审查前端代码时使用。包括目录扫描、组件逻辑分析、性能与可访问性检查、输出分级审查报告。 --- # 前端代码审查流程 当用户要求审查前端项目代码时，按照以下步骤执行： 1. 先运行 `tree -I node_modules` 查看目录结构，标注核心组件。 2. 逐个读取组件文件，按"逻辑正确性 / 代码可维护性 / 性能隐患 / 可访问性"四个维度分析。 3. 输出审查报告，按 P0/P1/P2 分级问题。

这里有几个细节值得注意。name是技能唯一标识，不要乱起；description是触发模型的关键，写得太泛会让模型在无关场景下也尝试调用，写得太窄则会导致“明明装了却完全没触发”。正文部分要有序、可执行，最好拆成步骤，因为模型读到的是 Markdown，线性步骤比大段描述更容易被执行。辅助脚本不是必须的，但当 Skill 需要跑测试、查端口、统计代码量时，带脚本能显著降低模型出错的概率。

1.3 为什么明明能写进 CLAUDE.md，还是要用 Skills

很多人会问：Claude Code 不是有 CLAUDE.md 吗？我把这些规矩写进 CLAUDE.md 不就行了？这个问题我一开始也犯过嘀咕，但实际对比下来差别很大。

CLAUDE.md 是“常驻记忆”，每轮对话都会塞进上下文里，适合放项目背景、编码规范、常用命令这类“模型始终需要知道的东西”。但也正因为常驻，它不能写太多，否则白白消耗上下文窗口，还会干扰模型对当前任务的注意力。Skills 则相反，它是“按需加载”。description 匹配到任务时才会被唤醒，平时只是目录里的一个文件，不占上下文。此外 Skills 能携带文件和脚本一起打包，CLAUDE.md 做不到。

所以我的经验是：高频背景知识放 CLAUDE.md，低频且流程固定的任务拆成 Skills。这两者不是替代关系，而是互补关系。如果项目里既有全局规范，又有高度定制化的处理流程，配合使用效果最好。

2. 别急着装：先分清项目级和全局级，避免后面返工

2.1 项目级 Skills 的存放位置与生效逻辑

项目级 Skills 的位置是当前项目根目录下的.claude/skills/文件夹。以我常用的目录为例：

my-project/ ├── .claude/ │ └── skills/ │ ├── frontend-review/ │ │ └── SKILL.md │ └── commit-message/ │ └── SKILL.md ├── src/ └── package.json

放在这个路径下的 Skill，只对当前这个项目生效。最核心的好处是它能跟着 Git 仓库走：团队成员把仓库 clone 下来，进入项目后 Claude Code 会自动识别这批 Skills，不需要每个人都单独去配置。对于“绑定项目技术栈”的专用流程，比如某个后端项目的代码生成规范、某个 React 项目特定的组件写法检查，项目级是唯一合适的选择。

但项目级也有它的尴尬。如果你同时维护好几个项目，每个项目都有一套通用工作流（比如写规范 commit message、做代码审查、整理依赖），那你就得在每个项目的.claude/skills/里复制同一份内容。表面上看只是复制目录，实际上后续每改一次 Skill 都要同步 N 个项目，迟早会踩到“某个项目还是旧版”的坑。

2.2 全局 Skills 的存放位置与生效机制

全局 Skills 存放在用户主目录下的.claude/skills/。macOS 和 Linux 上通常是这样：

~/.claude/skills/ ├── code-review/ │ └── SKILL.md └── commit-message/ └── SKILL.md

Windows 下则在C:\Users\<你的用户名>\.claude\skills\。只要你是当前用户，打开任意项目，Claude Code 都会把这份全局目录纳入扫描范围。它和项目级 Skill 唯一显著的区别是作用域，一个全局一个局部，但扫描加载机制基本相同。

需要注意一个细节：全局 Skills 改动之后，已经打开着的 Claude Code 会话不一定会立刻加载新配置。我实操时经常出现“我明明把 Skill 放进去了，当前会话却调用不到”的情况。这不是装错了，而是会话缓存。稳妥的验证姿势是退出会话重新进入，或新开一个终端窗口再测试。这个点我在第 5 章会再展开。

2.3 什么时候该用项目级，什么时候该上全局

很多新手最容易犯的错就是一上来把所有 Skills 都丢进全局。表面看图省事，实际埋了雷：全局 Skills 会对所有项目生效，如果你在日常写 Java 的项目里装了“React 脚手架生成”Skill，模型可能会在无关场景多次误触发，导致对话里飘出一堆没用的建议。我建议按下面这个标准来划分：

拿我自己的项目举例：我把“Vue3 组件生成”放在某个具体项目的.claude/skills/里，因为它依赖那个项目的内部目录约定；而“代码审查报告生成”我放在全局，因为我所有项目都要审查，验证通用流程时也只需改全局这一份。这个划分原则从长期维护角度看，能帮你省掉大量的同步成本。

3. 实操：把项目级 Skills 切到全局，三种方法任选

3.1 方法一：手动复制/移动目录（最通用，适合所有版本）

不管你用的是官方最新版还是社区魔改版，手动复制永远是最稳的切换方式。操作分三步。

第一步，确认项目里有哪些 Skills：

cd /path/to/your-project ls -la .claude/skills/ find .claude/skills -maxdepth 1 -type d

find能看到完整目录列表，避免漏掉没有权限显示的隐藏目录。

第二步，把想要全局化的 Skill 复制到全局目录。macOS/Linux 上直接用cp：

mkdir -p ~/.claude/skills cp -r .claude/skills/frontend-review ~/.claude/skills/

这里我用的是cp -r而非mv。原因是切换初期你还没验证全局那份是否健康，项目级保留一份原样，万一全局出了状况还能秒回滚。等你确认全局那份能正常工作，再回来删项目级也不迟。

Windows 用户请用 PowerShell：

Copy-Item -Path ".claude\skills\frontend-review" -Destination "$env:USERPROFILE\.claude\skills\" -Recurse

第三步，验证全局目录内容：

ls -la ~/.claude/skills/

看到frontend-review目录且里面有 SKILL.md，说明文件层面的切换已经完成。

这个方法的缺点是纯手工会比较枯燥，但它有一个巨大的优点：完全不依赖 Claude Code 版本差异，也绕开了所有环境问题。无论你怎么升级、怎么变配置，文件复制过去就是过去了。

3.2 方法二：利用 claude skills 命令完成切换

如果你用的是较新版本的 Claude Code，它自带 Skills 管理命令。不同版本命令略有差异，建议先用claude skills --help或者claude --help看看当前版本支持什么子命令。常见的形式是：

claude skills add frontend-review --path .claude/skills/frontend-review

这个命令做的事情本质上就是“把指定路径的 Skill 注册到全局”，比手动复制省事的地方在于它通常会自动处理目录创建、配置更新等步骤。不过我在多个版本实测下来，有一条经验很重要：命令行并不总是会自动覆盖同名的全局 Skill。如果~/.claude/skills/frontend-review已经存在，部分版本会直接报错或者跳过，你需要先手动删掉旧的全局副本再执行添加：

rm -rf ~/.claude/skills/frontend-review claude skills add frontend-review --path .claude/skills/frontend-review

另外如果你习惯用斜杠命令，进入 Claude Code 交互界面后敲/skills一般能看到当前会话加载了哪些技能。有些版本支持直接在交互界面管理技能源，但坦白说我在命令行里的体验更顺畅。交互界面的操作按钮在不同版本上变化较快，如果你发现界面里没有类似选项，直接用命令行事是最稳妥的。

3.3 方法三：用 Git 仓库统一管理全局 Skills

一旦你的全局 Skills 数量超过五六个，我强烈建议不要再裸放目录了，直接用 Git 仓库管理。大致思路是建一个专门的仓库存放全局 Skills：

mkdir -p ~/skills-repo cp -r ~/.claude/skills/* ~/skills-repo/ cd ~/skills-repo git init git add . git commit -m "init global skills"

以后要“切换”或“同步” Skill，就把它当作正常的代码改动静默管理。换新机器时，只需要 clone 这个仓库，再把内容软链到~/.claude/skills/：

git clone git@github.com:yourname/global-claude-skills.git ~/skills-repo ln -s ~/skills-repo/* ~/.claude/skills/

这里要注意：如果你用软链，建议先确认~/.claude/skills/里没有同名真实目录，否则可能产生冲突。我个人用这个方案稳了一个多月，最大的好处是改任何全局技能都有 git 历史兜底，改坏了直接git checkout回滚。

具体到“从项目级切到全局”，Git 管理下就变成了两步：把项目里的 Skill 目录复制进 skills-repo 并 commit，同时删掉或保留原项目里的副本，然后在~/.claude/skills/建软链指向它。这样切换后你改的永远是仓库里的那份，多台机器之间同步也很自然。

3.4 切换后如何立即验证，确保真的生效了

文件复制过去、命令执行成功，都不代表 Claude Code 真的认了。我踩过太多次“复制了但没生效”的坑，所以把验证经验单独列出来。

先关掉当前所有 Claude Code 会话，重新进入一个测试项目（最好不是原来那个项目），敲：

/skills

看输出列表里有没有frontend-review。如果命令行不支持/skills，直接问一句“你现在有哪些可用的技能？”看它的回答即可。这招听起来简单，但能节省大量排查时间。

然后做一次真实任务验证，比如在一个临时目录里放一段有明显问题的小代码，然后说“用 frontend-review 审查一下这个目录”。注意观察它的行为是否符合 SKILL.md 中定义的步骤顺序。这里有个很容易忽略的点：Claude Code 对 Skill 的“调用”不一定实时提示，它可能悄悄在你后台执行脚本。如果没看到预期的审查报告结构，先别急，看看它的运行日志或问它“你刚才调用了哪些工具”。验证通过后，再回原项目删除项目级副本，完成整个切换闭环。

4. 必装 Skills 清单：从哪找、推荐装哪些、怎么快速装

4.1 找 Skills 的渠道：官方市场、GitHub 社区、自建三种来源

先说渠道。最省事的是官方市场，Claude Code 的官方 Skills 市场里可以直接搜索和安装。安装方式一般是：

claude skills add skill-name

或者按照市场页面提示复制安装命令。没有图形市场入口的版本，也可以去 GitHub 搜awesome claude skills这类聚合仓库，里面通常整理了社区大量 Skill，按前端、后端、测试、文档等分类。第三个来源就是自己写。Skills 的本质是 Markdown + 脚本，只要你会写说明文档，就能写出自己的 Skill，这个后头再说。

我必须强调的是：不管从哪个渠道下载，都要先看 SKILL.md 内容再装进环境。社区 Skill 质量参差不齐，有些只是把通用提示词换了层皮，有些可能会引导模型执行高风险命令。我见过有人在网上分享“一键装全部”的脚本，不建议盲目执行，花两分钟扫一眼待装的 SKILL.md 并不亏。

4.2 我实际装着在用、且推荐新手先装的三类 Skills

结合我自己的使用频率和社区热度，先推荐三类。

第一类是代码审查类。比如审查前端代码、审查 Python 代码、审查 Go 代码等。这类 Skill 的价值在于能把“仔细审查、按严重程度输出”这种模糊要求，转化成可重复的、分门别类的检查流程。我实际用下来，审查类 Skill 对 P0/P1/P2 分级的要求越清楚，输出越可用。

第二类是测试驱动类。它的典型流程是：先读需求，列出测试用例；再写测试骨架；再实现业务代码使测试通过。对于习惯了“先写码再补测”的人来说，这类 Skill 能强制流程折返，减少遗漏。如果你负责维护一个老项目，强烈建议装一个“运行测试并生成失败摘要”类的 Skill，它能把一大堆测试输出压缩成几条关键信息，省心不少。

第三类是提交信息规范类。它会在你执行 git commit 前，根据 diff 内容生成符合 Conventional Commits 格式的提交信息，并附带 scope 判断。这类 Skill 单个看起来很简单，但对团队协作的规范性提升真实有效。

如果你做前端，最值得先装的是前端脚手架/组件生成类。用户搜“前端开发 skills”很多也是这个需求。比如“生成 Vue 组件”、“生成 React 组件”，要求它遵循你项目的目录结构、样式方案、状态管理方式。这种 Skill 绑定项目级场景特别强，通常放在具体项目的.claude/skills/下最合适。

4.3 一次完整的前端 Skill 安装示范（从下载到验证）

下面演示一个将社区前端审查 Skill 安装到项目级，并随后切到全局的完整流程，方便你对比理解。假设你在 GitHub 上找到了一个叫claude-skill-frontend-review的仓库。

先把仓库下载下来：

cd /path/to/your-project git clone https://github.com/example/claude-skill-frontend-review.git

然后把它的内容放进项目级 Skills 目录：

mkdir -p .claude/skills cp -r claude-skill-frontend-review/. .claude/skills/frontend-review/ ls .claude/skills/frontend-review/

确认里面SKILL.md存在后，重启 Claude Code 并验证是否能调用。接着做全局切换：

cp -r .claude/skills/frontend-review ~/.claude/skills/ cd ~/skills-repo # 如果你建了全局 skills 仓库 cp -r ../path/to/your-project/.claude/skills/frontend-review . git add . git commit -m "add frontend-review skill to global"

最后把项目里重复的那份删掉，或者保留但不推荐重复维护：

rm -rf .claude/skills/frontend-review

到这里，一次完整的“从项目级到全局”的切换就发生在一次很普通的日常开发过程中了。你不需要专门为了切换而切换，按需操作即可。

4.4 自己写一个简单 Skill 的大概步骤

如果你想要完全贴合自己工作流的 Skills，自写也是最推荐的路径。创建一个 Skill 的核心步骤其实很轻：

1. 新建目录：mkdir -p ~/.claude/skills/my-skill
2. 创建SKILL.md，写清楚name和description，正文里把处理流程拆成编号步骤。
3. 如有必要，放入辅助脚本。
4. 重启 Claude Code，测试触发描述，比如直接说“执行 my-skill”。

自写 Skill 的难度天花板不在 Markdown，而在你对任务的拆解能力。我见过很多“我写了个 Skill 但没起作用”的案例，最后追查原因十有八九是 description 写得不好：要么写得像普通聊天内容，模型不知道什么时候触发；要么写得过于狭窄，真实任务中几乎不可能匹配。比较好的做法是把 description 写成“当用户要求 xxx 时使用，包括但不限于 aaa、bbb、ccc 场景”，给模型留足判断空间。

5. 装完就踩坑：常见问题与排查实录

5.1 技能装了但没反应：八成是目录或描述问题

这是我在各个群里被问得最多的问题。用户说“我明明把 Skill 放进去了，Claude 完全不理我”。我排查时按这个顺序走：

先检查目录层级。常见错误是~/.claude/skills/my-skill/skills/SKILL.md这种多套一层目录。Claude Code 默认扫描的是skills/下的一级目录，如果里面再套一层，就可能识别不到。记住结构应该是skills/<skill-name>/SKILL.md。

再检查文件名。大小写必须准确，文件名是SKILL.md，不能是skill.md或Skill.md。这个错误在 Windows 上尤其隐蔽，因为默认不区分大小写，但 Claude Code 的加载逻辑是区分大小写的，我建议始终用ls确认文件名。

最后检查 description。模型是靠 description 判断是否触发 Skill 的。如果它写得太抽象，比如“帮助用户处理代码”，那模型面对“帮我看看这段代码”时会犹豫要不要调用，最终选择不调用也是常有的事。改成具体场景描述能显著提高触发率。

5.2 项目级和全局级同名 Skill 冲突时谁说了算

当你从项目级切到全局，但没有删除项目级副本时，就会遇到同名冲突。遇到这种情况，Claude Code 的加载优先级一般情况下是项目级优先。原因也合理：项目级更贴合当前项目的定制需求，如果两边定义不一致，理应让“离项目最近”的配置生效。

但这个“默认”不一定在所有版本上都有清晰体现。我在排查时发现有的版本会直接报重复加载警告，有的版本则默默只加载一个。最稳妥的办法永远不是在规则边缘试探，而是手工保持唯一性。切换后立即删掉项目级副本，全局里只留一份，就能从根上避免这类问题。

5.3 从全局切回项目级的反向操作

虽然标题是“从项目级切到全局”，但实际工作中反向切换也经常发生。比如你把某个 Skill 全局化之后，发现它只在这个项目里适用，丢在全局反而会在别的项目误触发。这时候操作正好反过来：把~/.claude/skills/<skill-name>复制回项目.claude/skills/下，然后删除全局副本。

需要注意一点：如果这个全局 Skill 之前已经通过 Git 仓库管理，反向切换时记得同时在仓库里删掉，免得以后同步又把 Skill 拉回全局。我踩过一次这个坑，某个项目的专用 Skill 明明已经从全局目录删了，结果因为没同步提交仓库，换台机器同步后它又赫然出现在全局目录里，害我排查了半天。

5.4 升级 Claude Code 后 Skills 神秘消失的排查思路

Claude Code 迭代速度很快，Skills 功能本身在演进，内部目录结构和配置方式也可能调整。我遇到过一次升级后全局 Skills 全部失效的情况，原因就是某个版本把配置读取路径改了。如果你升级之后发现 Skills 全部失踪，先别急着重装，按这三步排查：

第一步，确认全局目录是否还在：ls -la ~/.claude/skills/。第二步，检查新版本是否有迁移命令或新的配置项，看看官方 changelog。第三步，用claude --version查看版本号，去社区搜一下相同版本的其他用户有没有类似问题。

如果确认是路径调整导致失联，最常见的解法是把旧目录内容复制到新的约定路径，而不是重新从市场下载所有 Skill。直接复制保留了自己后期修改过的版本，比重新安装社区原版更贴合你的实际工作流。

5.5 关于“必装”这个说法的个人取舍

最后聊点私货。现在网上铺天盖地都在说“必装 XX Skills”，我的态度一直是：Skills 是给人减负的工具，不是越多越好的装饰品。真正必装的，是你日常重复度最高、流程最固定、且每次人工操作都嫌烦的那几个任务。装太多反而会让模型在触发判断时频频犹豫，影响对话体验。

我自己保留的全局 Skills 数量没有超过八个。凡是与具体仓库强绑定的流程一律不进全局；凡是跨项目通用工作流尽量全局化，并通过 Git 仓库统一管理。这个原则让我在项目级和全局之间切换时，不会有“删也不是、留也不是”的纠结。你也完全可以按自己的节奏定一套规则，核心是让 Skills 服务于你的工作流，而不是反过来为管理 Skills 消耗精力。