企业官网建设流程全解析

如果把 Claude Code、Skills、MCP 这三样东西拆开看，每一样单独拿出来都不算复杂；可一旦把它们组合进同一条开发工作流，我的日常开发方式确实被改写了。最早我是"裸用"Claude Code 的——在终端里开个对话，让它改点代码、写个函数，用起来跟高端聊天窗口差不多，新鲜感过了就开始失望。真正让我改变的是两件事：给 Claude Code 配上了 Skills，又把 MCP 服务接进了项目。前者像给模型一份作业指导书，后者像给模型装上手和眼睛。这篇文章就把我从"裸用"到工程化的完整过程讲透，包括这三者分别解决什么问题、怎么安装怎么配置、怎么写自己的 Skill、怎么按项目选 MCP，以及过程中踩过的那些坑。

1. 裸用 Claude Code 的三条翻车链路，以及我现在怎么回头看

1.1 裸用到底意味着什么

我先把"裸用"这个词定义清楚，免得后面大家对不齐。所谓裸用，就是只把 Claude Code 当作一个终端里的对话助手：你问一句，它答一句，偶尔让它改个文件、跑个命令。除此之外，不配任何 Skills，不接任何 MCP 服务，也没有项目级的规则文件。听起来好像也够用？我最初就是这么想的，一个能看懂代码、能写代码的对话窗口，已经比绝大多数工具强了。

但问题恰恰出在"没有上下文约束"上。一个刚装好的 Claude Code，面对你的仓库时，它并不知道：这个项目用什么框架、依赖了哪些包、版本策略是什么；团队的代码风格、目录规范、命名约定是什么；改动之后要不要跑测试、跑 lint、更新文档；哪些目录能碰、哪些文件不能碰。于是它只能靠你的对话去猜，猜错了就瞎改，改完了你还要人肉收拾。这就是裸用的本质——你给了一个很聪明的模型，却没有给它任何"工作环境说明"。

1.2 三条最有代表性的翻车链路

我这三个月里的翻车，总结下来可以压缩成三条链路。

第一条：改代码不跑验证。我让 Claude Code 重构一个模块，它很痛快地改完了，然后告诉我"改好了"。本地编译、单测、lint 全没做。我人在开会，等合并完 CI 一片红，同事过来问我怎么回事。后来我才意识到，它不是不想跑，是它压根不知道自己应该跑——我不会每次都想起来说"改完记得跑测试"。

第二条：文件落地完全无视目录约定。项目里明明有src/utils和src/components，它会把工具函数塞到组件目录下面，还自己新建了一层嵌套。原因是它只看到了文件系统快照，没看到团队约定，对"应该把代码放哪里"这件事，几乎没有任何判断依据。

第三条：长对话"失忆"。聊到第 40 轮，它开始忘记前面定的技术方案。你以为它记住了，实际上上下文已经被大量代码片段挤爆了，早期的关键决策早就被截断。于是它后面给的方案，经常推翻自己前面说的话。

这三条链路的根因是同一个：模型有通用能力，但没有专用上下文。裸用相当于把一个大模型直接空降到你的仓库里，既不告诉它纪律在哪里，也不给它任何"干活用的手"。它当然会自由发挥。

1.3 我最终想明白了：模型不缺能力，缺的是"作业指导书"和"手"

后来我翻了很多资料，包括官方对 Agent Skills 的说明，才慢慢把这件事想清楚：模型本身不缺推理和编码能力，缺的是两样东西——行为约束和工具接口。

行为约束就是 Skills 要做的事。Agent Skills 这套机制在 2025 年推出后，解决的是"让模型在特定任务里按标准流程执行"的问题。它不是简单地把一大段提示词塞进上下文，而是让模型在遇到某个触发场景时，主动去读一份"作业指导书"，按里面的步骤干活。

工具接口就是 MCP 要做的事。MCP（Model Context Protocol）把模型和外部工具通过一个标准协议接起来，让 Claude Code 能操作文件、浏览器、数据库、调试器、甚至工业软件。没有 MCP 的时候，模型只有一张嘴；接上 MCP，它才有了手和眼。顺带说一句，Claude Code 本身允许模型在受控范围内执行终端命令——前提是你在设置里开了对应权限，这一点很多人不知道。但裸用状态下，命令执行往往是"随机尝试"，配合 Skills 的流程约束之后，它才会变成"按步骤执行"，命令才开始有了明确目的。

