不要再直接把 UI 图转成代码了，先看这份 UI Spec 模板

有人把一张刚生成的后台图贴到群里，顺手问了一句：这图已经挺像样了，能不能直接丢给图片转代码工具？我盯着那张图看了两秒，第一反应不是“好不好看”，而是它到底有没有告诉工具，这个页面给谁用、先看什么、状态怎么补、手机端怎么折。

图确实顺，阴影、留白、层级都在，第一眼很容易让人放松警惕。可真把它放进浏览器，数据一长，卡片就开始挤；屏幕一缩，按钮和列表就互相顶；几个状态页没补齐，页面看起来就像少了骨架。那一刻会特别直观：图能给 AI 视觉结果，给不了工程判断。

那条留言其实点得很准：UI Spec 不是多写一步，而是先把结构说清楚，再让工具去画、去写、去落地。

这条留言最有价值的地方，不是在评价 image2，而是把真正的问题挑明了：你要交付的不是图，是页面。

很多人第一次看到 AI 生成的 UI 图，都会先被外观骗到。深色背景、柔和阴影、整齐卡片、像样的图标，放在一张图里看，确实很有完成度。

但只要把它放进真实业务里，问题很快就会冒出来：数据一长，卡片就撑；屏幕一窄，布局就塌；按钮一多，主次就乱。

很多人会把“看起来像界面的图片”直接当成 UI 设计稿。这个误会很常见，因为它们第一眼确实很像。

但两者要解决的事不一样。图片主要回答“长什么样”，设计稿还要回答“怎么组织、怎么响应、怎么切换、怎么复用”。前者偏外观，后者更接近页面骨架。

同一张图，放在大屏上看可能很完整，切到手机预览里就开始挤；占位文案看着舒服，换成真实数据以后，留白和卡片边界立刻紧起来。那种“图很稳、页面很飘”的感觉，通常就是在这里暴露的。

可以把它理解成看效果图盖房子。效果图能看出大概风格，却不会告诉你承重墙、管线、楼板和动线怎么排。页面也是一样，光有图，代码工具只能猜。

这张表的意思很简单：单张图不是不能用，而是不能单独当源头。

它可以帮你定风格、定氛围、定视觉密度，但页面落地最麻烦的部分，不在“看起来好不好看”，而在“能不能实现、能不能维护、能不能继续扩展”。

image-to-code 真正的难点，不是“把图翻译成代码”，而是“根据视觉表象猜结构”。

它看得到三个很像的卡片，却未必知道这三个卡片其实应该抽成同一个组件。它看得到一个很亮的按钮，却未必知道它是业务主操作还是次要操作。它看得到一块炫光效果，却未必知道那只是装饰，不该变成复杂的绝对定位。

所以你会看到一种很典型的结果：生成速度很快，返工也很快。第一眼觉得能用，第二眼就开始改，第三眼已经在手动重构。

如果只在“图”和“代码”之间来回跳，大概率还是会回到手改。更稳的做法，是在中间补一层 UI Spec。

这一步不是什么概念包装。它要解决的，就是 AI 生成的 UI 图在落地时最容易缺掉的那层结构判断。

这层东西也不需要写得很玄。它本质上就是一份结构化界面规范，可以是 YAML，也可以是 JSON。格式不是重点，重点是先把工程判断写清楚：

1. 页面要解决什么问题。 2. 主路径和次路径分别是什么。 3. 哪些模块可以复用。 4. 哪些状态必须补齐。 5. 响应式规则怎么变。

下面这份就是我现在会先写出来的最小模板：

page:
  name: 页面名称
  purpose: 页面目的
  target_user: 目标用户
  primary_action: 用户核心动作
  layout_type: dashboard / form / list / detail / landing

sections:
  - name: 模块名称
    purpose: 模块作用
    priority: high / medium / low
    component_type: Card / Table / Form / Tabs / Chart

states:
  - loading
  - empty
  - error
  - normal

responsive:
  desktop: 桌面端布局
  tablet: 平板端布局
  mobile: 移动端布局

visual_tokens:
  color_style: 视觉风格
  density: 信息密度
  radius: 圆角规则
  spacing: 间距规则

acceptance:
  - 验收标准 1
  - 验收标准 2

有了这层东西，gpt-image-2 之类的模型再去出图，就不再是“凭感觉画一张漂亮图”，而是围绕一套已经被约束过的结构去做视觉探索。图的角色也会变轻：它更像情绪板，不是唯一标准。

比如我要做一个交易仪表盘，我不会直接说：帮我生成一个高级的交易后台页面。

这种说法太空了，AI 很容易生成一个很酷但不一定能用的页面。

我会先写成这样：

page:
  name: 交易仪表盘
  purpose: 帮助用户快速查看账户风险、持仓和交易信号
  target_user: 个人交易者 / 专业交易员
  primary_action: 查看当前账户风险
  layout_type: dashboard

sections:
  - name: 账户概览
    component_type: Metric Cards
    priority: high
  - name: 风险预警
    component_type: Alert Card
    priority: high
  - name: 持仓表格
    component_type: Data Table
    priority: medium
  - name: 信号面板
    component_type: Signal Cards
    priority: medium

states:
  - loading
  - empty
  - error
  - normal

这样 AI 至少知道：这个页面不是单纯展示数据，而是要帮助用户快速判断账户风险。风险预警和账户概览是高优先级，持仓表格和信号面板是中等优先级，页面还必须考虑 loading、empty、error、normal 四种状态。

后面再用这份 UI Spec 去生成视觉图，结果会比“随便生成一个交易后台”稳定很多。再拿这份 UI Spec 加上参考图去生成代码，也比直接丢一张图给图片转代码工具更容易落地。

我的建议很简单，按四步走就够了。

先自己填一版。 不用追求完美，先把页面目标、核心用户、主要模块写出来。

再让 AI 检查。 你可以直接问它：这份 UI Spec 是否缺模块、缺状态、缺响应式规则？有没有不适合工程落地的地方？

然后用 UI Spec 生成视觉图。 这时候再让 AI 做视觉探索，而不是让它凭空决定页面结构。

收口时用 UI Spec + 参考图生成代码。 代码阶段不要只追求还原图片，而是要根据 UI Spec 做组件化实现。

我的经验是，只要前面这一步写清楚，后面 AI 生成页面会稳定很多。它不一定一次完美，但至少不会完全跑偏。

页面需求 → UI Spec → 视觉参考 → 代码实现 → 截图修正