企业官网建设流程全解析

前几天我在社区看到一个讨论串，有人把 Claude Code 跑起来之后第一句话就问“它怎么不会自己看网页”，下面一群人回复“你没配 MCP Server 吧”。那一刻我特别理解提问的人——因为我自己最开始也是裸跑 Claude Code 的，当时的感觉是：这工具确实能写代码，但它更像一个“无网、无仓库权限、无浏览器、无文档库”的初级程序员，只会凭训练记忆硬写，写错了也不知道自己错在哪。后来我陆续把 8 个 MCP Server 接进去，Claude Code 才真正像从“初级实习生”变成了“高级开发者”的搭档。这篇就把我自己的配置清单、每个工具的用途、为什么值得装、装完之后实际工作流的变化，一次性讲清楚。

1. 裸跑的 Claude Code 到底缺了什么

1.1 我踩过的坑：它不知道“真实世界”长什么样

先说最直观的痛点。我最早用 Claude Code 写一个 React 页面，需求是“把 GitHub 上某个开源项目的 README 抓下来，按品牌风格排版”。按我当时的理解，这种纯体力活给 AI 干应该很快。结果 Claude Code 噼里啪啦生成了一堆代码，表面逻辑没问题，但运行起来全是错的。原因特别简单：它没法访问 GitHub，没法访问网络，也看不到页面渲染结果。它只是在靠自己训练数据里的“印象”在写代码，而那些印象可能停留在两年前。

这就是裸跑 Claude Code 的真实状态。它虽然跑在本地终端里，看起来像个“全栈工程师”，但它的能力边界被死死限制住了：没有工具调用、没有实时读取、没有环境感知。它更像一个记忆力很强、但被关在没有网线的工位上的开发者，只能凭着脑内资料做方案，一旦资料过时或者场景太具体，就开始一本正经地胡编。

1.2 MCP 是分水岭：它让 AI 从“聊天”变成了“干活”

MCP 的全称是 Model Context Protocol，模型上下文协议。你可以把它理解成一个标准化的“USB 接口”——Anthropic 定义了一整套规范，让外部的数据源、工具、服务能够安全地被 Claude 调用和访问。一旦接上某个 MCP Server，Claude 就不再局限于“文字生成文字”，而是能主动发起文件读取、执行命令、访问 API、浏览页面，并把结果拿回来继续推理。

我后来回头想，裸跑和接入 MCP 之后的区别，根本不是“功能多了几个”，而是协作模式的质变。裸跑时你给 Claude 下一段指令，它只能生成“一段答案”；接好 MCP 之后，它是在“完成一个任务”——它会调用工具、观察结果、修正路径，像真人工程师一样处理工作中多步骤、多信息源的复杂过程。这个差异，正是我今天想展开说的重点。

2. 先搞懂 MCP 的底层机制，再去选工具

2.1 用一个类比吃透 MCP 的工作方式

如果觉得 MCP 的协议概念太抽象，可以想象你请了一个远程助理。助理本身很聪明，但他手上没有任何通讯工具；MCP Server 就是给助理配的一台台专用设备——电话、传真、邮箱、数据库终端。这些设备之间用统一的标准接口连接，助理不需要知道每台设备背后的电路怎么走，只要会用标准操作就能拿到结果。

具体到 Claude Code 的场景里，Claude 是“助理”，MCP Client 内置在 Claude Code 里负责“插线”，MCP Server 则是那一台台“设备”。每个 Server 启动后，会把自己的能力以工具（Tools）的形式暴露出来，Claude 在对话中判断“现在该用哪个工具”，然后把参数传过去，等 Server 返回结果，再基于结果继续做事。

2.2 为什么说“工具数量多”不等于“能力强”