这两样东西是互补的：Skills 管"怎么做"，MCP 管"能做什么"。不理解这一点，后面配置再多工具，都是堆砌。

2. Skills：给模型配一份看得懂的作业指导书

2.1 先纠正一个误解：Skills 不是把提示词变长

很多人第一次接触 Skills，会以为它就是把 system prompt 写得更长、更详细。这个理解有偏差。Skills 在 Claude Code 里是一种结构化的目录：核心是SKILL.md文件，里面用 YAML frontmatter 声明 name 和 description，正文写具体执行步骤；旁边还可以挂scripts目录放可执行脚本，挂resources目录放模板和示例。

关键设计在于"触发-加载"机制。Claude Code 在跑任务时，会根据任务描述去匹配 Skills 的 description，匹配到了，才去读对应的 SKILL.md。也就是说，Skills 不是每轮对话都在上下文里的常驻大段文本，而是按需加载的知识包。这样既省上下文窗口，又对路——你让它写代码的时候，它不会把"写文档"的 Skill 先读一遍。对比一下把一大段提示词贴进 system prompt 的做法，区别很明显：提示词是"塞给它的"，Skill 是"它自己根据需要去读的"，后者不需要每轮都占用宝贵的上下文空间，维护起来也是独立文件，不用动整个项目的提示词配置。

2.2 官方生态和社区资源：从 superpower skills 到 codex skills

我现在搭的这套 Skill 体系，一半来自社区，一半自己写的。先说你能直接拿来用的。GitHub 上搜 "awesome claude skills"，能找到不少聚合仓库；官方文档也维护着一份 Skills 指南，讲怎么写、怎么挂载、怎么在项目里发现可用技能（对应的命令类似find skills，各家客户端叫法略有差异，思路一致）。社区里流传比较广的是 Superpower Skills 系列，它把编码、调试、需求拆解、文档撰写这类高频场景拆成了一组细分的 Skill 包，每个包都带独立目录和说明，装完就能感觉到 Claude Code 的"处事风格"明显变得更稳。

这里要提一个趋势：Skills 正在跨工具扩散。OpenAI 的 Codex 也有了自己的 skills 体系，GitHub 上有很多 skills 模板可以直接迁移——因为核心结构都差不多，SKILL.md + scripts + resources 这套骨架已经成了事实标准。所以我现在写一个 Skill，会刻意写成"可迁移"的：只依赖通用目录结构，不写死 Claude Code 专属配置。这样哪天 Codex 也接进来了，同一份 skill 基本不用改。至于 skills 下载平台，除了 GitHub 搜索和 awesome 聚合仓库，不少开源社区站点也做了可视化浏览，甚至有一些客户端（像 Reasonix）提供了更友好的 skills 安装入口，逻辑都类似：找到仓库、装进本地的 skills 目录、在配置里启用。

2.3 实测前端项目：配上 Skills 之后，代码质量的变化

我拿自己一个 React 项目做了对照。没配 Skills 之前，让 Claude Code 加一个错误边界组件，它会直接开写，完全不看项目里有没有现成的错误上报组件、有没有封装的 ErrorBoundary 基类。配了一套前端开发 Skill（包含需求确认、组件设计、编码自测三个步骤）之后，同样的任务，它的动作变成了：先读 package.json 确认 React 版本，再扫描 components 目录看有没有可复用的基类，然后才动手写，写完自动跑 lint 和 build。

说实话，第一次看这个流程完整跑下来，我还是有点惊讶的。整个过程我没有输入一句额外指令，它自己就按 Skill 里的流程把上下文搜集齐了。这才是 Skills 的价值——它不是让模型变聪明，是让模型在特定场景里的"职业习惯"变好。

同类的还有一堆现成好用的：code review 类的 Skill、写 commit message 的 Skill、写论文的 Skill（社区里叫 codex 写论文的 skills，本质上 Claude Code 也能用）、需求拆分的 Skill 等等。装 Skills 之前最好想清楚一件事：高频场景，优先配。低频场景，配了反而是负担，因为技能列表一长，模型反而可能在关键时刻选错包。

3. MCP：打开模型能力边界的那扇门

