企业官网建设流程全解析

1. 从“裸用”到工程化的转变起点

先说个直观的感受。刚接触 Claude Code 的时候，我基本是把它当成一个“高级版终端助手”在用：写代码遇到问题就丢给它，让它改 bug、写测试、补注释。用了一阵子后，效率确实有提升，但总觉得差点意思——每次开新项目，都要把同样的背景说明、同样的代码规范、同样的工具链配置重新解释一遍，Claude 就像个记忆力极差的实习生，换个会话就把什么都忘了。

后来我做了两件事，整个工作流彻底变了个样：一是给 Claude Code 装上了Skills，二是接入了MCP服务。这两个东西合在一起，才真正让我感觉不是在“用”一个 AI，而是在“搭建”一套属于自己的 AI 开发流水线。

如果你也正在经历从“裸用”到“工程化”的这个阶段，这篇文章应该能给你一些参考。我会把 Skills 和 MCP 的原理、选购思路、落地方案、踩坑记录都拆开讲一遍，尽量少说虚的，多给能直接照做的内容。

2. Skills 到底是什么，为什么它比“提示词模板”高一个维度

2.1 从“每次重复解释”到“一次性定义能力”

很多人第一次听说 Skills 的时候，会下意识觉得：“这不就是预设提示词吗？”我在最开始也是这么理解的，直到我用过之后才知道区别在哪。

预设提示词本质上是“对话前的一次性上下文注入”。它的作用范围仅限于当前会话，换个会话就要重新粘贴。而Skills 是“可复用的能力模块”，它定义的是“Claude 在特定场景下应该怎么做”的一套行为规范，包括任务拆解方式、工具调用规则、输出格式约定、质量检查清单等等。用一次之后，这个能力就被“安装”到了 Claude 的运行环境中，之后无论开多少个新会话，它都记得自己具备这项能力。

我举个例子。我平时用 Claude 写前端组件，以前每次都要说“请按照我的项目规范，使用 TypeScript，样式用 CSS Modules，组件要支持无障碍访问”。这些话加起来快两百字，每次新会话都要复制一遍。后来我把它写成一个frontend-component-developer的 Skill，里面不仅包含了这些约束，还把组件的验收标准、常见的代码组织方式、首选依赖都定义好了。现在只要在对话里说“用 frontend-component-developer 这个技能帮我写一个下拉组件”，它就能自动进入“角色状态”，输出的代码直接就能跑通项目里的 lint 规则。

2.2 和 MCP 的关系：一个是“行为准则”，一个是“手脚延伸”

再强调一下 Skills 和 MCP 的区别，因为很多人会把这两个概念搞混。

**MCP（Model Context Protocol）**解决的是“AI 能触达什么”的问题。它的本质是一个开放协议，让 Claude 能通过标准化的接口去读取本地文件、查询数据库、调用外部 API、操作浏览器，甚至控制设计软件。如果说 Claude 是个大脑，MCP 就是给它接入四肢的通讯协议——没有它，大脑再聪明也够不到外部世界的工具。

Skills解决的则是“AI 该如何思考和组织行为”的问题。它定义的是工作流程、思维框架和行为约束。有了 Skills，Claude 就像是接受过专业训练的员工——它知道遇到任务该怎么拆解、按什么顺序执行、产出物应该长什么样、怎么样算达标。

打个比方：MCP 是给 Claude 装上了“手和眼睛”，Skill 则是给这个“手和眼睛”配了一本 SOP 手册。没有 MCP，Claude 的能力边界受限；没有 Skills，Claude 即使能接触到工具，也不知道怎么用得高效、用得规范。

这两者的搭配才是工程化的关键。我当时就是先装了 Skills，让 Claude 知道“写前端组件应该遵循什么标准”，又装了对应的 MCP 服务，让它能直接读取项目里的设计稿文件、组件库文档、接口定义。这样它不仅能按规范思考，还能直接拿真实数据工作，产出的准确率直接上了一个台阶。

2.3 Skills 市场里值得关注的几个方向

目前社区里已经有不少现成的 Skills 可以下载使用，我逛了一圈之后发现真正有价值的其实集中在这么几类里面：

• 代码审查类：这类 Skill 定义了代码审查的检查点，比如安全性、性能、可维护性、测试覆盖度等维度，能让 Claude 在提交代码前自动跑一遍预审，省去很多低级问题。
• 架构设计类：针对特定项目框架（比如 React、Vue、Spring Boot）生成项目骨架、目录结构建议和模块划分方案，适合项目启动阶段用。
• 文档生成类：把散乱的注释、 API 定义、变更记录自动整理成结构化的项目文档，对维护老项目特别实用。
• 测试生成类：根据业务逻辑自动生成单元测试和集成测试用例，还能根据覆盖率报告补齐缺口。

