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

别让漂亮的UI图骗了你，真正的页面需要的是结构，而不是像素。一份清晰的UI Spec，能让AI工具从“猜”变成“精准执行”。

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

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

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

---

为什么不要直接把图转成代码？

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

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

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

这不是“AI不行”这么简单。

更准确地说，是你给它的输入，本来就不够它做工程判断。

---

UI Spec到底是什么？

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

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

一张图能告诉你颜色和氛围，却很难告诉你层级、约束和状态。

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

而前端真正要落地的，恰恰就是这些工程信息。

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

图片不是源头，它只是视觉表达。

页面能不能跑，决定权在结构，不在像素。

---

最小可用UI Spec模板

前端真正需要的信息	单张图片是否提供？	缺失后的结果
组件层级嵌套	❌	页面容易被平铺成一堆 div，看着像，结构却散。
交互与页面状态	❌	没有Hover、Loading、Empty、Error，页面像静止的海报。
响应式规则	❌	一到手机端就跑版，文字挤压，模块互相顶撞。
设计Token	❌	颜色、字号、间距只能靠猜，后面很难接入统一体系。
真实数据边界	❌	占位符一换成长文本，卡片马上撑爆。

这张表的意思很简单：

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

---

为什么image-to-code总会跑偏

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

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

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

问题不在于工具不会画，而在于它不知道该先理解什么。

它是在猜结构，不是在翻译结构。

---

破局的关键，是先补UI Spec

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

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

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

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

先写结构，再谈好看。

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

YAML

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

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

---

用交易仪表盘举个例子

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

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

会先写成这样：

YAML

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加上参考图去生成代码，也比直接丢一张图给图片转代码工具更容易落地。

---

这份模板怎么用？

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

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

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

这时候再让AI做视觉探索，而不是让它凭空决定页面结构。

代码阶段不要只追求还原图片，而是要根据UI Spec做组件化实现。

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

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

下一步可以这样做：如果你也在做AI UI，先把这份UI Spec模板收藏起来，下一次别再从一张图直接开工。如果已经踩过“图很好看，页面一落地就跑偏”的坑，欢迎把最卡的一步留在评论区，说清楚问题就够了。需要继续看后续拆解的话，可以转给正在做页面的同事，下一篇会接着讲怎么把结构写对。