Article
前端视觉生成：从参考到 Prompt
前端视觉生成：从参考到 Prompt
前端本质上是一种视觉语言。它把信息结构、空间关系、视觉层级、组件状态和交互反馈组织在屏幕上。HTML 负责语义结构，CSS 负责视觉表达，JavaScript 负责状态和行为
这也是大语言模型和前端很贴合的原因。前端需求往往不是纯算法问题，而是把某种体验描述清楚，再逐步落实成界面。只要描述足够具体，模型就能把布局、样式、交互和响应式约束转成代码
但前端视觉生成不应该被理解成“写一段很长的 prompt”。文字只是输入方式之一，而且是低带宽输入。很多视觉判断，例如比例、间距、材质、状态变化和动画节奏，用截图、录屏或参考网站传达会更直接
更稳的方式，是先用截图、录屏或参考链接建立视觉目标，再用设计变量把这个目标拆成可以执行的工程要求。每一次修改都应该落到可浏览的界面、小范围 diff 和清晰的 Git 提交里
不只是提示词
Prompt 适合表达意图、约束和取舍，但它不总是最高效的视觉输入。前端界面里有大量信息很难靠文字一次说清楚：
- 间距是不是紧凑
- 卡片边界是不是太重
- 浮层是不是从正确的锚点展开
- hover 和 focus 的状态是不是自然
- 动画是轻微反馈还是强烈表演
- 移动端是否还能保持同样的信息层级
截图、录屏和参考网站可以补上这些信息。截图适合传达布局、比例、色彩、材质和排版；录屏适合传达状态变化、动画节奏、hover 反馈和页面切换；参考网站适合让模型理解一整套产品气质
更实际的工作流通常是：
:::code-group
先给模型一张截图或一个参考网站，让它描述这个界面的结构、层级、组件、状态和动效
再说明：保持这种 compact utility UI 的气质，但替换成我的业务内容
最后补充工程约束：响应式、focus-visible、reduced motion、transform / opacity 动画:::
这样做的重点不是让模型“照抄”某个网站，而是让它从具体界面中抽取设计变量。Prompt 负责补充目标和边界，截图和录屏负责传达视觉事实
设计变量模板
不要把视觉要求拆成互不相关的术语表。更自然的方式，是在观察一个模块时，按同一套变量模板去拆解它：
| 变量 | 需要回答的问题 | 常见表达 | |-----|---------------|---------| | 结构 | 内容如何分组，主次区域在哪里 | grid、rail、list、detail panel、stacked layout | | 层级 | 用户第一眼应该看哪里 | type scale、contrast、spacing、density、focal point | | 表面 | 内容承载在什么材质和深度上 | solid surface、muted surface、hairline border、soft shadow | | 状态 | 用户操作后界面如何反馈 | hover、pressed、selected、loading、empty、error | | 动效 | 元素如何进入、离开和变化 | fade、scale、slide、stagger、origin-aware motion | | 约束 | 这个效果能否稳定落地 | responsive、focus-visible、reduced motion、transform / opacity |
这套模板不要求每次都写满。它的作用是让截图、录屏和参考网站可以被拆解成可执行的前端任务
:::code-group
请先观察这张截图，把它拆成：结构、视觉层级、表面材质、组件状态、动画方式和工程约束
然后保留它的产品气质，用我的业务数据重新实现
不要照抄品牌、文案和图形资产:::
把参考拆成三个高频模块
设计变量模板如果一直停留在抽象层，会很像一套漂亮术语。真正有用的方式，是把它落到几个高频模块里，看同一套分析法怎么处理不同问题
这里故意只保留三个例子：Hero section 代表品牌首屏，Settings popover 代表浮层交互，Data table 代表高密度工具界面。它们分别覆盖气质、状态和信息密度这三类最常见的前端判断
重点不是记住这三个模块，而是看参考图时都回到同一组问题：
- 结构是什么，内容怎么分区
- 第一视觉信号是什么，层级靠什么建立
- 表面和边界是轻还是重
- 状态怎么反馈，是否补齐 hover、focus、selected、empty
- 动画从哪里开始，是否符合触发位置
- 最终能不能稳定落到响应式、无障碍和性能约束里
Hero section
Hero section 最容易被 prompt 写坏。只说“做一个现代化首页”通常会得到空泛的大标题、渐变背景和装饰卡片。截图或参考网站在这里更有价值，因为它能直接传达首屏比例、背景媒体、标题尺度和 CTA 的位置关系
看 Hero 时，最重要的不是某个单独术语，而是结构、焦点和气质是否一致：
| 观察点 | 判断方式 | |-------|---------| | 首屏焦点 | 第一眼是品牌名、产品本体、人物、场景，还是关键操作 | | 背景媒体 | 是真实产品图、生成图、视频、3D 场景，还是纯色背景 | | 标题尺度 | 标题是否承担品牌信号，而不是挤在普通卡片里 | | CTA 位置 | 主操作是否在首屏可见，次操作是否降级 | | 下一区域 | 首屏是否露出下一段内容，避免像封闭海报 |
更好的做法是先给模型参考，再限制它的输出：
:::code-group
参考这张首屏截图的构图：品牌名是第一视觉信号，背景使用真实产品场景，标题覆盖在媒体上
请改成我的产品内容，保留 full-bleed hero 和下一区域露出的节奏
不要使用纯渐变背景，也不要把标题放进卡片里:::
Settings popover
Settings popover 是最适合用录屏解释的模块。截图只能看到它打开后的样子，录屏能告诉模型它从哪里出现、是否有 scale in、离开时有没有 exit animation，以及 hover 区域是否稳定
这类模块的重点不是“它长什么样”，而是锚点、状态和动效是否像一个真的工具界面：
| 观察点 | 为什么重要 | |-------|-----------| | 触发器 | 决定浮层锚点和 transform origin | | 表面 | 决定是工具面板、系统浮层还是品牌装饰 | | 尺寸 | 决定它是轻量菜单还是复杂设置面板 | | 状态 | 决定 hover、focus、selected 是否可见 | | 动画 | 决定它是从按钮方向长出来，还是从中心突兀出现 | | 可达性 | 决定键盘能否进入、切换和关闭 |
:::code-group
参考录屏里的 settings popover：它从右下角按钮 origin-aware 展开
面板使用 muted surface、hairline border、8px radius 和轻微 shadow
打开 220ms fade in + scale in，关闭 160ms fade out
内部控件补齐 hover、focus-visible、selected 和 disabled 状态
动画只用 transform 和 opacity，并支持 prefers-reduced-motion:::
这个例子也说明，所谓 surface、shape、state、motion 并不是互相独立的章节。它们共同决定一个模块是否像真实产品
Data table
Data table 很容易被模型做成“有表头的卡片列表”。真正的数据表关心的是比较、定位、筛选和批量操作，而不是装饰
到了数据表，分析重点会从品牌气质切换成信息密度。这里最该观察的是列宽、行高、表头、排序、筛选、hover row、selected row、sticky header、empty state 和横向滚动策略。它的视觉质量来自密度控制和状态清晰，而不是阴影或渐变
:::code-group
做一个高密度 data table：表头 sticky，列宽稳定，数字列右对齐并使用 tabular numbers
行 hover 只使用很轻的背景变化，selected row 要比 hover 更明确
顶部提供筛选和批量操作区域，空结果时显示可操作的 empty state
移动端不要硬塞完整表格，改成可扫描的 stacked rows:::
这里最值得用截图传达的是密度。文字说“紧凑”很模糊，但截图能告诉模型一行到底应该多高、单元格留白应该多窄
这三个例子已经足够覆盖大部分前端视觉输入。你不需要把所有组件都写进 prompt，而是要先判断眼前的问题更像品牌首屏、浮层交互，还是高密度数据界面，再用同一套变量去拆
工程边界
视觉生成最终要落到浏览器里。模型能看懂参考，不代表实现就一定稳定。每个模块都应该补一层工程约束，避免生成看起来对、用起来差的界面
最常见的约束有四类：
- 响应式：桌面、平板、移动端的布局是否分别成立
- 性能：动画是否只使用
transform和opacity，是否避免 layout shift - 无障碍：是否有 focus-visible、语义标签、键盘路径和可读对比度
- 状态完整性：是否覆盖 loading、empty、error、disabled 和 selected
:::code-group
实现时请同时给出 desktop 和 mobile 行为
动画只使用 transform 和 opacity，不要动画 width、height、top、left
所有 icon buttons 提供 screen-reader labels
保留 focus-visible，尊重 prefers-reduced-motion
动态内容加载时不要造成 layout shift:::
这部分可以放在每次 prompt 的最后。它不负责创造视觉风格，但负责让视觉效果能稳定进入真实代码
附录：常见动画效果
动画不适合作为正文主线硬背，但适合放在附录里做速查。实际使用时，先判断模块的交互目的，再选择对应的动效，而不是为了“炫”而加动画
| 效果 | 适合场景 | 观察重点 | |-----|---------|---------| | Fade in / Fade out | Toast、遮罩、内容切换 | 透明度变化是否轻，不要突然闪现 | | Scale in | Popover、菜单、轻量 Modal | 是否从触发器方向展开，避免中心突兀放大 | | Slide in | Drawer、侧栏、通知 | 进入方向是否符合界面结构 | | Stagger | 菜单项、列表、卡片组 | 子项延迟是否克制，避免拖慢操作 | | Transform origin | Popover、Tooltip、Context menu | 锚点是否和触发器位置一致 | | Easing / Spring | Hover、拖拽、面板切换 | 速度曲线是否像界面反馈，而不是视频转场 |
Entrance / Exit
出入场动画
Stagger
错峰编排
Transform origin
变换与空间
Easing
缓动曲线对比
附录：常见形状效果
形状会直接改变产品气质。工具型界面通常更适合小圆角、清晰边界和紧凑控件；品牌页或视觉实验可以使用更强的几何语言
| 效果 | 适合场景 | 风险 | |-----|---------|------| | Rounded rectangle | 卡片、按钮、输入框 | 圆角过大会让工具界面玩具化 | | Pill shape | 标签、开关、筛选 chip | 大量使用会削弱信息密度 | | Squircle | App icon、现代卡片 | 需要和整体图形语言一致 | | Cut corner | HUD、科技面板、游戏 UI | 容易显得过度主题化 | | Notch | 工具面板、设备外壳感 | 使用太多会制造噪音 | | Organic shape | 品牌视觉、插画、封面 | 不适合严肃数据和操作界面 |
Shape vocabulary
形状术语示例
附录：常见前端组件
如果你想把参考图进一步翻译成组件语言，可以再补一层常见组件识别。这里不追求完整词典，而是把最常见的模块先认出来，再回到结构、状态和约束去描述
shadcn/ui 的组件文档是很好的速查入口，尤其适合统一命名和交互语义：Components
| 类别 | 代表组件 | 更适合描述什么 | |-----|---------|---------------| | 录入 | Input、Textarea、Checkbox、Radio Group、Select、Switch | 用户如何输入文本、选择选项、切换状态 | | 导航 | Breadcrumb、Tabs、Pagination、Navigation Menu | 用户现在在哪、内容如何分组、页面怎么切换 | | 浮层 | Popover、Tooltip、Dialog、Drawer、Dropdown Menu | 信息从哪里弹出、是否打断流程、怎样关闭 | | 反馈 | Badge、Progress、Skeleton、Toast | 系统当前状态、加载进度、结果提示是否明显 | | 展示 | Card、Table、Data Table、Accordion、Collapsible | 信息怎样承载、比较、折叠和展开 |
如果要进一步识别参考图里具体用了什么组件，可以先记住这些高频术语：
| 组件 | 简要介绍 | |-----|---------| | Accordion | 一组可展开、可折叠的内容区，适合 FAQ、设置分组和长说明 | | Breadcrumb | 面包屑导航，用来表示当前页面在站点层级里的位置 | | Tabs | 一组平级内容面板，同一时间通常只显示一个 tab panel | | Tooltip | 悬停或聚焦时出现的轻量提示，适合补充说明，不适合承载关键流程 | | Popover | 相对某个触发器展开的浮层面板，适合轻量设置、筛选和次级操作 | | Dialog | 中断当前流程的对话框，适合确认、危险操作或必须完成的表单 | | Drawer | 从边缘滑出的面板，更适合移动端详情、筛选和辅助编辑 | | Dropdown Menu | 由按钮或触发器展开的动作菜单，适合放一组离散操作 | | Badge | 小型状态标记，适合表达标签、状态或数量提醒 | | Skeleton | 内容未加载完成前的骨架占位，用来降低等待时的跳变感 | | Toast | 短暂出现的非阻塞反馈，适合成功提示、轻量错误和后台状态 | | Table / Data Table | Table 偏结构化展示，Data Table 还会补上排序、筛选、列控制和批量操作 |
写 prompt 时，组件名最好不要单独出现，而要和状态一起出现。比如不是只说“做个 popover”，而是说“做一个从按钮锚点展开的 popover，补齐 hover、focus-visible、selected 和 reduced-motion”
检查清单
一个前端视觉输入是否完整，可以按这几项检查：
- 是否给了足够具体的参考，而不是只说“现代化”
- 是否说明了要复用参考里的哪些结构、比例、密度和气质
- 是否先判断当前问题更像首屏、浮层，还是数据界面
- 是否覆盖了默认、hover、focus、selected、loading、empty、error 等状态
- 是否说明了动画的触发、方向、原点、时长和退出方式
- 是否说明了桌面端和移动端分别如何布局
- 是否说明了性能边界，尤其是
transform/opacity和 layout shift - 是否说明了无障碍要求，例如 focus-visible、contrast、reduced motion
好的视觉输入不是更长的提示词，而是更清楚的参考、更准确的模块拆解和更明确的工程边界。模型负责生成，开发者负责判断这些输出是否真的像一个可用产品
参考资料与工具
- shadcn/ui Components：常见前端组件参考，适合统一组件命名、交互语义和术语口径
- Animation Vocabulary：动画术语参考
- Transitions.dev：页面和组件过渡参考，适合观察 transition pattern、duration、easing 和 route transition
- React Bits：React 动效组件和视觉片段参考，适合观察可复用的 animated UI pattern
- Navbar Gallery：导航栏设计参考，适合观察 navigation layout、active state、dropdown 和 responsive nav
- Collect UI：UI 模式和界面灵感参考，适合找 card、form、dashboard、navigation 等常见组件的视觉方向
- Chrome DevTools MCP：前端大模型调试工具，让模型可以连接 Chrome DevTools，检查页面、性能、网络和控制台状态