企业官网建设流程全解析

前两天我在 Cursor 里做前端还原，卡在了一个特别常见的问题上：AI 能看到代码，却看不到设计稿。我不得不把蓝湖上的标注、接口字段、数据库表结构全部手动复制到对话框里，再一遍遍叮嘱模型“按这个字段来，别猜”。光是整理上下文就花了二十分钟，最后生成的代码还是对不上设计稿。后来我把蓝湖的 MCP Server、数据库的 MCP Server 接进去，AI 可以直接按需读取设计标注和真实表结构，整个流程从“人肉搬运上下文”变成了“模型主动拉取上下文”。

这个变化让我意识到一件事：MCP 之所以被反复讨论，不是因为它多了一种“让 AI 调工具”的方法，而是它正在改变 AI 应用里最容易被忽略的一层——工具与上下文之间的标准化连接。看到标题里写着“8.8.5”，先别急着把它当成一个需要记住的版本号。MCP 协议本身还在快速迭代，今天记死的版本，下周可能就变了。真正值得理解的是它的定位：标准化的工具与上下文接入协议。

1. 工具接入的旧世界：为什么上下文总靠人肉搬运

1.1 大模型不是天生会“用工具”的

大模型本质上是一个文本输入输出的系统。它能写代码、能总结文档、能推理，但它本身不会直接查数据库、不会点开浏览器、不会读取 Figma 文件。要想让它使用外部能力，必须有一层“中间人”把外部世界翻译成它能理解的文本，再把它的决策翻译回外部系统能执行的调用。

这不是新问题。OpenAI 的 Function Calling、Anthropic 的 Tool Use，以及各种 Agent 框架，早就实现了“让模型决定调用哪个函数”的能力。你定义一个结构化的函数描述，模型根据用户问题决定是否调用，然后框架执行函数，把结果返回给模型继续推理。

但问题从来不是“能不能调”，而是“每个生态都有一套自己的调法”。

1.2 过去几种工具接入方式，各有什么短板

早期最常见的是 Per-Model API 的 Function Calling。缺点是绑定厂商。你在 OpenAI 生态里写好的工具定义，换到 Anthropic 模型上基本要重写。工具描述和返回格式、参数校验、错误处理全都要根据模型 API 的差异重新适配。

接着是插件化方案。ChatGPT 的 Plugin、各类应用内置的插件市场，确实降低了使用门槛，但它们本质上是平台自己的标准。一个插件能不能被其他宿主应用复用，取决于平台是否开放。如果你想让同一个工具同时被多个 Agent 应用使用，就需要为每个平台维护一份接入代码。

还有一类更原始的方式：把工具执行结果手动塞进上下文。这是很多人每天都在做的事——把表结构复制进对话框、把接口文档粘贴到提示词里、把设计稿标注截图丢给模型。这种方式最灵活，但是成本极高。上下文是“一次性”的，每次都要重新复制；上下文是“静态”的，一旦数据库字段改了，你复制的东西就过时了；上下文还是“污染式”的，大量无关文本堆进模型视野，反而拉低回答质量。

1.3 这背后真正的痛点是“非标准化”

把几种方式放在一起看，它们的共同问题其实是两件事。

第一，工具接入没有统一协议。每个模型 API、每个插件平台、每个 Agent 框架，都有自己的工具定义格式。工具本身是可复用的，但接入层不能。

第二，上下文没有统一的数据通道。就算工具返回了结果，结果怎么进入模型、以什么格式进入、如何控制长度、如何区分“这是工具返回”和“这是用户输入”，也没有统一标准。

MCP 的提出，就是在模型应用和外部系统之间加了一个标准协议层。它的目标不是替代 Function Calling 或插件，而是让“模型如何发现工具、如何调用工具、工具返回的上下文如何被处理”这件事变得可复用、可互操作。这才是它和之前各种工具接入方案最本质的区别。

2. MCP 协议模型拆解：Host、Client、Server 到底在干什么

2.1 三个角色，把“接入”变成了“连接”

MCP 的架构并不复杂。理解它只需要搞清楚三个角色。

你可以把 Host 理解成“人”，Client 是“电话”，Server 是“电话另一头的服务窗口”。人想查数据库，不需要自己去数据库服务器现场操作，只需要通过电话告诉服务窗口“我要查什么”，窗口工作人员搞定后把结果传回来。

