MCP的陷阱。Lovable事件两个月后，我改变的三件事

“你连了几个MCP服务器？“被问到这个问题时，能答出三位数的人正在悄悄增多。

我差点也成了其中之一。一个接一个地添加MCP服务器，心想着只要让Claude Code”看到所有东西”，它就能完美地写代码。

然而到了2026年5月，这个前提开始悄然动摇。来自微软和海外安全媒体的警告指向同一个方向：“MCP服务器加得越多，AI反而越笨”，“便利性的代价还没以账单的形式到来”。

导火索是4月的Lovable漏洞报道。大约两个月过去了，我想以一个曾经受挫、后来重返编程的工程师视角，整理一下AI编程实战的变化。包括我自己在本地踩过的坑，以及本周开始改变了哪些工作方式。

---

“MCP越多=越聪明”是一种误解

首先要厘清的是，对MCP的期待值出了偏差。

MCP（Model Context Protocol，模型上下文协议）是Anthropic发布的连接规范。它充当LLM智能体（如Claude）与外部工具和数据源之间的桥梁——GitHub、Slack、本地文件系统、数据库、浏览器操作。人们把它比作AI的”USB-C”：将智能体与外部世界相连的通用接口。

但USB-C这个比喻遮蔽了一个重要的事实。同时插入五根USB-C线并不会让你的电脑性能提升五倍，反而可能因为电源管理和带宽分配而产生混乱。同时连接多个MCP服务器也有着类似的结构。

连接多个MCP服务器后，智能体首先需要决定调用哪个工具。在五个选项和五十个选项之间，选择精度会发生变化。实际跑过Claude Code的人应该有感觉：当MCP工具超过两位数，第一次就选错工具的频率明显上升。

据多家二手媒体报道，微软在内部技术博客中，在智能体评估的语境下指出了类似的趋势：“工具选择精度并不随工具数量单调增加”，“添加MCP服务器是在便利性和判断噪声之间做权衡”。目前我无法找到一次URL，但以”多家二手媒体报道”的层级来处理这一信息。

我自己曾经同时开启了大约15个MCP服务器。GitHub、Linear、Notion、Slack、本地DB、图像生成、数据可视化、PDF读取、浏览器、公司内部API等等。第一周简直是感动连连，所有东西都能从Claude Code调用。

到了第二周，奇怪的行为开始增多。只想更新一个GitHub Issue，却去尝试更新Linear工单。拉取Slack私信，内部API搜索却跑了起来。“工具选择错误”持续累积。

在便利性的背后，智能体被不断增加的选项所困扰。MCP越多不等于越聪明，而是判断成本呈指数级增长。这是2026年5月的现状。

---

Lovable事件两个月后，积累了哪些变化

让我把时钟倒拨一点。

2026年4月1日，我以Lovable漏洞报道为起点，写了一篇关于AI编程安全风险的文章。部分AI生成的应用存在认证绕过、权限泄漏等大范围漏洞，内容来源于一项类Tenzai的安全调查。

写那篇文章时，论点聚焦于”生成代码本身的漏洞”。LLM写出的代码中混入了初学者难以察觉的安全漏洞——这是大多数读者能够直观理解的问题。

然而，从4月下旬到5月，论点悄悄偏移了一步。问题不再只是”生成的代码”，而是延伸到了”智能体所连接的路径”本身。

具体而言，以下类型的报道和讨论持续积累：海外安全媒体开始关注AI编程环境中的供应链污染，以及恶意MCP服务器混入的风险；部分开源MCP服务器的实际权限范围比文档描述的更广；企业内部部署的智能体可能在无意中将SaaS认证信息泄露给外部。这些风险已进入讨论视野。

据多家媒体报道（一次URL未确认），部分内容在Infosecurity Magazine 2026年的AI编程专题中有所涉及，其方向与我自己的本地体感相吻合。

也就是说，“Lovable事件”并不是一次孤立的事件，而是一个入口。从生成代码的漏洞，到智能体周边基础设施的漏洞——AI编程所涉及的风险领域在这两个月内确实在扩大。

这里最重要的一点是：这并不意味着”所以我们停止使用吧”。我完全没有停止AI编程的打算。恰恰相反，接下来几个月，建立了运营规范的人与没有建立的人，所承受的损失总量将会大相径庭。

---

AI编程2026的结构性风险全景

在这里我想先发散一下。以我的实战感觉，梳理出2026年5月时点的结构性风险全景。

