1. 为什么改版要从运行界面倒推而不是从白稿开始1.1 白稿起步的隐性代价做过几年产品设计的人大概都有过这种经历拿到一个改版需求打开 Figma新建一个 Frame从零开始画。画完首页画详情页画完详情页画弹窗一套下来几十个画板视觉上看着挺整齐交付给前端之后问题就来了——真实运行界面里的数据长度跟设计稿对不上列表滚动之后的样式没定义空状态和加载状态压根没画暗色模式下颜色全糊了。这不是个别现象。从白稿开始做改版本质上是在一个“理想环境”里做设计而真实产品是一个“脏环境”有历史数据、有极端情况、有性能约束、有组件库的历史包袱。你在白稿里做的每一个决策到了真实界面里都要重新验证一遍验证不通过就得返工。返工的成本不只是时间还有沟通成本——前端已经按你的稿子写了一部分你改一版他就要改一版来回几次双方都疲惫。我自己的经验是一个中等复杂度的后台系统改版如果从白稿开始从设计到前端落地中间至少会有三轮以上的“设计-开发-走查-修改”循环。而如果一开始就把运行界面带回去做参照这个循环能压缩到一轮甚至零轮。差别在哪差别在于你设计的时候参照物是真实的不是想象的。1.2 运行界面带回去到底带的是什么“把运行界面带回去”这句话听起来有点抽象具体操作起来带的是这几样东西真实数据的截图或录屏不是截一张干净的首屏而是把列表滚到底、把长文本展开、把极端数值填进去之后的界面状态。这些截图是你做设计时的“底图”你的新设计要能覆盖这些真实状态。DOM 结构和样式信息如果你能拿到运行界面的 DOM 结构哪怕只是一部分你就能知道现有组件的层级关系、间距规则、颜色变量。这些信息比你在白稿里凭感觉定的 8px 网格要可靠得多。交互状态的全集hover、active、disabled、loading、error、empty这些状态在运行界面里是真实存在的在白稿里往往被忽略。把运行界面带回去就是把这些状态一并带回去。性能相关的约束比如某个列表在真实环境里渲染一千条数据会卡那你的新设计就不能再增加 DOM 节点数量。这种约束在白稿阶段是看不见的。带回去的方式可以很灵活。最轻量的做法是截图加标注把关键区域的尺寸、颜色、字体大小标出来。重一点的做法是用浏览器开发者工具把 DOM 结构导出或者用 Figma 的插件把运行界面的截图直接导入为参考图层。再重一点就是用 MCP 协议把 Figma 和运行环境打通让设计稿和真实界面之间建立可追溯的映射关系。1.3 改版的本质是“迁移”而不是“重画”很多人把改版理解成“重新设计”这个理解是有偏差的。改版的本质是“迁移”——把现有的功能、内容、交互逻辑从一个视觉框架迁移到另一个视觉框架里。迁移的前提是你得先知道“现有的东西长什么样”。如果你连现有界面都没仔细看过就开始画新稿那你画的其实是一个全新的产品而不是改版。这个区别在评审的时候特别明显。从白稿开始的改版评审时大家讨论的是“这个新设计好不好看”“这个交互合不合理”而不是“这个改版有没有把原来的问题解决掉”。而从运行界面倒推的改版评审时讨论的是“原来这个列表滚动卡顿的问题新设计里怎么解决的”“原来这个表单在移动端换行错乱的问题新稿里有没有覆盖”。后者的讨论质量明显更高因为大家有共同的参照物。2. Figma 在改版流程里的真实定位2.1 Figma 不是画图工具是协作中枢Figma 这几年在国内设计圈普及得很快汉化插件、桌面中文版这些搜索词的热度一直不低。但很多人对 Figma 的理解还停留在“一个可以在浏览器里画图的设计工具”。如果你只把它当画图工具用那确实跟 Sketch 或者 Axure 差别不大。Figma 真正的价值在于它是一个协作中枢——设计稿、组件库、评论、版本历史、开发标注全部在一个文件里完成。在改版场景下这个协作中枢的定位尤其重要。因为改版涉及的角色多产品经理要确认需求范围设计师要出方案前端要评估实现成本测试要覆盖回归用例。如果这些角色各自看各自的文档信息就会失真。Figma 的好处是所有人看的是同一份文件评论直接挂在具体图层上版本历史可以回溯到任何一个时间点。我自己的做法是改版项目启动时先在 Figma 里建一个“参考”页面把运行界面的截图按模块贴进去每个截图旁边用文字标注这个模块的问题和改版目标。这个页面不追求好看只追求信息完整。然后在这个页面的基础上再建“设计”页面开始画新稿。这样做的目的是让所有参与者在看新稿之前先看一遍旧稿建立共同的问题认知。2.2 组件库和 Design Token 的衔接改版项目最容易出问题的地方是组件库的衔接。旧系统可能有一套自己的组件库新设计可能想引入一套新的组件库两套库之间的映射关系如果没理清楚前端就会陷入“这个按钮到底用旧组件还是新组件”的困惑。Figma 的组件系统和 Design Token 功能可以缓解这个问题。你可以把旧系统的颜色、字体、间距定义成一套 Token把新系统的定义成另一套 Token然后在设计稿里明确标注哪些地方用旧 Token哪些地方用新 Token。这样前端在实现的时候就知道哪些样式是继承的哪些是覆盖的。具体操作上我习惯在 Figma 里建一个“Token 对照表”页面左边是旧 Token 的名称和值右边是新 Token 的名称和值中间用箭头标注映射关系。比如旧系统的color-primary是#1890FF新系统的color-brand是#165DFF那就在对照表里写清楚所有用到color-primary的地方改版后统一替换为color-brand。这个表看起来简单但能省掉前端大量的猜测时间。2.3 从 Figma 到代码的链路打通Figma 本身不能直接生成可运行的代码但它可以通过插件和 MCP 协议跟开发环境打通。MCP 是 Model Context Protocol 的缩写简单理解就是一种让不同工具之间互相“对话”的协议。Figma MCP 的作用是让 AI 编程助手比如 Codex 这类工具能够读取 Figma 文件里的设计信息然后生成对应的代码。这个链路打通之后改版流程会变成这样设计师在 Figma 里改完稿前端在 Codex 里输入指令Codex 通过 MCP 读取 Figma 的图层结构和样式信息生成对应的组件代码前端再基于运行界面的实际情况做微调。整个过程里设计稿和代码之间的“翻译”环节被大幅压缩了。但这里有个前提你的 Figma 文件必须结构清晰。图层命名要规范组件要复用自动布局要用起来。如果图层全是Rectangle 123这种命名MCP 读出来的信息就是一团乱麻生成的代码也没法用。所以我在改版项目开始前会花半天时间把 Figma 文件的图层结构整理一遍该合并的合并该命名的命名该做成组件的做成组件。这个时间投入是值得的后面能省出好几倍的时间。3. 把运行界面带回 Figma 的具体操作3.1 截图采集与标注的规范截图这件事听起来简单但要做对不容易。我的做法是分三层采集第一层是全页面截图用浏览器自带的截图功能或者插件把整个页面从上到下截完整。注意要关掉浏览器的书签栏和插件栏保持界面干净。截完之后在 Figma 里按页面层级排列方便对照。第二层是模块截图把页面拆成头部、侧边栏、内容区、底部等模块每个模块单独截图。模块截图的目的是让你在设计新稿时能快速找到对应区域的旧样式不用在整页截图里放大缩小地找。第三层是状态截图把 loading、empty、error、disabled 这些状态单独截出来。这些状态在正常运行界面里不一定能同时看到可能需要手动触发。比如在浏览器控制台里把某个接口的返回改成空数组就能看到空状态把网络调成慢速就能看到加载状态。截图采集完之后在 Figma 里建一个“运行界面参考”页面按模块和状态分类摆放。每个截图旁边用文本框标注这个模块的尺寸是多少用了什么字体主色是什么有哪些交互状态。标注不用太精细但关键信息要有。3.2 用 Figma 插件导入真实界面手动截图加标注的方式比较笨但胜在可控。如果你想更自动化一点可以用 Figma 的插件把运行界面直接导入。比如有一些插件可以抓取网页的 DOM 结构然后转成 Figma 的图层。这种方式的好处是尺寸和颜色是精确的不用手动量。坏处是导入的图层结构可能很乱需要花时间整理。我试过几种插件实测下来比较稳的做法是先用插件抓取一个模块的 DOM导入 Figma 之后把不需要的图层删掉只保留关键的结构和样式。然后把导入的图层作为底图在上面画新稿。这样新稿的尺寸和旧稿是对齐的不会出现“新稿比旧稿宽了 2px”这种低级问题。还有一种做法是用 MCP 协议把 Figma 和运行环境连起来。比如在 Codex 里配置 Figma MCP然后输入指令让 Codex 读取某个 Figma 文件的图层信息再对比运行界面的实际样式输出差异报告。这种方式适合改版范围比较大、需要系统性对比的场景。配置过程稍微复杂一点需要先在 Figma 里生成访问令牌然后在 Codex 的配置文件里填入令牌和文件 ID。具体步骤我在下一节展开。3.3 建立旧稿到新稿的映射关系把运行界面带回 Figma 之后最重要的一步是建立映射关系。也就是说旧界面的每一个模块在新稿里对应哪个模块旧界面的每一个组件在新稿里对应哪个组件。这个映射关系如果不建立改版就会变成“另起炉灶”而不是“迁移”。我的做法是在 Figma 里用连线工具把旧稿的模块和新稿的模块连起来。连线的时候标注清楚这个模块是“保留但换样式”还是“拆分”还是“合并”还是“删除”。比如旧界面的顶部导航栏在新稿里可能拆成了顶部栏加侧边栏那就在连线上标注“拆分导航项移到侧边栏”。这个映射关系图看起来有点乱但它是改版项目的“地图”。前端拿到这张图就知道旧代码的哪些部分可以复用哪些部分需要重写。测试拿到这张图就知道回归测试要覆盖哪些模块。产品经理拿到这张图就知道改版的范围有没有遗漏。4. Codex 与 MCP 在改版链路里的实操配置4.1 Codex 的安装与基础配置Codex 这类 AI 编程助手在改版项目里的作用是加速“设计稿到代码”的转换。安装过程不复杂官网下载安装包按提示走就行。安装完之后需要配置模型接入国内用户常用的做法是接入 DeepSeek 或者其他兼容的模型服务。配置的时候要注意Codex 的配置文件里需要填 API 地址和密钥密钥不要直接写在配置文件里用环境变量引用更安全。配置完成之后先跑一个简单的测试比如让 Codex 生成一个按钮组件的代码确认链路是通的。如果报错常见的原因是 API 地址填错了或者密钥没有权限。排查的时候先看日志日志里会写明是网络问题还是鉴权问题。4.2 Figma MCP 的接入步骤Figma MCP 的接入分三步第一步在 Figma 里生成个人访问令牌。路径是设置 → 账户 → 个人访问令牌 → 生成新令牌。生成的时候要勾选文件读取权限不需要勾选写入权限因为 MCP 只需要读设计稿信息。第二步在 Codex 的配置文件里添加 MCP 服务器配置。配置项包括 MCP 服务器的地址、Figma 令牌、以及要读取的文件 ID。文件 ID 可以从 Figma 文件的 URL 里提取就是figma.com/file/后面那一串字符。第三步重启 Codex然后在对话里输入指令测试。比如输入“读取 Figma 文件里的按钮组件生成对应的 React 代码”。如果 Codex 能正确读取到组件的尺寸、颜色、字体信息并生成可用的代码说明配置成功了。这里有个坑要注意Figma 的免费版对 MCP 的调用次数有限制如果改版项目比较大可能需要升级到付费版。另外MCP 读取的信息精度取决于 Figma 文件的结构如果图层命名混乱读出来的信息也会混乱。所以前面说的图层整理工作在这里就体现出价值了。4.3 设计稿到代码的转换边界MCP 能帮你把设计稿转成代码但转换是有边界的。它能转的是静态的样式和结构转不了的是交互逻辑和业务逻辑。比如一个按钮的圆角、颜色、内边距MCP 能准确读取并生成 CSS但这个按钮点击之后要调哪个接口、要做哪些校验MCP 是不知道的需要前端自己补。所以我的做法是用 MCP 生成组件的“壳”也就是结构和样式部分然后前端在这个壳的基础上补交互逻辑。这样前端的工作量能减少一半左右而且生成的样式跟设计稿是一致的不会出现“前端凭感觉写样式写完跟设计稿对不上”的问题。还有一个边界是响应式。MCP 读取的是某个特定尺寸下的设计稿信息如果你在 Figma 里只画了桌面端MCP 生成的代码也只有桌面端的样式。移动端的适配需要设计师在 Figma 里把移动端的稿子也画出来或者前端根据桌面端的样式自己推导。我建议是至少画两个断点桌面端和移动端这样 MCP 能生成两套样式前端做响应式的时候有参照。5. 改版过程中的常见问题与排查技巧5.1 设计稿与运行界面不一致的排查改版过程中最常见的问题是新稿在 Figma 里看着没问题到了运行界面里就变形了。原因通常有几个一是字体不一致Figma 里用的字体运行环境里没有浏览器回退到了默认字体导致文字宽度变化布局错乱。二是盒模型不一致Figma 的自动布局和 CSS 的 flex 布局在计算方式上有差异间距对不上。三是图片的 object-fit 属性没设置好导致图片拉伸或裁剪。排查的时候先用浏览器的开发者工具检查实际渲染的样式跟 Figma 里的标注对比。如果字体不一致就在 CSS 里显式声明字体栈把回退字体也写进去。如果间距对不上就检查是 margin 还是 padding 的问题Figma 的自动布局里间距是加在容器上的CSS 里可能是加在子元素上的。如果图片变形就检查 object-fit 是 cover 还是 contain跟设计稿的预期是否一致。5.2 MCP 调用失败的常见原因MCP 调用失败的原因我遇到过几种一是令牌过期Figma 的个人访问令牌有有效期过期之后需要重新生成。二是文件权限不足令牌生成的时候如果没有勾选文件读取权限MCP 就读不到文件。三是网络问题MCP 服务器和 Figma 之间的通信需要稳定的网络如果网络波动调用会超时。四是文件 ID 填错URL 里的文件 ID 是一串大小写敏感的字符填错一个字母就会报“文件不存在”。排查的时候先看 Codex 的日志日志里会写明是鉴权失败还是网络超时。如果是鉴权失败就重新生成令牌如果是网络超时就检查网络连接如果是文件不存在就核对文件 ID。我自己的习惯是把令牌和文件 ID 写在配置文件的注释里方便排查的时候核对。5.3 前端实现与设计稿走查的要点走查是改版流程的最后一道关也是最容易扯皮的地方。设计师觉得前端没按稿子写前端觉得设计师的稿子没法实现。避免扯皮的关键是走查的时候用同一套标准。我的做法是走查时打开 Figma 和运行界面并排对比逐项检查间距、颜色、字体、圆角、阴影、交互状态。每检查一项就在 Figma 里用评论标注“通过”或“不通过原因是……”。走查的优先级是先看布局对不对再看样式对不对最后看交互对不对。布局不对的话样式再对也没用。交互走查的时候要把 hover、active、disabled、loading 这些状态都点一遍不能只看默认状态。我见过很多项目默认状态走查通过了一上线发现 hover 状态的颜色跟设计稿差了一大截就是因为走查的时候没覆盖到。5.4 常见问题速查表问题现象可能原因排查方法解决方式新稿在运行界面里字体变宽字体未加载浏览器回退默认字体开发者工具检查 computed font-familyCSS 显式声明字体栈包含回退字体模块间距与设计稿不符Figma 自动布局与 CSS flex 计算差异对比 Figma 标注和 computed margin/padding统一间距加在容器上避免子元素单独加 marginMCP 读取不到组件信息图层命名混乱或组件未复用检查 Figma 图层结构整理图层命名将重复元素转为组件MCP 调用报鉴权失败令牌过期或权限不足查看 Codex 日志重新生成令牌勾选文件读取权限图片在运行界面拉伸object-fit 未设置或设置错误检查 CSS object-fit 属性根据设计意图设置为 cover 或 contain暗色模式下颜色对比度不足Design Token 未区分明暗主题切换暗色模式检查为暗色主题单独定义 Token 值列表滚动卡顿新设计增加了 DOM 节点数量性能面板录制滚动过程减少嵌套层级使用虚拟滚动6. 从运行界面倒推的改版工作流总结6.1 一套可复用的改版流程把上面这些操作串起来就是一套可复用的改版流程第一步采集运行界面。用截图和 DOM 导出两种方式把旧界面的全页面、模块、状态都采集下来导入 Figma 作为参考。第二步整理 Figma 文件。把参考图层按模块分类标注关键尺寸和样式。同时整理组件库和 Design Token建立新旧对照表。第三步建立映射关系。用连线工具把旧模块和新模块连起来标注每个模块的处理方式保留、拆分、合并、删除。第四步画新稿。在参考图层的基础上画新稿确保新稿的尺寸和旧稿对齐覆盖所有真实状态。第五步配置 MCP 链路。在 Codex 里配置 Figma MCP让 AI 助手能读取设计稿信息生成组件代码。第六步前端实现与走查。前端基于 MCP 生成的代码补交互逻辑走查时用 Figma 和运行界面并排对比逐项检查。这套流程走下来改版的返工率能明显降低。我自己的项目里从白稿开始的改版平均要 3 轮走查用这套流程之后压缩到了 1 轮。6.2 工具选型的取舍逻辑工具选型上Figma 是核心这个没什么争议。Codex 和 MCP 是加速器但不是必需品。如果项目比较小改版范围只有几个页面手动截图加标注就够了不需要上 MCP。如果项目比较大涉及几十个页面和多个组件库那 MCP 的价值就体现出来了它能帮你系统性地对比新旧稿减少人工核对的工作量。蓝湖 MCP 这类国内工具也在做类似的事情优势是中文支持和国内网络环境更友好。选哪个取决于你的团队习惯和项目需求。我自己的做法是Figma 原生 MCP 和国内工具都配一套哪个稳定用哪个。6.3 我踩过的几个坑第一个坑是过度依赖 MCP 生成的代码。MCP 生成的代码是“能跑”的但不一定是“好用”的。它生成的组件往往缺少边界处理比如空数据、超长文本、极端数值这些情况。所以生成的代码一定要人工 review补上边界处理。第二个坑是Figma 文件结构没整理就上 MCP。图层命名混乱的话MCP 读出来的信息也是乱的生成的代码里会出现一堆div嵌套没法维护。所以上 MCP 之前一定要花时间整理图层结构。第三个坑是走查时只看默认状态。hover、active、disabled、loading 这些状态如果不走查上线之后就会出问题。我现在的习惯是走查清单里把状态检查单独列一项每个组件都要点一遍。第四个坑是忽略性能约束。新设计如果增加了 DOM 节点数量在低端设备上可能会卡顿。所以改版的时候要跟前端确认性能预算比如列表渲染不超过多少个节点动画不超过多少毫秒。这个约束在设计阶段就要考虑进去不能等上线了再优化。6.4 后续可以扩展的方向这套流程目前主要用在 Web 端的改版上但思路可以扩展到其他端。比如移动端的改版可以把运行界面的截图换成真机截图Figma 里用移动端的 Frame 尺寸MCP 生成的代码适配 React Native 或 Flutter。再比如桌面端的改版可以用 Avalonia UI 或 Electron 的截图作为参考流程是一样的。另一个扩展方向是把改版流程和自动化测试结合起来。走查通过之后用 Playwright 这类工具把关键页面的截图存下来作为视觉回归的基线。下次再改版的时候自动对比新旧截图快速定位差异。这样改版的质量控制就从“人工走查”升级到了“自动比对”效率会更高。我个人在实际操作中的体会是改版这件事最怕的不是设计得不好看而是设计得“不对”。从运行界面倒推本质上是用真实约束来校准设计决策让每一个改动都有依据。这套方法不复杂但需要耐心——耐心采集、耐心整理、耐心走查。耐心到位了改版的质量自然就上去了。