企业官网建设流程全解析

我接触 Claude Code 也有一段时间了，从一开始拿它写点脚本、补个测试，到后来慢慢把整个项目的日常开发都交给它，中间最明显的转折点，就是开始折腾 MCP Server。如果你只用原生的 Claude Code，会觉得它确实聪明，但总像隔着一层——它读不到你的代码仓库结构，不能记忆偏好，更不能自己去查最新的包版本。说白了，它是个厉害的话痨，但在项目里更像“顾问”，而不是“员工”。

直到我给 Claude Code 接上了 8 个 MCP Server，才感觉它真正从一个聊天的模型，变成了熟悉你的项目、会自己看代码、会动手改文件、还把每一步理由讲清楚的资深同事。这篇文章我就把这 8 个工具挨个讲清楚，从为什么选它、怎么配置，到实际使用中能解决什么问题，全部摊开讲，适合所有正在用或准备用 Claude Code 的人参考。

1. 为什么 Claude Code 需要 MCP Server，以及我筛选工具的四个标准

1.1 原生 Claude Code 的能力边界在哪里

很多刚接触 Claude Code 的朋友会有个误解，觉得它既然是写代码的 AI，那一定天生就能读整个项目、知道每个函数在哪定义、每个依赖是什么版本。实际上原生 Claude Code 的上下文窗口里，你放进去什么它才知道什么，项目里的代码它要一个文件一个文件地读，才能形成“全貌”。遇到稍微大一点的项目，这种方式很浪费 token，而且它脑子里没有任何“既往偏好”——你今天告诉它用单引号、用 pnpm、测试文件放 tests 目录，明天新开会话它又忘了。

这就引出了一个核心矛盾：模型本身参数是固定的，但每个项目的结构、习惯、工具链是千变万化的。MCP Server 就是来解决这个矛盾的。它是一种标准化的“外部工具接口”，让 Claude Code 在对话过程中实时去调用外部服务。比如它想知道项目里有多少个文件、目录长什么样，就可以调用一个 MCP 工具去扫描，而不是靠猜或者靠用户手动复制粘贴。这改变了整个交互模式：从“你喂它”变成“它自己拿”。

1.2 我挑选 8 个 MCP Server 时用的判断标准

市面上 MCP Server 数量非常多，光官方 registry 里就几百个，质量参差不齐。我最后留下这 8 个，主要过了四道筛子。

第一是安全边界。MCP 本质上给了 AI 执行权限，一个写得不严谨的 Server 可能让模型做出危险操作。我优先选择官方维护、开源背书、社区使用量大的，尽可能减少未知风险。

第二是场景覆盖。我日常开发里最耗时的几个环节是：理解陌生代码结构、写胶水代码、调试报错、查依赖文档。这 8 个工具基本围绕这四个场景展开，相互之间不重叠，也不冗余。

第三是易配置性。Claude Code 的 MCP 配置是通过.mcp.json文件或claude mcp add命令完成的，我需要确认这些工具都有成熟的 npx 包或远程服务地址，不能要我自己去编译源码。毕竟工具是拿来用的，不是拿来折腾的。

第四是稳定性和可观测性。开发到一半 MCP 连不上是非常恼火的，所以我选了那些日志友好、错误信息明确的。这样真出问题时我能快速定位是网络、权限还是服务本身的问题。

这四条标准听起来不复杂，但实际操作里很多工具会在这上面翻车。下面每个工具我都会带上它在这几个维度的具体表现。

2. 8 个 MCP Server 逐个拆解：用途、配置与实战细节

2.1 server-context：让 Claude Code 一眼看懂项目结构

先说一个最基础也最容易被忽视的工具：server-context。它的作用一句话总结，就是向 Claude Code 提供当前代码库的上下文概览，包括目录树、文件列表、文件大小、语言占比等。别小看这个能力，Claude Code 在很多情况下需要“知道项目里有什么”才能决定下一步读哪个文件。没有它，模型只能从根目录开始深度优先遍历，既慢又费 token。

配置上非常简单，在项目根目录执行：

claude mcp add project-context -- npx -y @anthropic-ai/server-context

添加完之后，你会在对话里看到多出来的工具描述。实操中我感知最明显的场景，是让 Claude Code 写一个变更影响面分析。以前我要把整个目录结构贴给它，现在它自己先调用 context 工具扫一遍，然后直接说“根据目录结构，这个改动会影响 api/ 下的三个路由文件和 middleware 里的一处拦截逻辑”。这种回答方式，明显是“看过”代码之后给出的，而不是泛泛而谈。

2.2 github-mcp-server：把 Issue、PR 和 CI 全部拉进对话

