AI编程的天花板，不是模型智商

你有没有过这种体验——

打开 Claude Code，信心满满地说：”帮我把这个设计稿还原成页面。”然后 AI 回你一句：”请提供设计稿的详细描述。”

你深吸一口气，开始手动描述：顶部导航栏，高度 64px，背景色 #1a1a2e，左边一个 logo，右边三个菜单项……

打了二十分钟字，你突然意识到：你正在用人肉 OCR 的方式，把一张 Figma 设计稿翻译成自然语言，再喂给一个号称”智能”的 AI。

这个画面，怎么看怎么魔幻。

问题出在哪？不是 Claude 不够聪明——同样的模型，给它足够的上下文，它能写出让你惊艳的代码。问题是，它看不见你的设计稿，读不到你的接口文档，摸不着你的数据库。

它不是智商不够，是感官被剥夺了。

一个协议，给 AI 装上了”眼睛和手”

2024 年底，Anthropic 发布了一个叫 MCP（Model Context Protocol）的开放协议。名字很学术，但干的事很直白：

让 AI 工具直接连接你的设计稿、接口文档、数据库、部署系统——不再需要你当中间人。

打个不太恰当的比方：以前的 AI 编程助手像一个被关在小黑屋里的天才程序员，你只能通过门缝塞纸条跟他沟通。MCP 做的事，就是把墙拆了，让他直接走进你的办公室，自己看屏幕、翻文档、查数据库。

技术上怎么实现的？很简单——MCP 定义了一套标准的”插头”规范。任何工具只要按这个规范做一个 MCP Server，AI 就能直接调用它。就像 USB 协议让所有设备都能插到电脑上一样，MCP 让所有开发工具都能”插到” AI 上。

不需要每个 AI 工具单独做适配，不需要写复杂的 API 胶水代码。一个协议，全部打通。

Before vs After：同一个需求，两种人生

光说概念太抽象，来看一个真实场景：产品经理丢给你一个需求——”把这个用户资料页面重新设计一下，接口用 YApi 上的那套。”

没有 MCP 的你：

  1. 打开 Figma，截图或手动描述每个组件的布局、颜色、间距
  2. 打开 YApi，复制接口文档的 URL、请求参数、返回字段
  3. 把这些信息整理成一大段 Prompt，粘贴给 AI
  4. AI 生成代码，但用的字段名和接口文档对不上
  5. 手动对照修改，来回三次
  6. 发现设计稿里有个渐变色你没描述清楚，AI 用了纯色
  7. 再改……

整个过程，你有一半时间在当”人肉翻译器”。

有 MCP 的你：

  1. 告诉 AI：”读取 Figma 上这个页面的设计稿，用 YApi 上用户资料的接口，生成前端页面”
  2. AI 通过 Figma MCP 直接读取设计稿的组件树——颜色、间距、字体、层级关系，一个不漏
  3. AI 通过 YApi MCP 直接拉取接口定义——字段名、类型、校验规则，原封不动
  4. 生成代码，设计还原度 90%+，接口字段完全匹配
  5. 你只需要微调业务逻辑

同一个需求，前者两小时，后者二十分钟。差距不在 AI 的能力，在于 AI 能拿到多少上下文。

这就是为什么我说，AI 编程的天花板不是模型智商，而是”上下文饥渴”。MCP 解决的，正是这个饥渴问题。

MCP 前后工作流对比：从人肉翻译到直连工具链

五个现在就能用的 MCP Server

说了这么多，落地才是硬道理。以下五个 MCP Server，覆盖了大多数开发者的日常场景，而且现在就能装、现在就能用。

1. Figma MCP —— 让 AI 直接”看”设计稿

不用再截图、不用再口述。AI 直接读取 Figma 文件里的组件树，包括颜色值、间距、字体大小、图层关系。设计还原从”看截图猜”变成”读数据做”。

适用场景：前端页面开发、设计稿走查、UI 组件生成。

2. GitHub MCP —— 让 AI 理解你的项目全貌

AI 可以直接读你的仓库代码、Issue 列表、PR 历史、CI 状态。不用再手动粘贴代码片段、不用解释”这个函数在 src/utils/auth.ts 的第 87 行”。

适用场景：代码审查、Bug 定位、写技术文档。

3. 数据库 MCP —— 让 AI 直接查数据

连上 PostgreSQL、MySQL 等数据库，AI 可以直接查询表结构、查看示例数据、生成 SQL。写后端接口时，不用再手动告诉 AI “users 表有 id, name, email, created_at 这几个字段”。

适用场景：后端开发、数据分析、SQL 调优。