很多人刚接触 MCP 时容易陷入一个误区：看到 MCP 市场几百个 Server，感觉越全越好，一口气全装上。我一开始也这么干过，结果 Claude 在每次任务里都要先遍历一遍工具列表，Token 消耗翻倍，响应速度变慢，而且有些工具互相抢场景。后来我筛选下来的经验是：好的 MCP 配置应该像精干的开发团队，每个成员解决一类明确的问题，而不是什么都接。所以要选就选“能帮 AI 获取实时外部信息、能操作本地工程、能自我验证结果”这三类核心工具，剩下的一律按需再说。

3. 基础环境准备：装 8 个 MCP 之前，先把 Claude Code 跑顺

3.1 Node.js 与 Claude Code 的安装要点

想接 MCP，前提是 Claude Code 本身能稳定运行。Claude Code 是一个运行在终端里的编程代理，你可以在 macOS、Linux、Windows 上安装，但对 Windows 用户，最好在 WSL 或 Git Bash 环境里跑，否则后续一些本地路径和权限继承问题会很折腾。我这里以 macOS 和 Linux 的安装流程为例：

# 1. 确认 Node.js 版本 ≥ 18，推荐用 nvm 安装 LTS 版本 node -v npm -v # 2. 全局安装 Claude Code npm install -g @anthropic-ai/claude-code

安装完成后，在项目目录里直接输入claude就会进入交互终端。首次使用需要在浏览器里完成 OAuth 登录授权，这一步的体验比较简单，跟着提示走即可。如果你在 VSCode 里用，我更推荐直接打开 VSCode 终端跑claude，这样代码修改和编辑器上下文能无缝衔接，省去频繁切换窗口的麻烦。

3.2 为什么我推荐用命令行来管理 MCP 配置

Claude Code 接入 MCP Server 有两种常见方式：一种是直接编辑配置文件，另一种是用包管理器命令。我强烈建议先掌握命令行方式，因为它有自动补全、参数提示和错误检查，比手写 JSON 配置文件稳定得多。以官方标准写法为例：

claude mcp add server-name -- npx -y @somepackage/server

这条命令的意思是用 npx 启动一个远程包。npx -y会自动下载并运行包，后面的@somepackage/server就是 MCP Server 的 npm 包名。如果你本地已经安装了包，也可以直接写成claude mcp add server-name -- node /path/to/server.js。配置文件一般会被保存在~/.claude.json或者项目级的.mcp.json里，每个项目的配置可以互相隔离，这一点对做多项目的人非常友好。

3.3 需要提前准备的密钥和 Token

不少 MCP Server 需要访问外部服务，所以提前把密钥准备好能节省大量后续调试时间。至少要准备两类密钥：一类是 GitHub Token，一类是各类搜索/抓取服务的 API Key。GitHub Token 可以在 GitHub Settings → Developer settings → Personal access tokens 里生成，权限按需勾选：读取仓库内容用repo权限，操作 Issue 和 PR 再加workflow、write:packages等。这个 Token 同时也是后面 4.1 节那个 GitHub MCP 的前提。

4. 让 Claude Code “升级成高级开发者”的 8 个 MCP Server 逐一点评

4.1 GitHub MCP：给 AI 接上代码托管平台的手脚

它解决的问题：让 Claude 能直接浏览远程仓库、读取 Issue、查看 PR 状态，甚至帮你提交 PR、管理分支。裸跑的 Claude Code 只能处理你已经克隆到本地的代码，但真实开发里，我们经常需要“看一眼线上仓库的动态”或者“把这次改动开一个 PR”。

我选的 source 和配置：

claude mcp add github -- npx -y @modelcontextprotocol/server-github

启动前需要设置环境变量GITHUB_PERSONAL_TOKEN，我一般写在 shell profile 里：

export GITHUB_PERSONAL_TOKEN="ghp_你的token"

配置好之后，你在 Claude Code 里可以直接说“打开这个仓库最新 Issue，总结一下讨论”，它就会调用 GitHub MCP 去读取真实数据。用久了你会发现，这个 MCP 最大的价值是让代码审查工作流变得更自然。过去我写完代码把 diff 贴给 AI 看，上下文一长就乱；现在可以直接指定某个 PR 让它 review，它像同事一样看到完整的改动文件和讨论上下文。