MCP Server 不是一个藏在模型里面的“函数库”，它独立于模型运行，通过协议对外暴露能力。这也是为什么同一个 MCP Server 可以在 Cursor 里用，也可以在 Claude Desktop 里用，还可以被另一个自定义应用复用。

2.2 三种核心原语：工具、资源、提示

MCP 协议里定义了三种原语，它们共同构成模型与外部系统交互的“上下文空间”。

• Tools（工具）：可执行的动作，例如“查询订单”“打开网页”“执行一段 SQL”。工具是被模型按需调用的，调用后返回结构化结果。
• Resources（资源）：可读取的数据或上下文，例如“最新的表结构文档”“某个文件的内容”“数据库 schema 快照”。资源相当于协议层面的“上下文供给”。
• Prompts（提示）：可复用的提示模板或交互流程。它不属于工具调用，而是把一套复杂的提示词组织成标准模块，方便 Host 和模型快速进入某个任务形态。

很多人刚接触 MCP 时，会把它简化为“工具调用协议”。实际上，工具只是其中一部分。Resources 解决的是“模型怎么按需拿到上下文”，Prompts 解决的是“模型怎么按正确方式组织任务”。三者合在一起，才构成了“标准化的工具与上下文接入协议”这个完整含义。

2.3 一次完整调用是怎么发生的

把流程拆开看，MCP 调用并没有魔法，它是这样工作的：

1. Host 启动，同时启动 MCP Client。
2. Client 根据配置连接一个或多个 MCP Server，完成握手和协议协商。
3. Client 向 Server 请求能力列表：有哪些 Tools、Resources、Prompts。
4. 这些能力信息传给模型。模型在推理时看到“有一个工具叫 search_note”，于是决定调用它。
5. Host 通过 Client 把调用请求发给 Server。
6. Server 执行真实操作，把结果返回给 Client。
7. Client 把结果整理成协议格式，交给模型继续推理。

整个过程中，模型不直接接触外部系统，Server 也不直接接触模型。它们之间只认 MCP 协议。你可以在任意一侧替换实现：换一个更强的模型，只要它还支持工具调用，MCP 连接不需要重写；把 Server 从 A 服务商换成 B 服务商，只要接口符合 MCP 标准，Host 也不需要改。

这种设计非常像 USB-C 接口：设备内部可以完全不同，但对外接口统一了，就可以互相连接。MCP 做的就是 AI 工具接入层的“USB-C”。

2.4 和 Function Calling、Computer Use 的区别

这里有必要做一个区分，因为热词里同时出现了 Function Calling、Computer Use 和 MCP。

Function Calling 是模型 API 内部的一种约定。它解决的是“模型如何决定调用函数”这个推理环节。而 MCP 解决的是“外部系统如何用统一协议暴露工具和上下文”这个工程环节。两者可以配合使用：MCP Server 暴露能力，Host 利用模型 API 的 Function Calling 能力去决定调用哪个能力。

Computer Use 更不一样。它让模型直接操作图形界面，模拟人的鼠标键盘行为，更像是在做“界面自动化”。MCP 更擅长的是结构化工具接入。虽然以后两者可能组合，但不要把它们当成同一个东西。MCP 的价值在于标准连接，Computer Use 的价值在于视觉和界面操作能力。

3. 从能连到好用：AI 编码里最值得接的四类 MCP Server

3.1 数据库类：让模型基于真实表结构写代码

AI 编码时最让人头疼的幻觉之一，就是模型会编造不存在的字段名和表名。它没见过你的数据库，只能根据常识猜。而数据库类 MCP Server 可以直接解决这个问题。

接上数据库 MCP Server 后，模型可以查询表结构、查看示例数据、在只读模式下执行 SQL。它知道了 order 表有 order_no、user_id、amount 这些字段，再写查询代码就不会凭空发明。

这里有一个重要经验：数据库类 MCP Server 默认应该只读。不要用管理员账号、不要授予写权限、不要允许执行 UPDATE/DELETE/DDL。AI 是辅助工具，它可以读数据帮你写逻辑，但能不能写回数据库，必须由人来做，或者经由审计严格控制的专用通道。

常见的做法是单独建一个只读账号，配置DATABASE_URI时指向该账号，再在查询语句里加 LIMIT。如果你接的是生产库，还要考虑读压力，尽量让 MCP Server 只允许访问需要的库和表，其他全部拒绝。