开发工作流里逃不开 GitHub，而 github-mcp-server 解决的是“让 Claude Code 能直接操作 GitHub 数据”的问题。它支持的功能非常全：列出 issue、读取 PR 详情、查看 review 评论、检查 CI 状态、创建 gist，甚至能直接创建 issue 和合并 PR。

安装方式值得单独说一下，因为它的推荐路径不是 npx，而是远程 MCP：

claude mcp add --transport http github \ --url https://api.githubcopilot.com/mcp/ \ --headers "Authorization: Bearer your_github_token"

这里用的是 GitHub 官方提供的远程 MCP 端点，好处是不需要本地起进程，token 也不会写进 shell 历史。当然，如果你不放心把 token 给远程端点，也可以用 Docker 跑本地版：

docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN your_token ghcr.io/github/github-mcp-server

我的实际用法是让 Claude Code 在改完代码后，自动帮我开 PR，并在描述里带上变更清单和测试结果。它调 GitHub API 的过程是透明的，每一步做了什么都能在对话里看到。省掉的不只是切窗口的时间，更是“写完代码后还要组织语言写 PR 描述”的那股烦躁感。

2.3 Chroma MCP Server：给 Claude Code 装上长期记忆

这是我认为提升开发体验最明显的工具之一。Chroma 是一个开源向量数据库，而它的 MCP Server 让 Claude Code 能把对话里的关键信息写入本地向量库，之后随时检索。

安装分两步：

# 第一步：启动本地 chroma 容器（或本地服务） docker run -p 8000:8000 chromadb/chroma

# 第二步：给 Claude Code 添加工具 claude mcp add chroma -- npx -y chroma-mcp-server@latest

配置完还要设置环境变量，指明 chroma 服务地址和 collection 名称：

export CHROMA_URL=http://localhost:8000 export CHROMA_ORGANIZATION=my_workspace export CHROMA_TENANT=default_tenant export CHROMA_API_KEY=... export CHROMA_COLLECTION=my_project_memory

这个工具解决的核心痛点是“会话隔离”。Claude Code 默认不跨会话记忆，我昨天让它给某个模块写的代码规范，今天新开会话它就忘了。有了 Chroma，我会在每个会话开始时要求它“先检索一下项目记忆库，看看有没有相关的历史决策”。检索之后，它能说出类似“根据上次对话，你希望 API 错误统一通过 Result 对象返回，并且使用中文错误提示”这样的内容。这种记忆连续性带来的体验提升，是质变级的。

2.4 Context7 MCP Server：最新文档的实时手册

写过代码的人都知道，查依赖库的最新用法有多痛苦。Context7 恰好就是解决这个场景的 MCP Server：它会在你需要的时候，主动去拉取相关库的最新文档，然后切出上下文相关的片段给模型。

添加方式有两种，推荐用远程端点：

claude mcp add context7 --transport http \ --url https://mcp.context7.com/mcp

或者本地安装：

claude mcp add context7 -- npx -y @upstash/context7-mcp

我印象最深的场景是一次升级依赖。我想把项目里的某个库从 v4 升到 v5，直觉告诉我 API 变化不大，但保险起见还是让 Claude Code 用 Context7 查一下文档。结果它不仅拉出了新版文档中三个被废弃的方法，还直接给了我替换方案。这种“模型本身不知道，但它知道去哪里查”的能力，才是工具该有的样子。

2.5 Memory MCP Server：轻量级知识图谱记忆

前面讲 Chroma 是向量检索式记忆，适合存大段文本和相似度搜索。而这个 Memory MCP Server 走的是另一条路：用知识图谱的方式，把实体、关系、观察存成节点和边。它适合存结构化信息，比如“用户叫张三”“这个项目使用 pnpm”“当前主分支是 main”。

安装：

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

使用的时候，Claude Code 会在对话中自动判断哪些信息值得记住，比如在讨论某个配置时，它会主动调用create_entities和create_relations把关键信息存下来。

我建议的做法是这样的：在每个项目开始时，先花两分钟让 Claude Code 把项目的基础信息（语言、包管理工具、测试框架、部署方式）写入 Memory Server。之后所有对话里涉及这些信息的判断，它都能直接命中，不用反复问。使用这个方法后，我在新项目上的前期沟通成本肉眼可见地降低了。

2.6 Fetch MCP Server：把网页内容直接丢给模型

很多时候 Claude Code 需要读文档、看 issue 里的链接、或者了解一下线上配置，但原生它是不会主动去打开网页的。Fetch MCP Server 就是解决这个问题的。它支持抓取 URL 内容并转成 Markdown，还会自动处理重定向和基本的内容提取。

claude mcp add fetch -- npx -y mcp-server-fetch

