最近同时在用 Claude Code 和 Codex 两套 AI 编程环境做前端 UI 设计工作，都需要接 Figma、接主题库、接文档源。用下来发现一个事：同样是"让 AI 用上外部工具"，这两家走的是完全不同的路子。今天把两边的真实配置过程和踩坑记录整理出来，给同样在搭 AI 工具链的朋友做个参考。

先说清楚：MCP 是什么

MCP（Model Context Protocol）是让 AI 模型接入外部工具的协议标准。简单理解：AI 本身只会"聊天"，MCP 相当于给它装了一堆"手"——读 Figma 文件、查最新文档、存跨会话记忆，都是通过 MCP Server 实现的。

关键问题是：这些 MCP Server 怎么接进来、密钥存在哪、出问题了能不能查——这两套工具给出的答案完全不同。

路子一：Codex 的"托管插件式"

Codex 这边的接入方式是：

Codex App 内置插件市场 → 安装 Figma、mcp-vibe-ui 等工具 → 通过 OAuth 或平台托管授权 → MCP 工具自动出现在可调用工具列表里

我实际接的是 Figma MCP 和 mcp-vibe-ui。整个过程就是在插件市场里点启用、走一遍账号授权，工具列表里就出现了 mcp__codex_apps__figma。用 _whoami 验证账号身份（返回 seat: Full, tier: pro），再通过文件链接读节点、创建文件，全部跑通。

这种方式最大的特点是：配置过程对用户几乎不可见。没有 JSON、没有本地进程、没有 Token 管理，一切都在云端完成。

路子二：Claude Code 的"本地自部署"

Claude Code 这边完全是另一套逻辑：所有 MCP Server 在 .claude.json 里手工声明，支持三种传输模式——本进程启动（stdio）、远程连接（SSE/HTTP）、OAuth 授权。没有插件商店，配置全靠自己写。

以 Figma 为例，实际的 OAuth 声明结构是：

• type
  : oauth
• clientId
  : figma_oauth_client_xxxxxxxx
• authorizationEndpoint
  : figma.com/oauth/authorize
• tokenEndpoint
  : api.figma.com/oauth/token
• scopes
  : files:read, files:write

认证走的是标准 OAuth 2.0 授权码流程：终端打印授权链接 → 浏览器点 Allow → 本地临时服务器捕获回调 → 用授权码换 Token → Token 存进系统凭据管理器（Windows 凭据管理器 / macOS Keychain）。整个流程 1-2 分钟，之后自动续期。

再比如接 mcp-vibe-ui（一个内置 15 套 Tailwind 主题的工具），配置是一段明确的声明：

• type
  : stdio
• command
  : npx
• args
  : -y, mcp-vibe-ui

type: stdio 意味着这个 MCP Server 是作为本机子进程运行的，通过标准输入输出跟 Claude Code 通信——网络请求从你自己的机器发出，IP 是你自己的。

三个真实踩过的坑

坑一：重复配置导致工具列表混乱

Figma MCP 有 figma（稳定版）和 figma-dev（沙箱版）两个变体，功能几乎重叠。同时配置会导致工具列表里出现两份同名工具，AI 调用时容易选错。解决方式很直接：只留一个，删掉冗余的那个。

坑二：明文 Token 的泄露风险

Figma 早期用 Personal Access Token 的方式，Token 会以明文写进 .claude.json——如果这个配置文件不小心提交到 Git，密钥就泄露了。换成 OAuth 之后，Secret 存进系统凭据管理器，配置文件里只留 clientId 这种公开值，风险明显降低。

坑三：OAuth 授权依赖桌面环境

OAuth 流程需要弹浏览器、需要本地 HTTP 回调，如果 Claude Code 跑在没有桌面的远程服务器上（比如 SSH 连接的 Ubuntu Server），这套流程直接跑不通。解决办法：先在本地 Windows/Mac 上完成认证，Token 存在用户目录，跟项目文件无关，可以单独同步过去。

顺带提一句 Codex 那边的机制：还接了一个叫 context7 的工具，专门解决"AI 写的代码用的是旧版 API"这个问题——因为大模型训练数据有截止日期，遇到新版本的库（比如 PrimeVue v4），AI 可能按旧版语法生成代码，运行时直接报错。context7 的做法是在生成代码前，实时从官方文档拉最新的 API 签名喂给 AI，让生成的代码跟你实际装的版本对得上。这个工具两边理论上都能装，属于"版本漂移"这个具体问题的解法，不属于托管还是自部署的路线之争。

两种路子，本质上是什么差异

拆开看，核心差异就三条：

• 配置可见性
  Claude Code 的配置是一份你能打开、能读懂、能修改的 JSON 文件；Codex 的配置在云端，你看不到底层结构。
• Token 归属
  Claude Code 的密钥存在你自己电脑的系统凭据管理器里；Codex 的密钥存在平台云端，用户拿不到也看不到。
• 网络出口
  Claude Code 的请求从你自己的 IP 发出；Codex 的请求从平台服务器发出。

优缺点也很对称：Codex 的托管式换来的是零配置、开箱即用、自动更新，代价是不透明、依赖网络、出问题时排错空间有限；Claude Code 的自部署式换来的是完全透明、可离线、安全可控，代价是需要自己懂配置、遇到问题要自己排查。

该怎么选

如果只是想快速验证一个设计想法、不太在意底层怎么跑的，托管插件式更省心，点几下就能用。

如果涉及需要长期维护的生产环境、需要接自建或内网的非标工具、或者对密钥归属有明确要求（不能离开本地机器），自部署式是唯一选项——Codex 目前不支持自定义 MCP Server。

两者也不是非此即彼。我自己的做法是：深度代码工作用 Claude Code（配置灵活、可控），轻量设计协作用 Codex（开箱即用、省心）。工具选型这件事，从来不是选"更好的"，而是选"跟当前任务匹配的"。

如遇到配置问题，可以直接和你的AI沟通，它会教你如何处理：

Codex配置Figma的时候，需要通过Share功能，产生项目链接分享处理。

Claude Code需要你进入Figma设置里，在Security里创建Personal access tokens，然后把创建的tokens给到你的Claude Codex，它就可以完成配置了。

零代码AI编程交流，欢迎私信交流。