企业官网建设流程全解析

做 AI 编程工具这几年，真正拉开差距的从来不是模型聪明不聪明，而是你有没有把自己团队的做事方法“灌”进工具里。Claude Code 之所以在 GitHub 上热度一直很高，不是因为它能多写几行代码，而是因为它提供了一套把“工作流程”变成“可复用能力”的机制，也就是 Skill。这一期内容不聊虚的，直接把 Skill 的创建、组合、从 GitHub 获取第三方技能包，以及如何接入日常开发流程讲清楚。

很多人装完 Claude Code，打开就是一个终端对话框，让它写个函数能写，让它改个 bug 能改，但换个项目、换个团队，又回到了从零开始的状态。问题不在于 AI 不够强，而是你没有一个能把“项目规范、代码风格、验证步骤”打包交给 AI 的载体。Skill 解决的就是这件事：把一次性的“帮忙写代码”变成可持续的“按你的标准自动干活”。如果你最近刚好在折腾 Claude Code，或者从 GitHub 下了一些 skill 却不知道怎么用，这篇文章建议收藏后照着做。

1. 这篇文章真正要解决的问题

先给结论：Claude Code 的安装本身并不难，难的是让它在真实项目里稳定地输出符合预期的结果。大多数用户的体验曲线是这样的——第一次用觉得惊艳，第二次用发现它不了解你的项目背景，第三次用发现它每次都要重新交代一堆上下文，效率反而下降了。

Skill 的存在，就是用来解决这个“每次都要重新交代”的问题。它相当于给 AI 预装了一份“项目岗位说明书”：你的项目结构是什么、代码规范有哪些、常见的坑在哪里、处理某类任务时应该按什么步骤走。一旦定义好，后续只需要一句话触发，AI 就会按既定流程执行。

这篇文章要覆盖四件事：

1. Claude Code 和 Skill 的基本概念，以及它们和普通 Prompt 的本质区别；
2. Skill 的目录结构与创建方法，包含可以直接复制的 SKILL.md 示例；
3. 三个实用 Skill 的组合工作流，从一个需求描述到代码生成再到代码审查；
4. 将 Claude Code 接入 GitHub 日常协作流程的注意事项，避免 AI 乱提交、乱改分支。

无论你是前端、后端，还是主要用 AI 做自动化脚本的开发者，这套思路都适用。核心不是某个具体插件有多神，而是你掌握“如何给 AI 定义能力边界”之后，能把任何团队规范沉淀进工具里。

2. 基础概念：Claude Code、Skill 与组合插件的区别

2.1 Claude Code 是什么

Claude Code 是 Anthropic 推出的终端 AI 编程助手，核心交互发生在命令行里。它可以直接读取项目文件、执行命令、编辑代码，并且以会话方式与开发者协作。相比网页版聊天窗口，它的优势在于“手”更长——能真实操作你的项目，而不是只给一段建议。

它通常具备这些能力：

• 读取项目目录结构，理解上下文；
• 在用户确认后修改代码文件；
• 执行测试、构建等命令；
• 配合 Git 完成仓库操作；
• 通过扩展机制加载额外能力。

安装方式比较统一，命令行下通过 npm 全局安装即可：

node -v npm -v npm install -g @anthropic-ai/claude-code claude --version

安装完成后，在项目根目录执行claude即可启动会话。如果是第一次使用，需要先完成登录授权，后续才能正常调用模型。

2.2 Skill 是什么

Skill 可以理解为“你交给 AI 的一份结构化操作手册”。它存储在项目的.claude/skills/目录下，每个 Skill 是一个独立子目录，子目录里有一个SKILL.md文件，用于描述该能力的作用范围、触发条件和具体工作流程。

通俗类比一下：如果 AI 是一个新入职的工程师，普通 Prompt 相当于你口头交代“帮我看一下这个页面为什么白屏”，而 Skill 相当于你递给他一份《前端问题排查手册》，里面写了“先看控制台报错、再查网络请求、然后检查组件生命周期、最后按规范输出修复方案”。效果差别显而易见。

这正好解释了为什么单纯堆 Prompt 解决不了效率问题。口头交代每次都要重新说，而且容易遗漏关键约束，Skill 则把经验固化成了可重复执行的流程。

2.3 插件、Skill 与普通 Prompt 的对比

“插件”这个词在 Claude Code 社区里，通常指的就是“被打包成 Skill 的扩展能力”。有些插件仓库会把多个 Skill 放在一个项目里，方便用户一次克隆、按需选用。因此下文提到“组合插件”，本质上就是多个 Skill 的组合使用。

2.4 还需要知道的一点：MCP 扩展

