尧图网页设计 
说实话以前让我去“拼 UI”是我最抗拒的事情之一。本身不是科班设计师但前端工作又躲不开界面每天对着设计稿切图、量间距、算圆角、调状态几轮改版下来人都麻了。后来我开始用 AI 辅助做界面从文案到布局再到代码生成从第一次生成到最终落地我基本不再需要手动去拼每一个控件。这篇文章就把这两年我实际用 AIUI 的完整路径、工具选型和踩过的坑整理出来希望能帮到还在手动调像素的UI设计师、前端开发者和独立开发者。1. 拼UI的旧日子到底痛在哪1.1 传统手工“拼UI”的三个大坑手动拼UI有三个绕不过去的痛点。第一个是重复劳动。拿到设计稿要有人肉翻译标注、切图、适配不同屏幕、点选状态一套界面十几个页面每个都要重新量一遍。尤其是列表页和表单页组件长得差不多但细节全不一样改一个间距可能要连带改几十个页面。第二个是还原度偏差。设计稿里一个阴影、一条分割线靠肉眼和规范文档很难完全对齐。经常出现“设计稿看着很精致切出来页面像个半成品”的情况视觉验收来回拉锯时间都耗在微调上。第三个是调试成本。UI不只是静态视觉还要考虑loading、空态、报错、键盘弹起、横竖屏切换。这些状态在“拼”的阶段容易漏漏了就要反复补补的时候又会引入新的样式覆盖问题。所以“拼UI”看起来是体力活实际上是在透支判断力。1.2 为什么AI能切入这个场景AI能接手“拼UI”底层是大模型同时打通了视觉理解、代码生成和设计语言这三个能力。多模态模型可以直接看一张界面截图说出布局结构也可以把一个草图描述翻译成可运行的HTML或React组件。更关键的是AI理解的不只是“画出来”它知道按钮、输入框、导航栏这些组件在业务里的常规动作所以生成的代码往往自带交互逻辑。这就像以前外包切图沟通半天才能做对现在给AI一段需求描述它能在几秒钟内给出第一版成品。我们只需要站在用户视角做验收和修正而不是从空白画布开始一像素一像素地“拼”。2. AI重写UI设计流程从灵感草稿到可交付代码2.1 关键转变从“画框”到“描述需求”过去做UI的第一步是画线框先想好左侧导航还是顶部导航几个卡片间距多少。现在用AI辅助第一步变成了“描述需求”。我会按“场景-目标用户-布局-风格-技术栈”五个要素写一段需求说明。比如做充电桩运营后台就会写“面向运维人员的大屏监控面板深色背景左侧菜单右侧放设备状态卡片卡片内展示实时功率、充电进度和告警信息技术栈是HTMLTailwind”。这段描述越具体AI生成的界面越接近可用状态。以前“画框”是在约束视觉现在“描述”是在约束语义AI把语义翻译成视觉和代码核心技能也从拖动鼠标变成了写清楚需求。2.2 AI生成UI的两种主流形态文生UI与图生UI目前我常用的AI生成UI方式有两条路。文生UI适合从零开始直接输入文字需求让AI生成完整页面或组件代码。这种方式适合产品早期做原型、验证想法几分钟就能拿到一版能点能看的Demo。图生UI适合有设计沉淀的情况上传设计稿、截图甚至手绘草图让AI还原成可编辑的代码。这种方式在改版旧系统时特别有用比如业务系统没有设计源文件只有线上截图我用图生UI把截图变成干净的代码结构再继续迭代。两条路不是互斥的实际项目里经常先图生UI拿到基座再用文生UI做局部模块增改。按照我的习惯前期探索用文生UI快速铺开进入正式开发后切到图生UI锁定结构和视觉减少随机性。对比维度文生UI图生UI输入文字提示词、需求描述截图、设计稿、手绘草图最佳场景原型验证、从零起项目旧系统翻新、还原设计稿输出稳定性依赖提示词质量随机性偏大参考图约束强结构相对稳定常用工具v0、ChatGPT、ClaudeScreenshot to Code、Figma AI插件2.3 提示词才是“新UI骨架”有了AI提示词就像以前的“UI骨架文档”。很多人觉得“AI生成UI不准”大部分原因是提示词太笼统。我现在写UI类提示词会固定包含五部分角色、任务、风格、布局、约束。比如角色资深UI设计师 任务设计一个充电桩状态监控面板 视觉风格企业级深色主题克制的霓虹高亮卡片圆角12px 布局左侧导航栏右侧四个设备状态卡片卡片内包含实时功率数字滚轮和充电进度环 约束输出HTMLCSS使用Tailwind适配1080p大屏字体不小于14px这样AI拿到的不只是一句“做一个充电桩界面”而是一份结构清晰的需求说明书。生成之后再把不符合规范的地方比如间距、颜色、状态文案逐条告诉AI修改。提示词的作用不是让AI一次做完美而是把所有“拼UI”过程中的约束前置减少来回沟通的次数。写提示词的时候多用具体数字和名词少用“好看一点”“大气一点”这种空话。3. 我实测过的AIUI工具链选型3.1 设计侧先让AI给“看起来对”的视觉稿在视觉素材层面我常配合几类AI工具。Figma里现在有不少AI插件可以一键生成设计变量、补齐图标、生成文案甚至根据组件库风格给出新页面建议适合团队有设计系统的场景。Comfy UI这类节点式AI绘画工具则适合生成UI的背景纹理、渐变质感和氛围光。我习惯用几个风格LoRA固定色板避免每次生成的质感差太多。如果你还在用Comfy UI的基础模型直接出UI大概率会觉得“脏”原因就是没有固定风格粒子和LoRA层面的一致性。Midjourney和Recraft这类模型更适合做风格探索比如“充电站大屏的三种视觉方向”。但它们生成的文字和控件排布并不可控所以我不直接用它们出正式界面而是让它们出氛围图再用人或代码工具落地成UI。设计侧的核心原则是AI负责“产出素材”人负责“定义约束”。3.2 代码侧让AI直接给出可运行的前端实现代码侧是我现在用得最多的部分。需要快速原型时我会用v0这类工具输入需求描述直接生成React或Tailwind页面。如果要在现有项目里改样式、加组件就用Cursor配合Claude或GPT类模型在编辑器里框住代码提需求AI直接改。GitHub Copilot和通义灵码这类补全插件适合写重复的样式块、响应式断点、简单的状态切换。用PyCharm写Python桌面工具时Fitten这类AI插件也可以在Qt界面布局上帮上忙。这里有个提醒AI生成的代码有时候会堆很多嵌套div和复杂CSS导致UI界面卡顿。所以要定期压缩层级能用Flex就用Flex别让AI自由发挥画一堆绝对定位。3.3 游戏与特殊场景Unity、自动化回归UI不只在网页端。游戏项目里用Unity做界面很常见Unity UI Toolkit配合AI辅助写UXML和USS效率会高很多。比如动态数字滚轮效果让AI先生成滑动数字的组件逻辑再套上投影和圆角样式比纯手写快不少。Unity的ShaderGraph也可以用AI辅助生成一些着色器节点逻辑给UI加动效。测试端我会用Maestro这类UI自动化工具让AI根据需求描述直接生成YAML脚本自动走一遍登录、点击、状态切换的流程用来验证AI生成的界面交互链路。最近还看到有人把虚幻引擎的Web UI插件和AI结合让网页端UI直接嵌入游戏理论上也能用同一条AI工作流维护。多AI协作也逐渐成为常态生成UI用一个模型审查UI代码再用另一个模型两个AI互相找问题比单模型自检靠谱。4. 实操案例用AI从0到1拼出一个充电桩显示界面4.1 需求拆解与提示词设计拿充电桩显示UI开发来做个完整案例。这个场景足够典型有实时数据、状态切换、大屏展示三个难点。我先拆需求页面要有顶部标题栏左右结构主区域放四个设备状态卡片每张卡片要有设备编号、当前功率、充电进度环、告警灯整页需要深色底和高亮数据方便远距离观看。拆完需求后我把这些写进提示词按“角色-任务-风格-布局-约束”组织先让AI生成一份HTMLCSS原型。这一步的重点不是追求完美而是让AI先给出“结构和视觉方向”把人工从空白画布里解放出来。4.2 落地过程AI生成、手动微调、引入设计规范拿到AI生成的第一版后我不会直接上生产而是按四步走。第一步检查布局看四个卡片在1080p下是否排得开间距是否一致。第二步检查数据逻辑实时功率、充电进度这些数据要从接口来AI生成的代码里大概率是写死的假数据我会把数据绑定改成变量或者让AI生成数据请求的占位方法。第三步是视觉微调AI给的蓝色渐变经常太刺眼我会压暗背景、统一按钮圆角、给告警状态补一个不那么突兀的橙红色。第四步是走查状态把“充电中、已充满、故障、离线”四个状态轮流替换一遍看看有没有文字溢出或颜色对比度不够。如果项目最终要落到Unity里我会再让AI把这份HTML结构改写成UXMLUSS顺便用Comfy UI生成一张带颗粒感的深色纹理作为面板背景这样视觉质感和代码结构都能保下来。4.3 关键代码片段与AI的取舍这是AI生成的卡片代码我加了少量注释方便理解div classdevice-card span classdevice-label充电桩-A01/span div classpower span classvalue idpowerValue120.4/span span classunitkW/span /div div classprogress-ring> AI+UI实战：从文生UI到图生UI，告别手动拼界面
说实话以前让我去“拼 UI”是我最抗拒的事情之一。本身不是科班设计师但前端工作又躲不开界面每天对着设计稿切图、量间距、算圆角、调状态几轮改版下来人都麻了。后来我开始用 AI 辅助做界面从文案到布局再到代码生成从第一次生成到最终落地我基本不再需要手动去拼每一个控件。这篇文章就把这两年我实际用 AIUI 的完整路径、工具选型和踩过的坑整理出来希望能帮到还在手动调像素的UI设计师、前端开发者和独立开发者。1. 拼UI的旧日子到底痛在哪1.1 传统手工“拼UI”的三个大坑手动拼UI有三个绕不过去的痛点。第一个是重复劳动。拿到设计稿要有人肉翻译标注、切图、适配不同屏幕、点选状态一套界面十几个页面每个都要重新量一遍。尤其是列表页和表单页组件长得差不多但细节全不一样改一个间距可能要连带改几十个页面。第二个是还原度偏差。设计稿里一个阴影、一条分割线靠肉眼和规范文档很难完全对齐。经常出现“设计稿看着很精致切出来页面像个半成品”的情况视觉验收来回拉锯时间都耗在微调上。第三个是调试成本。UI不只是静态视觉还要考虑loading、空态、报错、键盘弹起、横竖屏切换。这些状态在“拼”的阶段容易漏漏了就要反复补补的时候又会引入新的样式覆盖问题。所以“拼UI”看起来是体力活实际上是在透支判断力。1.2 为什么AI能切入这个场景AI能接手“拼UI”底层是大模型同时打通了视觉理解、代码生成和设计语言这三个能力。多模态模型可以直接看一张界面截图说出布局结构也可以把一个草图描述翻译成可运行的HTML或React组件。更关键的是AI理解的不只是“画出来”它知道按钮、输入框、导航栏这些组件在业务里的常规动作所以生成的代码往往自带交互逻辑。这就像以前外包切图沟通半天才能做对现在给AI一段需求描述它能在几秒钟内给出第一版成品。我们只需要站在用户视角做验收和修正而不是从空白画布开始一像素一像素地“拼”。2. AI重写UI设计流程从灵感草稿到可交付代码2.1 关键转变从“画框”到“描述需求”过去做UI的第一步是画线框先想好左侧导航还是顶部导航几个卡片间距多少。现在用AI辅助第一步变成了“描述需求”。我会按“场景-目标用户-布局-风格-技术栈”五个要素写一段需求说明。比如做充电桩运营后台就会写“面向运维人员的大屏监控面板深色背景左侧菜单右侧放设备状态卡片卡片内展示实时功率、充电进度和告警信息技术栈是HTMLTailwind”。这段描述越具体AI生成的界面越接近可用状态。以前“画框”是在约束视觉现在“描述”是在约束语义AI把语义翻译成视觉和代码核心技能也从拖动鼠标变成了写清楚需求。2.2 AI生成UI的两种主流形态文生UI与图生UI目前我常用的AI生成UI方式有两条路。文生UI适合从零开始直接输入文字需求让AI生成完整页面或组件代码。这种方式适合产品早期做原型、验证想法几分钟就能拿到一版能点能看的Demo。图生UI适合有设计沉淀的情况上传设计稿、截图甚至手绘草图让AI还原成可编辑的代码。这种方式在改版旧系统时特别有用比如业务系统没有设计源文件只有线上截图我用图生UI把截图变成干净的代码结构再继续迭代。两条路不是互斥的实际项目里经常先图生UI拿到基座再用文生UI做局部模块增改。按照我的习惯前期探索用文生UI快速铺开进入正式开发后切到图生UI锁定结构和视觉减少随机性。对比维度文生UI图生UI输入文字提示词、需求描述截图、设计稿、手绘草图最佳场景原型验证、从零起项目旧系统翻新、还原设计稿输出稳定性依赖提示词质量随机性偏大参考图约束强结构相对稳定常用工具v0、ChatGPT、ClaudeScreenshot to Code、Figma AI插件2.3 提示词才是“新UI骨架”有了AI提示词就像以前的“UI骨架文档”。很多人觉得“AI生成UI不准”大部分原因是提示词太笼统。我现在写UI类提示词会固定包含五部分角色、任务、风格、布局、约束。比如角色资深UI设计师 任务设计一个充电桩状态监控面板 视觉风格企业级深色主题克制的霓虹高亮卡片圆角12px 布局左侧导航栏右侧四个设备状态卡片卡片内包含实时功率数字滚轮和充电进度环 约束输出HTMLCSS使用Tailwind适配1080p大屏字体不小于14px这样AI拿到的不只是一句“做一个充电桩界面”而是一份结构清晰的需求说明书。生成之后再把不符合规范的地方比如间距、颜色、状态文案逐条告诉AI修改。提示词的作用不是让AI一次做完美而是把所有“拼UI”过程中的约束前置减少来回沟通的次数。写提示词的时候多用具体数字和名词少用“好看一点”“大气一点”这种空话。3. 我实测过的AIUI工具链选型3.1 设计侧先让AI给“看起来对”的视觉稿在视觉素材层面我常配合几类AI工具。Figma里现在有不少AI插件可以一键生成设计变量、补齐图标、生成文案甚至根据组件库风格给出新页面建议适合团队有设计系统的场景。Comfy UI这类节点式AI绘画工具则适合生成UI的背景纹理、渐变质感和氛围光。我习惯用几个风格LoRA固定色板避免每次生成的质感差太多。如果你还在用Comfy UI的基础模型直接出UI大概率会觉得“脏”原因就是没有固定风格粒子和LoRA层面的一致性。Midjourney和Recraft这类模型更适合做风格探索比如“充电站大屏的三种视觉方向”。但它们生成的文字和控件排布并不可控所以我不直接用它们出正式界面而是让它们出氛围图再用人或代码工具落地成UI。设计侧的核心原则是AI负责“产出素材”人负责“定义约束”。3.2 代码侧让AI直接给出可运行的前端实现代码侧是我现在用得最多的部分。需要快速原型时我会用v0这类工具输入需求描述直接生成React或Tailwind页面。如果要在现有项目里改样式、加组件就用Cursor配合Claude或GPT类模型在编辑器里框住代码提需求AI直接改。GitHub Copilot和通义灵码这类补全插件适合写重复的样式块、响应式断点、简单的状态切换。用PyCharm写Python桌面工具时Fitten这类AI插件也可以在Qt界面布局上帮上忙。这里有个提醒AI生成的代码有时候会堆很多嵌套div和复杂CSS导致UI界面卡顿。所以要定期压缩层级能用Flex就用Flex别让AI自由发挥画一堆绝对定位。3.3 游戏与特殊场景Unity、自动化回归UI不只在网页端。游戏项目里用Unity做界面很常见Unity UI Toolkit配合AI辅助写UXML和USS效率会高很多。比如动态数字滚轮效果让AI先生成滑动数字的组件逻辑再套上投影和圆角样式比纯手写快不少。Unity的ShaderGraph也可以用AI辅助生成一些着色器节点逻辑给UI加动效。测试端我会用Maestro这类UI自动化工具让AI根据需求描述直接生成YAML脚本自动走一遍登录、点击、状态切换的流程用来验证AI生成的界面交互链路。最近还看到有人把虚幻引擎的Web UI插件和AI结合让网页端UI直接嵌入游戏理论上也能用同一条AI工作流维护。多AI协作也逐渐成为常态生成UI用一个模型审查UI代码再用另一个模型两个AI互相找问题比单模型自检靠谱。4. 实操案例用AI从0到1拼出一个充电桩显示界面4.1 需求拆解与提示词设计拿充电桩显示UI开发来做个完整案例。这个场景足够典型有实时数据、状态切换、大屏展示三个难点。我先拆需求页面要有顶部标题栏左右结构主区域放四个设备状态卡片每张卡片要有设备编号、当前功率、充电进度环、告警灯整页需要深色底和高亮数据方便远距离观看。拆完需求后我把这些写进提示词按“角色-任务-风格-布局-约束”组织先让AI生成一份HTMLCSS原型。这一步的重点不是追求完美而是让AI先给出“结构和视觉方向”把人工从空白画布里解放出来。4.2 落地过程AI生成、手动微调、引入设计规范拿到AI生成的第一版后我不会直接上生产而是按四步走。第一步检查布局看四个卡片在1080p下是否排得开间距是否一致。第二步检查数据逻辑实时功率、充电进度这些数据要从接口来AI生成的代码里大概率是写死的假数据我会把数据绑定改成变量或者让AI生成数据请求的占位方法。第三步是视觉微调AI给的蓝色渐变经常太刺眼我会压暗背景、统一按钮圆角、给告警状态补一个不那么突兀的橙红色。第四步是走查状态把“充电中、已充满、故障、离线”四个状态轮流替换一遍看看有没有文字溢出或颜色对比度不够。如果项目最终要落到Unity里我会再让AI把这份HTML结构改写成UXMLUSS顺便用Comfy UI生成一张带颗粒感的深色纹理作为面板背景这样视觉质感和代码结构都能保下来。4.3 关键代码片段与AI的取舍这是AI生成的卡片代码我加了少量注释方便理解div classdevice-card span classdevice-label充电桩-A01/span div classpower span classvalue idpowerValue120.4/span span classunitkW/span /div div classprogress-ring>