逐一说明这五个圆圈。

第一，生成代码的漏洞。这是2026年初之前讨论的核心。LLM生成的代码中包含认证缺陷、权限泄漏、SQL注入、XSS等问题。Lovable类事件让这一问题被广泛可见化。作为基线风险，它至今仍然存在。

第二，MCP过度连接。除了前一章提到的工具选择错误增加之外，连接的MCP服务器越多，原本应该隔离的数据越容易混在一起。“想更新Slack却调用了内部API”的智能体误操作，在数据管理严格的环境中是致命的。

第三，开源MCP服务器的权限范围。GitHub等平台上发布的MCP服务器中，有些README写着”只读”，但代码里却有写入权限。我自己因为省略了使用前的代码审查，差点将不必要的权限授予MCP。

第四，认证信息的意外路径泄漏。在本地运行MCP服务器时，API令牌和认证信息通常通过环境变量传递。通过对话历史、日志、截图等途径，认证信息流入意想不到的地方的风险不容忽视。习惯直接把日志粘贴到Slack的人，在结构上最容易踩这个坑。

第五，供应链污染。通过npm或pip包混入恶意MCP服务器、悄悄寄生在开发者本地环境的可能性也已被指出。据报道，Lovable事件后，海外安全研究者一直在持续分享这方面的担忧。

这五个圆圈并不是相互独立的。一个圆圈被突破，就会波及相邻的圆圈。正因如此，“一口气全部处理”只会让人心力交瘁。

以上是发散。下一章，我把它压缩成三点。

---

我在本地环境踩过的三个”MCP过度连接”坑

在压缩之前，先讲三个亲身踩过的案例。希望读者不要重蹈覆辙，先把坑分享出来。

第一个：Linear和GitHub的混线。

我用Linear管理内部任务，用GitHub管理代码。当我让Claude Code”针对这个Issue开一个PR”时，智能体把GitHub的Issue和Linear的工单搞混了。Linear的工单编号和GitHub的Issue编号恰好格式相同——“LIN-142”和”#142”——智能体因此选错了。

损失很小，没有影响到生产环境。但一想到如果当时连接了生产数据库的MCP服务器也是开启状态……冷汗直冒。

第二个：写着只读的MCP服务器，其实也能写入。

我在本地安装了一个图像管理类的开源MCP服务器。README上清楚地写着”read-only”。开始使用一周后，重新读代码才发现，删除API的调用函数被正常实现了进去。README和实现之间存在出入。

我使用前没有读代码，这是我的问题。开源MCP服务器，不能只看许可证和README，必须读实现代码。

第三个：差点把含有令牌的日志直接粘贴到Slack。

有一次我想把Claude Code的输出日志粘贴到内部Slack，分享”遇到了这个报错”。千钧一发时发现，日志里混入了API令牌的片段。不是完整泄漏，但根据设置，完全有可能把整个日志粘贴出去。

乘着便利的顺风继续跑，这种陷阱就看不见。“先分享坑”是Gen文章的原则，所以我想先把自己的失败列出来。

---

本周开始改变的三项预防措施

现在压缩。从五个风险领域、三个失败案例，缩减到本周开始要改变的三项预防措施。

第一项：同时连接的MCP控制在”3个以内”。

这里说的3个只是参考值。我的本地观测（主观感受）： 同时连接2~4个时运行最稳定。GitHub、本地文件系统，加上当前项目专用的一个SaaS——这三个能处理大多数工作。其余的改为”切换项目时启用，结束后禁用”的轮转运营方式。

在能通过配置文件开关智能体的环境中，最好把”常驻启用”组和”按需启用”组分开管理。Claude Code系的话，在配置里只开启需要的三个，其余注释掉休眠。这样做之后，智能体的判断错误明显减少了。

第二项：开源MCP服务器，读完代码再启用。

README是作者的意图，代码是实际行为。两者出现偏差并不罕见。这里给出一个具体的确认步骤。把MCP服务器提供的工具列表（大多以JSON schema定义了工具名和参数），与内部调用的API函数进行比对。如果原本应该是只读的MCP在调用写入或删除系的API，就先停止连接到生产环境。

“全部都读，不可能”——我理解这种感受。实际上，我自己每个MCP服务器也投入不了超过30分钟。但最低限度，有两点要看：“工具定义列表”和”调用的HTTP方法”。如果只出现GET，可以基本信任为只读；如果混入了POST/DELETE/PUT，就要确认README和实现是否存在出入。