我的建议是，刚开始不用贪多，挑一两个跟日常开发最相关的就够了。Skills 这东西不是装得越多越好，装多了反而会让 Claude 在“该用哪个技能”这件事上产生混乱。我自己的经验是先装一个代码审查类的，再装一个跟项目框架强相关的开发类，用顺了之后再逐步扩展。

3. MCP 的实战接入：从环境配置到场景落地

3.1 配置的前置条件：先理清你的运行环境

在聊具体方案之前，先把前置条件交代清楚。这里有一个很多新手会忽略的问题：Claude Code 的环境兼容性。装不同版本的 Claude Code，MCP 的配置方式会有差异；有些功能只在特定版本上开放，旧版本可能根本识别不到你配置的 MCP 服务。

我个人的实际经验是：先确认 Claude Code 版本，再动 MCP 的配置。如果你在自己的环境里运行claude --version，发现版本比较旧，建议先升级到最新版。新版对 MCP 的支持更完整，包括 SSE 传输、流式输出这些能力都有改进。

另外，如果你的 Claude Code 用的是第三方 API（比如通过 CC Switch 这类工具接入其他模型服务商），有些 MCP 功能可能不受支持。这跟 MCP 协议的实现程度有关系，不同的模型服务商对工具调用的支持力度不同。我试过在本地模型（比如通过 LM Studio 跑开源模型）上挂 MCP，结果是：模型能收到工具定义，但实际调用经常超时或返回格式错误。后来我干脆把“需要通过 MCP 来操作”的任务都保留在云端 Claude Code 环境里执行，把本地区域留给纯代码生成和审查这类任务。

3.2 三种主流 MCP 配置方案的对比

MCP 服务接入的方式很多，我这个项目里实际尝试过三种，各有优劣，直接说结论：

我实际的建议是：如果你只是在自己开发的这台电脑上用，优先选 stdio 模式。它的稳定性和易用性最好，出现问题的概率最低。当你有跨设备需求、或者想让团队共享一套 MCP 服务的时候，再升级到 SSE 模式。

3.3 完整示例：把本地文件系统接入 Claude Code

我用一个最简单的例子来演示配置过程，目标是让 Claude 能直接读取指定目录下的文件内容。

配置命令如下：

claude mcp add filesystem -- stdio npx -y @modelcontextprotocol/server-filesystem /Users/yourname/projects

如果你不想用命令行配置，也可以直接改配置文件。Claude Code 的配置文件位置通常在~/.claude.json，打开之后找到mcpServers字段，手动添加即可。

加入之后，在 Claude Code 里跑一下/mcp命令，就能看到当前已加载的 MCP 服务状态。如果显示为 connected，说明接入了成功。之后你让 Claude 读某个文件，它就会直接调用这个 filesystem 工具去操作，而不再依赖对话上下文里的“历史记忆”。

3.4 接入 IDE 类 MCP 的场景扩展

我后来又把 MCP 接入了几个开发场景，效果都挺明显的，挑两个有代表性的讲一下。

一个是接入Figma MCP。前端开发最头痛的事情就是“设计稿和代码不对齐”。我以前是人工对着设计稿量尺寸、取色值，费时费力还容易出错。接入 Figma 的 MCP 服务之后，Claude 可以直接读取设计稿中的组件信息、样式参数和布局结构，生成出来的代码基本不用做大的调整。

另一个是接入蓝湖 MCP。蓝湖是很多团队做设计交付的常用工具，接入之后 Claude 可以直接获取蓝湖上的标注信息、切图资源和交互备注。这一步省掉了我大量来回切换工具的时间消耗。

其实很多流行的设计协作工具都已经支持 MCP 或者有相应的社区实现，关键在于你要去“找”。找 MCP 服务有一个固定的思路：搜索 “工具名 + MCP”，大概率能找到官方或社区封装的实现，比如Altium Designer AI 接口 MCP、IDA MCP、x32dbg MCP这些都是社区里已有的现成方案。

4. 工程化落地的关键拼图：把 Skills 和 MCP 串成完整流水线

4.1 先搭“骨架”：用 Skill 定义流程，用 MCP 提供数据