4.2 Playwright MCP：让 Claude 长出“眼睛”

在接入 MCP 之前，Claude Code 生成的网页代码对我而言就是个黑盒。它自己写完组件，我只能手动去跑 dev server、开浏览器、肉眼检查，再把报错信息粘回去。这个循环每次都要消耗大量时间，尤其前端调整布局的时候，经常来来回回好几轮。Playwright MCP 就是专门解决这个问题的：它让 Claude 直接操作一个真实浏览器，访问页面、截图、点击、读取 DOM，然后根据看到的内容自主调整代码。

配置方式：

claude mcp add playwright -- npx -y @playwright/mcp@latest

这个 MCP 启动后，Claude 会在需要时自动打开浏览器。我给你描述一下我实际使用时的场景：我让它实现一个响应式导航栏，Claude 先写了代码，然后自己调起 Playwright 打开 localhost 页面，在 375px 宽度下截图，发现汉堡菜单没有正常展开，于是它又回头修改了状态管理逻辑，再截图确认。整个过程中我几乎没参与“把错误信息复制给它”的步骤，它自己完成了开发者最费时间的“验尸”循环。

4.3 Context7 MCP：AI 的“活文档”，专治 API 幻觉

大模型生成的代码里，最坑的不是语法错误，而是“API 名称看着对但实际不存在”。尤其是遇到快速迭代的库，AI 的训练数据早就过时了，它还在用老版本的方法名。Context7 是我见过解决这个问题最直接的 MCP：它相当于一个实时文档检索器，能按需获取最新版本的官方库文档，并把相关内容注入 Claude 的上下文。

我也尝试过自己在 prompt 里粘贴官网文档，但那样既繁琐又有上下文窗口限制。有了 Context7，我可以直接说“查最新版 Next.js App Router 的动态路由写法，再实现一个页面”，Claude 会自动去拉取文档中与动态路由最相关的片段，然后基于准确信息写代码。对依赖大量第三方库的前端任务来说，这个工具几乎能根除“伪装成正确的 API 幻觉”。

4.4 Filesystem MCP：让 Claude 学会规划文件路径

可能有人觉得文件操作不是 Claude Code 自带的能力吗？实际上 Claude Code 本身就有一定的文件读写能力，但它是通过自主规划完成的，遇到大项目多目录的时候经常会出现“读半天读错文件”或者“重命名了还在引用旧路径文件”的低级问题。Filesystem MCP 以标准库方式提供了一套文件操作工具，让 Claude 可以对目录做清单列举、路径检查、批量移动和文件替换，效率比自己写模糊命令高得多。

它的配置方式如下：

claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem /你的工作目录

注意最后那个目录参数：这个参数是用来限制文件操作范围的白名单。这意味着即使 Claude 拿到了文件操作权限，也只能在指定目录内活动，不会失手去改系统文件。我平时做重构时，会先把整个 monorepo 根目录传给它，然后告诉它“帮我找出所有还引用旧路径的文件并批量改掉”，这个任务在 Filesystem MCP 的帮助下能执行得非常干净。

4.5 Sequential Thinking MCP：逼着 AI 先想清楚再下手

如果你用过 Claude Code 处理复杂需求，你可能会感觉到一个毛病：它倾向尽快给出答案。遇到多模块强关联的架构问题时，容易“拍脑袋”直接写，然后后期推翻重来。Sequential Thinking MCP 的思路是强制 Claude 把推理过程展开成多条思考步骤，一步一步地进行逻辑推演，并且在每一步里验证上一步的结论，而不是一步跳到最终结果。

它的配置比其他 Server 更接近“解题提示”：

claude mcp add sequential-thinking -- npx -y @modelcontextprotocol/server-sequential-thinking

