现在 image2 模型的爆火，加上目前主流 AI 工具例如 Codex 和 Claude code，都存在前端视觉能力弱的问题，因此就出现了用 image2 生成前端UI 的图片，再让 AI 去还原的方式，Product design 这个 plugin 也是这么处理问题的。
但是，这种方式依然存在问题，如果是一些简单的页面还好，但是很多页面 AI 生成没有规范、没有标注，甚至同一个产品的不同页面就会基础样式完全不一样，这就需要设计师的参与在 Figma 这类设计工具里进行微调。又或者设计师只是用来作为参考，而不是真的使用这个 UI 位图。
IMG to figma 这个 Skill 的价值，就是把这类“停留在图片里的灵感”推进成一套可继续工作的设计底稿。它不强调你去理解背后的技术细节，而是把重复、费时、容易漏项的还原流程整理成一条清晰路径：先理解图片，再补齐缺失元素，生成可检查的界面稿，最后交给 Figma 继续编辑和组件化。
经过几次迭代，我认为效果还不错，左边是 image2 生图，右侧是利用 skill 制作的可以编辑的设计稿。
痛点分析
就像我开篇讲的那样，很多时候，设计需求不是从一份完整的 Figma 文件开始的，而是从一张图片开始的。它可能是 AI 生成的界面概念图，也可能是客户发来的参考截图，或者是你在小红书、Dribbble、Pinterest 上看到的一个好方向。
问题是，图片只能提供视觉灵感，却很难直接进入后续工作。你不能快速改文案，不能单独调整按钮，不能复用卡片，也不能把里面的图标、插画、组件拆出来继续做设计系统。它看起来像设计稿，但本质上还是一张静态图。
imgod Skill 解决的就是这个断点：把一张 UI 图片从“好看但不能用”，推进到“可以编辑、可以整理、可以继续交付”的设计底稿。
Skill 逻辑
整个 Skill 的流程可以理解成一条很顺的生产线。你不需要每次重新组织复杂要求，也不需要从零搭一套检查清单，imgod 会把关键步骤按顺序走完。
先根据图片让 AI 自己生成一份设计规范，包括样式、字体等等，输出为一份 design.md；
启动一个 react+vite 的前端项目，引入 huge icon 这套 icon 库；
找到图片里的视觉元素，调用 imag gen skill 也就是 image2 模型生图；
开始进行前端代码编程，包括 css 和 html；
开启 chrome 然后使用 playwright 执行 js 脚本将界面保存为 figma txt 并复制到用户的剪切板
这条流程的重点不是追求“一键终稿”，而是把最耗时的前半段先标准化，让人把精力放在判断、取舍和最终设计质量上。
最终效果
走完这套流程后，最终得到的不是一张新的截图，而是一份可以继续生产的设计底稿。它既保留原图的视觉方向，又能进入 Figma 做后续编辑、组件整理和团队协作。
原来的状态 | 使用 imgod Skill 后 |
|---|---|
只能看，不能改 | 文字、图片、按钮和页面区域可以继续调整 |
只能当参考图 | 可以作为设计底稿继续推进 |
复刻过程依赖手工经验 | 流程被固定下来，每次处理更稳定 |
素材缺失容易卡住 | 插画、图标、吉祥物等元素可以被补齐 |
很难进入团队协作 | 可以继续整理成组件、变量和规范 |
对于日常工作来说，这个效果很直接：你可以更快把灵感图变成可讨论的方案，把 AI 图变成可继续设计的稿子，把参考截图变成能落地的设计资产。
总结
imgod Skill 的核心价值，不是把工具讲得更复杂，而是把一条原本割裂的工作流接起来：图片负责提供灵感，Skill 负责把它整理成可继续加工的界面底稿，Figma 负责承接后续编辑、组件化和团队协作。
它最适合解决的痛点，是“我有一张很好的图，但不知道怎么把它变成可用设计资产”。通过固定流程，原本需要反复试错、手动复刻、到处补素材的工作，被压缩成一条更清晰的路径。
所以你可以把 imgod 理解成一个 UI 图片转设计底稿的流程助手。它不替代审美，也不承诺一键终稿，但它能把灵感落地的第一步做得更快、更稳定、更适合继续协作。对于想把 AI 生图、参考截图和真实设计生产接起来的人，这就是它最大的价值。