4. 浏览器 MCP（Playwright/Puppeteer）—— 让 AI 看到页面长什么样

AI 可以打开浏览器、访问 URL、截图、读取 DOM。你说”这个页面的按钮点了没反应”，AI 直接打开页面自己看、自己试，不用你截图描述半天。

适用场景：E2E 测试、前端调试、页面可访问性检查。

5. 文件系统 MCP —— 让 AI 操作本地文件

读写本地文件、遍历目录、搜索代码。这是最基础也最实用的 MCP Server——Claude Code 等工具本身就内置了这个能力。

适用场景：代码重构、配置管理、日志分析。

一个小建议：不要贪多。先挑一个和你日常工作最相关的 MCP Server 装上，体验到”哦，原来还能这样”的那个瞬间，你自然会想装第二个。

别急着 All In，风险也要看清楚

MCP 很好，但不是万能的。任何头脑清醒的开发者在拥抱新工具前，都应该看看它的另一面。

安全权限是最大的隐患。

MCP Server 本质上是给 AI 开了一扇门——让它能读你的设计稿、查你的数据库、操作你的文件系统。这扇门开得不对，后果可以很严重。

想象一下：你装了一个数据库 MCP，AI 不仅能查数据，还能执行 DROP TABLE。或者一个第三方的 MCP Server，看起来功能正常，但在背后把你的代码偷偷发送到了某个服务器。

目前 MCP 生态还处于早期，Server 的质量参差不齐。有些是官方维护的，质量有保障；有些是社区个人开发者写的，可能连基本的权限控制都没做。

几个实操建议：

  • 只用可信来源的 MCP Server（官方推荐、知名开源项目）
  • 数据库 MCP 一定要用只读权限的账号连接
  • 在不需要的时候关闭 MCP Server，不要 24 小时挂着
  • 敏感项目（涉及用户数据、支付系统）慎用第三方 MCP
  • 定期检查 MCP Server 的更新日志，留意安全补丁

另一个现实问题：MCP Server 的质量落差。

有些 MCP Server 做得非常好，API 设计清晰、错误处理完善、文档齐全。有些则连基本的边界情况都没考虑——大文件读取超时、特殊字符导致解析失败、并发请求时直接崩溃。

在这个生态成熟之前，”踩坑”是每个早期用户的必修课。好消息是，MCP 社区正在快速成长，Anthropic 也在推动标准化和安全审计。

下一个竞争力：不是”会写 Prompt”，而是”会搭工具链”

过去两年，”Prompt 工程”是 AI 编程圈最热的词。大家研究怎么写 Prompt 能让 AI 输出更好的代码，各种 Prompt 模板、最佳实践、框架层出不穷。

但如果你仔细想想，Prompt 工程本质上是在做什么？是在用自然语言，手动弥补 AI 缺失的上下文。

你写一段很长的 Prompt 告诉 AI “这个项目用 React + TypeScript，状态管理用 Zustand，路由用 React Router v6，接口返回的用户对象有 id、name、avatar 三个字段”——这些信息，本来 AI 自己就应该能拿到的。

MCP 做的事，就是让 AI 自己去拿这些信息，不需要你手动喂。

当 MCP 生态足够成熟的时候，”怎么写 Prompt”的重要性会大幅下降，”怎么搭工具链”的重要性会大幅上升。

你和另一个开发者用同一个 AI 模型，写同样的 Prompt。但你的 Claude Code 连着 Figma MCP + GitHub MCP + 数据库 MCP + Sentry MCP，而对方只有一个光秃秃的聊天窗口。你们的生产力差距，可能不是 20%，而是 5 倍。

AI 编程的进化路径越来越清晰了：

第一阶段：复制粘贴代码片段给 AI（2022-2023） 第二阶段：学会写高质量 Prompt（2023-2024） 第三阶段：用 MCP 搭建 AI 工具链（2025-）

每个阶段都在做同一件事——降低”人-AI”之间的信息损耗。只不过前两个阶段靠的是人的努力（你多打几个字），第三个阶段靠的是基础设施的升级（让 AI 自己获取信息）。

这个方向不可逆。AI 不会变回只能通过聊天窗口交流的工具，就像我们不会回到用软盘拷贝代码的时代。

所以，与其继续在 Prompt 的措辞上死磕，不如花点时间研究一下 MCP 生态。装一个 Server 试试，感受一下 AI “能看见你的项目”时的那种流畅体验。

那种”它终于懂我了”的感觉，不是更好的 Prompt 能给的，而是更完整的上下文能给的。

AI 编程进化路径：从 Prompt 工程到 MCP 工程