这个 MCP 没有外部 API 依赖，也不需要密钥。它内部提供一组结构化的“思考”工具，让 Claude 可以在回答前先创建思考步骤、修订步骤、写注释结论。我一般会在任务描述里直接加一句“请先用 Sequential Thinking 拆解这个需求，再开始写代码”。它给我的最大改进不是代码速度，而是方案质量——尤其在做架构设计、迁移方案和数据模型设计这类工作时，Claude 给出终稿前会先经历一段可追踪的推理过程，我能看到它是怎么得出结论的，也方便纠正它的方向错误。

4.6 Fetch MCP：线上数据就地取材

Fetch MCP 可以说是 Claude 的“基础网络访问能力”。它负责抓取一个 URL 并返回内容，常见用途包括查看接口文档、获取网页内容、排查线上问题。在接入它之前，你让 Claude 总结一份在线文档，它会说“我无法访问外部网站”；接入之后，它会直接请求那个页面，把正文内容拿回来理解。

claude mcp add fetch -- npx -y @modelcontextprotocol/server-fetch

这个工具不需要 API key，我用它的频次非常高。一种最实用的组合是：我先让 Claude Code 从终端里查看某个服务返回的报错页面，然后把 URL 丢给 Fetch MCP，Claude 会请求这个地址，再从返回的 HTML 或报错信息里定位问题。特别适合联调阶段快速排查后端接口是否可用、静态资源是否正常返回。

4.7 Firecrawl MCP：把整站文档“喂”给 AI 吃

如果 Fetch 是“零买零卖”，那 Firecrawl 就是“批发采购”。Firecrawl MCP 能把整个网站、整个文档站抓取下来，并转成干净的 Markdown 格式，供 Claude 深度分析。导航类文档站最实用：当你想让 Claude 按照某个框架的官方最新内容来开发，如果只靠 Fetch 一页一页抓，效率太低，不如直接让 Firecrawl 对某个文档站做站点级抓取，再把处理过的 Markdown 作为上下文喂给 Claude。

配置 Firecrawl 时需要一个 API Key，可以到 Firecrawl 官网申请：

export FIRECRAWL_API_KEY="你的key" claude mcp add firecrawl -- npx -y firecrawl-mcp

使用中需要注意的是，抓取范围越大，产生的上下文越多，消耗的 Token 也随之暴涨。因此我通常会限制抓取路径，比如只让它抓取某个子目录下的全部文档，而不是整站一把梭。这样既拿到了关键信息，又不至于让上下文窗口被无关页面塞满。

4.8 SQLite MCP：让 Claude 直接操作数据库

最后一个压轴的是SQLite MCP。它来自官方 MCP servers 仓库，主要能力就是让 Claude 直接查询、修改 SQLite 数据库。以前我调试数据问题时要手动开一个数据库客户端，把表结构导出来，再手动把数据结果粘给 Claude；现在只需要把数据库文件路径和表名告诉它，Claude 就能自己读取结构、执行 SQL、分析结果。

claude mcp add sqlite -- npx -y @modelcontextprotocol/server-sqlite -- db 你的数据库文件路径

这个 MCP 带来的最大价值在于“数据驱动的调试”。比如有用户反馈某个订单状态不对，Claude Code 可以直接连上本地 SQLite 数据库，查看订单表里这条记录的变更轨迹，再结合代码逻辑定位到是哪个状态机转换写错了。因为看到了真实数据，它的排查方向会准确得多，也不会提出“理论上可能”却和实际数据矛盾的建议。

5. 8 个 MCP 一起工作时，实际开发是什么体验

5.1 一个真实任务：给旧项目写一个文档站

为了让你理解这些工具不是独立的，我拿一个最近实际做过的小任务来复盘。任务是：给一个已有的 Node.js SDK 写一个静态文档站，内容要覆盖最新 API，并进行一次可视化的页面验证。

在这个任务里，真正运行起来不是单独某一个 MCP，而是它们之间层层配合：

