1. 从手写每个像素到说句话就出界面的转变前两年我还在为一个后台管理系统的表格组件调 padding左边距 16px 还是 24px纠结了整整一个下午。那会儿觉得这就是 UI 开发的日常——打开设计稿量间距写样式调响应式改 hover 态然后被产品经理一句这个按钮再往左挪两像素打回重做。直到我开始把 AI 真正嵌进 UI 工作流里才发现过去那种一个像素一个像素抠的模式本质上是在用人力做机器更擅长的事。这篇内容想聊的不是AI 会不会取代 UI 工程师这种老生常谈而是一个更实际的问题当 AI 能直接生成界面代码、能理解设计意图、能根据自然语言描述产出可运行的 UI 时我们到底该怎么用它才能既快又不失控。适合正在做前端、做全栈、做独立开发或者单纯想提升界面产出效率的人看。不管你是刚入行的新手还是写了七八年 CSS 的老手下面这些从实际项目里磨出来的经验应该都能直接拿去用。核心关键词就几个AI 生成 UI、提示词工程、组件化思维、人机协作边界。我会从为什么传统拼 UI 的方式效率低讲起然后拆解 AI 生成 UI 的几种典型路径再深入到提示词怎么写、生成结果怎么验收、哪些坑必须提前避开。最后会聊一个很多人忽略的问题AI 生成的 UI 代码怎么保证它不变成技术债。2. 传统 UI 开发到底卡在哪几个环节2.1 重复劳动占比高得离谱做过中后台系统的人都有体会一个项目里 60% 以上的界面是表格、表单、弹窗、卡片这四类东西的排列组合。每个新页面看起来不一样但拆开看无非是字段不同、布局微调、交互逻辑换汤不换药。我统计过自己过去半年的 commit纯手写样式和调整布局的代码占了总提交量的 47%真正涉及业务逻辑的不到三成。这种重复劳动的问题不在于难而在于碎。你写一个搜索表单要处理 label 对齐、输入框宽度、按钮间距、响应式折行、校验态样式、禁用态颜色……每一项都不复杂但加起来就是几个小时。更麻烦的是这些细节在不同页面之间还不完全一致导致你没法简单复制粘贴每次都得重新调。2.2 设计稿到代码的翻译损耗设计师给的是 Figma 稿工程师要把它翻译成 DOM 结构和 CSS。这个翻译过程天然有损耗设计稿里的阴影是0 2px 8px rgba(0,0,0,0.08)你写成box-shadow: 0 2px 8px rgba(0,0,0,0.1)肉眼几乎看不出差别但设计走查时就是会被挑出来。间距也是设计稿标 12px你凭感觉写了 10px整个页面的呼吸感就变了。这种损耗的根源是设计语言和代码语言之间没有直接的映射关系。设计师用视觉工具表达意图工程师用代码结构实现意图中间靠人脑做转换。人脑转换就会出错就会不一致就需要反复沟通。2.3 状态管理的隐性成本一个按钮看起来简单但它可能有 default、hover、active、focus、disabled、loading 六种状态。一个输入框可能有空值、有值、校验中、校验失败、校验成功五种状态。这些状态在视觉上都要有区分在代码里都要有对应的样式类或条件渲染。手写的时候你很容易漏掉某个状态或者某个状态的样式和设计稿对不上。我见过太多项目功能都跑通了但一到走查就冒出一堆状态缺失的问题。这不是工程师不认真而是人脑本来就不擅长穷举所有状态组合。AI 在这方面反而有优势——你只要在提示词里把状态列全它就能一次性生成所有状态的样式。3. AI 介入 UI 生成的四种实际路径3.1 从自然语言直接生成完整页面这是最直观的用法你用一段话描述想要什么界面AI 直接吐出 HTML CSS JS或者 React/Vue 组件代码。比如你说生成一个用户管理页面顶部有搜索栏下面是表格表格列包括姓名、邮箱、角色、状态、操作操作列有编辑和删除按钮整体用浅色主题圆角 8px主色调用蓝色。这种方式的优势是快几分钟就能出一个能跑的页面。但问题也很明显生成结果的质量高度依赖你的描述精度而且不同 AI 工具对浅色主题圆角 8px这类描述的理解差异很大。我试过同一个提示词喂给三个不同的模型出来的东西风格能差出十万八千里。提示自然语言生成适合做原型和 MVP不适合直接上生产。生成结果必须经过人工审查和重构尤其是可访问性、响应式断点和浏览器兼容性这三块AI 经常处理得不够细致。3.2 基于设计稿截图生成代码现在不少工具支持上传设计稿截图AI 识别图中的布局、颜色、文字然后生成对应的代码。这条路比纯文字描述更准因为设计稿本身就是精确的视觉规格。我用这个方式处理过一批 Figma 导出的页面识别准确率大概在 70% 到 85% 之间剩下的 15% 到 30% 需要手动修。识别出错的地方主要集中在复杂嵌套布局比如表格里嵌卡片卡片里再嵌标签、渐变和阴影AI 经常把渐变识别成纯色、图标识别成图片占位符或者干脆漏掉。所以用这条路的时候最好把设计稿拆成相对独立的模块一个模块一个模块地生成而不是整页丢进去。3.3 在现有代码基础上做增量修改这是我觉得最实用的场景。你已经有了一套组件库和页面框架现在要加一个新功能或者改一个现有模块。你把相关代码片段和修改需求一起给 AI让它在你现有代码的风格和结构上做增量修改。比如你说在这个表格组件里加一列最后登录时间格式是 YYYY-MM-DD HH:mm如果超过 30 天没登录就用灰色文字显示。AI 会基于你给的代码上下文生成符合你项目风格的修改。这种方式的好处是生成结果和现有代码风格一致不需要大量重构就能直接用。3.4 用 AI 做 UI 代码的审查和优化这个用法很多人没想到。你可以把一段手写的 UI 代码丢给 AI让它帮你检查有没有冗余样式、有没有可以合并的重复规则、响应式断点是否合理、可访问性属性是否缺失、有没有性能隐患比如频繁触发的重排重绘。我拿这个方式审查过一个老项目的样式文件AI 指出了十几处可以优化的地方包括三个重复定义的媒体查询、两个可以合并的相似类、一个会导致布局抖动的动画属性。这些如果靠人眼扫很容易漏掉。4. 提示词怎么写才能让 AI 产出能用的 UI4.1 把感觉翻译成参数很多人写 UI 提示词喜欢用形容词现代一点简洁一点高级感。这些词对 AI 来说几乎等于没说因为每个人对现代的定义都不一样。有效的做法是把形容词翻译成具体参数。不要说圆角大一点说border-radius: 12px。不要说间距舒服一点说卡片内边距 24px卡片之间间距 16px。不要说颜色柔和一点说主色 #4A90D9背景色 #F5F7FA文字色 #333333。我自己的提示词模板里固定会包含这几类参数布局方式flex/grid方向对齐、尺寸宽高、间距、圆角、颜色主色、辅色、背景、文字、边框、字体字号、字重、行高、状态hover/active/disabled 的具体样式、响应式断点值和各断点下的变化。4.2 给结构不要给描述AI 对结构化的输入理解得更好。与其用一段话描述页面不如用类似这样的结构页面用户列表 布局上下结构 - 顶部搜索栏flex 横向排列gap 12px - 输入框placeholder 搜索用户名或邮箱宽度 240px - 下拉框选项为全部角色/管理员/编辑/访客宽度 120px - 按钮文字搜索主色背景白色文字 - 主体表格 - 列姓名、邮箱、角色、状态、最后登录、操作 - 操作列编辑文字按钮、删除文字按钮红色这种结构化的描述AI 几乎不会理解错。而且你写一次之后下次改需求只需要改其中几行效率极高。4.3 指定技术栈和代码风格同一个界面用 React Tailwind 写和用 Vue SCSS 写产出完全不同。你必须在提示词里明确技术栈否则 AI 会按它自己的偏好来。我一般会指定框架React/Vue/Svelte、样式方案Tailwind/CSS Modules/styled-components/SCSS、组件库如果有的话比如 Ant Design、Element Plus、代码风格函数组件还是类组件、是否用 TypeScript、命名用 camelCase 还是 kebab-case。还有一个容易被忽略的点指定代码的组织方式。比如样式和结构写在同一个文件里还是样式单独抽成文件组件是否拆分、状态用 useState 还是 useReducer。这些如果不指定AI 会按默认习惯来可能和你的项目规范冲突。4.4 用示例引导风格如果你对某个页面的风格有明确参考最好的办法是给 AI 一个示例。可以是现有页面的代码片段也可以是一段你手写的样式。AI 会模仿示例的风格来生成新内容。我经常用的做法是先手写一个样板组件把颜色变量、间距规范、圆角规范、字体规范都定义好然后把这个样板组件作为上下文给 AI让它按这个规范生成其他组件。这样出来的东西风格高度统一几乎不需要再调。5. 生成结果验收哪些地方必须人工过一遍5.1 响应式断点几乎每次都要改AI 生成的响应式代码最常见的问题是断点值不合理。它可能用 768px 作为移动端和桌面端的分界但你的项目规范可能是 640px 和 1024px 两个断点。或者它只处理了一个断点而你的页面需要在三个断点下都有合理布局。我的做法是生成之后先不看样式细节先把浏览器窗口从宽到窄拖一遍看哪里开始崩。崩的地方就是需要手动调断点的地方。通常一个页面需要调三到五处工作量不大但必须做。5.2 可访问性属性经常缺失AI 生成的按钮可能没有aria-label生成的表格可能没有scope属性生成的弹窗可能没有焦点管理。这些在视觉上看不出来但对屏幕阅读器用户来说是致命的。我一般会在验收清单里固定加这几项检查所有交互元素是否可键盘访问、图片是否有 alt、表单元素是否有关联的 label、颜色对比度是否达标、动态内容变化是否有 aria-live 提示。这些检查用 Lighthouse 或者 axe 插件跑一遍就能发现大部分问题。5.3 边界状态容易漏AI 生成 UI 时默认假设数据是正常的。但实际项目里数据可能是空的、可能超长、可能包含特殊字符、可能加载失败。这些边界状态如果不处理上线后就是 bug。我通常会在提示词里明确要求 AI 处理这些状态表格数据为空时显示空状态提示文字超长时用省略号截断并显示 tooltip加载失败时显示重试按钮。如果忘了写验收时就要手动补。5.4 性能隐患需要排查AI 生成的代码有时候会有性能问题比如在渲染函数里创建新对象导致不必要的重渲染、用大量 DOM 操作代替 CSS 动画、没有做列表虚拟化就渲染上千条数据。这些在小数据量下看不出来数据量一大就卡。我的经验是生成之后用 React DevTools 或者 Vue DevTools 看一下渲染次数如果发现某个组件在无关状态变化时也重新渲染就要检查是不是有引用类型的问题。列表超过 100 条的话考虑加虚拟滚动。6. 让 AI 生成的 UI 不变成技术债的三个习惯6.1 生成即重构不要直接提交AI 生成的代码是能跑不是好维护。我见过有人直接把 AI 生成的几百行代码提交上去结果后面改需求时发现根本改不动——样式全是行内写死的组件没有拆分状态逻辑混在一起。我的习惯是生成之后先做一轮重构。把重复的样式抽成变量或类把可复用的部分拆成组件把行内样式移到样式文件里把魔法数字换成有意义的常量。这一轮重构大概花生成时间的 30% 到 50%但后面维护起来省的时间远不止这些。6.2 建立自己的组件库和规范AI 生成的东西风格不统一根本原因是你的项目没有统一的规范。如果你有一套自己的组件库和设计 token颜色变量、间距变量、字体变量AI 生成时就可以引用这些 token出来的东西自然就统一了。我现在每个项目开始前都会先花半天时间定义设计 token 和基础组件按钮、输入框、卡片、表格然后把这些作为上下文给 AI。这样后面生成的页面风格一致性极高几乎不需要再调样式。6.3 把 AI 当快速草稿机不当最终交付者这个心态很重要。AI 的价值在于帮你快速产出草稿把从零到一的时间从几小时压缩到几分钟。但从一到一百——打磨细节、处理边界、优化性能、保证可维护性——这些还是得人来。我现在的流程是AI 生成草稿 → 人工审查和重构 → 手动补边界状态 → 跑可访问性和性能检查 → 提交。整个流程下来一个中等复杂度的页面从原来的四五个小时压缩到一个半小时左右效率提升明显但人的判断始终在关键环节上。7. 几个实际项目里踩过的坑第一个坑是过度依赖 AI 的布局建议。有一次我让 AI 生成一个仪表盘布局它给了一个看起来很合理的 grid 方案但实际跑起来发现在中等屏幕宽度下图表区域会被压缩到几乎看不清。原因是 AI 按平均分配的思路算的列宽没有考虑图表的最小可读尺寸。后来我手动加了min-width才解决。这个教训是AI 懂布局语法但不懂你的业务对尺寸的实际要求。第二个坑是颜色对比度不达标。AI 生成的一套浅色主题主色按钮上的白色文字对比度只有 2.8:1远低于 WCAG 要求的 4.5:1。视觉上看着还行但视力不好的用户根本看不清。后来我养成了习惯生成之后一定用对比度检查工具跑一遍。第三个坑是动画性能。AI 生成的一个卡片 hover 效果用了box-shadow过渡在低端设备上明显掉帧。原因是box-shadow的过渡会触发重绘性能开销大。改成transform和opacity之后就流畅了。这个坑让我意识到AI 对性能优化的理解还停留在语法正确层面实际性能还得靠人判断。第四个坑是组件拆分粒度。AI 倾向于把整个页面写成一个组件几百行代码堆在一起。这在原型阶段没问题但后面要复用时就很痛苦。我现在会在提示词里明确要求按功能拆分成独立组件每个组件不超过 150 行这样生成出来的结构就好很多。8. 我目前的工作流和一点个人体会现在我的 UI 开发流程大概是这样先在脑子里或者纸上画出页面结构然后用结构化提示词让 AI 生成初版代码接着在浏览器里跑一遍看整体效果然后做一轮重构抽组件、提变量、理状态再手动补边界状态和可访问性属性最后跑一遍性能检查。整个过程里AI 承担了大概 60% 的打字工作我承担了 100% 的判断工作。说实话用了这套流程之后我确实再也不想拼 UI 了——不是不想做 UI而是不想再做那些重复的、机械的、没有创造性的拼装工作。AI 把这些活接过去之后我反而有更多时间思考真正重要的问题这个交互对用户来说是否自然、这个信息层级是否清晰、这个状态转换是否流畅。这些是 AI 目前还做不好的也是 UI 工程师真正的价值所在。如果你刚开始尝试用 AI 做 UI我的建议是从小模块开始别一上来就整页生成。先拿一个按钮、一个表单、一个卡片试试摸清楚 AI 在你常用技术栈下的产出质量再逐步扩大范围。另外一定要建立自己的验收清单把响应式、可访问性、边界状态、性能这几项固定检查形成肌肉记忆。这样用久了你会发现 AI 不是替代你而是把你从重复劳动里解放出来让你能专注在真正需要人判断的地方。