ui拆图转html的一些思考

最近我看了 SemineChen/yueban-image-to-code 这套 skill。看完之后，我对”UI 图怎么转成 HTML”这件事有了更系统的认识。

以前一说这个事，我第一反应也是最常见的那种做法：把图丢给 AI，让它先出一版页面，哪里不对再慢慢修。

这个办法当然能用。想快速出一个差不多的页面，没问题。但如果你想做高还原，失控的概率就很大。因为模型一旦开始”猜”，总会有不少地方差一点——而你不知道它差在哪一步。

这套 skill 有意思的地方就在这里。它不是先让 AI 猜页面，而是先把整件事拆开：先拆图层，先量坐标，先裁图，再写代码，最后对照原图去验。这样一来，整个过程就没那么玄了，变成了一条很实在的工程流程。

这套 skill 到底在做什么

如果只看名字，你会以为它是那种“一键把图变成页面”的东西。

但我把 README 和 SKILL.md 看完之后，发现它真正抓的是这三件事：

• 原图就是唯一参考，不能凭感觉重排，也不能顺手美化。
• 所有元素都先统一到 750px 画板坐标系里，再谈代码实现。
• 代码、切图、坐标、验收都必须围绕同一份 layers.manifest.json 来组织。

简单来说，它不是让 AI 直接看图写页面，而是先把图拆成一堆对象——文字是一类，简单图形是一类，复杂图标和插画是一类。每一类用不同方法处理，但最后都要回到同一份清单上。

这份清单就是 manifest。你可以把它理解成一份”视觉清单”：图纸上有什么元素、各自在什么位置、用什么方式还原，全部记在这里。

没有这个中间层，事情就会很麻烦。页面出错了，你根本不知道到底是识别错了、布局错了、切图错了，还是缩放错了。有了这份清单，每一步都能对得上，出了问题也能定位到具体环节。

作者这套方案，大概是怎么跑的

作者这套方法，概括下来就是下面这几步：

1. 读取原图尺寸，先统一缩放到 750px 画板。
2. 建立 layers.manifest.json，把每个图层的 source_bbox、scaled_bbox、类型、层级和资源路径都记下来。
3. 先做 bbox 预览，确认框选区域是否真的覆盖了完整元素。
4. 再按 bbox 精确导出 PNG，而不是先写页面再补素材。
5. 文本层还原成可编辑文本，规则图形尽量用 CSS，复杂图标和插画走独立切图。
6. 页面完成后再做整页截图，与归一化后的原图做差异对比。

这里最关键的其实不是”切图”本身，而是顺序——它要求你必须按这个顺序来：

先把图层定义清楚 → 再导资源 → 再写代码 → 最后验收。

这和我们平时的习惯正好反着来。平时更常见的做法是先糊一版页面，哪里不对再修，结果就是越修越乱。

这套 skill 的意思很明确：如果 manifest 没立住，后面的代码其实都是浮的。

裁图这一步，真的是硬活

我自己看下来，最有感触的部分不是”生成页面”，而是”怎么裁图”。

因为真正容易翻车的，往往不是页面大结构，而是那些小东西：图标、头像、插画、装饰块。这些东西一旦裁歪了，整个页面的还原度就不对了。

作者在 references/slicing.md 里把这件事写得很细。我翻成人话，大概就是：

• 裁剪框不能凭肉眼估，必须先有 bbox。
• bbox 要覆盖“完整视觉外框”，不只是深色主体本身。
• 半透明边缘、阴影、浅色底形、抗锯齿留白，都属于元素的一部分。
• 如果边界不确定，宁可多留 4px-12px 安全边，也不能切小。
• 背景抠除必须发生在固定画布内部，不能抠完以后再自动裁边。

这个思路我很认同。因为很多人做这类事，最容易犯的错误就是看着主体去裁。结果裁出来虽然“干净”，但也把阴影、底形、留白一起裁没了。

所以很多图标最后只剩一半，或者刚好贴着边，不是因为抠图技术差，而是因为前面的 bbox 本身就错了。

仓库里几个脚本，其实也都是围着这个问题在转：

• preview_bboxes.py：把 manifest 里的 bbox 直接画回原图，先验框。
• extract_png_asset.py：按精确 bbox 裁图，输出画布大小严格等于 bbox，不自动 trim。
• audit_png_assets.py：检查 PNG 是否贴边、是否有 alpha、角落是否真的透明。
• compare_images.py：拿最终页面截图和参考图做像素级差异比对。

这里面我最喜欢的是 extract_png_asset.py 这个思路。很朴素，就一句话：