1. 我先用 Filesystem MCP 告诉 Claude 当前项目的目录结构，让它搞清楚 SDK 有哪些公开接口；
2. 我用 Context7 让 Claude 拉取最新版静态站点生成器（比如 VitePress 或 Astro）的文档，确定目录配置和相关 API 写法；
3. Claude 根据 SDK 源码和文档生成初版文档站页面；
4. 我启动本地预览后，Claude 调用 Playwright MCP 打开页面，截图发现移动端排版错乱；
5. 它再回去改样式，重新打开页面验证；
6. 最终它用 GitHub MCP 帮我提交代码并创建 PR，在 PR 描述里自动总结了改了什么、验证结果如何。

整个流程里我更像一个审查者，而不是每一步都亲自操作。这就是我标题里说的“升级成高级开发者”——从一天手写十几个小时，变成设定目标、分配任务、验收结果。以前要花一下午的事情，现在一个小时能完成初稿和自测，剩下时间都用来打磨细节。

5.2 MCP Server 之间的配合也有顺序讲究

在实际使用中我发现，同时给 Claude 接很多工具时，任务描述里的“顺序”非常重要。你越是把任务拆成清晰的阶段，它越能精准地用对工具；反之，如果你扔给它一个模糊的“帮我做个东西”，它可能先用了 Fetch 去抓取无关页面，或者在不需要浏览器时莫名打开了 Playwright，导致任务路径偏移。我现在写 prompt 的固定习惯是：先提供项目背景，再给具体任务路径，最后标注“如果实现过程中需要参考最新文档，请先查 Context7，不要凭记忆”。这一句话，就能显著减少 AI 在错误路径上消耗的 Token。

6. 成本与风险的边界：装了 8 个不代表一定要全用

6.1 Token 消耗的实测感受

MCP 不是免费的午餐。每多一个 Server，Claude 在对话中都会多一批可调用的工具定义，而这部分定义本身要占用系统上下文。我实测下来，在接入上面 8 个 MCP 后，每次对话的工具定义开销会比裸跑高不少，但在同一个 Session 里不同断使用时，因为省去了大量的“我帮你查、再粘贴给你”的来回对话，总 Token 反而更省了。

如果一定要控成本，可以考虑按项目分目录配置 MCP，而不是全局一把梭。比如这个项目纯做前端页面，就没必要挂上 SQLite MCP；同理纯写脚本任务，也不一定要带上 Playwright。Claude Code 支持在项目目录配置独立的 MCP 列表，这一点非常值得利用。

6.2 权限安全：给 AI 再强的能力，也要圈好边界

Filesystem MCP 的目录白名单、GitHub Token 的最小权限原则、Firecrawl API Key 的付费额度管理，这三件事一定要在正式上手前做好。我给 Claude Code 的权限从来不会超过我自己日常操作的权限，GitHub Token 也只为当前需要协作的仓库范围勾选权限，绝不开一个永不过期的全仓库写权限。MCP 的初衷是让 AI 获得真实世界的操作能力，但任何能力如果失去边界约束，都会带来风险。

7. 一点悄悄话：高级开发者不是“工具最多”的那个

把 8 个 MCP Server 摆出来讲可能给人一个感觉：装完这些就无敌了。实际上，我身边的真实情况恰好相反。工具变多之后，如果你没有清晰的工程方法论，Claude Code 反而会变得很难控制。它会东摸一下、西摸一下，浪费很多 Token 在没有产出的验证上。

我的核心建议是：先从一个 MCP 开始用，用熟了、摸清了它的脾气，再逐步增加。我自己尤其推荐先接 Context7 和 Playwright，前者能明显减少代码幻觉，后者能带来最直观的“AI 自己验证自己”的体验。等这两个融入工作流，再补 GitHub MCP、Filesystem MCP、Sequential Thinking MCP，最后根据实际需求再尝试 Firecrawl、SQLite MCP 等场景型工具。

配置环境这种事，第一次用到顺手可能需要一整个周末，但一旦跑通，你就能体会到 Claude Code 真正的价值：把重复劳动还给药，把项目的方向和决策握在自己手里。希望这份实践清单对你有点帮助。