3.1 用 USB-C 的类比理解 MCP 协议

MCP 全称 Model Context Protocol，是一条公开协议。我平时跟同事解释它，喜欢用 USB-C 做类比：以前每家手机厂商都有自己的充电口，你要带一堆线；USB-C 统一之后，一根线通吃所有设备。MCP 做的就是类似的事——它把"模型要调用外部工具"这件事标准化了。

在这个协议里，有三个角色：MCP Server 负责把某个能力包装成标准接口，比如文件系统 Server、浏览器 Server；MCP Client 是发起请求的一方，Claude Code 就是这个角色；协议本身则通过一条基于 JSON-RPC 的通道完成工具发现、调用和资源读取。因为有了这套协议，Claude Code 不需要为每个外部工具写专属集成代码。谁想接什么能力，就自己写一个 MCP Server，模型侧能自动发现。这也是为什么过去一年里 MCP 生态能爆发——各种垂直软件都开始自己做 MCP 服务，而不是等 AI 厂商来适配。

3.2 我常用/实测过的 MCP Server 清单

下面的列表是我真实在项目里接入、并且觉得值得写出来的：

这里得提醒一句：MCP Server 的质量差异非常大。官方维护的几个比较稳，社区第三方 Server 我一般先看 README、看 Star 数、看最近有没有更新，再决定要不要装进项目。毕竟 MCP Server 拿到的权限通常是真权限，瞎装等于把仓库钥匙交出去。授权问题在上手时最容易卡住。以 Figma 为例，你需要先在 Figma 开发者平台生成一个 Personal Access Token，然后在 MCP Server 的配置里把它作为环境变量填进去，模型才能替你读设计稿。蓝湖 MCP 也是类似的思路——先拿 token，再配环境变量。这一步卡住的大多是 token 权限范围没选对，不是协议的问题。

3.3 一个值得单独拿出来说的需求：把模型输出流式写到文件

很多人以为 MCP 是给"重活"用的，其实一些看似不起眼的小需求，MCP 也解决得很香。比如"把模型输出的内容流式写到文件"。

以前我让 Claude Code 生成一份长文档，它经常在终端里磨磨蹭蹭输出，我又要手动复制粘到 Markdown 文件里，长文档复制还容易断行。后来我发现可以直接挂一个输出类型的 MCP Server，让它把内容按增量流式写入指定文件，生成逻辑和落盘逻辑分离。这个需求听起来小，但在做批量内容生成、代码仓库文档化这类任务时，体验差异非常大。

我也见过有人在 Cherry Studio 这类客户端里做同样的流式输出落盘，原理大同小异——都是借助 MCP 通道把模型输出转成文件操作。核心就一句话：只要模型和文件系统之间有了标准的工具通道，很多"复制粘贴搬运工"的工作就可以取消了。

4. 把环境搭对：安装、配置与多模型切换的完整实操

4.1 安装和 VSCode 集成的正确姿势

Claude Code 的安装其实不难。我用的方案是 npm 全局安装：

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

装完在终端里执行claude就能进入交互界面。升级也简单，Claude Code 支持在线升级，命令行里跑一次claude update就能同步到最新版本。另外官方也提供了一键安装脚本，适合不想碰 npm 的情况，不过我个人还是习惯 npm，因为后续版本回退更直观。

在 VSCode 里配合使用，是另一个高频选择。安装好 Claude Code 之后，可以直接把它当成一个终端面板拉起来，也可以安装官方/社区提供的扩展，在编辑器里跑命令。我自己的偏好是：VSCode 只负责代码编辑和查看 diff，Claude Code 跑在独立终端，两边通过文件系统同步。这样分工清晰，Claude Code 改完文件我立刻能在编辑器里看到变化，又不至于被它的每一步操作打断。

有一件事我踩过坑：在 Ubuntu 等 Linux 环境上，如果 Node.js 版本太老，npm 全局安装容易失败或者跑起来报错。建议先把 Node 升到 18 以上再装，省得后面排错。

4.2 用 CC Switch 管理多套模型配置：DeepSeek/Qwen/GLM

这里先纠正一个容易混的概念。Claude Code 官方默认接的是 Anthropic 的模型，但它的接口地址是可以覆盖的。很多第三方服务提供了兼容的 API 端点，于是社区里出现了像 CC Switch 这样的配置管理工具，用来在多个模型供应商之间快速切换，而不需要手动改环境变量。