3.2 设计稿类：让模型能“看见”产品文档

前端开发过去最痛苦的是“AI 看不到设计稿”。你把设计稿截图发过去，模型看到的只是模糊图片，标注、间距、色值都拿不到。

蓝湖、MasterGo、Figma 等设计协作平台都出现了对应的 MCP Server 或插件，目的就是让模型能按需读取设计标注、图层结构、导出切图信息。像初始场景里我接的蓝湖 MCP，本质上就是把设计稿里的结构信息变成模型可读取的上下文。

这类接入的实际效果，不是让 AI 一次性复刻整张设计稿，而是让 AI 在完成某个组件时，先读取相关设计节点，再写代码。顺序很重要：先拉取设计上下文，再生成代码，而不是让 AI 凭空想象。

不过这里要注意，设计协作平台的 MCP 成熟度参差不齐。有的需要访问令牌，有的需要特定客户端版本，有的只是社区项目，更新不及时。接入前要看维护状态，不要选一个已经几个月没更新的 Server，否则后面排查问题时会很痛苦。

3.3 浏览器与端到端测试类：让模型自己验证自己

Playwright MCP 这类服务，把浏览器控制能力暴露给了 AI。模型可以调用工具打开页面、点击按钮、截图、读取控制台日志，甚至跑端到端测试。

这类 MCP 的价值在于“闭环”。以前 AI 写完前端代码，你要自己手动验证。现在模型写完代码后，可以直接调用浏览器工具打开本地页面，检查是否渲染成功、报错信息是什么，再根据真实反馈修改代码。省掉的不只是时间，而是“代码写完就结束”这种断裂的工作流。

但这类工具也要限制使用边界。让 AI 控制浏览器跑测试是可以的，让 AI 在没有人工监督的环境里执行生产环境的“危险操作”就不合适。建议在本地开发服务器或者测试环境里跑，不要直接对着线上系统操作。

3.4 工程系统类：让模型接入仓库、文件和持续集成

GitHub MCP、文件系统 MCP、CI 状态查询这类 Server，是把模型接进工程基础设施。

举个实际例子：模型在一个较大的仓库里修改代码时，经常需要查找相关文件。文件系统 MCP 可以允许模型遍历目录、读取多个文件、搜索关键词；GitHub MCP 可以让模型查看 Issue、分支、PR 状态。这样模型定位问题的能力会强很多，不再只是“猜一个文件路径然后报文件不存在”。

工程系统类的接入还要考虑一个副作用：文件读取范围越大，模型可以上下文的“注意力”越分散。你给了 model 整个仓库的读权限，它不一定变聪明，反而可能被无关文件干扰。最好是按任务范围限定目录，比如当前模块目录、某个 package 目录，而不是把根目录整个暴露出去。

这也是为什么我建议不要一上来就接几十个 MCP Server。工具的个数不是越多越好，上下文的质量才是关键。

3.5 一个最小可落地的 MCP Server 示例

如果你自己想写一个 MCP Server，不必等到所有官方 SDK 成熟。下面是一个“查本地笔记”的最小示例结构，用 Python SDK 的常见写法展示：

from mcp.server.fastmcp import FastMCP mcp = FastMCP("note-server") @mcp.tool() def search_note(keyword: str) -> list: """按关键词查找本地笔记，返回前 20 条标题。""" # 这里是你的实现：读取笔记目录，过滤包含 keyword 的文件 return [] @mcp.resource("note://latest") def latest_notes() -> str: """返回最近 5 条笔记的概要。""" return "note1\nnote2\nnote3" if __name__ == "__main__": mcp.run()

这段代码只展示结构，不包含具体文件读取逻辑。不同版本的 MCP SDK，类名和方法可能存在差异，落地前要查阅对应版本的官方文档。

客户端的 MCP 配置也类似。常见写法是在.mcp.json或claude_desktop_config.json里加一个mcpServers字段：

{ "mcpServers": { "note-server": { "command": "python", "args": ["/path/to/note_server.py"], "env": { "NOTE_DIR": "/Users/you/notes" } } } }

补充一下：“command/args” 怎么填，取决于你的 Server 是进程内启动还是远程 HTTP 服务。示例配置只用于解释结构，真正接入时要以客户端文档为准。