工程化改造这件事，最难的不是搞懂单个工具怎么用，而是怎么把零散的“能力碎片”组合成一条真正能跑的流水线。我自己摸索下来，核心其实是四个字：先定标准，再接数据。

标准指的是“流程规范”，需要用 Skills 来定义。比如我有一个 “新功能开发” 的 Skill，它的流程定义是：

1. 分析需求描述，拆解出功能点清单
2. 定位现有代码中受影响的所有模块
3. 读取涉及模块的代码结构与核心逻辑
4. 设计实现方案，列出改动文件清单
5. 按依赖顺序依次实现，每完成一个模块就自测
6. 输出变更摘要和受影响范围说明书

在定义这套流程之前，Claude 写代码基本上是“点对点”：你说什么它写什么，没有任何任务理解、影响面分析的动作。有了这套 Skill 之后，它就变成了一个“正规军”：接到任务先做分析，绕着代码库做完整调研，然后才动手写代码。虽然单次任务的速度慢了一点点，但产出物质量、代码一致性和后期返工率，都明显变好。

标准定好之后，剩下就是“数据供给”。这就是 MCP 的主场：我把项目的接口文档（通过一个自定义 MCP 服务暴露）、设计稿信息（通过 Figma MCP）、数据库 Schema（通过一个数据库 MCP）都接入进去，Claude 在按 Skill 流程执行任务的过程中，不需要我手动粘贴任何上下文，需要什么直接调用工具获取。

4.2 单条流水线的执行细节

我拿一个实际经历过的任务来完整复盘：给一个后台管理系统新增“角色权限配置”页面。

如果没有 Skills 和 MCP，我过去的做法是：在对话里把需求告诉 Claude → 把相关的代码文件内容粘贴进去 → 让它改 → 改完再去翻查组件库的规范逐个核对 → 发现问题再回头改。

有了 Skills 和 MCP 之后，流程变成了：

• 我在对话里只输入需求：“用 frontend-admin-developer 这个 Skill 给角色权限页面的 UI 增加模块。”
• Claude 自动读取了这个 Skill 里的工作流程，先分析了需求，列出了“权限配置页需要支持的交互逻辑”“当前管理系统的前端架构约束”“组件库中可复用的基础组件”这三个待确认的信息。
• 随后它通过 MCP 调用项目文件系统，自动识别出权限页面相关的目录和文件，又通过数据库 MCP 查看了后台的权限表结构和已有的接口定义。
• 在确认信息完整后，它按照 Skill 里定义的组件编写规范，生成了完整实现代码，并同步输出了对这一改动影响的文件清单和潜在风险点。

整个过程中，我只说了第一句话和最后一句“确认可以提交”。中间大量繁琐的“上下文搬运”工作，全部由这套机制自动完成了。

4.3 可复用的工程化实践清单

如果你也想把自己的 AI 开发工作流从“裸用”往“工程化”方向推，我总结的这几条建议是可以直接照搬的：

1. 从项目骨架开始沉淀 Skill。每个项目团队都有自己的代码规范、目录组织方式和提交规范，把这些沉淀成一个 Skill，让 Claude 在项目里默认遵守。
2. 按“开发流程”而不是“单一动作”来设计 Skill。比如不要只写一个“生成接口调用代码”的 Skill，而要写一个“新增一个数据请求闭环”的完整流程。
3. MCP 优先接入“直接影响产出准确性”的数据源。比如你们项目的真实接口定义、数据库 Schema、设计稿图标信息，这些数据是 AI 生成代码的“参照物”，有和没有差别巨大。
4. 建立工具的“默认组合”而不是“大杂烩”。给不同的任务类型搭配固定的 MCP + Skill 组合，比如“前端开发 = 代码规范 Skill + 项目文件系统 MCP + 设计稿 MCP”，不要每次都临时翻找工具。

5. 实操过程中的高频问题与排查实录

5.1 Skill 装了但 Claude 不调用，怎么办？

这是我被问过最多的问题。Skill 装了，也确认出现在列表里，但让它执行任务的时候，Claude 就是不按照 Skill 定义的行为来。

这个问题我排查了几次之后发现，根源多半出在Skill 的触发表述上。Claude 不是每次都会主动去检索所有已安装的 Skills，它需要明确的信号才会“进入技能状态”。

解决方案其实很直接：对话中直接用“使用 XX 技能”“按照 XX 技能的定义来做”这类引导句式。更稳妥的做法是，在你的 Skill 内容里定义一个“触发条件”字段或者“核心适用场景”说明，让 Claude 能通过上下文的匹配更大概率地命中正确的 Skill。