Skill 负责“教会 AI 怎么按流程干活”，而 MCP（Model Context Protocol）负责“让 AI 能连上更多外部数据源或工具”。两者可以互补。例如，你可以在 Claude Code 中挂一个内部文档服务的 MCP，让 AI 在按 Skill 流程执行时，还能主动查询最新文档。

claude mcp add team-docs --transport http --url http://your-internal-docs-service

不过 MCP 的搭建属于另一个话题，本期先以 Skill 为主线。了解这一点，是为了避免你把 Skill 和 MCP 混为一谈。

3. 环境准备与前置条件

开始写 Skill 之前，先把运行环境准备到可复现状态。以下步骤适用于常见开发系统，版本细节请以你本机实际安装为准，但思路是通用的。

3.1 安装 Node.js 与 npm

Claude Code 通过 npm 分发，因此机器上需要有 Node.js 环境。

node -v npm -v

如果输出显示版本号，说明环境正常。如果提示命令不存在，需要先安装 Node.js LTS 版本，再重新打开终端确认。

3.2 安装并登录 Claude Code

npm install -g @anthropic-ai/claude-code claude --version

安装完成后，在项目目录执行claude，首次启动通常需要登录。根据界面提示完成授权。登录成功后，可以用/status或/model命令确认当前会话使用的模型。

需要注意：Claude Code 版本迭代很快，不同版本的配置命令可能略有差异。遇到“模型名称不识别”之类的报错，优先查看官方更新日志，而不是在配置文件里乱猜模型名。

3.3 决定 Skill 放在项目级还是用户级

Claude Code 的 Skill 可以放在不同层级：

• 项目级：放在当前项目的.claude/skills/目录，仅对当前仓库生效；
• 用户级：放在用户主目录的~/.claude/skills/目录，对所有项目生效。

判断标准很简单：如果这个 Skill 是团队项目规范，放项目级，并跟随 Git 仓库共享；如果是你个人常用的通用方法，放用户级。

4. Skill 的目录结构与创建方法

4.1 目录结构

一个最小 Skill 的目录结构如下：

your-project/ ├── .claude/ │ └── skills/ │ └── frontend-codegen/ │ └── SKILL.md ├── src/ └── package.json

这里的frontend-codegen是 Skill 名称，目录名建议使用小写英文加连字符，便于跨环境识别。

4.2 SKILL.md 文件格式

SKILL.md由两部分组成：开头的 YAML 元信息和正文 Markdown 操作流程。

--- name: frontend-codegen description: 根据需求描述生成前端静态页面代码，包含 HTML、CSS 和基础交互。 allowed-tools: - Read - Write - Edit - Bash --- # 前端页面生成 Skill ## 适用场景 - 需要从产品描述快速生成可运行的静态页面 - 需要将低保真原型改写成规范的 HTML/CSS 页面 ## 工作流程 1. 读取项目根目录 docs/ 下的需求文档，提取页面区块和交互要求。 2. 确定页面资源存放目录，建议放在 src/pages/ 与 src/styles/ 下。 3. 生成 HTML 文件时，遵循项目现有的 class 命名规范。 4. 生成 CSS 文件时，使用项目已有的设计变量，不引入新颜色体系。 5. 完成后输出文件清单和启动方式。

字段解释：

在 Claude Code 中定义allowed-tools是控制 AI 行为边界的关键。例如，只让 Skill 读写代码文件，不允许执行包管理命令，就在白名单里去掉 Bash。这样能显著降低 AI 乱执行命令的风险。

4.3 在对话中触发 Skill

Skill 定义完成后，不需要安装，也不需要重启。你可以直接在 Claude Code 的对话里用自然语言触发，也可以把 Skill 名称醒目地放在任务描述中。

请使用 frontend-codegen 技能，根据 docs/todo-app.md 的需求，生成一个待办事项页面的完整实现。

如果 Skill 的 description 写得足够清晰，AI 可能会在任务匹配时自动调用。但更稳妥的做法是主动指定名称，避免它凭感觉选择错误流程。

4.4 从 GitHub 获取社区 Skill 包

社区中有不少开发者把封装好的 Skill 包推到 GitHub 上，你可以通过git clone方式获取，然后放到项目的.claude/skills/目录下。

cd your-project/.claude/skills git clone https://github.com/yourname/awesome-claude-skills.git

接着检查克隆下来的项目目录结构，只保留需要的 Skill 子目录，删除无用的说明文档和示例文件，避免干扰 Claude Code 识别。

这里要特别提醒：不要盲装来路不明的 Skill。Skill 本质是可执行指令，一个恶意 Skill 完全可能诱导 AI 读取敏感文件、执行危险命令。安装前至少要看一遍 SKILL.md 内容，确认它不会调用超出预期的工具，再放进项目目录。

5. 完整示例：用组合 Skill 完成一个小需求迭代