4. 落地边界与排查链路：跑通 MCP 之后，真正的问题才刚开始

4.1 从“本地跑通”到“稳定使用”，差的不是协议，是边界

很多 MCP 教程讲到这里就结束了：安装一个 Server，配置一行命令，重启客户端，工具出现在列表里，成功。但实际落地时，“出现了”和“能用”距离很远，“能用”和“长期稳定用”又差了一大截。

我见过最多的问题，不是 MCP Server 启动失败，而是“工具调通了，但模型变笨了”。原因是工具返回的数据太多，把有限的上文窗口塞满了。

举个例子：数据库 MCP Server 查出一张表的所有数据，返回 10 万行。从协议角度看，调用成功了。但模型在下一步推理时，可能已经忘了用户一开始的问题，只记得眼前这一大堆数据。这就是为什么我一直在强调：MCP 引入上下文的能力越强，越要注意上下文控制。

4.2 输入输出边界：先想清楚“什么能返回给模型”

给 MCP Server 设计工具时，最好先定一个“返回上限”。

比如数据库查询工具，强制在服务端加LIMIT 50，同时只返回指定字段，而不是SELECT *。文件读取工具，限制单文件读取大小，超过 100KB 就返回摘要而不是全文。日志查询工具，只允许查询最近一小时，避免把海量日志一次性丢进模型。

还要考虑到模型的实际上下文窗口。即使某个模型宣称有 200K 上下文，也不等于你应该用满。上下文越长，模型对关键信息的注意力越容易分散。更稳妥的做法是：返回刚好够用的上下文，而不是尽可能多的上下文。

如果遇到“上下文超过限制”或者“模型开始复读之前的内容”，优先检查是不是某个工具返回值过大。不要急着换更大的模型，先把工具返回的“口子”收小。

4.3 安全边界：只读优先、最小权限、白名单

MCP 的本质是把外部系统暴露给模型。暴露这个动作本身，就带来了风险。

我建议按这个顺序做安全加固：

• 数据库连接使用只读账号，不授予写权限。
• 文件系统 Server 只挂载工作目录，不暴露整个磁盘。
• 使用独立的 API Token，不用个人主令牌。
• 把 Token 和敏感配置放到环境变量或 Secret 管理，不要提交到仓库。
• 如果 Server 是远程部署，关闭不必要的端口访问，通过认证和 IP 白名单控制。

不要因为 MCP 是“给 AI 用的协议”就觉得它不需要审计。AI Agent 可能做出超出预期的操作，工具本身必须有“拒绝危险操作”的能力。比如删除文件的工具，至少要二次确认；生产数据库的写操作工具，直接不提供。

4.4 一个可执行的排查链路

MCP 出现问题的时候，很多人会凭感觉胡乱试。这里给一个按层排查的顺序，基本上能覆盖绝大多数场景。

再补充一个顺序：

1. 先看现象：是工具不存在、报错、超时，还是回答质量差。现象不同，入口完全不同。
2. 再看日志：MCP Client 和 Server 的日志是最可靠的证据。图形客户端一般可以在配置里开启 debug 日志。
3. 再看配置：路径、参数、环境变量、Token 是否正确。
4. 再看返回：让 Server 直接手动执行一次，看看原始返回结果是否正常。
5. 最后看上下文：如果工具本身正常，问题往往出在返回内容太大或格式太乱。

记住，不要在“配置对了但没重启”的情况下浪费时间。很多客户端在修改 MCP 配置后需要完全重启才会重新加载，单独重开对话未必生效。

4.5 适用边界：什么场景适合，什么场景要谨慎

MCP 的优点是标准、灵活、可复用，但它不是银弹。它的适用边界很明确。

适合的场景：

• 个人开发工作流，需要让 AI 读取本机文件、数据库结构、设计稿标注。
• 小团队内部工具，统一维护一套 MCP Server，供 Cursor、Claude Desktop 等客户端复用。
• 原型验证和本地测试环境，需要快速跑通某个 Agent 功能。
• 内部知识库查询，通过 MCP Server 把文档、工单、代码片段暴露给 AI。

不适合或需要谨慎的场景：

