Coinbase 用 MCP 把 AI 幻觉关进笼子：设计到代码的真正拐点

当大厂都在抱怨 AI 写代码“不靠谱”时，Coinbase 反其道而行：不是调教模型，而是重构上下文。他们用 MCP 把设计系统直接接入 AI，让设计到代码第一次变成可规模化的事。

5000 个 PR/周的公司，最先被 AI“坑”了一把

Coinbase 有一个听起来就让人头皮发麻的数据：5000 名员工、其中一半是工程师，每周合并约 5000 个 PR，代码最终服务的是全球上亿用户、5000 亿美元级别的资产规模。在这种体量下，任何一点效率问题都会被指数级放大。

AI 编程工具刚进入 Coinbase 时，气氛一度很亢奋。Cursor、Cloud Code 上线后，工程师们发现“写得真快”。但很快，Slack 里开始出现熟悉的问题：AI 发明了不存在的组件、瞎编 props、完全无视设计系统。最讽刺的是——AI 越聪明，工程师在中间当“翻译”的成本越高。

一句话总结当时的状态：我们在用 AI 加速开发，但同时也在更快地制造偏离设计系统的技术债。

设计系统不是文档，而是 AI 的“现实世界”

Coinbase 的解法不是继续给 LLM 写更长的 prompt，而是回到一个被长期忽视的问题：AI 根本不知道你的设计系统长什么样。

他们的设计系统 CDS，从 2021 年开始构建，横跨 Web 和 Mobile，100+ 组件、8 个大版本，内建可访问性和复杂的 design token 体系。这套系统对人类工程师很友好，但对 LLM 来说几乎是“隐形的”。

最早的尝试，是给每个组件写 context file，喂给 AI。效果确实立竿见影：代码质量和正确性明显提升。但新问题立刻出现：上下文太占 token、维护成本爆炸、组件一变所有文件都要跟着改。

于是他们遇到了 MCP（Model Context Protocol）。这是 Anthropic 推出的开放协议，本质只有一件事：让模型按需获取上下文，而不是一次性塞给它。这成了整个故事的转折点。

MCP + CDS：把“别乱写代码”这件事自动化

Coinbase 为 CDS 搭了一个极简 MCP Server，只提供两个工具：

• 一个“鸟瞰视角”，告诉 LLM 现在有哪些组件，但不给细节
• 一个“单组件查询”，只在需要时返回 import 路径、示例和 props

效果非常反直觉：上下文更少了，结果反而更准了。Token 使用量下降，幻觉显著减少，设计到代码的路径第一次变得顺滑。

更关键的是，这套机制直接嵌进了 Figma 的设计到代码流程。工程师在 Figma 里点一个组件，就能看到真实、可用、符合 CDS 的代码，而不是“看起来差不多”的伪实现。

Sid 在分享中说，这个组合“完全改变了我们把设计变成代码的方式”。翻译成人话就是：AI 第一次开始像一个真正了解公司内部规则的同事。

当 MCP 成为基础设施，变化开始失控式扩散

设计到代码只是起点。Coinbase 很快意识到：如果 MCP 能解决上下文问题，那它几乎可以接管所有“需要理解内部知识”的 AI 任务。

他们又做了一个 MCP：SourceCraft，直接索引所有代码仓库。现在，工程师可以用自然语言问：设计系统用了多少？哪些地方用错了？哪些组件该被废弃？以前要几天甚至几周的分析，现在几分钟搞定。

接下来发生的事更像“组织层面的化学反应”：一个内部 MCP 应用商店上线，任何团队都能一键把 MCP 装进自己的 AI 工具。100 天内，100+ MCP，上线调用超过 100 万次。

设计师和工程师开始在同一个 playground 里协作，用 MCP + AI 快速做原型，直接丢 Vercel 链接。原本只存在于 Figma 的想法，开始自然“毕业”到生产代码。

总结

Coinbase 这个案例给 AI 从业者一个极其重要的提醒：问题往往不在模型，而在上下文。与其抱怨 LLM 幻觉，不如反问一句——你有没有给它一个可被机器理解的“现实世界”？MCP 的意义，不只是省 token，而是把企业内部知识变成一种可调用的基础设施。如果你在做 AI 编程、Agent 或内部工具，现在就该思考：你的系统，是否已经准备好被 AI 正确地使用？

关键词： MCP， 设计系统， AI Agent， 大语言模型， Coinbase

事实核查备注： 需核查：Coinbase 员工数量（约5000）、每周 PR 数量（约5000）、CDS 组件数量（100+）、MCP 协议由 Anthropic 提出、内部 MCP 数量（100+）、调用次数（100 万次）、视频发布时间（2025-11-13）