我用 CC Switch 接过的模型包括 DeepSeek 的 V4、阿里的 Qwen、智谱的 GLM。切换之后，Claude Code 的使用体验几乎不变，但成本和可用性有了更多选择。尤其是当官方入口在高负载时段不稳定时，切到第三方端点能救急。

实际配置上，CC Switch 本质上是把你的"供应商列表"保存成配置，切换时自动重写相关的环境变量或配置文件。它只是一个标准的配置管理器。我更建议你在项目团队里使用时，把不同供应商的配置统一写进一份说明文档，谁要用哪家，跑一下切换命令就行，别各自乱配。

4.3 本地模型接入：LM Studio 当 Claude Code 的推理后端

还有一个很实用的玩法：让 Claude Code 调用本地模型。我用的是 LM Studio，加上一个适配层的方案。

这里有个技术细节要说明：Claude Code 期望的是 Anthropic 格式的请求，而 LM Studio 这类本地推理工具通常提供的是 OpenAI 兼容接口。要让两端对上，需要中间加一层转换，把 Anthropic 格式翻译成 OpenAI 格式。CC Switch 或者 claude-code-router 这类工具都在做这件事。

大概的操作路径是：在 LM Studio 里加载一个模型，并启动本地服务（默认端口通常是 1234）；在适配工具里把模型供应商指向http://localhost:1234/v1；切到本地模型作为当前供应商；然后在 Claude Code 里正常发指令。

本地模型的好处是数据不出机器，适合处理敏感代码；缺点是能力和速度都弱于官方模型，我一般只拿它做轻量任务和离线演示。要是你的主力场景是大量重构和代码生成，本地模型暂时还顶不上。

5. 手写一个自己的 Skill：从 SKILL.md 到 scripts

5.1 一个 Skill 文件夹里到底该放什么

写自己 Skill 的念头，大部分人都是在"配了别人写的但总感觉不对味"之后冒出来的。别急，先从目录结构开始。

一个标准 Skill 目录长这样：

code-review-skill/ ├── SKILL.md ├── scripts/ │ ├── collect_changes.py │ └── run_review.py └── resources/ └── review-checklist.md

SKILL.md是入口，模型靠它判断触发场景和执行流程；scripts/放实际操作脚本，模型可以调用它们去收集信息、执行分析；resources/放辅助资料，比如检查清单、示例模板，模型在需要时可以读取。这套结构不是官方强制的，但现在已经成了事实标准，跨工具迁移都方便。

我见过不少人图省事，把所有东西都塞进SKILL.md，不要脚本也不要资源文件。短期能用，长期维护会很难受——模型上下文里塞不下那么长的文字，真要执行复杂逻辑时，又没有脚本可以调。

5.2 写 SKILL.md 的顺序：先定义触发条件，再设计工作流

写 Skill 最容易犯的错误是：一上来就写执行步骤。我建议反过来，先把触发条件写清楚。

触发条件写在 frontmatter 的description里。这句话非常重要，因为模型是靠它来判断"当前任务要不要加载这个 Skill"。写得太泛，模型什么都想用，反而干扰；写得太窄，模型又压根发现不了它。比如我写代码审查 Skill，description 会写成：当用户要求进行代码审查、提交信息检查、代码质量评估、或 review PR 时使用……第一时间把所有会触发这个场景的用户表达法列进去。

触发条件定好后，再设计工作流。我的习惯是分成 3～5 个阶段，每个阶段明确三件事：输入是什么、采取什么动作、产出什么校验物。拿代码审查 Skill 举例，SKILL.md 的正文骨架大概是：

--- name: code-review description: 当用户要求进行代码审查、提交信息检查、代码质量评估、或 review PR 时使用本技能。 --- # Code Review ## 步骤 1：收集变更 运行 scripts/collect_changes.py 获取 git diff，列出涉及文件。 ## 步骤 2：定位风险 按依赖变更、逻辑分支、异常处理三个维度扫描变更内容。 ## 步骤 3：输出报告 把问题按严重级别分类，每条给出修改建议，存为 review-report.md。

把这个结构写进 SKILL.md 后，实测下来 Claude Code 在审查时的动作明显更有条理。

