前段时间我在移动端项目里连续做了几轮 UI 还原。
一开始我也很乐观：有设计稿截图，有 MasterGo MCP，有 AI 助手，理论上应该很快。结果真正验收的时候，问题还是一堆。
截图第一眼看着差不多，设计师一验，间距不对。
主页面像了，弹窗不像。
静态样张没问题，真实数据一进来，长文案、空态、按钮状态又开始变形。
后来我才意识到，UI 还原这件事不能只靠“看起来像”。尤其是让 AI 参与以后，如果没有规则和检查点，它很容易生成一份能跑、也挺像，但后面不好验收、不好维护的页面。
所以这段时间，我把这套流程慢慢收敛成了一个可复盘的工作流。
今天这篇主要讲三件事：
第一，为什么只靠截图或 MCP，还原度会不稳定。
第二，我现在怎么把 UI 还原拆成输入、规则、资源、状态和验证。
第三，怎么让 AI 在这个流程里真正帮上忙，而不是只生成一份“看着还行”的代码。
一、为什么截图和 MCP 都不够
先说结论：截图和 MCP 都有用，但它们都不是完整答案。
我之前直接拿截图让 AI 还原页面，效果很一般。页面能生成出来，但还原度大多在 50% 左右。页面简单一点，可能能到 60%。
问题不是 AI 完全不能写，而是它只能猜。
坐标要猜，层级要猜，图片比例要猜，状态细节也要猜。截图只告诉你“结果长什么样”，但不会告诉你每个节点的真实尺寸、资源来源、组件约束和业务状态。
那只用 MCP 呢？
也不稳。
MCP 能把设计稿结构化，能给颜色、字号、节点坐标、宽高、图片 URL，这一步确实能省掉大量抄数值的时间。但如果没有项目规则配合，稍微复杂一点的页面，还原度可能只有 30% - 40%；简单页面会好一些，大概在 45% - 60% 之间浮动。
因为 MCP 不知道这些事：
- 项目里按钮和弹窗到底该复用哪个组件。
px和rpx怎么换算。- 哪些 CSS 在目标端有兼容风险。
- 图片资源应该怎么归档，后面怎么替换线上地址。
- 空态、loading、失败态和真实接口数据会怎么撑开页面。
我现在这套流程解决的就是这个问题：先把输入、规则、资源、状态和验证方式固定下来。
按这套方法做，UI 还原度最低能稳定到 70% 以上；规则越完善，还原度越高。以我现在的实践来看，平均还原度可以到 95% 左右，通常只剩部分图片资源需要替换，字体、定位和层级基本不需要再大调。
这些不是实验室评测数据，只是我在真实项目里反复调页面后总结出来的经验区间：
| 输入方式 | 典型还原度 | 主要问题 |
|---|---|---|
| 只给截图 | 约 50%，简单页面可到 60% | 坐标、层级、比例和状态都靠猜 |
| 只用 MCP，但没有规则约束 | 复杂页面约 30% - 40%，简单页面约 45% - 60% | 有结构化数据，但没有项目工程口径 |
| AI + MCP + 设计稿原图 + 规则 + 资源 + 状态表 + 检查表 | 最低可稳定到 70% 以上，当前平均约 95% | 主要剩图片替换、少量资源对齐 |
所以我现在不会单独看 MCP。
它是一个很好的结构化入口，但不是验收标准。真正能把还原度稳定下来的，是后面那一整套规则。
可以先看一个更直观的对比。
左边这种页面不是完全不能用，它的问题是“差一点”：间距差一点、圆角差一点、资源质感差一点、状态表达也差一点。
但 UI 验收时，真正消耗时间的往往就是这些“差一点”。如果没有尺寸表、资源表、状态表和检查表，最后只能靠肉眼来回改。
右边的意义不是说每次都能一次做到 100%，而是所有关键差异都有依据：哪个尺寸来自 DSL，哪个资源来自设计稿，哪个状态来自业务规则，哪个地方是兼容取舍。
二、我现在会先看这 5 件事
以前我判断 UI 还原度，更多是看截图像不像。
后来发现这个判断太虚了。
页面第一眼像，不代表真实数据进来以后还能稳。弹窗、长文案、空态、按钮状态，这些才是最容易暴露问题的地方。
所以现在我会先看这 5 件事：
| 我会看的层级 | 解决什么问题 | 最后要留下什么 |
|---|---|---|
| 设计稿结构化 | 不靠截图主观猜 | DSL、设计稿原图、关键尺寸表 |
| 规则约束 | 不同人和 AI 口径一致 | 换算规则、组件规则、兼容规则 |
| 资源归档 | 图片来源可追溯 | 资源清单、本地文件、线上映射 |
| 状态建模 | 静态稿能覆盖真实业务 | 状态表、边界条件、交互路径 |
| 实现验证 | 偏差能定位和修正 | 自查清单、构建结果、取舍记录 |
这五层里，我最看重的是“留下什么”。
如果一次 UI 还原结束以后，只留下了一份页面代码，下次遇到类似页面还是要从头调。
但如果留下了 DSL、关键尺寸表、资源表、状态表和偏差记录，下一次 AI 和人都能沿着同一套口径继续做。
这就是我后来对“高保真”的定义：
页面第一眼像还不够。布局层级、坐标关系、尺寸比例、图片资源、颜色、圆角、字体、状态和交互路径，都要能被追踪和验证。
三、先把流程固定下来
下面这张图，是我现在做 UI 高保真还原时的主线。
这张图里最关键的不是“实现”。
而是实现前后有没有对上。
实现前，先把设计稿结构化。
实现中，按项目范式复用组件。
实现后，按文档核对偏差。
有偏差，回到调优环节，不要直接交付。
我以前最容易跳过的是前两步：拿到截图就写，拿到 MCP 就写。看起来推进很快，但后面返工更多。
现在我会先让 AI 做分析文档，不让它直接写代码。
这一步慢一点，但后面稳很多。
四、10 条规则，比一句“尽量还原”更有用
“尽量还原”这句话没有约束力。
对人没约束力，对 AI 更没约束力。
所以我现在会把规则压成一张表，开发前扫一遍，改完再扫一遍。
| 规则 | 我会怎么做 | 我踩过的坑 | 要留下什么 |
|---|---|---|---|
| 先分析再写代码 | 先用 MCP 拿 DSL、设计稿原图和资源 | 只看截图直接写页面 | 设计分析文档 |
| 多状态逐稿分析 | 页面、弹窗、空态、详情态分开看 | 用主页面样式猜其他状态 | 状态清单 |
| 固定换算规则 | 375px -> 750rpx 时用 1px = 2rpx | 开发时临时心算 | 关键尺寸表 |
| 文档先于实现 | 记录结构、资源、状态、取舍 | 把结论留在聊天记录里 | 还原说明 |
| 资源归档命名 | 图片 URL、用途、本地路径一一对应 | 临时链接直接写进页面 | 资源表 |
| 三方对照 | DSL、设计稿原图、资源一起核对 | 只信其中一个来源 | 偏差记录 |
| 固定还原优先级 | 先骨架，再视觉，再状态 | 哪里显眼先改哪里 | 调优顺序 |
| 兼容优先 | 避开目标端风险 CSS 和事件写法 | 为炫技牺牲稳定性 | 兼容说明 |
| 样式模块化 | SCSS 跟 DOM 和业务模块组织 | class 平铺、重复堆叠 | 样式结构 |
| 完成后验证 | 检查表 + 构建验证 | 看一眼差不多就交 | 验收记录 |
里面最容易漏的是三条：
- 多状态逐稿分析。
- 资源归档。
- 三方对照。
很多页面第一眼看着还行，最后验收卡住，基本都绕不开这三件事。
五、关键尺寸和资源要先落表
如果原稿是 375px，实现是 750rpx，我会先把关键尺寸写成表，而不是边写边算。
1px = 2rpx
375px = 750rpx
812px = 1624rpx
示例表可以这样写：
| 模块 | 设计稿数据 | 实现数据 | 检查重点 |
|---|---|---|---|
| 底部面板 | x=0 y=102 w=375 h=711 | x=0 y=204 w=750 h=1420 | 起点和高度不能偏 |
| 关闭按钮 | 28 x 28 | 56rpx x 56rpx | 点击区域是否足够 |
| 标题图 | 245 x 69 | 490rpx x 138rpx | 宽高比例是否保持 |
| 列表卡片 | 347 x 118 | 694rpx x 236rpx | 左右边距和圆角 |
资源表也要尽早写。
不要等页面快写完才找图。
| 资源 | 用途 | 来源 | 实现策略 |
|---|---|---|---|
| background.png | 页面或弹窗背景 | 设计稿 URL | 先本地归档，后续替换线上地址 |
| title.png | 标题视觉 | 设计稿 URL | 按设计稿比例展示 |
| close.png | 关闭按钮 | 设计稿 URL | 同时保证点击热区 |
| decoration.png | 装饰光效 | 设计稿 URL | 目标端不支持滤镜时用图片或渐变近似 |
这两张表后面会反复用到。
这张图就是我现在更推荐的做法：实现前先把尺寸、资源和状态写清楚。AI 后面写代码时，输入就不再是一句“尽量还原”，而是一组能检查的约束。
改偏差时不用吵“感觉”。到底是坐标错、资源错、兼容取舍，还是设计稿本身和截图不一致，表里能翻到依据。
六、调优顺序：先骨架，再细节
我现在不会一上来就调字体、颜色和阴影。
顺序反了，很容易越调越乱。
| 阶段 | 重点看什么 | 常见偏差 |
|---|---|---|
| 承载结构 | 全屏、底部弹窗、居中弹窗、导航、安全区 | 面板起点错，后面全都不像 |
| 主层级和坐标 | 背景、遮罩、标题、面板、卡片、按钮 | 大块布局偏上偏下 |
| 图片资源 | 背景、主视觉、装饰、图标、按钮皮肤 | 用错图，或者用 CSS 硬画 |
| 颜色字体圆角 | 色值、渐变、描边、阴影、字号、行高 | 简化设计稿导致质感变差 |
| 状态模型 | 空态、loading、成功、失败、待处理、已完成 | 只做了样张态 |
| 数据边界 | 长文本、空图、缺字段、按钮文案变化 | 真实数据一进来就撑破 |
| 端侧兼容 | 事件、图片模式、CSS 能力、公共组件 | H5 正常，目标端异常 |
| 检查表修正 | 坐标、资源、文案、状态、构建 | 看着差不多但无法验收 |
这个顺序是被返工逼出来的。
骨架错了，颜色再准也不像。
比例错了，字体再准也不像。
七、示例 1：活动弹窗不能只做静态稿
活动弹窗看起来最简单。
一张背景，一张标题图，一个主按钮，一个关闭按钮。照着设计稿写出来，第一眼通常不会太差。
但真实页面至少还要补这些东西：
设计稿能直接给出
| 模块 | 设计稿信息 | 实现关注点 |
|---|---|---|
| 遮罩 | 全屏半透明黑色 | 是否覆盖全屏和安全区 |
| 标题图 | 固定宽高 | 是否保持比例，不被压缩 |
| 主视觉 | 居中展示 | 是否和标题、按钮保持相对位置 |
| 关闭按钮 | 固定尺寸和坐标 | 点击热区是否足够 |
| 底部说明 | 两行短文案 | 长文案是否换行或截断 |
设计稿不会自动告诉你
| 问题 | 需要补的工程规则 |
|---|---|
| 用户快速连续点击主按钮 | 加重复点击保护 |
| 弹窗正在 loading | 保持布局稳定，不让按钮抖动 |
| 接口失败 | 给失败态和重试入口 |
| 目标端不支持复杂滤镜 | 用稳定的遮罩、渐变或图片近似 |
| 图片资源没发布线上地址 | 先本地归档，记录后续替换位置 |
我以前最容易犯的错，是先把视觉调得很像，然后真实状态一接进来就乱。
所以现在我会先把状态表列出来，再改 DOM 和样式。
八、示例 2：记录弹窗不是一张卡片的问题
记录弹窗一开始看起来像列表样式问题。
真正动手后才会发现，它更多是状态问题。
| 状态 | 卡片展示 | 主要操作 | 容易漏掉的问题 |
|---|---|---|---|
| 待处理 | 标题、图片、状态标签 | 主要操作按钮 | 按钮宽度和点击节流 |
| 已完成 | 完成标识、详情入口 | 查看详情 | 状态文案是否和设计稿一致 |
| 有凭证 | 凭证内容、复制入口 | 复制 | 长凭证是否撑破 |
| 失败态 | 失败原因、辅助说明 | 重试或查看 | 失败原因过长 |
| 空态 | 空图、空文案 | 无或辅助入口 | 不要额外增加设计稿没有的 UI |
实现前，我会把静态结构和真实状态分开：
静态结构：面板、标题、列表、卡片、图片、按钮、空态
真实状态：待处理、已完成、有凭证、失败、无记录
边界数据：长标题、长凭证、图片为空、接口缺字段
这一步不复杂，但很管用。
它能避免一种很尴尬的情况：样张卡片很像，真实数据进来以后开始错位、溢出、按钮挤压。
九、示例 3：互动页面要保留业务主流程
互动页面通常不是单纯静态 UI。
它会包含点击反馈、数据同步、动画时序和状态变化。
做高保真时，不能为了改视觉，顺手重写业务主流程。
| 层级 | 应该调整 | 不应该顺手改 |
|---|---|---|
| 视觉资产 | 背景、主视觉、提示图、反馈图 | 数据统计口径 |
| 布局 | 主视觉位置、按钮位置、模块间距 | 路由结构 |
| 交互反馈 | 点击热区、轻微动效、反馈展示 | 核心业务状态机 |
| 兼容适配 | 图片模式、安全区、长短屏 | 接口协议 |
这个案例给我的提醒是：不要把 UI 还原理解成照搬设计稿层级。
更稳的做法，是先别动原有业务逻辑，先把关键视觉资产和交互反馈对齐。
十、三方对照：DSL、设计稿原图、资源谁说了算
实现时我不会只看一个来源。
DSL、设计稿原图、资源清单各有用，但也各有坑。
| 来源 | 最适合判断 | 风险 |
|---|---|---|
| DSL | 坐标、尺寸、字体、色值、节点层级 | 节点命名可能不表达业务含义 |
| 设计稿原图 | 整体观感、层级压盖、相对位置 | 无法精确读数 |
| 资源清单 | 图片是否用对、是否需要切图 | 临时 URL 可能失效 |
| 真实实现 | 兼容性、状态、性能、交互 | 容易偏离设计稿 |
三者不一致时，我一般会优先保留设计稿原图和 DSL 里的尺寸层级，再结合目标端兼容性做工程取舍。
关键是把取舍写进文档。
不要只留一句“这里先这样”。
十一、AI 应该放在流程里的哪里
我现在不会把 AI 当成“直接给我写完页面”的工具。
我更多会把它放在三个位置：
| AI 任务 | 输入 | 输出 |
|---|---|---|
| 结构化设计稿 | DSL、设计稿原图、资源 URL | 结构表、尺寸表、资源表 |
| 转成开发计划 | 项目规则、现有代码、分析文档 | 组件拆分、样式计划、状态清单 |
| 帮助自查 | 设计分析、代码实现、设计稿原图 | 偏差清单、修正优先级 |
我现在更常用的提示词会写得更具体一点，尤其是多个弹窗、多个状态一起还原时：
这里最关键的一句是：
请先用 MasterGo MCP 分析这些设计稿，不要直接写代码。
如果提示词里只给链接，不要求分析、归档资源和沉淀检查表，AI 很容易直接生成一份看起来能跑、但后面不好验收的页面。
十二、踩坑和对应规则
这张表我会放在规则文档里，每次 UI 还原前先过一遍。
目的很简单：少返工。
| 坑 | 问题表现 | 对应规则 |
|---|---|---|
| 只看主页面 | 主页面像，弹窗和空态完全不是一个系统 | 多页面和多状态逐稿分析 |
| 只按截图写 | 验收时全是间距偏差，没人知道改多少 | 同时记录 px 和 rpx |
| 资源没归档 | 图片能显示，但后续找不到来源 | 资源 URL、本地路径、用途入表 |
| 使用风险 CSS | 浏览器看着可以，目标端不稳定 | 兼容优先，必要时近似 |
| 只做样张态 | 长标题、长凭证、空图撑破布局 | 补真实数据边界 |
| 样式越调越乱 | class 重复、旧样式残留、文件过长 | SCSS 按模块组织，必要时拆分 |
十三、最后交付前，我会过这张检查表
设计稿分析
- 是否拿到了设计稿链接、页面节点和设计稿原图。
- 是否所有页面、弹窗、空态、详情态都单独分析。
- 是否记录原稿尺寸和换算规则。
- 是否提取背景、面板、卡片、按钮、图标、文字等关键节点。
- 是否记录颜色、渐变、圆角、描边、阴影、字体、字号、行高。
文档和资源
- 是否在项目约定目录写分析文档。
- 是否有结构表、尺寸表、资源表、状态表。
- 是否下载可用资源并语义化命名。
- 是否标注后续线上资源替换位置。
- 是否记录设计效果和工程兼容之间的取舍。
实现和验证
- 是否先阅读现有页面、组件和样式。
- 是否复用设计系统里的按钮、弹窗、导航等公共组件。
- 点击事件是否使用项目约定写法，自定义点击是否节流。
- 图片填充模式是否明确。
- SCSS 是否按模块嵌套，单文件是否控制在合理范围。
- 长文本、空数据、缺字段、失败态是否处理。
- 是否运行项目构建或开发命令并通过验证。
最后
回到开头的问题：UI 高保真还原到底靠什么？
表面上看，它是一个“设计稿转页面”的问题。
但真正做下来，我觉得它更像一个工程流程问题。
工具层，MCP 把设计稿结构化。
规则层，项目统一约束换算、组件、事件、样式和兼容性。
文档层，把设计稿分析、资源和取舍沉淀下来。
实现层，在现有工程范式里落页面、样式、资源和状态。
验证层，用检查清单和构建结果闭环。
AI 确实能加速 UI 还原，但前提是规则足够明确。
没有规则时，它大概率只是把设计稿“翻译”成一份看起来能跑的代码。
规则清楚后，它才更容易沿着项目的工程口径，把设计稿变成可维护、可验收、后面还能继续改的页面。
所以我现在对 UI 还原度的要求，基本就是这句话：
不追求一次生成完美页面，而是追求每一次偏差都能被定位、解释、修正和沉淀。
这是 AI 参与前端 UI 还原后，我觉得真正能留下来的东西。
纯经验干货分享，为了帮助大家节省token使用量，分享给大家一个工具：
zengate.shiyuncs.com
