一套可逼近像素级前端生成的流程：先拆 layout，再拆 element，再做实现 diff

1. 先说结论

我最近在收敛一套流程，目标不是“让 AI 大概做一个像样页面”，而是：

让它尽可能逼近参考图，朝像素级前端生成去走。

这里真正的钩子，不只是模型能力，而是 prompt 的结构化程度。

如果 prompt 还是一句：

请你根据这张图实现一个 landing page

那结果通常只会停在“差不多像”。
问题不在模型完全不会写，而在于它没有被强制进入一个适合前端实现的分析顺序。

我现在更倾向于把这个任务拆成三段：

1. layout extraction
2. element extraction
3. implementation diff

这三段连起来，才更像一套真的能用于生产的前端生成流程。

2. 第一层：先拆 layout

第一步不是让 AI 写代码，而是先让它只看布局。

目标不是“理解产品”，也不是“分析品牌”，而是：

把截图里的实现单元先拆出来。

比如它要先回答：

• 页面主容器是什么
• 顶部导航是不是单独模块
• Hero 是不是双栏
• 左列是不是还要继续拆成 social proof、标题块、评分行、CTA 行
• 右列是不是要继续拆成头像簇、tab、卡片、logo 行

这一步如果没做，AI 很容易直接输出一个“大而糊”的组件，后面很难再收敛。

所以我现在会先要求它输出：

• Name
• Type
• Parent
• Children
• Implementation Unit
• Need Build
• Module Level

这样拿到的就不只是“描述”，而是一个实现清单。

3. 第二层：再拆 element

只拆 layout 还不够。

很多页面看起来像，但一落到实现就会出问题，通常不是因为大结构错了，而是因为这些小东西漏了：

• 分隔线
• 导航中间的小点
• pill / chip
• 头像叠放关系
• 装饰符号
• 图标容器
• 卡片内部 padding
• 按钮与链接之间的节奏

所以第二层必须继续拆 element。

这一步我更关注的是：

• 哪些元素必须存在
• 哪些元素影响 spacing / grouping
• 哪些只是装饰
• 哪些值得单独验收

这样做的好处是，AI 不会只做一个“大框架”，而是会被迫把真正影响视觉完成度的小部件补上。

4. 第三层：最后做实现 diff

当 layout 和 element 都有了，才进入代码实现。

但实现完也不能停，因为“生成一次”通常不够。
更稳的方式是：

把当前实现截图，再和参考图做一次 diff。

这时关注的不是内容语义，而是这些实现差异：

• spacing
• alignment
• grouping
• sizing
• missing elements
• extra elements
• typography 导致的布局偏差

这一步很关键，因为很多时候第一版代码已经有了 70%-80% 的结构，但剩下的完成度，全在 diff 阶段里。

5. 这套流程为什么有效

因为它把一个模糊任务，改造成了一个适合 agent 执行的顺序：

1. 先抽象成可实现模块
2. 再补齐小元素
3. 再落代码
4. 再做视觉收敛

这样 AI 不再只是“写一页 HTML”，而是在做一件更像前端工程师的事：

先拆结构，再实现，再校正。

6. 当前已经能做到什么

当前这套流程已经能比较稳定地生成：

• landing page hero
• SaaS 风格首页
• agent / workflow / platform 类页面
• 带复杂卡片、tab、logo strip、装饰元素的首屏

如果参考图本身很清晰，第一版通常就能把模块层级做对。
后面再通过 element 和 diff 两轮收敛，视觉接近度会明显提高。

7. 当前还差什么

这里也要说实话。

现在它还没有到“随便给图就 100% 像素级还原”的程度。
要继续逼近，至少还有两件事要补：

1. 切图 / 资产补充

如果参考图里有这些内容：

• 真人头像
• 品牌 logo
• 特定图标
• 插画
• 产品截图

那只靠代码近似，效果总会有上限。
这时还是需要：

• 切图
• SVG 资产
• 更准确的图片素材

2. 基于 AI 的微调闭环

第一版实现出来后，还需要让 AI 基于“实现图 vs 参考图”继续微调：

• 字号
• 间距
• 比例
• 对齐
• 元素密度
• 装饰位置

也就是说，真正更好的效果，不只是“生成”，而是：

生成 + 对比 + 微调。

8. 我更关心的不是 demo，而是流程

我觉得这里最有价值的，不只是某一张图被做出来了。

更有价值的是：

这件事开始有一套流程了。

一旦流程稳定下来，它就不只是单次演示，而会变成：

• UI 复刻流程
• 设计到代码的转换流程
• agent 驱动的前端实现流程
• 更适合验收和交付的实现流程

这意味着后面可以继续加：

• 模块计数
• 实现 checklist
• 视觉 diff
• 自动验收标准

它会越来越像真正能落地的工程系统，而不是一次性的 prompt trick。

9. 这篇的最短版本

如果要把这篇压缩成一句话，那就是：

像素级前端生成，不是靠一句 prompt，而是靠一套 prompt workflow。

核心顺序是：

layout -> element -> diff -> refine

而下一步要把它继续推高，关键在两点：

• 补资产
• 做 AI 微调闭环

这两件补上之后，整体效果会再往前走一大截。

10. Version 2：基于 image2code skill 跑完整实战

这次我把流程往前推进了一版：不只是写 workflow，而是直接拿一张 Radiance Beauty Commerce Landing Page 参考图，用 image2code skill 跑成一个可预览的前端页面。

这版的关键变化是：

1. 先确认本地项目结构和预览方式
2. 对参考图做 full-image inspection
3. 拆出页面主结构：外层深色舞台、白色页面卡片、顶部导航、左侧 hero、商品网格、右侧拱形产品视觉
4. 再拆小元素：搜索框、头像、CTA 箭头、商品卡阴影、圆形产品缩略图、加号徽标、金色线条、叶片、花形装饰
5. 实现静态 HTML/CSS 页面
6. 用 Playwright 按 MacBook 视口截图
7. 基于实现图继续调右侧拱形主视觉、页面高度和底部视口

这不是最终意义上的“100% 像素级”。因为原图里的真实产品摄影、真人头像和材质光照没有原始素材，所以这版用 CSS 合成近似。但它已经验证了一个更关键的点：

image2code 不应该只产出代码，还应该产出过程证据。

这包括：

• 参考图观察结论
• layout / element 拆解结果
• 可运行页面
• 实现截图
• full-page 截图
• bottom viewport 截图
• diff 后的 refine 记录

下面是这次 Version 2 的底部视口截图，按 MacBook Pro 16 寸常见最大逻辑视口 1728x1117 截取，并滚到页面底部：

这是同一页面的 full-page 截图，用来保留完整页面高度和滚动结果：

这次也暴露出一个实际问题：如果一开始没有严格保存 skill 每一步的中间文件，那么后面复盘会变弱。所以下一版我会把过程产物固定下来：

image2code-case/
  reference-full.png
  manifest.json
  slices/
  analysis/
    layout.md
    elements.md
    visual-diff.md
  screenshots/
    implementation-top.png
    implementation-bottom.png
    implementation-fullpage.png

这比“生成一页 HTML”更接近我想要的方向：一个可审计、可复盘、可继续迭代的 image2code workflow。