5.3 用 Agent 自己来"折磨"你的 Skill

写好 Skill 之后，我强烈建议做一轮"自我折磨"测试。方法很简单：准备 5～10 个不同形态的任务，输入给已经配置好的 Claude Code，观察它有没有正确加载这个 Skill、加载后有没有按 SKILL.md 的流程执行、中途有没有卡住或者跑偏。

这里分享一个我复盘出来的经验：Skill 的 description 需要根据测试结果反复调措辞。我第一次写的代码审查 Skill，用"帮我看看最近的改动有没有问题"去触发，结果模型没有加载它，直接当普通问答处理了。后来我把 description 改得更直接、更贴近用户原话，再测，就能稳定触发了。

社区里管这一类测试叫 agent skills testing，GitHub 上也有对应的测试工具和框架。我自己的做法更朴素：做一个固定的评测任务集，每次改了 Skill 就跑一遍对比。这套回归思路对维护多个 Skill 特别有用，因为改了一个 Skill，很可能会影响其它 Skill 的触发率。有一类社区习惯把 Skill 写得特别"自然语言化"，让流程尽可能像人类的工作习惯，这一类常被叫做 nature skills——我自己的体会是，自然语言化的 Skill 更容易被模型理解，但后期调试也会更费嘴皮子，得平衡。

6. 项目级选型与工程化落地：按领域选 MCP，按团队沉淀 Skills

6.1 不同领域怎么搭 MCP + Skills

到最后一步，你会发现最核心的问题不是"哪个工具好"，而是"我的项目该上什么"。我整理了一个按领域划分的对应表，都是我实际接触过或看到真实案例的：

这张表的核心逻辑是：先看这个领域的"高频操作"是什么，再去找能把该操作标准化的 MCP Server；Skills 则负责把该领域的工作流程写成模型能照做的步骤。两者配合，才叫工程化；只堆工具，不配流程，还不如裸用。

6.2 不是所有场景都适合上 MCP

我必须泼一盆冷水：MCP 不是越多越好。

原因有三：权限风险。每个 MCP Server 都意味着额外的权限通道。接了一个第三方 Server，等于让模型多了一处可以操作真实环境的入口。没有经过审核的 Server，千万不要往正式项目里塞。维护成本。Server 要装、要配置、要升级，有些还依赖特定版本的外部软件。接了 10 个 Server，光维护就够喝一壶。延迟和不确定性。调用外部工具意味着要等待、要处理失败，会让整个任务链路变得脆弱。

我给自己的底线是：一个工作流闭环里，确实缺哪一环，才补哪一类的 MCP Server。宁可少接，不要瞎接。如果你在 Codex 里遇到"找不到 MCP"这类问题，先查配置路径和权限，别急着换工具——大多数时候是路径或环境变量的问题，不是协议的问题。

6.3 从个人经验到团队资产：让新成员一键上手

工程化的最后一步，是把个人经验沉淀成团队可用资产。我给团队做这件事的三个动作，可以参考。

第一，在项目里维护统一目录.claude/skills，把团队的代码规范、审查流程、文档模板全翻译成 Skill 文件。这东西跟 README 一样，是项目的资产，跟着仓库走。

第二，把 MCP Server 的清单和配置说明写成一份mcp-setup.md，标注哪些是官方维护的、哪些是社区方案、各自需要什么权限。新成员照着文档跑一遍，半小时内就能把环境拉齐。

第三，把"踩坑记录"回填到 Skill 里。比如我们发现"改完代码必须跑一遍 lint + test"是团队铁律，就把这步写进所有编码类 Skill 的末尾。等于是把组织经验固化进了 Skill 本身。

我个人在做了这套工程化改造之后，最直观的感受是：Claude Code 从一个"我不断纠偏的工具"，变成了一个"大多数时候不需要我盯着"的协作者。Skills 让它懂规矩，MCP 让它有手有脚，而工程化的过程，不过是把这两样东西变成项目基础设施的一部分。

如果你现在还在裸用，我建议从最小的闭环开始：先找一个最高频的场景写一个 Skill，再挂一个最需要的 MCP Server，跑通一个完整任务。等这个闭环稳定了，再谈扩展。工程化不是一步到位的，是长出来的。