理论知识讲完，下面用一个完整示例演示“组合插件”的实际打开方式。为了便于理解，这里以“开发一个待办事项页面”为例。

5.1 示例需求

产品给了这样一段描述：

做一个待办事项页面，用户可以新增待办、勾选完成、删除待办。页面要适配移动端和桌面端。数据先存在本地 localStorage，后续再接入后端接口。

按照传统方式，你可能直接让 AI 一口气生成代码。但第一次生成的代码往往不符合项目规范，还要反复改。使用组合 Skill 后，流程会变成：需求澄清 -> 代码生成 -> 代码审查。

5.2 Skill A：需求澄清

.claude/skills/requirement-clarify/SKILL.md：

--- name: requirement-clarify description: 将模糊的产品描述拆解为可开发的需求点，输出功能清单和边界条件。 allowed-tools: - Read - Write --- # 需求澄清 ## 工作步骤 1. 读取用户提供的需求描述。 2. 拆解出功能点，区分 P0 必做与 P1 可延后。 3. 列出容易遗漏的边界条件：空数据、超长文案、重复提交、设备适配。 4. 将结果输出到 docs/requirements.md。

这个 Skill 的价值在于：强制 AI 在写代码前先把“要做什么”想清楚，而不是拿到描述就开工。

5.3 Skill B：前端代码生成

.claude/skills/frontend-codegen/SKILL.md：

--- name: frontend-codegen description: 根据需求文档生成前端静态页面代码，严格按照项目已有目录结构输出。 allowed-tools: - Read - Write - Edit --- # 待办页面代码生成 ## 输入 - docs/requirements.md ## 工作步骤 1. 读取 docs/requirements.md，确认功能清单。 2. 按 modules/todo/ 目录组织代码： - todo.html：页面结构 - todo.css：样式 - todo.js：交互逻辑 3. 使用原生 HTML/CSS/JS 实现，不引入框架。 4. 数据存储使用 localStorage。 5. 页面必须兼容 375px 宽度移动端和 1280px 桌面端。

这里没有给 AI 开放 Bash 权限，目的是让它专注写代码，不要在执行过程中顺手装依赖或跑脚本。

5.4 Skill C：代码审查

.claude/skills/frontend-review/SKILL.md：

--- name: frontend-review description: 检查前端代码文件的功能完整性、可维护性和常见安全风险，输出评审意见。 allowed-tools: - Read - Bash --- # 前端代码审查 ## 工作步骤 1. 读取 modules/todo/ 下所有代码文件。 2. 检查以下要点： - 是否有缺失的交互逻辑； - 是否有 XSS 风险（例如通过 innerHTML 直接插入用户输入）； - 样式是否覆盖移动端和桌面端； - 是否有重复代码； - 是否有关键函数缺少注释。 3. 输出评审结果，按阻塞、重要、建议三级分类。

注意，代码审查 Skill 允许使用 Bash，但仅用于查看文件内容和运行静态检查，不应修改代码。

5.5 组合调用

在 Claude Code 中这样发起一次完整流程：

请依次使用 requirement-clarify、frontend-codegen、frontend-review 三个技能完成待办事项页面的开发。先澄清需求，再生成代码，最后审查代码。

这种写法把责任边界划得很清楚：AI 不能跳过需求澄清直接写代码，也不能写完就宣称完成，必须经过一轮审查。审查结果如果出现阻塞问题，再回到代码生成阶段修复。

5.6 示例执行结果

执行完成后，项目中会出现：

docs/requirements.md # 需求澄清产物 modules/todo/todo.html # 页面结构 modules/todo/todo.css # 页面样式 modules/todo/todo.js # 交互逻辑

打开todo.html可以验证页面功能。如果发现 AI 在审查阶段提出了修改意见，可以继续对话要求修复。整个过程的关键收获是：需求、开发、审查这三个环节被 Skill 固化成了一条流水线，而不是依赖每次重新口头说明。

6. 把 Claude Code 接入日常 GitHub 工作流

Skill 解决的是“AI 怎么干活”，但开发工作始终绕不开团队协作。实际项目中，你大概率还要把 AI 产出的代码提交到 Git 仓库。这一章讲清楚接入时的边界，防止 AI 把你的仓库搞乱。

6.1 推荐的工作流

建议遵循以下流程：

1. 从远程仓库拉取最新代码，切出独立的功能分支；
2. 在功能分支上使用 Claude Code 和 Skill 完成开发；
3. 人工检查 diff，确认没有误改无关文件；
4. 手动完成 commit 和 push，触发代码评审；
5. 评审通过后合入主干分支。

git pull origin main git checkout -b feat/todo-skill-demo # 在 Claude Code 中完成代码生成与审查 git diff git add docs/requirements.md modules/todo git commit -m "feat: 使用组合 Skill 完成待办页面" git push origin feat/todo-skill-demo

