你可能已经见过这样的演示：把一张网页截图扔给 AI，几十秒后，一个“看起来差不多”的 React 页面就出现了。
第一次看到确实很震撼。但当你把两个页面叠在一起，问题就会一个接一个地冒出来：标题偏了十几个像素，字体不像，渐变方向不对，卡片比例变了，图片只是占位图。桌面端勉强相似，一切换到手机端，整个布局又散了。
所以，截图生成代码今天到底发展到什么程度了？它真的能把 GPT 生成的网页原型变成几乎一样的静态页面吗？
我查阅了当前主流产品、GitHub 开源项目、相关论文和开发者社区讨论。答案可以浓缩成一句话：
AI 已经很擅长生成第一版，但真正的高还原度来自“生成—渲染—比较—修正”的闭环，而不是某一次神奇的生成。
来源：NoviScl/Design2Code，GitHub
一张截图里，缺失的信息比想象中更多
浏览器最终呈现给我们的是像素，但开发者写的不是像素，而是结构和规则。
一张设计图不会告诉模型：
- 这里原本使用的是 Grid，还是嵌套的 Flex；
- 标题用了哪个字体文件、哪个字重；
- 图片是
cover裁切，还是设计师提前裁好的素材； - 这个容器在 1440px、1024px 和 390px 下分别怎样变化；
- 按钮在 hover、focus 和 loading 时是什么状态；
- 截图下方还有多少没有截进来的内容。
这也是为什么“固定尺寸下很像”和“真正还原了这个页面”是两件不同的事。
Figma 官方在介绍 Figma Make 时也特别建议：如果有条件，应当给模型提供 Figma Frame，而不只是图片。Frame 里包含层级、尺寸和样式等结构化信息；普通截图只能让模型猜测，甚至无法稳定读出精确颜色。Figma Make 官方文档
Design2Code 对 484 个真实网页进行测试后发现，多模态模型最常见的问题仍然是遗漏视觉元素和生成错误布局。Design2Code 论文
这并不意味着截图生成代码没有价值。恰恰相反，它已经足够好，只是我们需要用对方法。
哪些工具已经值得用？
如果只是希望尽快看到结果，v0 是目前最顺手的选择之一。上传高分辨率截图后，它可以识别页面结构、颜色和组件，并快速生成 React/Next.js 风格的实现。v0 官方文档
它尤其适合 Landing Page、Dashboard 和常规表单页面。不过，v0 的目标更接近“迅速生成一个合理、漂亮、能运行的界面”，不是严格复刻每个像素。面对特殊字体、不规则排版、复杂渐变和品牌化视觉时，它仍然容易回到熟悉的 SaaS 风格。
如果已经有 Figma 源文件，Figma Make 或 Builder.io 通常更可靠。Builder CLI 还会尝试识别现有项目、复用组件和样式，并在更新设计时保留业务逻辑。Builder CLI 官方文档
Lovable、Bolt 和 Replit 更适合快速搭建完整 MVP。它们会主动补齐路由、状态和应用结构，但“主动补齐”有时正是视觉复刻不需要的东西。Hacker News 上也有团队表示，他们主要用这些产品制作需求验证原型，之后会丢弃生成代码。相关讨论
开源方案中，谁最成熟？
如果你希望自托管，目前最值得先试的是 abi/screenshot-to-code。
来源：abi/screenshot-to-code，GitHub
它支持 HTML/CSS、Tailwind、React、Vue、Bootstrap、Ionic 和 SVG，也可以接入多家模型。项目还加入了 Playwright 截图预览，让模型能够看到自己生成的页面。
但这里有一个关键区别：能截图，不等于已经形成严格的视觉优化闭环。
不少新项目正在补这一块。例如 imugi 尝试结合 SSIM、像素差异热图、局部截图和 DOM computed styles；screenshot-to-html 则明确把工作流拆成读取设计、生成初稿、浏览器截图和多轮修正。
这些项目代表了正确方向，但目前社区采用量和实践积累还无法与 screenshot-to-code 相比。我的判断是：可以借用它们的方法论，暂时不要把任何项目宣传的“95% 匹配”当成普遍结果。
真正有效的工作流是什么样？
来源：作者基于公开资料整理
我现在更推荐把整个过程拆成六步。
第一步：把输入准备好
不要只给一张被聊天软件压缩过的 JPEG。尽量提供原始 PNG、准确的 viewport 尺寸、字体名称或字体文件，以及 Logo、SVG 和照片素材。
如果希望页面能够响应式工作，至少再提供一张手机端参考图。截图没有展示出来的断点规则，模型只能自行发挥。
第二步：先锁定一个基准尺寸
例如先只做：
Viewport: 1440 × 900
Browser: Chromium
Zoom: 100%
Device scale factor: 1
第一轮只要求模型处理大区块、容器宽度、列关系、字体层级和主要间距。不要同时要求动画、移动端和完美组件抽象。
第三步：用真实浏览器截图
使用 Playwright 固定窗口尺寸，在字体和图片加载完成后截图：
await page.setViewportSize({ width: 1440, height: 900 });
await page.goto("http://localhost:3000");
await page.screenshot({ path: "actual.png", fullPage: true });
这一步很重要。开发服务器里“肉眼看着差不多”，通常经不起叠图比较。
第四步：不要只看一个相似度总分
至少应该同时给 Agent：
- 原始目标图；
- 当前页面截图；
- 半透明叠加图；
- 像素差异热图；
- Header、Hero、主体等区域裁剪；
- 差异区域对应元素的 computed styles。
Pixel diff 对位置和颜色敏感，SSIM 更关注结构，CLIP 类指标更接近感知相似度。它们各有盲区，组合起来才比较可靠。还要加入 OCR、DOM 和可访问性检查，否则模型可能通过背景大图或大量绝对定位“刷高分”。
第五步：按层次修，不要一口气重写
我的建议顺序是：
- 页面总宽高；
- 大区块位置；
- 容器和列宽；
- 字体与行高；
- padding、gap、margin；
- 图片裁切和背景；
- 阴影、边框和渐变；
- 图标与装饰；
- 响应式；
- hover、focus 和动画。
每次只处理一类差异。这样比较不容易出现“Header 修好了，Hero 又坏了”的情况。
第六步：视觉收敛后，再整理代码
等页面已经足够接近目标，再提取 design token、拆分组件、清理临时定位、补可访问性和建立视觉回归测试。
过早追求漂亮的组件抽象，往往会让视觉迭代变慢。
“像素级一致”不是唯一指标
如果只追求一张截图上的像素分数，最简单的作弊方式是把原图设成页面背景，或者把所有元素绝对定位。它们在 1440px 下可能非常像，但换一个宽度就失效，也无法访问和维护。
真正有意义的还原应该同时满足：
- 目标尺寸下视觉接近；
- DOM 结构合理；
- 文本可以选择和读取；
- 控件真的可以操作；
- 页面能适应至少几个关键断点；
- 代码能够继续维护。
视觉还原度和工程质量不是敌人，只是两者需要分阶段优化。
最后的判断
如果让我今天从一张 GPT 生成的网页图开始，我会这样选：
- 想最快看到第一版：用 v0；
- 想自托管并比较多个模型：用 screenshot-to-code；
- 已经有 Figma：优先走结构化设计到代码；
- 想尽量接近原图：用 Codex、Claude Code 或 Cursor 写入真实项目，再接 Playwright 视觉反馈闭环。
真正成熟的方案不是某个按钮，而是一条可验证的生产线。
AI 负责理解图片、写代码和提出修正；浏览器负责给出事实；视觉 diff 负责告诉我们究竟差在哪里。三者连起来之后，“截图生成网页”才从一次有趣的演示，变成一套可以稳定复现的工程方法。