• 高合规生产环境，特别是金融、交易、风控等对审计和确定性要求极高的系统。MCP 可以做受限网关，但不能直接把生产库暴露给模型。
• 多租户 SaaS 应用。MCP 目前更像是一个优质的单租户/内部接入方案，多租户隔离、配额、计费、审计都还需要额外开发。
• 对响应时间要求极高的场景。MCP 多了一层协议和服务，做得好不会太慢，但不要指望它比本地函数调用更轻。
• 需要模型执行危险写操作的场景。AI 的不确定性加上工具的破坏性，结果很难保障。

5. 长期价值：把“上下文工程”变成一种可复用的基础设施能力

5.1 MCP 表面是协议，本质是“上下文总线”

如果只把 MCP 理解成一个“工具接入标准”，格局就小了。它的长期影响其实在上下文工程这个层面。

AI 应用里最难的不是模型选型，不是提示词，而是“怎么在正确的时间，把正确的上下文，以正确的形式，送给模型”。以前这件事靠人肉复制、靠提示词堆砌、靠各种临时脚本。MCP 提供了一条更规范的路：外部系统通过 Server 主动“供给”上下文，模型按需“拉取”，Host 负责连接和转发。

这就是上下文数据流的典型形态：不是把所有内容塞进一段提示词，而是拆成“发现能力—按需调用—返回结果—写回上下文”四个阶段。MCP 正是为这条数据流提供了一个标准化的承载层。

5.2 工作流会有什么变化

习惯 MCP 之后，你会发现自己的 AI 编码方式变了。

以前你想让 AI 完成一个任务，需要把所有相关上下文写进提示词：“这是表结构，这是接口文档，这是设计稿，请按这些生成代码。”现在你只需要说“看一下 order 表结构，查一下接口文档里订单状态的定义，然后帮我写一个订单列表组件”。模型在你允许的范围内，自己去读取这些数据。

这个变化看起来只是少了几步复制粘贴，实际上是人和模型的协作方式发生了变化：从“你把上下文喂给模型”变成了“你和模型共享一套可访问的上下文环境”。

更长远看，团队可以沉淀一整套 MCP Server 集合作为“团队上下文基础设施”。新成员接入时不需要手动整理上一堆文档，而是直接配置好 MCP Server 列表，AI 就能读取团队规范、代码库结构、运维手册。这比任何“如何写提示词”的规范都更接近工程化。

5.3 一个可复用的 MCP 落地四步框架

如果你现在打算在自己的项目里引入 MCP，我用一个简单的四步框架建议你开始。

第一步，找准一个高频的重复劳动。不要一上来就接十个 Server。先想清楚你最痛的点是什么：是模型总编造数据库字段？是前端还原设计稿费劲？是 Agent 自己写代码但没人验证？选一个。

第二步，选一个最小可验证的 MCP Server。优先选官方维护、社区活跃、文档齐全的 Server。没有现成的就自己写一个简单工具。先让它解决一个具体问题，比如“查询笔记”“读取环境变量文件”。

第三步，用只读、小样本跑通。先不开写权限，不接生产库。用一个测试库、一个小目录，验证工具的输入输出、返回格式、上下文占用是否符合预期。跑通后记录日志，观察模型在不同提示词下的表现。

第四步，固化配置和权限基线。当某个 MCP Server 被证明有用，再把它写进团队配置模板，把敏感信息放到密钥管理，把 Server 部署方式文档化。这时它才从一个临时试验变成了基础设施。

5.4 一点提醒：MCP 不会消除幻觉

最后提醒一句：MCP 能解决“工具能不能连上”“上下文怎么传”，但它解决不了“模型做得对不对”。

模型拿到真实数据后，仍然可能推理错误；工具返回正确结果后，模型仍然可能过度解读；你给了再好的上下文，模型仍然可能产生幻觉。MCP 只是让上下文接入变得更标准、更可控，而“如何设计上下文边界”“如何审核模型输出”“如何避免把不可逆操作交给 AI”，依然要靠人来把握。

这也是为什么我会反复强调只读优先、最小权限和人工确认。工具协议可以让连接变得标准化，但能不能用好这个连接，永远取决于使用者的工程判断。

MCP 真正值得长期关注的原因，不是它会在短期内取代所有插件和函数调用，而是它把“工具接入”和“上下文管理”这两件原本分散的事，收拢成了标准化的协议能力。对普通开发者来说，早一点理解它，就能早一点把重复的上下文搬运工作交给系统，把判断和决策留给自己。