image-to-ui 不是单一产品，而是一类 Agent Skill 的统称，不同实现的侧重点差异明显。核心逻辑是一致的：把 UI 参考图拆解为“代码实现层”和“位图资产生成层”，分别用正确的方式处理，然后组装成可运行的页面[citation:1][citation:5]。
它的工作前提是你已经有一张图：UI 截图、设计稿、App Store 预览图、或者 AI 生成的 concept image[citation:13][citation:16]。输入这张图，输出是一个包含 index.html、styles.css、script.js 和 assets/generated/ 目录的完整 demo 项目[citation:13]。
它的核心纪律来自对“假高保真”的反对：用 CSS 渐变、SVG 拼凑或纯色占位来“近似”一张复杂的摄影图或插画，不算完成了任务[citation:1][citation:3]。该生图的地方必须真的调 image2 生图，该写代码的地方必须是真的可编辑文本。
image-to-ui 的主要功能
代码与位图的自动拆分。Skill 要求 AI 在动笔之前先输出一份“资产清单”：哪些区域是 code-ui（标题、正文、按钮、表单、导航、状态栏、价格标签），哪些区域是 image2-assets（首屏主视觉、摄影场景、插画、产品渲染图、复杂纹理、地图、角色）[citation:1][citation:5]。
真实生图与后处理。对于需要生图的区域，AI 编写提示词、调用 image2 通道生成真实位图文件，然后进行裁切、缩放、透明化、尺寸修正，最后把图片接回页面[citation:1][citation:5]。
可点击交互组装。生成的页面不是静态截图。按钮有响应，导航能跳转，文本可选中，页面在浏览器中可预览、可继续修改[citation:1][citation:13]。
差距核对。实现完成后，Skill 要求 AI 用截图对比最终页面和参考图，报告视觉差异，而不是自行宣布“已经高保真还原”[citation:1][citation:16]。
image-to-ui 的核心特色
“什么不算完成了”的硬规则。这是它最独特的设计。官方明确列出几种不能声称“已经用了 image2”的情况：只写了结构页面还没生成真实位图；只生成了图片但没有接回页面；只用 CSS、渐变、SVG 临摹复杂视觉却说完成了高保真复刻[citation:1][citation:3]。
Effect Image 策略（部分实现）。在 Redesign/Create 模式下，Skill 会先生成一张完整的“效果图”（Effect Image）作为视觉规范，审核通过后再从这张效果图中拆分出代码 UI 和位图资产。Recreate 模式则跳过这一步，直接以原始参考图为真相来源[citation:2][citation:4]。
image2 通道的多级回退。Skill 定义了“原生 image2”和“备案通道”的区分。原生通道优先（system imagegen、project image2）；失败时回退到 OpenRouter ICU gpt-image-2 等通道。如果所有通道都不可用，必须如实报告“尚未生图”，不能继续[citation:2][citation:3]。
品牌与组件约束（进阶实现）。部分实现支持 Brand Profile 和 Component References，约束颜色、字体、间距、圆角、组件样式，并生成 brand-compliance.md 合规报告。但明确边界：品牌配置不授权生成品牌 Logo、商标或商业字体[citation:2][citation:4]。
image-to-ui 可以用来做什么？
把 UI 截图变成可交互的前端原型。你有一张 App 设计稿或网页截图，想快速得到一个能点击、能预览、能继续改的 HTML/CSS/JS 页面，而不是继续在 Figma 里改[citation:1][citation:6]。
做高保真还原，但不想让 AI “用 CSS 糊弄”。参考图里有复杂的摄影主视觉、颗粒纹理、手绘插画、产品渲染图——这些用 CSS 很难逼近。Skill 强制 AI 走真实生图路线[citation:3][citation:5]。
从 AI 生成的 concept image 落地到真实网页。先用 GPT-Image 或类似工具生成一张理想中的页面图，再用这个 Skill 把它变成真实的、可部署的前端代码[citation:16]。
不适合的场景：纯代码实现的页面（没有复杂位图需求）、需要精确像素级还原但无法接受 AI 生图差异的场景、以及不涉及 UI 的后端任务。
image-to-ui 适合哪些人？
- 需要快速做 UI 原型的前端开发者：手上有一张图，想快速得到可运行、可继续改的页面骨架。
- 设计师：想把自己的设计稿直接转成可点击的 demo，用于验证交互或演示。
- 用 AI 做高保真还原的人：受够了 AI 用 CSS 渐变“假装”摄影图的输出，需要一个强制走真实生图的工具。
- 独立开发者：想从一张参考图快速搭建一个演示页面，而不需要手动切图、找素材。
不太适合：只需要简单静态页面的场景、不涉及位图资产的纯表单/文档页面、以及不信任 AI 生图质量的像素级还原需求。
image-to-ui 如何安装？
不同实现的安装方式不同，以几个代表性项目为例：
方式一：通过 skills CLI 安装（通用）
npx skills add bahayonghang/my-ai-cli-toolkit --skill image-to-ui-skill方式二：克隆到 Codex 技能目录（zhu-guli326 实现）
git clone https://github.com/zhu-guli326/image2_UI_skill.git "$env:USERPROFILE\.codex\skills\image2_UI_skill"安装后重开 Codex 或新开会话[citation:1][citation:5]。
方式三：Cursor 用户（Uizze 实现）
npx skills add uizze/uizze --skill image-to-ui --agent cursor无需 Uizze 账户或 MCP 连接[citation:11]。
前置条件：需要可用的图像生成通道（原生 image2、或配置好的回退通道）。没有生图通道时，Redesign/Create 模式无法完成效果图或位图资产生成，但 Recreate 模式仍可运行（如果页面不需要新生成的位图资产）[citation:2]。
image-to-ui 怎么使用？
基本流程（以 Recreate 模式为例）：
- 上传参考图到 AI 助手。
- 触发 Skill，例如：“使用 image-to-ui-skill。参考我上传的图，完成一个可点击预览的 demo。要求：先判断哪些部分应该用代码实现，哪些部分必须真实调用 image2 生图”[citation:1]。
- AI 执行分析：输出资产清单，拆分
code-ui和image2-assets。 - AI 为需要生图的区域编写提示词，调用 image2 生成真实位图。
- AI 做后处理（裁切、透明化、尺寸修正），把图片接回页面。
- AI 补齐可点击行为和页面跳转。
- AI 用截图核对最终结果和参考图的差距，报告完成情况。
推荐的提示词模板（来自官方 README）[citation:1][citation:5]：
使用 image-to-ui-skill。
参考我上传的图，完成一个可点击预览的 demo。
要求：
1. 先判断哪些部分应该用代码实现，哪些部分必须真实调用 image2 生图
2. 不要把标题、正文、按钮文字、价格做进图片里
3. 需要真实生成的位图资产，请实际生成并接回页面
4. 如果没有真实生成位图并接入页面，不要告诉我已经用了 image2
5. 最后告诉我生成了哪些图片、图片放在哪、哪些区域仍然是代码实现image-to-ui 使用技巧
明确要求“先分析，再动手”。如果你只想先看拆解结果，可以在提示词中写“先不要写代码，先分析我上传的 UI 图，并输出：哪些部分适合代码实现，哪些部分需要生图”[citation:5]。这样可以先审查资产清单，确认方向后再执行。
注意“什么不算完成了”的硬规则。如果 AI 说“我已经完成了高保真还原”，但实际只用 CSS 近似了复杂视觉，这不符合 Skill 的要求。你可以直接追问：“生成的位图资产文件在哪？请列出路径。”[citation:1]
代码 UI 和 image2 资产的边界不要混淆。标题、按钮文字、价格、导航标签不能被烘焙进生成的图片里，它们必须是可编辑的 HTML 文本。否则页面就失去了可访问性和可翻译性[citation:1][citation:13]。
验证时不要只看完整页面截图。对于长页面，Skill 的建议是同时截取“全页宏观图”和“分段视口截图”，逐段检查排版、间距、图标完整性、颜色和响应式行为[citation:12]。
image-to-ui 收费吗？
Skill 本身免费且开源。搜索到的 image-to-ui 相关 Skill 均以开源形式发布（MIT 或其他开源许可证），不收取费用[citation:11]。
但 image2 生图可能产生 API 费用。如果使用需要付费的 image2 通道（如 OpenRouter ICU gpt-image-2），每次生图会产生调用费用。原生 imagegen 通道（随 Codex 附带）通常不额外收费，但具体取决于你的 Agent 和配置[citation:2][citation:13]。
image-to-ui 的优点与缺点
| 维度 | 优点 | 缺点 |
|---|---|---|
| 代码与位图分离 | 强制区分“该写代码的”和“该生图的”，避免用 CSS 近似复杂视觉 | 需要用户理解这个边界，否则可能得到“代码骨架 + 缺失资产”的半成品 |
| 可运行性 | 输出是真实可点击的 HTML/CSS/JS 页面，不是静态截图 | 交互逻辑需要 AI 补齐，复杂交互可能需要额外调整 |
| 生图纪律 | 明确定义“什么不算完成了 image2 流程”，防止虚假宣称 | 依赖可用的 image2 通道；通道不可用时功能受限 |
| 视觉验证 | 要求用截图对比参考图，报告差距而非自行宣布完成 | 视觉差异的接受程度因项目而异，AI 判断可能不够精确 |
| 实现多样性 | 不同实现覆盖 Recreate/Redesign/Create 不同模式，有品牌和组件约束的进阶版本 | 同名 Skill 来源众多，质量和功能完整度参差不齐，需要甄别 |
image-to-ui 与同类工具对比
vs 手动切图 + 写 CSS。手动流程需要你导出图片素材、测量间距、写样式、组装页面。image-to-ui 把这个流程自动化，且强制 AI 用真实生图替代“用 CSS 假装是图片”[citation:1]。
vs 通用“把截图写成 HTML”提示词。通用提示词没有“代码/位图分离”的纪律，AI 倾向于用 CSS 渐变和 SVG 拼凑复杂视觉，产出看起来“差不多”但质感明显掉档的页面。image-to-ui 的硬规则阻止了这种行为[citation:3]。
vs image-to-code（纯代码路线）。image-to-code 专注于生成响应式前端代码，不涉及位图资产生成[citation:8]。如果你的参考图没有复杂位图需求，纯代码路线更简单。如果有摄影图、插画、纹理，image-to-ui 是更合适的选择。
vs codex-vision（图像生成/评审工具）。codex-vision 专注于“生成 UI mock 图”或“评审截图”，不涉及把截图转成可运行页面的流程[citation:7]。image-to-ui 覆盖的是从参考图到可运行页面的完整链路。
image-to-ui 常见问题 FAQ
Q：image-to-ui 和 image-to-code 有什么区别？
image-to-code 专注于从设计图生成响应式前端代码，不涉及位图资产生成[citation:8]。image-to-ui 的核心是代码和位图的分离：该写代码的写代码，该生图的真的生图，然后组装成可运行页面[citation:1]。
Q：没有 image2 生图通道还能用吗？
取决于模式。Recreate 模式下，如果页面不需要新生成的位图资产，可以运行。Redesign/Create 模式下需要 Effect Image 或位图资产时，缺少生图通道会阻塞流程[citation:2]。
Q：生成的图片里会不会包含标题和按钮文字？
不应该。Skill 的硬规则明确要求：标题、正文、价格、按钮文字、导航标签不能被做进图片里，它们必须保留为可编辑的 HTML 文本[citation:1][citation:5]。
Q：它和 Figma 的“导出代码”功能有什么不同？
Figma 导出的是布局和样式，但复杂视觉仍然是你手动导出的图片素材。image-to-ui 不仅处理布局，还真实生成缺失的位图资产（主视觉、纹理、插画），并自动接回页面[citation:1]。
Q：如果 AI 说“已经高保真还原”但看起来不像怎么办？
追问具体细节：“生成的位图资产文件路径是什么？”“在 320px 宽度下渲染检查了吗？”“用截图对比参考图了吗？”Skill 要求 AI 在最终报告中列出图片路径和替换区域，而不是只给一个模糊的结论[citation:1][citation:5]。
image-to-ui 综合评价
image-to-ui 解决的是一个被 AI 编码工具系统性忽略的问题：截图转代码的“差不多”和“真的能用”之间的差距。
大多数 AI 在收到“把这个截图做成页面”的请求时，会用 CSS 渐变近似天空、用 SVG 拼凑插画、用纯色块占位产品图。输出看起来“有那味儿”，但质感明显掉档，而且难以继续修改。image-to-ui 的核心价值在于它拒绝这种近似：它强制 AI 判断哪些区域必须走真实生图，并真的去生成、接回、验证。
它的门槛在于生图通道的可用性。原生 image2 通道（如 Codex 附带的 imagegen）让流程相对顺畅，但如果你依赖回退通道（如 OpenRouter ICU），则可能产生 API 费用和额外的配置步骤。另外，不同实现的成熟度差异较大：基础版覆盖核心流程，进阶版有品牌约束和多 Agent 编排，选择时需要看你的具体需求。
对于任何需要从 UI 参考图快速得到“真的能跑、该是图片的地方真的是图片”的开发者，image-to-ui 值得尝试。它的输出不一定是像素级完美的，但它的纪律——代码和位图分离、真实生图、可点击交付——让结果比“CSS 拼贴”靠谱得多。
◯ 评论 0