一个比较实用的经验是：不要给 AI 开放自动 push 权限。AI 自动提交代码出现冲突或误操作之后，排查成本往往比省下的几秒高得多。

6.2 让仓库配置成为 Skill 的“项目上下文”

Claude Code 支持通过项目配置文件持久化上下文，例如在.claude/settings.json中声明项目级设置。团队可以在这里固化一些通用约束，与 Skill 配合使用。

{ "permissions": { "deny": [ "Bash(npm publish:*)", "Git(force-push:*)" ] } }

上面的示例只是演示一种思路：把危险操作默认拒绝，AI 即使被诱导也不会执行发布和强制推送。实际配置项请以你使用的版本说明为准。

6.3 Git 操作时最容易忽略的坑

• 不要创建完分支就切换上下文，Claude Code 是按目录读取上下文的，工作目录混乱会导致它改错文件；
• 提交前一定用git diff --stat查看变更文件列表，确认没有包含本地配置、密钥、临时文件；
• 如果团队有提交信息规范，建议写成项目级 Skill 的一部分，让 AI 在生成 commit message 时自动遵守。

7. 常见问题与排查方法

Skill 在使用过程中比较容易出现的问题主要有以下几类，这里整理成排查表。遇到问题时，先看现象，再按表中顺序检查。

三个比较典型的排查逻辑：

• 如果 Skill 文件没生效，先看目录层级。.claude/skills/下必须直接是 Skill 子目录，子目录里再放 SKILL.md，中间不能再多套一层无关目录；
• 如果 AI 行为不受控，优先检查 allowed-tools。大部分问题源自你给了 AI 过多工具权限，尤其是 Bash；
• 如果改完 SKILL.md 仍然无效，尝试新开一个会话。Claude Code 可能在当前会话中缓存了旧配置。

8. 最佳实践与工程建议

Skill 用起来不难，但要用得稳，还是有一些工程层面的细节需要注意。

8.1 Skill 的命名与描述要“面向触发”

SKILL.md 中的 description 不只是给人看的，也是 AI 判断“何时该用这个 Skill”的依据。描述里应该包含足够的关键词。例如“根据需求描述生成前端页面代码，包含 HTML、CSS 和基础交互”，比“前端生成工具”更容易被正确触发。

8.2 收紧权限，遵循最小授权原则

在 Skill 的 allowed-tools 中，只声明完成该任务必需的工具。特别是涉及 Bash 时，要明确 AI 可执行的命令范围。代码生成类 Skill 通常不需要 Bash，代码审查类 Skill 可以只允许只读命令。

8.3 不要把密钥和敏感信息写进 Skill

SKILL.md 是纯文本文件，通常会被提交到 Git 仓库。任何 API Key、数据库地址、登录凭证都不允许出现在里面。如果 Skill 需要引用内部信息，建议通过环境变量或专门的密钥管理工具注入，并在文档中注明“从环境变量读取”。

8.4 控制组合数量，先跑通最小闭环

“组合 Skill”不等于“装得越多越好”。每一次组合都会增加上下文复杂度和出错概率。更稳妥的落地方式是从一个最小闭环开始：一个需求澄清、一个生成、一个审查，跑通后再逐步增加新 Skill。

8.5 将 Skill 纳入版本控制

团队协作时，.claude/skills/目录应当纳入 Git 管理。这样团队所有人的 AI 行为规范保持一致，Skill 的改进也有迹可查。同时，Skill 变更应该走代码评审，不要直接往主干提交未验证的 Skill 文件。

8.6 关注版本兼容

Claude Code 迭代速度较快，Skill 的字段、权限模型和配置方式都可能变化。建议在项目文档里固定 Claude Code 版本，或者在升级前先查看变更说明，避免团队成员的本地环境版本不一致导致行为差异。

9. 总结与后续学习方向

如果这一期你只记住三句话，那就是：

1. Skill 不是锦上添花的“插件”，它是把团队经验固化给 AI 的核心载体；
2. 组合使用 Skill 时，要按“澄清 -> 生成 -> 审查”的流程拆解任务，而不是让 AI 一把梭；
3. 所有让 AI 自动执行的操作都要收紧权限，尤其是 Git 提交和 Bash 命令。

下一步建议找一个真实的小需求，先手动创建两个 Skill 跑通流程，再逐步扩展。你可以在 GitHub 上搜索社区维护的 Skill 集合，但先学会读懂 SKILL.md 的格式，再决定要不要引入。等你熟悉了这类结构，也可以把团队的接口规范、部署流程、代码审查清单逐步沉淀成 Skill，这才是 Claude Code 真正值得投入时间的方向。