用起来非常自然，我在对话里只要说“看一下这个链接里关于配置项的内容”，它就会自动调用 fetch 工具，然后把抓取结果总结给我。和 Context7 相比，Fetch 更通用一些，不限定于文档库，什么网页都能抓。两者配合使用：Context7 查官方文档，Fetch 抓任意链接。

这里有一点要注意：Fetch 抓取到的内容质量不稳定，有些页面本身是 JS 渲染的，抓出来全是脚手架。这时候可以配合浏览器相关的 MCP 或直接让用户粘贴关键内容，不要过度依赖。

2.7 Filesystem MCP Server：用白名单给文件操作划好安全线

Claude Code 本身有读写文件的能力，但那是模型原生的，缺乏一个清晰可控的权限边界控制。Filesystem MCP Server 提供的是更规范的文件操作方式：所有操作都限定在预设白名单目录内，支持读、写、创建目录、列目录等常见操作。

安装时需要指定允许操作的根目录：

claude mcp add fs -- npx -y @modelcontextprotocol/server-filesystem \ /Users/yourname/workspace/my-project

个人建议把白名单设置得尽量精确，不要直接给整个用户目录。这样即使模型在某个极端情况下产生了误操作，影响面也被锁在一个小范围内。

实际开发中，这个工具更多是在 Claude Code 大量生成代码文件时发挥作用。我会让它按照既定目录规划生成文件，比如“Controller 放这里，Service 放这里，类型定义放这里”。有了 filesystem 白名单，它生成文件时就不用反复向我确认“我可以写文件吗”，流程顺畅很多。

2.8 免费版官方 Playwright MCP Server：让 Claude Code 真正“看见”页面

最后一个是官方 Playwright MCP Server。它把浏览器自动化能力直接接入对话，Claude Code 可以自己打开页面、截图、查看 DOM 元素、操作表单，甚至跑一遍用户流程。

安装：

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

安装之后第一次使用，它会主动下载浏览器内核，时间取决于网速，需要耐心等一会儿。

一个典型的使用场景是：我让 Claude Code 写完一个前端页面后，直接用 Playwright 打开本地开发服务器，截图检查页面布局。它能自己看截图、判断元素是否重叠、颜色是否正常、点击事件是否生效。虽然这个工具不免费，但其免费额度对个人开发已经完全够用了。我用它来快速做可视化回归，省去了反复打开浏览器、手动刷新、肉眼对比的繁琐过程。

3. 配置方法、工作流串联与省 Token 实战

3.1 Claude Code 里安装 MCP 的两种标准姿势

讲工具的时候我提到了命令，这里系统梳理一下。Claude Code 添加 MCP 有两种主流方式：项目级别（写在项目根目录.mcp.json）和用户级别（写在~/.claude.json）。项目级别适合团队共享，提交到 Git 后所有人都能拉取同一套配置；用户级别适合个人全局工具，比如脑图、备忘录这类所有项目通用的。

具体到操作：

# 项目级（推荐，跟随仓库走） claude mcp add context7 -- npx -y @upstash/context7-mcp # 用户级（全局工具） claude mcp add --scope user context7 -- npx -y @upstash/context7-mcp

如果想查看、修改或删除已有配置：

# 查看所有已注册的 MCP 工具 claude mcp list # 删除一个不再需要的工具 claude mcp remove context7

3.2 TypeScript SDK 方式的配置示例

上面这些都是通过 CLI，对于习惯了代码化配置的人来说，直接写在.mcp.json里也很常见。以远程 MCP 为例：

{ "mcpServers": { "context7": { "url": "https://mcp.context7.com/mcp", "type": "http" }, "github": { "url": "https://api.githubcopilot.com/mcp/", "headers": { "Authorization": "Bearer ghp_your_token" }, "type": "http" } } }

本地 npx 类的工具也可以写成：

{ "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/whitelist"] } } }

如果你是在 TypeScript/Node 项目里，还可以通过 SDK 编程方式配置。Anthropic 提供了@anthropic-ai/claude-code的 SDK，但大多数场景下.mcp.json已经足够，不必强行上 SDK。

3.3 将 8 个 MCP 串成一条完整开发链路

工具单独用是散的，串起来才能体现出价值。我现在的标准开发流程长这样：拿到需求后，先让 Claude Code 用 server-context 扫一遍项目结构，再用 memory 确认项目约定；写代码阶段，它需要查依赖时用 Context7，需要看别的库的用法时用 Fetch；写完代码，开本地测试页面，直接跑 Playwright 做一次视觉验证；改动完成后，用 Chroma 把关键决策存入记忆库，最后用 github-mcp-server 开 PR。整套流程走下来，我只需要做 review 和决策，其他体力活全交给工具链。

3.4 如何控制 token 消耗，避免 MCP 反噬