在终端快速确认的方法也写一下。如果MCP服务器的源代码在src/目录下，用以下命令可以在30秒内提取出写入系API的调用。

# 确认开源MCP服务器的写入系API（即便README写着READ-ONLY也一定要跑一遍）
grep -rE "(DELETE|POST|PUT)" src/

没有输出就基本安全。有输出的话，对照README确认后再判断是否连接到生产环境。

第三项：把日志粘贴到外部之前，必须搜索令牌字符串。

我使用的是grep -E "sk-|ghp_|xoxb-|Bearer "这样的简易搜索，涵盖了OpenAI、GitHub、Slack、Bearer令牌的典型前缀。如果公司内部SaaS有专属令牌格式，就根据内部密钥管理器的命名规则添加搜索模式。

# 复制日志前先跑一遍简易检查
grep -nE 'sk-[A-Za-z0-9]{20,}|ghp_[A-Za-z0-9]{20,}|xoxb-[A-Za-z0-9-]{20,}|Bearer [A-Za-z0-9._-]{20,}' \
  ./logs/claude-code-*.log

这个检查我在”把日志粘贴到Slack之前”和”写博客案例之前”这两个时间点必跑。坚持7天，手就会自动动了。

三项预防措施回顾：MCP最多3个、开源MCP读完代码再启用、粘贴日志前搜索令牌。顺序不限。本周内把三项都跑一遍，是现实可行的起点。

---

同行的视角与我的立场

这里想整理一下我的立场。

我是AI编程的推进派。无论写多少遍，这一点都不会变。Cursor、Claude Code、各类MCP服务器、IDE插件——这些都是提升开发体验上限的工具。CS和业务侧的人能重新回到代码，这些工具也是原因之一。

尽管如此，我写预防措施的原因，是因为这与Nagi的文章反复提及的”AI智能体正式进入生产运营阶段”的话题一脉相承。在实验阶段，事故可以成为学习。但一旦投入生产，同样的事故就会影响到客户和同事。

Nagi写的AI智能体进入运营阶段这一论述，和我这里写的”MCP控制在3个以内”这一运营层面的节制，是从不同角度看向同一片风景。深层的技术架构留给Nagi的文章，我写的是从自己的工作台能看到的风险轮廓。

Masago一直对我说：“如果你太兴奋，就问自己——这真的很神吗？“Lovable事件后，我自己也乘着MCP的便利顺风跑，多次把警告信号当作耳边风。没有Masago式的冷静，我恐怕需要更长时间才能总结出这三项预防措施。

Mikoto大概会问的问题我也先回答了：“那么，这到底对谁有帮助？“答案是：所有开始把AI编程投入生产运营的人。尤其是不以工程师为主业的人——在CS和市场营销岗位自己开发业务工具的人、自由职业开发者。所有不想在乘着便利顺风跑的时候被割断脚跟的人。这三点，是我本周想让这些人改变的。

---

总结——便利与安全的平衡点

把以上内容压缩一下。

“MCP服务器越多，智能体越聪明”这个前提，在2026年5月已经开始崩塌。工具选择的判断成本增加，便利性的代价是精度下降——这种现实已经出现。

Lovable事件约两个月后，论点从”生成代码的漏洞”扩展到了”智能体所连接的路径”整体。AI编程的风险领域扩展到了五个：生成代码漏洞、MCP过度连接、开源权限范围、认证信息路径泄漏、供应链污染。

我自己在本地踩了三个坑。Linear×GitHub混线、写着只读的开源MCP其实也能写入、日志里混入令牌差点粘贴到Slack。三个都没有演变成生产事故，但根据设置，任何一个都可能是危险的。

三项预防措施，最终缩减如下。同时连接的MCP服务器控制在3个以内、开源MCP读完代码再启用、把日志粘贴到外部前先搜索令牌。顺序不限。本周内把三项都跑一遍是现实可行的起点，习惯也会慢慢养成。

最后一点。AI编程没有结束。只是进入了寻找便利与安全平衡点的运营阶段。这些工具是让我——曾经受挫、一度远离代码的我——重新回来的原因。我完全没有放弃的打算。

但乘着便利的顺风继续跑，那是另一个阶段的事了。本周只改变三件事。MCP控制在3个以内、开源代码读完再启用、粘贴日志前先搜索令牌。仅此三点，就能在本地防住Lovable事件后两个月积累的相当一部分风险。

便利与安全，两者我都不放弃。这是Gen选择的平衡点。