企业官网建设流程全解析

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 常见问题速查表

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 这类工具把关键页面的截图存下来，作为视觉回归的基线。下次再改版的时候，自动对比新旧截图，快速定位差异。这样改版的质量控制就从“人工走查”升级到了“自动比对”，效率会更高。

我个人在实际操作中的体会是，改版这件事，最怕的不是设计得不好看，而是设计得“不对”。从运行界面倒推，本质上是用真实约束来校准设计决策，让每一个改动都有依据。这套方法不复杂，但需要耐心——耐心采集、耐心整理、耐心走查。耐心到位了，改版的质量自然就上去了。