1. 打工人效率困局为什么Codex插件值得认真折腾每天打开IDE的第一件事是什么等索引、等加载、等AI助手转圈圈。写代码的时间可能只占工作日的一半剩下的一半全耗在工具链切换上——查文档切浏览器、画原型切设计工具、调接口切调试面板、写注释切翻译软件。这种碎片化的操作模式一天下来光是窗口切换就能吃掉一两个小时。Codex本身是一个代码智能辅助工具它的核心能力在于理解代码上下文、生成补全建议、辅助诊断问题。但很多人装完Codex之后只用了最基础的功能就像买了台高配电脑只拿来打字。真正让Codex从能用变成好用的是插件生态和MCP协议带来的扩展能力。MCP是什么全称Model Context Protocol翻译过来叫模型上下文协议。你可以把它理解成一座桥——桥的一头是Codex这个AI大脑另一头是各种外部工具和数据源。没有这座桥的时候AI只能看到你当前打开的文件有了这座桥AI就能读取你的设计稿、访问你的接口文档、操作你的浏览器、甚至帮你管理项目文件。这就是MCP的核心价值让AI从只能聊天变成能干活。这篇文章适合哪些人看如果你是每天跟代码打交道的开发者、需要频繁在设计和开发之间切换的前端工程师、或者想让AI真正融入工作流而不是当玩具玩的技术人那接下来的内容应该能帮你省下不少时间。我会从实际使用场景出发把Codex插件和MCP的配置、使用、避坑经验一次讲透。需要提前说明的是Codex的插件生态还在快速迭代中不同版本的界面和配置方式可能有差异。我下面提到的操作路径基于我目前使用的版本如果你发现菜单对不上大概率是版本更新导致的思路是通的具体位置自己找一下就行。2. MCP协议到底解决了什么问题从AI孤岛到工具互联2.1 没有MCP之前AI助手的工作边界在哪里在MCP出现之前Codex这类AI编程助手的上下文来源非常有限。它能看到的东西基本就是你当前打开的文件内容、你手动粘贴进去的代码片段、以及项目里它能索引到的文件。这个边界看起来很合理但实际用起来问题很大。举个例子你在写一个前端页面设计稿在Figma里接口文档在蓝湖上组件库文档在另一个网站。当你想让AI帮你生成一个符合设计稿的组件时你得先把设计稿截图、把接口文档复制粘贴、把组件库的用法说明贴进去。一套操作下来AI还没开始干活你自己先累了。这就是AI孤岛问题——AI的能力很强但它被困在一个信息孤岛上看不到外面的世界。MCP要解决的就是这个问题。它定义了一套标准协议让外部工具可以通过统一的接口把信息喂给AI。注意这里的关键词是标准——不是每个工具自己搞一套对接方案而是大家都遵循同一个协议。这意味着你只需要配置一次MCP就能让Codex同时接入多个外部工具。2.2 MCP的工作机制用生活化类比理解我用一个类比来解释MCP的工作机制。想象Codex是一个新来的同事能力很强但刚入职对公司的各种系统不熟悉。MCP就像公司的统一登录平台——不管你要访问的是设计系统、文档系统还是代码仓库都通过这一个平台来授权和连接。具体来说MCP的工作流程是这样的MCP Server端每个外部工具需要提供一个MCP Server它负责把工具的能力翻译成MCP协议能理解的格式。比如Figma的MCP Server会告诉Codex我可以提供设计稿的图层信息、颜色值、间距数据。MCP Client端Codex作为MCP Client负责连接这些Server并在需要的时候调用它们的能力。配置层你需要在Codex的配置文件里声明要连接哪些MCP Server以及连接所需的认证信息。整个链路跑通之后你在Codex里说帮我把Figma里那个登录页面的设计稿转成React组件Codex就能通过MCP直接去Figma拉取设计数据然后生成代码。不需要你截图、不需要你手动描述设计细节。2.3 哪些场景下MCP能真正提升效率不是所有场景都值得上MCP。根据我的实际使用经验以下三类场景的收益最明显第一类设计到代码的转换。前端开发者最头疼的事情之一就是对着设计稿写样式。Figma MCP接入之后Codex可以直接读取设计稿的图层结构、颜色变量、字体设置、间距数值生成的代码在还原度上比看着截图写高出一个档次。尤其是用了设计系统Design Token的团队MCP能把Token直接映射到代码里的变量省去了手动对照的环节。第二类接口联调与文档查询。蓝湖MCP这类工具接入后Codex可以直接读取接口文档中的请求参数、响应结构、错误码定义。你在写接口调用代码时AI能给出符合实际接口定义的代码而不是瞎编一个看起来像那么回事但字段名全错的版本。第三类浏览器自动化与调试。Playwright MCP接入后Codex可以控制浏览器执行操作——打开页面、点击元素、填写表单、截图对比。这在写端到端测试或者调试页面交互时特别有用。你可以让AI帮你跑一遍测试流程它自己操作浏览器把结果反馈给你。注意MCP的配置需要一定的动手能力如果你对命令行和JSON配置文件完全不熟悉建议先花半小时了解一下基础概念再动手。配置过程中遇到报错是正常的关键是要学会看日志定位问题。3. Codex插件配置实操从零跑通第一个MCP连接3.1 环境准备装Codex之前需要确认的几件事在开始配置插件之前先确认你的基础环境是OK的。我见过太多人卡在环境问题上折腾半天以为是插件的问题结果发现是Node版本太老或者网络配置有问题。首先确认Codex已经正确安装并且能正常使用基础功能。如果你还没装Codex去官网下载对应平台的安装包安装过程不复杂一路下一步就行。装完之后打开Codex确认能正常对话、能识别当前打开的文件。然后检查Node.js环境。大部分MCP Server是基于Node.js运行的所以你需要确保系统里装了Node.js而且版本不要太老。我建议用Node 18以上的版本可以用node -v命令查看当前版本。如果版本太低去Node官网下载新版安装包覆盖安装。node -v # 建议输出 v18.x.x 或更高接下来确认npm或pnpm可用。大部分MCP Server通过npm包的形式分发你需要用npm来安装它们。npm -v # 确认npm能正常工作最后找到Codex的配置文件位置。不同操作系统的路径不一样操作系统配置文件典型路径macOS~/.codex/config.json 或 ~/Library/Application Support/Codex/Windows%APPDATA%\Codex\ 或用户目录下的 .codex 文件夹Linux~/.config/codex/ 或 ~/.codex/如果你找不到配置文件可以在Codex的设置界面里找打开配置文件之类的选项通常会直接跳转到正确位置。3.2 配置文件的写法一个可复用的模板Codex的MCP配置通常写在配置文件的mcpServers字段里。下面是一个通用的配置模板你可以根据自己的需求增删条目{ mcpServers: { figma: { command: npx, args: [-y, figma/mcp-server], env: { FIGMA_ACCESS_TOKEN: 你的Figma访问令牌 } }, playwright: { command: npx, args: [-y, playwright/mcp-server] } } }这个配置里每个条目代表一个MCP Server。command指定启动命令args是启动参数env是环境变量通常用来传认证信息。配置写完之后保存文件然后重启Codex让配置生效。重启后在Codex的界面里应该能看到已连接的MCP Server列表。如果某个Server显示连接失败先检查命令能不能在终端里手动跑通。3.3 验证MCP是否生效三个检查步骤配置完之后怎么确认MCP真的在工作我通常用三个步骤来验证第一步看Codex的MCP状态面板。大部分版本的Codex会在设置或状态栏里显示已连接的MCP Server。如果显示绿色或已连接说明基础连接是通的。第二步发一条需要MCP能力的指令。比如配置了Figma MCP之后你可以问Codex帮我看看Figma里最近打开的设计稿有哪些图层。如果Codex能返回具体的设计稿信息说明MCP链路是通的。第三步检查日志。如果前两步有问题去看Codex的日志输出。日志里通常会显示MCP Server的启动过程、连接状态、以及具体的错误信息。常见的错误包括认证令牌过期、命令路径不对、网络超时等。提示第一次配置MCP的时候建议一次只配一个Server跑通之后再加第二个。同时配多个Server出问题的时候排查起来会很麻烦。4. 设计稿到代码Figma MCP接入的完整链路4.1 Figma MCP能做什么、不能做什么Figma MCP接入Codex之后最直接的能力是让AI读取设计稿的结构化数据。具体来说它能获取到图层层级关系、每个图层的类型矩形、文本、组件实例等、位置和尺寸信息、填充颜色和描边、字体和字号、以及组件和变体的定义。但要注意它的能力边界。Figma MCP不能直接看懂设计稿的视觉效果——它拿到的是结构化数据不是像素。所以如果你的设计稿里用了大量手绘风格的元素、复杂的渐变叠加、或者非标准的视觉效果MCP读取到的数据可能不足以让AI生成完全一致的代码。这种情况下还是需要人工调整。另外Figma MCP对设计稿的规范性有要求。如果设计稿里图层命名混乱、组件没有做成Component、颜色没有用Style管理MCP读取到的数据质量就会很差。我建议在接入MCP之前先花点时间整理一下设计稿的图层结构和命名规范。4.2 获取Figma访问令牌的详细步骤Figma MCP需要访问你的Figma账号数据所以需要配置访问令牌。获取步骤如下登录Figma官网进入个人设置页面。找到Security或开发者相关的选项卡。生成一个Personal Access Token权限至少需要file_read和file_dev_resources_read。复制生成的令牌粘贴到Codex配置文件的FIGMA_ACCESS_TOKEN字段里。令牌生成后要妥善保管不要直接提交到代码仓库里。如果你在团队里共享配置建议用环境变量的方式传递令牌而不是写死在配置文件里。4.3 从设计稿生成代码的实际效果与调优配置好之后实际使用时的操作流程是这样的在Figma里选中你要转换的组件或页面复制它的链接然后在Codex里粘贴链接并说明需求比如把这个设计稿转成React组件用Tailwind做样式。Codex会通过MCP拉取设计稿数据然后生成代码。实测下来对于结构清晰、用了标准组件和Design Token的设计稿生成的代码还原度能到80%以上。剩下的20%主要是间距的微调、特殊效果的补充、以及响应式断点的处理。调优的几个经验在提示词里指定技术栈和规范。比如用React函数组件TypeScriptTailwind CSS颜色用CSS变量比帮我写代码效果好得多。分块转换而不是一次全转。一个页面如果有十几个组件一次性让AI转换容易出错。建议按组件逐个转换转完一个确认没问题再转下一个。生成的代码要过一遍ESLint。AI生成的代码在格式和命名规范上不一定符合你项目的Lint规则跑一遍自动修复能省不少事。4.4 Figma汉化与MCP的配合使用很多团队用的是Figma汉化版或者第三方汉化插件比如月维Figma汉化。这里要注意的是汉化插件通常只影响界面显示语言不影响MCP读取的数据。MCP读取的是Figma的底层数据图层名称、组件名称这些如果被汉化了MCP读到的也是汉化后的名称。这带来的一个问题是如果你的代码里组件命名是英文的但设计稿里图层名是中文的AI在映射的时候可能会对不上。我的建议是设计稿的图层命名保持英文界面显示用汉化没问题但图层名和组件名用英文更利于后续的代码生成和团队协作。5. 浏览器自动化与接口调试Playwright MCP和蓝湖MCP的实战用法5.1 Playwright MCP让AI帮你跑浏览器测试Playwright MCP接入之后Codex获得了控制浏览器的能力。它能做的事情包括打开指定URL、点击页面元素、填写表单、截取页面截图、读取页面DOM结构、执行JavaScript代码。这个能力在写端到端测试的时候特别有用。传统的写法是你自己写测试脚本跑一遍看哪里报错然后改脚本再跑。用了Playwright MCP之后你可以让Codex直接操作浏览器跑一遍流程它自己看结果、自己判断哪里出了问题、自己修改测试脚本。配置Playwright MCP的步骤比较简单因为它不需要额外的认证信息{ mcpServers: { playwright: { command: npx, args: [-y, playwright/mcp-server] } } }配置好之后你可以给Codex下这样的指令打开本地开发服务器的登录页面用测试账号登录然后截图给我看登录后的页面。Codex会通过Playwright MCP启动浏览器、执行操作、返回截图。实际使用中需要注意Playwright MCP启动的浏览器是独立实例不会影响你正在使用的浏览器。但如果你本地开发服务器没有启动或者端口不对操作会失败。建议在发指令之前先确认开发服务器在跑。5.2 蓝湖MCP接口文档的自动化读取蓝湖是国内团队常用的设计协作和接口管理平台。蓝湖MCP接入后Codex可以读取蓝湖项目中的接口文档包括接口路径、请求方法、请求参数、响应结构、错误码定义。这个能力在前后端联调阶段特别实用。以前的做法是打开蓝湖网页、找到对应的接口、手动复制参数定义、粘贴到代码里。现在你可以直接让Codex去读蓝湖上的接口文档然后生成对应的请求代码。配置蓝湖MCP通常需要提供API Key或者项目ID。具体的配置方式参考蓝湖官方提供的MCP接入文档。配置好之后的典型用法是读取蓝湖项目XXX里的用户登录接口文档帮我生成对应的Axios请求函数和TypeScript类型定义。5.3 多个MCP Server同时运行的注意事项当你同时配置了多个MCP Server时有几个坑需要注意资源占用问题。每个MCP Server都是一个独立的进程同时跑多个会占用内存和CPU。如果你的机器配置一般建议按需启用不用的时候在配置里注释掉。端口冲突。部分MCP Server会启动本地HTTP服务如果两个Server用了同一个端口就会冲突。遇到这种情况需要修改其中一个Server的端口配置。认证信息管理。多个Server的认证令牌建议统一用环境变量管理不要散落在配置文件里。这样切换环境或者更新令牌的时候只需要改一个地方。启动顺序。有些MCP Server之间有依赖关系比如Playwright MCP可能依赖浏览器已经安装。建议在配置文档里记录每个Server的前置依赖换机器的时候照着装一遍。6. 踩坑实录MCP配置中最容易翻车的五个地方6.1 连接失败但没有任何报错信息这是最常见也最让人头疼的问题。Codex显示MCP Server连接失败但日志里只有一行connection failed没有任何详细信息。排查思路是这样的先在终端里手动执行MCP Server的启动命令看它能不能正常启动。如果手动执行也失败说明是Server本身的问题——可能是包没装好、Node版本不对、或者依赖缺失。如果手动执行能成功但Codex里连不上那问题出在Codex的配置上——检查命令路径、参数格式、环境变量是否正确传递。我遇到过一次是因为npx的缓存问题。手动执行npx -y figma/mcp-server能跑通但Codex里就是连不上。后来清了npx缓存npm cache clean --force再重启Codex就好了。这种问题没有通用解法只能靠耐心排查。6.2 认证令牌过期导致的静默失败Figma和蓝湖的访问令牌都有有效期。令牌过期之后MCP Server可能不会报错而是返回空数据或者默认数据。这导致你以为MCP在工作实际上它拿不到任何有效信息。我的做法是每隔一段时间主动验证一下MCP的数据读取是否正常。比如每周一早上让Codex读一次Figma设计稿确认返回的数据是真实的而不是空的。另外在配置令牌的时候设置一个日历提醒到期前提前更新。6.3 配置文件格式错误导致Codex启动异常JSON格式对逗号和引号非常敏感。一个多余的逗号、一个中文引号、一个缺少的括号都可能导致整个配置文件解析失败。更麻烦的是有些版本的Codex在配置文件出错时不会给出明确的错误提示而是直接忽略MCP配置。建议用支持JSON语法检查的编辑器来编辑配置文件比如VS Code。它会实时提示语法错误。改完配置之后可以用cat config.json | python -m json.tool这样的命令来验证JSON格式是否正确。6.4 MCP Server版本更新导致的接口不兼容MCP协议本身还在演进中不同版本的Server可能遵循不同版本的协议。当你更新了某个MCP Server的版本之后可能会出现Codex不认新版本的情况。应对策略是在配置文件里锁定MCP Server的版本号不要用latest。比如figma/mcp-server1.2.3而不是figma/mcp-server。这样即使有新版本发布你的环境也不会自动升级。等确认新版本兼容之后再手动升级。6.5 网络环境导致的连接超时部分MCP Server需要访问外部API比如Figma的云端数据如果你的网络环境对这些API的访问不稳定就会出现连接超时。表现是Codex发指令后长时间无响应最后报超时错误。这种情况下的排查方法是先用curl或浏览器直接访问对应的API地址确认网络是通的。如果网络本身有问题需要先解决网络层面的问题。如果网络是通的但MCP Server连不上可能是Server的代理配置有问题检查一下环境变量里的代理设置。7. 插件组合拳把Codex打造成个人工作流中枢7.1 我的日常配置方案经过一段时间的折腾我目前稳定使用的MCP配置包括三个ServerFigma MCP用于设计稿读取、Playwright MCP用于浏览器自动化、以及一个文件系统MCP用于项目文件管理。这三个组合起来覆盖了我日常80%的工作场景。典型的上午工作流是这样的打开Codex让它读取Figma上最新的设计稿变更生成对应的组件代码然后用Playwright MCP跑一遍本地页面的截图对比设计稿看还原度发现差异后让Codex调整代码再跑一遍截图确认。整个过程不需要离开Codex的界面。7.2 什么情况下不值得上MCPMCP虽然强大但不是所有场景都值得折腾。以下几种情况我建议先用基础功能项目还在早期探索阶段。需求频繁变动的时候花时间配置MCP的收益不高因为设计稿和接口定义本身就不稳定。个人小项目。如果只是写个脚本或者小工具手动复制粘贴信息比配置MCP更快。团队没有统一的设计规范。如果设计稿图层命名混乱、组件没有标准化MCP读取到的数据质量很差生成的代码还不如手写。7.3 后续可以关注的方向MCP生态还在快速扩展目前我关注到的几个方向值得留意一是更多国内工具的MCP支持比如语雀、飞书文档等二是MCP Server的聚合管理工具可以统一管理多个Server的配置和认证三是Codex本身对MCP的支持在持续优化未来配置流程可能会更简化。如果你现在刚开始接触MCP我的建议是从一个最刚需的场景入手——比如你每天都要从Figma复制设计稿信息那就先配Figma MCP。跑通一个之后再逐步扩展不要一上来就配五六个Server那样出问题的时候排查起来会让你怀疑人生。最后分享一个小技巧把MCP配置文件和相关的认证信息做一个加密备份。换电脑或者重装系统的时候直接恢复配置就能继续用省去重新配置的麻烦。我用的是1Password的加密笔记功能来存这些配置你也可以用任何你习惯的密码管理工具。 
长河君 · 2026/10/17 5:15:42 · 阅读 1.2k Codex插件与MCP协议实战：打通Figma、Playwright和蓝湖的AI工作流
1. 打工人效率困局为什么Codex插件值得认真折腾每天打开IDE的第一件事是什么等索引、等加载、等AI助手转圈圈。写代码的时间可能只占工作日的一半剩下的一半全耗在工具链切换上——查文档切浏览器、画原型切设计工具、调接口切调试面板、写注释切翻译软件。这种碎片化的操作模式一天下来光是窗口切换就能吃掉一两个小时。Codex本身是一个代码智能辅助工具它的核心能力在于理解代码上下文、生成补全建议、辅助诊断问题。但很多人装完Codex之后只用了最基础的功能就像买了台高配电脑只拿来打字。真正让Codex从能用变成好用的是插件生态和MCP协议带来的扩展能力。MCP是什么全称Model Context Protocol翻译过来叫模型上下文协议。你可以把它理解成一座桥——桥的一头是Codex这个AI大脑另一头是各种外部工具和数据源。没有这座桥的时候AI只能看到你当前打开的文件有了这座桥AI就能读取你的设计稿、访问你的接口文档、操作你的浏览器、甚至帮你管理项目文件。这就是MCP的核心价值让AI从只能聊天变成能干活。这篇文章适合哪些人看如果你是每天跟代码打交道的开发者、需要频繁在设计和开发之间切换的前端工程师、或者想让AI真正融入工作流而不是当玩具玩的技术人那接下来的内容应该能帮你省下不少时间。我会从实际使用场景出发把Codex插件和MCP的配置、使用、避坑经验一次讲透。需要提前说明的是Codex的插件生态还在快速迭代中不同版本的界面和配置方式可能有差异。我下面提到的操作路径基于我目前使用的版本如果你发现菜单对不上大概率是版本更新导致的思路是通的具体位置自己找一下就行。2. MCP协议到底解决了什么问题从AI孤岛到工具互联2.1 没有MCP之前AI助手的工作边界在哪里在MCP出现之前Codex这类AI编程助手的上下文来源非常有限。它能看到的东西基本就是你当前打开的文件内容、你手动粘贴进去的代码片段、以及项目里它能索引到的文件。这个边界看起来很合理但实际用起来问题很大。举个例子你在写一个前端页面设计稿在Figma里接口文档在蓝湖上组件库文档在另一个网站。当你想让AI帮你生成一个符合设计稿的组件时你得先把设计稿截图、把接口文档复制粘贴、把组件库的用法说明贴进去。一套操作下来AI还没开始干活你自己先累了。这就是AI孤岛问题——AI的能力很强但它被困在一个信息孤岛上看不到外面的世界。MCP要解决的就是这个问题。它定义了一套标准协议让外部工具可以通过统一的接口把信息喂给AI。注意这里的关键词是标准——不是每个工具自己搞一套对接方案而是大家都遵循同一个协议。这意味着你只需要配置一次MCP就能让Codex同时接入多个外部工具。2.2 MCP的工作机制用生活化类比理解我用一个类比来解释MCP的工作机制。想象Codex是一个新来的同事能力很强但刚入职对公司的各种系统不熟悉。MCP就像公司的统一登录平台——不管你要访问的是设计系统、文档系统还是代码仓库都通过这一个平台来授权和连接。具体来说MCP的工作流程是这样的MCP Server端每个外部工具需要提供一个MCP Server它负责把工具的能力翻译成MCP协议能理解的格式。比如Figma的MCP Server会告诉Codex我可以提供设计稿的图层信息、颜色值、间距数据。MCP Client端Codex作为MCP Client负责连接这些Server并在需要的时候调用它们的能力。配置层你需要在Codex的配置文件里声明要连接哪些MCP Server以及连接所需的认证信息。整个链路跑通之后你在Codex里说帮我把Figma里那个登录页面的设计稿转成React组件Codex就能通过MCP直接去Figma拉取设计数据然后生成代码。不需要你截图、不需要你手动描述设计细节。2.3 哪些场景下MCP能真正提升效率不是所有场景都值得上MCP。根据我的实际使用经验以下三类场景的收益最明显第一类设计到代码的转换。前端开发者最头疼的事情之一就是对着设计稿写样式。Figma MCP接入之后Codex可以直接读取设计稿的图层结构、颜色变量、字体设置、间距数值生成的代码在还原度上比看着截图写高出一个档次。尤其是用了设计系统Design Token的团队MCP能把Token直接映射到代码里的变量省去了手动对照的环节。第二类接口联调与文档查询。蓝湖MCP这类工具接入后Codex可以直接读取接口文档中的请求参数、响应结构、错误码定义。你在写接口调用代码时AI能给出符合实际接口定义的代码而不是瞎编一个看起来像那么回事但字段名全错的版本。第三类浏览器自动化与调试。Playwright MCP接入后Codex可以控制浏览器执行操作——打开页面、点击元素、填写表单、截图对比。这在写端到端测试或者调试页面交互时特别有用。你可以让AI帮你跑一遍测试流程它自己操作浏览器把结果反馈给你。注意MCP的配置需要一定的动手能力如果你对命令行和JSON配置文件完全不熟悉建议先花半小时了解一下基础概念再动手。配置过程中遇到报错是正常的关键是要学会看日志定位问题。3. Codex插件配置实操从零跑通第一个MCP连接3.1 环境准备装Codex之前需要确认的几件事在开始配置插件之前先确认你的基础环境是OK的。我见过太多人卡在环境问题上折腾半天以为是插件的问题结果发现是Node版本太老或者网络配置有问题。首先确认Codex已经正确安装并且能正常使用基础功能。如果你还没装Codex去官网下载对应平台的安装包安装过程不复杂一路下一步就行。装完之后打开Codex确认能正常对话、能识别当前打开的文件。然后检查Node.js环境。大部分MCP Server是基于Node.js运行的所以你需要确保系统里装了Node.js而且版本不要太老。我建议用Node 18以上的版本可以用node -v命令查看当前版本。如果版本太低去Node官网下载新版安装包覆盖安装。node -v # 建议输出 v18.x.x 或更高接下来确认npm或pnpm可用。大部分MCP Server通过npm包的形式分发你需要用npm来安装它们。npm -v # 确认npm能正常工作最后找到Codex的配置文件位置。不同操作系统的路径不一样操作系统配置文件典型路径macOS~/.codex/config.json 或 ~/Library/Application Support/Codex/Windows%APPDATA%\Codex\ 或用户目录下的 .codex 文件夹Linux~/.config/codex/ 或 ~/.codex/如果你找不到配置文件可以在Codex的设置界面里找打开配置文件之类的选项通常会直接跳转到正确位置。3.2 配置文件的写法一个可复用的模板Codex的MCP配置通常写在配置文件的mcpServers字段里。下面是一个通用的配置模板你可以根据自己的需求增删条目{ mcpServers: { figma: { command: npx, args: [-y, figma/mcp-server], env: { FIGMA_ACCESS_TOKEN: 你的Figma访问令牌 } }, playwright: { command: npx, args: [-y, playwright/mcp-server] } } }这个配置里每个条目代表一个MCP Server。command指定启动命令args是启动参数env是环境变量通常用来传认证信息。配置写完之后保存文件然后重启Codex让配置生效。重启后在Codex的界面里应该能看到已连接的MCP Server列表。如果某个Server显示连接失败先检查命令能不能在终端里手动跑通。3.3 验证MCP是否生效三个检查步骤配置完之后怎么确认MCP真的在工作我通常用三个步骤来验证第一步看Codex的MCP状态面板。大部分版本的Codex会在设置或状态栏里显示已连接的MCP Server。如果显示绿色或已连接说明基础连接是通的。第二步发一条需要MCP能力的指令。比如配置了Figma MCP之后你可以问Codex帮我看看Figma里最近打开的设计稿有哪些图层。如果Codex能返回具体的设计稿信息说明MCP链路是通的。第三步检查日志。如果前两步有问题去看Codex的日志输出。日志里通常会显示MCP Server的启动过程、连接状态、以及具体的错误信息。常见的错误包括认证令牌过期、命令路径不对、网络超时等。提示第一次配置MCP的时候建议一次只配一个Server跑通之后再加第二个。同时配多个Server出问题的时候排查起来会很麻烦。4. 设计稿到代码Figma MCP接入的完整链路4.1 Figma MCP能做什么、不能做什么Figma MCP接入Codex之后最直接的能力是让AI读取设计稿的结构化数据。具体来说它能获取到图层层级关系、每个图层的类型矩形、文本、组件实例等、位置和尺寸信息、填充颜色和描边、字体和字号、以及组件和变体的定义。但要注意它的能力边界。Figma MCP不能直接看懂设计稿的视觉效果——它拿到的是结构化数据不是像素。所以如果你的设计稿里用了大量手绘风格的元素、复杂的渐变叠加、或者非标准的视觉效果MCP读取到的数据可能不足以让AI生成完全一致的代码。这种情况下还是需要人工调整。另外Figma MCP对设计稿的规范性有要求。如果设计稿里图层命名混乱、组件没有做成Component、颜色没有用Style管理MCP读取到的数据质量就会很差。我建议在接入MCP之前先花点时间整理一下设计稿的图层结构和命名规范。4.2 获取Figma访问令牌的详细步骤Figma MCP需要访问你的Figma账号数据所以需要配置访问令牌。获取步骤如下登录Figma官网进入个人设置页面。找到Security或开发者相关的选项卡。生成一个Personal Access Token权限至少需要file_read和file_dev_resources_read。复制生成的令牌粘贴到Codex配置文件的FIGMA_ACCESS_TOKEN字段里。令牌生成后要妥善保管不要直接提交到代码仓库里。如果你在团队里共享配置建议用环境变量的方式传递令牌而不是写死在配置文件里。4.3 从设计稿生成代码的实际效果与调优配置好之后实际使用时的操作流程是这样的在Figma里选中你要转换的组件或页面复制它的链接然后在Codex里粘贴链接并说明需求比如把这个设计稿转成React组件用Tailwind做样式。Codex会通过MCP拉取设计稿数据然后生成代码。实测下来对于结构清晰、用了标准组件和Design Token的设计稿生成的代码还原度能到80%以上。剩下的20%主要是间距的微调、特殊效果的补充、以及响应式断点的处理。调优的几个经验在提示词里指定技术栈和规范。比如用React函数组件TypeScriptTailwind CSS颜色用CSS变量比帮我写代码效果好得多。分块转换而不是一次全转。一个页面如果有十几个组件一次性让AI转换容易出错。建议按组件逐个转换转完一个确认没问题再转下一个。生成的代码要过一遍ESLint。AI生成的代码在格式和命名规范上不一定符合你项目的Lint规则跑一遍自动修复能省不少事。4.4 Figma汉化与MCP的配合使用很多团队用的是Figma汉化版或者第三方汉化插件比如月维Figma汉化。这里要注意的是汉化插件通常只影响界面显示语言不影响MCP读取的数据。MCP读取的是Figma的底层数据图层名称、组件名称这些如果被汉化了MCP读到的也是汉化后的名称。这带来的一个问题是如果你的代码里组件命名是英文的但设计稿里图层名是中文的AI在映射的时候可能会对不上。我的建议是设计稿的图层命名保持英文界面显示用汉化没问题但图层名和组件名用英文更利于后续的代码生成和团队协作。5. 浏览器自动化与接口调试Playwright MCP和蓝湖MCP的实战用法5.1 Playwright MCP让AI帮你跑浏览器测试Playwright MCP接入之后Codex获得了控制浏览器的能力。它能做的事情包括打开指定URL、点击页面元素、填写表单、截取页面截图、读取页面DOM结构、执行JavaScript代码。这个能力在写端到端测试的时候特别有用。传统的写法是你自己写测试脚本跑一遍看哪里报错然后改脚本再跑。用了Playwright MCP之后你可以让Codex直接操作浏览器跑一遍流程它自己看结果、自己判断哪里出了问题、自己修改测试脚本。配置Playwright MCP的步骤比较简单因为它不需要额外的认证信息{ mcpServers: { playwright: { command: npx, args: [-y, playwright/mcp-server] } } }配置好之后你可以给Codex下这样的指令打开本地开发服务器的登录页面用测试账号登录然后截图给我看登录后的页面。Codex会通过Playwright MCP启动浏览器、执行操作、返回截图。实际使用中需要注意Playwright MCP启动的浏览器是独立实例不会影响你正在使用的浏览器。但如果你本地开发服务器没有启动或者端口不对操作会失败。建议在发指令之前先确认开发服务器在跑。5.2 蓝湖MCP接口文档的自动化读取蓝湖是国内团队常用的设计协作和接口管理平台。蓝湖MCP接入后Codex可以读取蓝湖项目中的接口文档包括接口路径、请求方法、请求参数、响应结构、错误码定义。这个能力在前后端联调阶段特别实用。以前的做法是打开蓝湖网页、找到对应的接口、手动复制参数定义、粘贴到代码里。现在你可以直接让Codex去读蓝湖上的接口文档然后生成对应的请求代码。配置蓝湖MCP通常需要提供API Key或者项目ID。具体的配置方式参考蓝湖官方提供的MCP接入文档。配置好之后的典型用法是读取蓝湖项目XXX里的用户登录接口文档帮我生成对应的Axios请求函数和TypeScript类型定义。5.3 多个MCP Server同时运行的注意事项当你同时配置了多个MCP Server时有几个坑需要注意资源占用问题。每个MCP Server都是一个独立的进程同时跑多个会占用内存和CPU。如果你的机器配置一般建议按需启用不用的时候在配置里注释掉。端口冲突。部分MCP Server会启动本地HTTP服务如果两个Server用了同一个端口就会冲突。遇到这种情况需要修改其中一个Server的端口配置。认证信息管理。多个Server的认证令牌建议统一用环境变量管理不要散落在配置文件里。这样切换环境或者更新令牌的时候只需要改一个地方。启动顺序。有些MCP Server之间有依赖关系比如Playwright MCP可能依赖浏览器已经安装。建议在配置文档里记录每个Server的前置依赖换机器的时候照着装一遍。6. 踩坑实录MCP配置中最容易翻车的五个地方6.1 连接失败但没有任何报错信息这是最常见也最让人头疼的问题。Codex显示MCP Server连接失败但日志里只有一行connection failed没有任何详细信息。排查思路是这样的先在终端里手动执行MCP Server的启动命令看它能不能正常启动。如果手动执行也失败说明是Server本身的问题——可能是包没装好、Node版本不对、或者依赖缺失。如果手动执行能成功但Codex里连不上那问题出在Codex的配置上——检查命令路径、参数格式、环境变量是否正确传递。我遇到过一次是因为npx的缓存问题。手动执行npx -y figma/mcp-server能跑通但Codex里就是连不上。后来清了npx缓存npm cache clean --force再重启Codex就好了。这种问题没有通用解法只能靠耐心排查。6.2 认证令牌过期导致的静默失败Figma和蓝湖的访问令牌都有有效期。令牌过期之后MCP Server可能不会报错而是返回空数据或者默认数据。这导致你以为MCP在工作实际上它拿不到任何有效信息。我的做法是每隔一段时间主动验证一下MCP的数据读取是否正常。比如每周一早上让Codex读一次Figma设计稿确认返回的数据是真实的而不是空的。另外在配置令牌的时候设置一个日历提醒到期前提前更新。6.3 配置文件格式错误导致Codex启动异常JSON格式对逗号和引号非常敏感。一个多余的逗号、一个中文引号、一个缺少的括号都可能导致整个配置文件解析失败。更麻烦的是有些版本的Codex在配置文件出错时不会给出明确的错误提示而是直接忽略MCP配置。建议用支持JSON语法检查的编辑器来编辑配置文件比如VS Code。它会实时提示语法错误。改完配置之后可以用cat config.json | python -m json.tool这样的命令来验证JSON格式是否正确。6.4 MCP Server版本更新导致的接口不兼容MCP协议本身还在演进中不同版本的Server可能遵循不同版本的协议。当你更新了某个MCP Server的版本之后可能会出现Codex不认新版本的情况。应对策略是在配置文件里锁定MCP Server的版本号不要用latest。比如figma/mcp-server1.2.3而不是figma/mcp-server。这样即使有新版本发布你的环境也不会自动升级。等确认新版本兼容之后再手动升级。6.5 网络环境导致的连接超时部分MCP Server需要访问外部API比如Figma的云端数据如果你的网络环境对这些API的访问不稳定就会出现连接超时。表现是Codex发指令后长时间无响应最后报超时错误。这种情况下的排查方法是先用curl或浏览器直接访问对应的API地址确认网络是通的。如果网络本身有问题需要先解决网络层面的问题。如果网络是通的但MCP Server连不上可能是Server的代理配置有问题检查一下环境变量里的代理设置。7. 插件组合拳把Codex打造成个人工作流中枢7.1 我的日常配置方案经过一段时间的折腾我目前稳定使用的MCP配置包括三个ServerFigma MCP用于设计稿读取、Playwright MCP用于浏览器自动化、以及一个文件系统MCP用于项目文件管理。这三个组合起来覆盖了我日常80%的工作场景。典型的上午工作流是这样的打开Codex让它读取Figma上最新的设计稿变更生成对应的组件代码然后用Playwright MCP跑一遍本地页面的截图对比设计稿看还原度发现差异后让Codex调整代码再跑一遍截图确认。整个过程不需要离开Codex的界面。7.2 什么情况下不值得上MCPMCP虽然强大但不是所有场景都值得折腾。以下几种情况我建议先用基础功能项目还在早期探索阶段。需求频繁变动的时候花时间配置MCP的收益不高因为设计稿和接口定义本身就不稳定。个人小项目。如果只是写个脚本或者小工具手动复制粘贴信息比配置MCP更快。团队没有统一的设计规范。如果设计稿图层命名混乱、组件没有标准化MCP读取到的数据质量很差生成的代码还不如手写。7.3 后续可以关注的方向MCP生态还在快速扩展目前我关注到的几个方向值得留意一是更多国内工具的MCP支持比如语雀、飞书文档等二是MCP Server的聚合管理工具可以统一管理多个Server的配置和认证三是Codex本身对MCP的支持在持续优化未来配置流程可能会更简化。如果你现在刚开始接触MCP我的建议是从一个最刚需的场景入手——比如你每天都要从Figma复制设计稿信息那就先配Figma MCP。跑通一个之后再逐步扩展不要一上来就配五六个Server那样出问题的时候排查起来会让你怀疑人生。最后分享一个小技巧把MCP配置文件和相关的认证信息做一个加密备份。换电脑或者重装系统的时候直接恢复配置就能继续用省去重新配置的麻烦。我用的是1Password的加密笔记功能来存这些配置你也可以用任何你习惯的密码管理工具。