按 bbox 截，画布别乱动。

哪怕后面要去背景，也是在这个固定画布里面去，而不是重新算边界。这个做法看起来笨一点，但真的稳。

这套方法真正有价值的地方

我看这套 skill 的时候，一个很强的感觉就是：它其实在故意限制 AI 的自由发挥。

比如不能自动重排，不能拿相似图标代替，不能用 AI 补一张差不多的图，也不能把复杂位图硬改成矢量。这些规则看起来有点死板，但如果目标就是高还原，我觉得很合理。

因为真正难的，不是”先写出一版 HTML”，而是写完以后你能不能说清楚它到底哪里不对。没有中间过程——没有 manifest，没有 bbox，没有切图记录——最后就特别容易变成一句话：”看着差不多，但总觉得哪里不对。”至于到底是哪一层错了，没人说得清。

所以我现在更愿意把它看成一个小型工作流，而不是一个简单的生成器。它先把图变成数据，再让脚本和代码围着这份数据去工作。

下面这些是我的想法，不是作者现在的方案

上面这些，说的是作者现在这套 skill 的逻辑。下面这两点，是我自己想到的延伸方向。

图标裁剪后，可以加一条 AI 重绘分支

作者现在的原则很明确：图标和位图尽量来自原图，不要替代，不要重绘。

这个原则我认同。

但如果是我后面继续做第二版，我会考虑加一条可选分支：先把图标按精确 bbox 切出来，然后让 AI 做一次受约束的重绘或者修复。

这个分支只适合一种情况，就是原图太糊了。

比如原始截图分辨率很低，或者压缩得很厉害，小图标边缘已经脏了。这时候你就算老老实实 1:1 搬过去，最后放到网页里也还是糊的。

但这里有个前提我觉得不能丢：AI 只能修，不能改。

也就是说它做的是“保形修复”，不是“顺手换个风格”。所以至少得守住这几条：

• bbox 还是原来的 bbox。
• 坐标还是原来的坐标。
• 图标语义、轮廓和视觉重量不能变。
• 重绘结果必须回到原位置对比，而不是单独看着好看就算过。

所以我会把这件事理解成一条修资源的支线，不是主线。

先让 AI 帮忙拆图标、标坐标

如果说上一条是"裁完之后 AI 帮忙修"，那这一条就是"裁之前 AI 帮忙看"。相比之下，我更想做的其实是这个方向：不是让 AI 直接生页面，而是先让它帮忙拆图。

因为作者现在这套方法虽然稳，但 bbox 测量这件事确实很花时间。页面元素一多，手动一个个框，挺累的。

所以我会想让 AI 先来一轮前置工作：

• 自动识别页面里有哪些疑似图标、插画、头像和复杂位图。
• 给出候选的 bbox。
• 顺手标一个图层 id 或用途标签。
• 产出一份待确认的 manifest 草稿。

这样人做的事就不是从零开始量，而是去检查：这些框对不对，要不要改。

我觉得这种工作方式会快很多。

但这件事也得说清楚：AI 给的只能是候选，不能直接当最终答案。

因为只要它把底形、阴影、半透明边缘这些东西看错了，后面的切图和布局都会跟着错。

所以在我看来，AI 更适合放在 manifest 前面，负责识别和提案；作者现在这套脚本，更适合放在 manifest 后面，负责执行和兜底。

如果把这两条思路接起来

如果把我的想法和作者现在这套方法接起来，我觉得最后会变成一条更顺手的流水线：

1. 原图输入。
2. AI 识别页面结构，输出图层候选和坐标草稿。
3. 人或规则复核 manifest。
4. 脚本按 bbox 导出 PNG，并做透明背景与贴边检查。
5. 代码层按 manifest 还原布局。
6. 对低质图标，按需走 AI 修复或重绘支路。
7. 最终页面截图和原图做差异复核。

这样一来，AI 放在什么位置就比较清楚了。

它不是一个上来就要包打天下的黑盒，而是流水线里几个明确环节上的加速器。

最后

看完这套 skill 之后，我自己最大的感受其实很简单，就是开篇那句话：图片转代码最难的，真的不是”让 AI 写页面”，而是先把这张图整理明白。

只要图层、坐标、裁剪、复核这些东西没立住，模型再强，也只是更快地给你一版”大概像”的东西。反过来，如果这些中间层先搭好了，就算模型没那么神，最后也能慢慢把页面推到一个很稳的状态。

所以我现在更愿意把这件事理解成一种很朴素的前端工程：不是先写组件，而是先把图里的世界整理出来。图整理明白了，代码反而是水到渠成的事。