5.2 MCP 配置了但显示连接失败

这类问题我踩过不少次，常见的就三种原因：

• 启动命令写错了。stdio 模式下的启动命令如果带了不能被正确解析的参数，服务就会起不来。
• 依赖缺失。有些 MCP 服务依赖 node 的特定版本，或者需要额外的环境变量，少了就加载失败。
• 网络受限。远程 SSE 模式的 MCP 服务，如果目标是国内不可直连的地址，连接大概率会直接失败。

我的排查习惯是三步走：先看claude mcp list确认配置信息，再用/mcp查看运行状态，最后手动在终端里运行一遍当时的启动命令，看有没有报错信息输出。这个操作能解决掉 90% 的问题。

5.3 工具调用看起来“生效了”但输出不可用

还有一种微妙的情况：MCP 工具确实被调用了，返回的数据也拿到了，但 Claude 最后的输出结果不可用。我之前接数据库 MCP 的时候就遇到过，它把整个表结构读出来之后，生成的代码里居然用了不存在的字段。

后来分析发现，问题出在Skill 里面对“如何处理数据源”的约束不够。也就是说，Claude 拿到了数据，但不知道该怎么用这些数据，于是它按照自己“默认的理解”来写代码，而不是按照你项目的真实情况。

解决办法也很简单：在 Skill 的编写规范里补充一条“在进行代码生成前，先核对数据源字段定义，所有输出的字段必须来自真实存在的数据定义”这样的约束条件。你的 Skill 让 Claude 与真实数据的绑定越紧密，输出的可用性就越高。

5.4 团队协作时的“环境一致性问题”

如果你不是一个人在折腾，而是要把这套工作流复制给整个团队，那么大概率会遇到环境不一致的问题。我这边实际处理过的情况是：同事的电脑上装了旧版本的 Claude Code，导致同一个 Skill 在他的环境里表现不一致；还有人完全没配置 MCP，同一个任务在他们的环境里就是纯靠对话硬猜。

我的建议是做一个团队内部的环境初始化文档，里面明确写出三个东西：一体化的配置步骤（从 Claude Code 版本、到 Skills 安装、到 MCP 服务启动命令）、一个最小可用的验证用例、以及每个人各自需要修改的个性化参数（比如项目路径、数据库连接配置）。这样新同事加入的时候，照着文档走一遍，五分钟内就能把整套“工程化”能力跑起来。

6. 关于 Skill 开发的一点个人心得

用了一段时间现成的 Skills 之后，我开始尝试自己开发一些定制 Skill。这块目前社区里讨论得很多，但大部分内容都集中在“怎么写一个能跑的 Skill”这个层面。我个人觉得，比“怎么写”更重要的是“怎么设计”。

一个真正好用的 Skill，需要做到三件事：有明确的职责边界、有可执行的行为步骤、有可量化的输出标准。不要贪大求全，一个 Skill 里面塞太多内容，反而让 Claude 在执行时失去焦点。我自己的经验是，一个 Skill 最好只解决一个类型的问题，比如“代码审查”“生成接口联调用例”“输出变更影响分析”各做一个独立的 Skill，使用起来最顺手。

也不建议过于追求“通用”。有些人的理想是写一个能应对所有场景的“超级 Skill”，结果做出来之后发现质量和直接让 Claude 自由发挥差不多。真正有价值的，往往是那些和你实际项目绑定得很紧、沉淀了大量项目特定经验的 Skill。

7. 一点关于工作流的总结性感悟

最后说点心里话。做了这套工程化改造之后，我最大的感受并不是“AI 写代码的速度变快了”，而是“我对 AI 产出的信任度变高了”。

裸用时代的最大痛点其实不是效率，而是不确定性。你永远不知道它这一轮会输出什么质量的代码，也不知道它会不会遗漏某个关键的上下文。这种不确定性导致你每次都要完整审查它的输出，审查成本一高，AI 的价值就被稀释了。

Skills + MCP 这套组合解决的核心问题，恰恰是把不确定性一点点压下去。Skill 让 Claude 的行为有据可依，MCP 让它的判断有真实数据支撑。当它的产出稳定可预期了，你才敢把更多关键任务交给它去执行。

如果你现在也处在“裸用”状态，我建议你从一个小切口开始：先把你的核心代码规范写成一个 Skill，再给 Claude 接入一个你最常用的本地文件系统 MCP，然后用一周时间观察它的产出变化。多数情况下，一周之后你就不会想退回去了。