MCP 工具用得越多，token 消耗也可能变大，尤其是一些工具返回内容特别长。我在实践中总结出几个控制 token 的要点：

• 只给 Claude Code 必要的工具，闲置的及时claude mcp remove，避免它在决策时考虑太多无关选项。
• 在和模型交互时，明确说“不要调用 fetch”，如果暂时不需要联网；Claude Code 尊重这些显性约束。
• Chroma 检索时尽量限定 collection 范围，避免一次检索召回过多无关片段。
• 尽量用远程 MCP 服务，省掉本地进程占用的资源。当然远程服务也有网络开销，根据个人网络情况衡量。

这套控制策略用下来，我日常一个完整功能的开发会话，token 消耗比人类用户全手动粘贴代码反而不高多少，但产出质量要高一大截。

4. 常见问题与排查技巧实录

4.1 MCP Server 添加后对话里看不到工具，怎么办

这个问题最普遍。添加之后执行claude mcp list确认状态，如果是failed，多半是 npx 包启动失败。解决办法是先手动跑一遍 npx 命令，看报错信息再对症处理。网络国内访问 npm registry 经常超时，遇到这种情况可以设置国内镜像，加速依赖下载。

4.2 Claude Code 识别不了我装的 Python/Ruby 环境的 MCP

Claude Code 底层走 Node，对 Python 写的 MCP 需要通过 npx 包装或直接用uvx运行。比如 Chroma 的 MCP 我用的是npx -y chroma-mcp-server@latest。如果你本地 Python 环境特别复杂，建议直接用 uv 管理的虚拟环境，避免 PATH 混乱导致加载不到模块。

4.3 MCP 工具返回内容过于冗长，挤占上下文窗口

有些工具（比如 filesystem 的列目录、fetch 抓取的完整页面）返回内容非常长，容易把上下文塞满。我的处理方式是：在指令里对模型说“只需要返回目录前三层”或“摘要一下链接内容就行”，模型会尽量精简调用行为的参数。如果仍不行，就按 3.4 节的方法，在对话里明确限制它使用某个工具。

4.4 Chroma 只能存固定 collection，怎么做到按项目隔离

Chroma MCP 在初始化时通过环境变量指定 collection 名称。如果你有多个项目，建议启动多个不同的 collection 或者通过组织名称做区分。更省事的方案是把 collection 设为项目名，开户时自动加载对应配置。但这样操作会比较繁琐，好在场景不复杂时完全够用。

4.5 8 个 MCP 同时开启，Claude Code 会不会变慢

工具变多后模型在选择工具时决策路径变长，确实会有一点响应延迟。我的做法是区分场景：日常开发只开 4 个基础工具，需要联调或提 PR 时才临时加上其他 MCP。这样既保证性能，也不会让对话干扰变大。

5. 这 8 个工具之外，我踩过的一些坑与心得

说几个网上教程不太会提的细节。MCP Server 的配置不是一劳永逸的，npx 包的更新频率很快，隔一段时间最好主动跑一次claude mcp list检查是否有工具失效。环境变量是 MCP 出错的大头，尤其是 Chroma 和 GitHub 这类需要鉴权的，报错十有八九是变量没配或者配错，排查时优先打印环境变量，别一上来就怀疑代码。

另一个坑是 token 的隐性消耗。很多人以为加了 MCP 能让回复更准确，但忽略了工具返回的内容本身也要计费。像 Fetch 抓取一个完整博客页面可能几千 token，如果项目里频繁触发，费用会非常可观。你需要在提示词层面主动约束，给模型设定“能不用 fetch 就不用”的默认策略，效果立竿见影。

关于 Playwright MCP 我有一个建议：它的浏览器自动化能力很强，但在 CI 环境中使用要格外小心，自动点击可能触达敏感操作。我自己的使用边界是只让它做“查看和截图”，真正的写入、点击操作我会手动确认。保护好操作边界，比追求“全自动”更重要。

最后说一下个人比较新的体会。MCP 这个生态的最大价值不在于某一个工具多强大，而在于它把 AI 从“回答问题的人”变成了“能动手做事的人”。8 个 MCP 接完，Claude Code 不再是那个只会纸上谈兵的助手，而是一个熟悉项目、能查文档、能写文件、能跑浏览器、还能记住你偏好的搭档。配置它们的过程本身就是在为你自己的工作流搭桥。每接一个工具，它就从“懂”你多了一分，这在长期使用中的回报是相当大的。

如果你也正在折腾 Claude Code，我建议不要 8 个全上，先挑最贴近你日常痛点的 2 到 3 个装上用一周。等适应了这种交互方式，再慢慢补全其他工具。适不适合，实践过才知道。