ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

从拼UI到管UI:AI辅助界面设计的高效工作流与提示词技巧

从拼UI到管UI:AI辅助界面设计的高效工作流与提示词技巧 自从用AI参与界面设计之后我发现自己越来越不想从零开始“拼UI”了。这里的“拼”不是指游戏里的拼接玩法而是过去那种对着设计稿切图、量间距、写样式、调交互状态、再做一遍响应式适配的机械循环。尤其是小团队和个人项目里UI从原型到上线往往需要一个人单挑设计、前端、测试好几个角色AI恰好把这个过程里最烦躁的部分接了过去。这篇文章不打算替任何工具站台只想记录一下我现在做界面时的真实工作流哪些环节最值得让AI介入哪些提示词可以直接抄哪些坑我已经帮大家踩过了。不管你是前端、全栈还是偶尔要负责后台界面的非专业设计应该都能从这里找到点能直接用的东西。1. 先聊聊我为什么再也不拼UI了1.1 “拼UI”到底拼的是什么以前做UI表面上是在“设计界面”实际工作里更多是在“翻译和拼装”。设计稿如果是别人给的我要把PSD里的图层还原成页面这个按钮距离左边多少像素那个标题的字号和行高是多少hover的时候阴影怎么变加载失败的时候提示文案放哪里。这些工作听起来不难但量一旦上来了人的耐心就会被一点点磨掉。更麻烦的是用户看到的UI并不只是静态视觉它是一整套状态和逻辑按钮有点击前、悬停、按下、禁用、加载中五种状态表单有正常、聚焦、错误、成功四种反馈列表有加载、空数据、异常、满页四种形态。把这些状态全部覆盖到并且在不同屏幕宽度下都能正常展示拼的就不是设计稿而是边界条件和细节工程。实际开发里还躲不开“还原成本”。设计工具里的字号、颜色、圆角、投影落到前端代码时往往要重新换算和验证浏览器渲染出的字体间距和设计稿经常有肉眼可见的偏差。以前为了精确还原我可能要反复微调数值一调就是一下午。这个过程不涉及太多创造力但占据了我大量时间于是灵感还没到体力先被榨干了。1.2 AI到底替我解决了什么问题AI进入日常工作后最明显的变化不是“自动画了个好看的界面”而是“把从想法到实现之间的距离压缩了”。过去做一个订单管理页面我得先画线框图再想配色再写组件再调布局。现在我只需要把业务需求、目标用户、模块边界说清楚AI就能直接吐出一个结构完整的页面方案连代码带样式一起给我。节省的时间非常可观。以前一个静态后台页面从零到能跑顺利的话半天遇到布局问题可能要一天。现在用AI生成第一版再花半小时检查和修正通常一小时内就能进入可用状态。这种效率提升不是一点半点而是能把人的精力从“重复劳动”里释放出来重新放到真正的业务逻辑和交互体验上。AI对非设计出身的开发者尤其友好。很多人不是审美不行而是缺少把想法转成视觉语言的经验不知道一个数据密集页面应该用几个颜色、字号怎么分层、卡片间距怎么控制。这些问题AI能给出一个基础合理的方案哪怕不是惊艳也足够让页面变得专业、可用。我经常跟朋友说AI像是一个不会累的设计助理它不会嫌弃你的需求写得乱也不会因为你改了第五版而翻白眼。当然“不想拼UI”不等于“不碰UI”。核心思路变了我不再亲手去拼每一个像素而是把拼装的底层操作交给AI自己盯住方向、风格和目标用户。下面我会拆开讲我现在是怎么把这件事跑起来的。2. 我实际用AI做UI的工作流2.1 先拆需求再问AI很多人觉得用AI生成界面只要把“帮我做个后台页面”扔进去就行。不排除运气好能出一个能看的东西但大概率会得到一个空泛、平庸又不知道往哪儿改的结果。问题不在AI而在“需求没有拆开”。我现在习惯先把页面拆成四块给谁用、做什么任务、包含哪些模块、有什么硬性约束。比如“订单管理后台”这个需求拆成完整描述会是这样我要做一个订单管理后台的列表页目标用户是运营人员。 页面包含顶部统计卡片、筛选区、订单表格、分页器。 设计约束使用公司现有的设计规范桌面端优先信息密度要紧凑颜色不要超过三种。 请输出页面布局描述、组件清单、建议的HTML/CSS结构。这段提示词看起来简单但每个信息都有明确作用。“目标用户”决定了信息密度和操作路径“容器模块”划定了页面边界“硬性约束”限制了视觉方向“输出格式”让AI的回答直接变成可落地的方案而不是长篇大论。这个拆解过程本身就是UI设计核心技能的体现如果连页面要解决什么问题都没想清楚AI再强也帮不了你。给AI描述时我还建议加一点“负面约束”。比如“不要用大面积渐变”“不要加多余的动效”“不要使用深紫色作为主色”。负面约束往往比正面描述更有用因为它能有效避免AI自己发挥出来的“设计腔”也让后续的修改成本大幅降低。2.2 从结构草案到视觉细节第一轮生成的重点不是好看而是“结构对”。我会让AI先给出线框级别的描述相当于把页面的信息架构列出来顶部放什么、筛选条件放哪几个、表格展示哪些列、分页放在什么位置。这步通过之后才进入视觉阶段。视觉阶段我会做二次迭代而不是一次到位。常用的做法是先定调性科技感还是商务感轻量还是厚重明亮还是暗色。然后把调性翻译成具体参数让AI生成设计token也就是颜色、字体、间距、圆角、阴影这一整套规则。举个我自己常用的提示词基于上一轮给出的布局请为这个后台页面定义一套设计token - 主色、辅助色、成功色、警告色、错误色 - 中文字体、数字字体、字号层级 - 基础间距 4/8/12/16/20卡片圆角 8阴影层级 - 需要同时支持浅色模式和暗色模式 - 输出格式CSS变量列表拿到设计token之后再让AI套用到具体组件上。这样做的优势是全局一致性有保障——AI不会为了单个按钮好看而把整页的颜色体系搞乱。之后再处理间距、对齐、状态每一步都基于上一轮结果做增量修改返工的概率会小很多。这个迭代过程有点像做菜先定菜系和食材再定调味和摆盘。如果一开始就要求AI端出一道成品菜它很容易给你一个看似华丽、但根本没办法重复的水平。分步走虽然看着多花了时间实际总时长反而更短因为你不需要反复推翻重来。2.3 把生成稿真正变成前端代码有些AI生成界面只停留在“图片很好看”但如果要接入真实项目我要的是能跑起来的代码。所以我在提示词阶段就会盯死技术栈React、Vue还是原生小程序TypeScript还是JavaScript有没有现成的UI框架如Ant Design或Element Plus。明确技术栈之后AI给出的代码才有了落地的可能。比如我需要一个筛选区域的React组件我会这么写请生成一个React TypeScript的筛选区组件要求 - 包含订单编号输入框、下单时间范围选择器、支付状态下拉框、搜索和重置按钮 - 使用Ant Design组件库 - 组件接收初始筛选条件props支持onChange回调 - 不要把数据和搜索逻辑写在组件内部 - 补充必要的类型定义这样AI生成的代码我拿过来不需要改逻辑只需要接入真实的接口即可。如果项目里没有现成组件库我也可以让AI直接生成纯CSS实现或者指定使用Tailwind工具类。关键是在每次提问时把“运行环境”说清楚否则AI很容易按自己最熟悉的方案来做出一个依赖根本不存在的东西。代码拿到手之后我还会做一次“人工走读”重点看状态覆盖和边界情况。AI擅长生成正常流程的代码但经常漏掉loading、error、empty这些非正常状态。我会在提示词里专门补一句“请覆盖加载中、空数据、请求失败三种状态”把AI的注意力拉到这些容易被忽视的细节上。等这轮补完代码才敢提交到仓库。3. 选对工具少踩一半坑3.1 不同场景下的AI工具选型AI工具的生态已经很丰富但并不是一个工具能吃下UI工作流里的全部环节。我现在会按场景分工让不同的AI各干各最擅长的事再在中间环节由我来串场。下面这张表是我自己日常使用的工具矩阵列在这里供参考使用场景适合的AI工具类型我的使用习惯与注意点页面逻辑与业务代码大型对话式大模型适合做需求拆解、结构设计、生成React/Vue代码上下文要交代清楚视觉风格探索AI图像生成模型做情绪版、风格参考、海报和插画不代表最终界面规范前端页面快速生成头部AI前端生成工具适合从描述直接生成可交互原型完成后再切成真实项目代码UI自动化回归AI辅助测试工具结合Maestro等自动化框架让AI帮忙生成测试路径断言线上问题排查对话式大模型DevTools把报错堆栈和控制台日志贴给AI让它给出分析思路而非直接改代码我在实际选择工具时有个原则能处理文字和逻辑的交给对话模型能生成图片视觉的交给视觉模型能直接出完整交互页面的交给前端生成工具。多AI协作的价值在于每个模型各有所长强行让一个模型干所有事只能得到“什么都懂一点但什么都不精”的结果。还要提醒一句工具更新很快没必要追新。只要手里那套工具能稳定输出、能导出代码、能方便迭代就足够了。我建议你选一个主模型一个图像生成模型一个前端生成工具先跑通完整流程再根据遇到的具体问题逐步补充。工具不在多顺手最重要。3.2 搭建一套自己的提示词库提示词不是玄学它是你个人经验的复利。每次跑通一个成功案例把提示词存下来下次遇到类似页面直接改几个关键词出效果的速度会快很多。我的提示词库分成五类每类都有固定模板第一类是页面结构模板。内容包含“要做什么页面、目标用户是谁、核心任务是什么、希望包含哪些功能模块、输出什么格式”。这类模板用来把模糊需求变成AI可执行的任务描述。第二类是视觉风格模板。内容包含“整体风格关键词、颜色偏好、字体偏好、布局密度、是否支持暗色模式、禁止使用的设计手法”。它会直接决定AI产出的界面观感我常把“简洁、数据密集、企业级、非装饰性”打包成一组固定短语。第三类是组件生成模板。内容包含“使用什么技术栈、基于什么组件库、组件需要接收哪些props、必须覆盖哪些状态、代码风格要求、是否需要类型定义”。这类模板保证代码不是一次性玩具而是能在项目里长期维护的完整单元。第四类是修改反馈模板。内容包含“对上一轮结果的具体问题描述、希望保持不变的约束、只允许调整具体哪些内容”。我在修改时会明确告诉AI“不要重新生成整个页面只修改表格列的排序规则”这样能大大降低返工范围。第五类是测试走查模板。内容包含“输出一份针对当前页面的UI检查清单、列出影响布局响应式和安全性的点、给出测试路径建议”。这类模板会在功能完成后使用用来补上我自己检查时容易遗漏的盲区。这些模板平时放在一个Markdown文件里按项目或页面类型分目录。用的时候复制、替换关键词然后发给AI。时间久了你会发现写作提示词的时间越来越少因为大部分场景已经被模板覆盖剩下要做的只是判断“这一次和上次有什么不同”。4. 实操记录一个后台面板从0到14.1 为什么选它光讲理论容易飘我干脆复盘一个最近做的订单数据看板页面。选它的原因是这类页面在后台系统里出现频率极高包含统计卡片、筛选区、图表、表格、分页多个典型模块能完整展示从0到1的过程。这个页面的目标用户是运营负责人任务是在一分钟内看完今日订单概况然后按条件筛选到具体订单详情。接到这个需求时我并没有直接打开空白的HTML文件去写结构而是先把上面提到的四个问题想清楚给谁用、做什么任务、包含哪些模块、有什么硬性约束。这里是页面被拆解后的结果目标用户运营负责人时间紧张需要快速掌握订单交付进度。 核心任务查看今日订单量、销售额、退款率、待发货数量按时间/支付状态/渠道筛选订单下钻到订单详情。 功能模块顶部KPI卡片区、筛选区、折线图卡片、订单明细表格、分页器。 硬性约束桌面端优先适配1440宽屏信息密度要高使用现有后台设计系统不要动画干扰。4.2 一步步生成并修正第一轮我把拆解结果发给AI要求它先输出页面布局描述和组件清单不追求视觉效果。AI返回的结构是这样的顶部四张统计卡片横向排布筛选区放在卡片下方折线图占卡片区域右侧大格子表格占下方整行分页器在表格底部。这个结构在信息架构上是成立的我没怎么改就直接进入视觉细化。第二轮我给了一组设计约束包括主色用品牌蓝、辅助色用灰色系、状态色沿用现有token、卡片圆角和阴影统一。然后让AI生成完整的HTML/CSS骨架。AI给出的方案里KPI卡片用了flex布局筛选区用inline-flex排列图表区预留了容器表格使用语义化table标签。整体方向对了但存在两个问题筛选区的间距不一致折线图的位置在小屏下会溢出。第三轮我针对这两个问题做增量修改告诉AI“保留整体布局间距请统一采用8的倍数折线图容器在宽度小于1200时换到表格上方”。AI调整后布局问题基本解决。随后我让它补上状态覆盖统计卡片加载中显示骨架屏筛选区重置按钮在未修改条件时置灰表格在无数据时显示空状态。这一轮补完页面才算真正到了可用的原型状态。第四轮是性能意识。订单表格数据量大我让AI给出了虚拟滚动和按需渲染的思路并把表格列固定和横向滚动的要求加进去。AI生成了一版带触发表格行点击事件和固定操作列的实现我再把它接入已有的业务接口前后半天就完成了这个页面的第一版。4.3 哪些环节必须人工介入AI帮我完成了大量基础工作但有几个环节我始终保留人工。第一是品牌语义校验AI有时会用错颜色含义比如把“已退款”标成绿色把“额度不足”标成蓝色这些规则必须由懂业务的人把关。第二是无障碍检查对比度、键盘操作路径、读屏顺序AI不容易理解真实用户的辅助设备使用习惯这部分需要手动走查。第三是最终的视觉走查AI生成的设计可以做到“看起来专业”但真正挑剔的眼睛会在细节上发现问题——标题和数字的对齐、空状态和异常图的协调性、暗色模式下阴影是否过重。我会把页面渲染出来后用截图或全屏预览的方式再过一遍发现问题继续用AI快速修改。所以正确的心态不是“让AI全自动交差”而是“AI写第一稿我负责最后一审”。这也解释了为什么我敢说“不想拼UI”——辛苦的重复拼装已经交给AI了但该花的人工时间一分不少花只是花在了更值得的地方。5. 常见问题与排查技巧实录5.1 AI生成UI的典型翻车现场只要你用AI做界面一定会遇到下面这些情况。最普遍的是“过度设计”AI为了证明自己有审美会在一个数据表格里同时使用渐变背景、彩色边框、悬浮光晕和图标动画结果页面华丽到没法用。我的处理方式是在提示词里加负面约束并且明确“这个页面是给后台用的不是给官网用的”。第二种是“布局脱离现实”。AI生成的布局有时候没有考虑真实数据长度比如用户昵称字段明明可能超过20个字符AI却只给表格留出一列固定宽度。这种问题需要在需求描述里给出例子告诉AI“用户昵称最长20个字符地址最多显示两行超出省略”。真实数据样本越具体AI的布局就越可靠。第三种是“交互状态缺失”。AI默认生成页面最理想的状态所有数据都有、所有按钮都可点、所有请求都成功。可真实系统里一定有加载中、空数据、请求失败、权限不足的情况。我会强迫自己在需求拆解阶段就把状态列表写进提示词并要求AI“不要遗漏错误和空态”。第四种是“代码集成时才发现问题”。有时候AI生成的代码在它自己的演示环境里没问题放进项目里一跑各种报错。原因多是框架版本不同、引入路径不对、组件库API有差异。我的应对方法是把项目里的package.json关键依赖版本一起贴给AI并明确告诉它“不要假设我使用了最新的API”。5.2 排查思路速查表为了少走弯路我把经常遇到问题的处理方式整理成了速查表。遇到对应症状可以直接对照着调整提示词或修改方向现象可能原因建议处理方式页面布局错乱没有给AI足够的结构约束先列模块边界和层级再要求“按上一轮布局生成”颜色/风格不一致没有定义设计token先在提示词里统一色板、间距、圆角再生成具体组件响应式断点失效没有说明目标设备和断点值指定桌面优先或移动优先并给出具体断点如≥1440/≥768组件状态缺失需求描述没覆盖非正常态在提示词中强制列出loading、empty、error、disabled代码运行报错框架版本或依赖不匹配贴出项目依赖版本约束AI使用现有API界面卡顿大量节点渲染/重排让AI给出性能方案比如虚拟滚动、惰性渲染、减少重排视觉方向不对风格描述太空泛给参考关键词或截图同时加负面约束这张表不是一次就能集齐的是我在多次返工后攒出来的。你也可以准备一个类似的速查表每翻一次车就记一行很快AI生成界面的稳定度就能拉起来。5.3 让AI生成结果更稳定的几个习惯第一个习惯是“每次只改一个变量”。不要一边换技术栈、一边改配色、一边要求加新模块AI在一次生成里承担太多变更结果容易失控。我会把改动拆开这一轮只改布局下一轮只改颜色再下一轮才改交互状态。每次变动都能精确定位到原因返工范围也更小。第二个习惯是“建立项目上下文文件”。我会为每个项目维护一个描述文件里面写着项目用的框架、组件库、设计token、目标浏览器、常见数据格式。每次发提示词之前先让AI读取这个文件再让它生成代码。虽然多花一点时间但AI产出的代码几乎不会出现依赖不存在的低级错误。第三个习惯是“把AI结果当作第一稿而不是最终稿”。无论第一版看起来多完整我都要在心里默认其中还有隐藏问题。对于一个页面我会依次检查信息架构对不对、设计token一致不一致、交互状态全不全、响应式有没有溢出、性能有没有隐患。这个检查流程现在已经变成肌肉记忆花不了几分钟但能堵住绝大多数线上问题。第四个习惯是“善用版本管理”。AI生成的不同版本我都单独保存甚至会把失败的方案也留下来。有时候这版“看起来失败”的布局换一种内容密度反而能用了。失败方案也是灵感来源不要因为效果不好就直接删掉。最后再分享一个小技巧做了这么多AI辅助UI的实践我自己最大的收获不是“界面生成得有多快”而是学会了把设计问题翻译成AI能理解的语言。以前我只会说“这个页面不好看”现在我会说“页面间距不够统一卡片内边距和卡片间的间距要成比例关系表格列需要根据内容宽度分配占比空状态需要补充引导文案”。当你能把抽象感觉拆成具体规则AI的每一次输出都会更接近预期。如果你也想从“拼UI”切换到“管UI”我的建议是从一个小页面开始带上一个真实的需求按本文第二部分的流程试一次。跑通之后把提示词存进自己的模板库再慢慢扩大范围。这个过程不需要什么门槛只要你愿意把需求想清楚、把约束说出口AI就真的能把那些重复的拼装工作接过去。一旦习惯了这种节奏你会和我一样越来越不想回到过去那种手拼像素的日子。
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进