自从用了AI我是真的再也不想拼UI了。这句话不是标题党而是最近一年我工作的真实状态。做了快十年前端过去接到一个页面流程永远是打开设计稿再一行行写HTML、调CSS、对像素复杂表单和弹窗能改到凌晨。而现在我手里绝大部分页面的第一版都来自AI我只负责把需求拆清楚、把边界想明白、把最后的细节收紧。这篇文章会把我正在用的工作流、工具选型逻辑和踩过的坑一起摊开讲。适合两种人一是被“拼UI”耗干精力的前端开发者二是完全不会写代码、但想快速做出页面的产品、运营和市场同学。看完你至少能少走一半弯路。1. 从“拼UI”到“说UI”这个转变到底颠覆了什么1.1 传统“拼UI”的痛痛在哪一环写前端多年的人都知道真正磨人的从来不是“实现”而是“对齐”和“适配”。设计稿上两栏布局实际渲染出来左边宽了三个像素设计师就盯着你看同一套组件在Chrome下正常切到某个旧版浏览器就整块错位弹窗层级一多z-index改到怀疑人生。这些活儿的特点高度一致重复、琐碎、不产生核心业务价值却又必须有人做。组件库确实解决了不少问题。Ant Design、Element Plus这类框架让“从零手搓按钮和表格”变成了过去式但页面结构还是要自己拼业务状态和控件交互还是要自己理。所谓“拼UI”本质上是把设计师的视觉意图翻译成浏览器能理解的HTML、CSS和JS这一层翻译工作占据了大量工时也消耗了开发者的热情。你可以回想一下有多少个周末是在“调居中”和“调字号”中度过的。尤其是后台管理类的页面数据表格加筛选条件加弹窗表单翻来覆去就是那几样写多了真的会腻。1.2 AI能把手写代码压缩成一句话的关键原理早期我用GitHub Copilot它解决的是“下一行代码可能写什么”。后来Cursor、Fitten Code这类AI编程插件出现把补全升级成了“按注释生成函数、按需求生成组件”。再到现在基于大模型的原生生成式工具比如V0、Claude Artifacts以及一批AI建站产品已经可以直接吃进一句需求吐出一个能点的交互页面。这里面的本质变化是什么补全工具在“帮你打字”生成工具在“帮你做设计”。为什么大模型能生成UI往通俗里说它训练时读过的代码量是天文数字包含大量成熟的前端项目、开源组件库和设计系统所以当你说“做一个订单管理表格能筛选、能翻页”它能推断出大多数人对这个页面的预期布局。加上指令微调和对话能力它能把你的自然语言约束映射成代码结构。所以AI把核心矛盾从“怎么写代码”变成了“怎么把需求描述得足够准确”。这个转变对老前端来说其实是解放实现成本趋近于零你终于可以把精力放到更值钱的“定义需求”和“架构设计”上去。2. 主流AI UI开发工具怎么选我的实测与选型逻辑2.1 先说结论不同工具解决不同问题工具选型不能只看“谁生成得好看”得看使用场景。快速验证一个想法、把现成设计稿转代码、在真实项目里让AI帮你写组件需求完全不同。我自己习惯把工具分成四类纯生成式Web工具V0、Claude Artifacts以及一批AI建站工具。适合从零做原型、Demo和个人站点出活快通常不需要本地环境。编辑器内嵌AICursor、GitHub Copilot还有JetBrains系里的Fitten Code等。适合在正式项目里让AI补写组件、调样式、写业务逻辑和现有代码库共生。设计稿转代码Figma的AI能力、市面上各种design-to-code工具。适合设计团队和开发团队之间有严格设计稿交接的流程。AI生图定视觉Midjourney、即梦、可灵这类生图模型以及ComfyUI这种节点式工作流。适合先定视觉风格和氛围再让开发拆解实现。划完这个分类你会发现没有一款工具能通吃所有环节。别指望一个工具解决全部问题也别在工具之间反复横跳围绕自己的主场景固定一条工作流比追新工具高效得多。2.2 五款工具的实测对比与适用范围工具迭代速度极快我下面这个表是“当下”的实测体会不是永久结论但选型思路可以参考工具类型适合场景上手门槛我印象最深的点V0生成式Web工具快速做MVP页面、产品Demo低组件质量高但导出的项目结构经常和团队规范不一致CursorAI代码编辑器日常项目开发、批量重构中Agent能跨文件改代码规则需要花时间调教FittenAI编程插件已有IDE里补全代码低轻量、免费额度友好VS Code和PyCharm都能装Claude Artifacts对话式生成页面非代码人员快速做演示Demo极低原型阶段好用但工程化能力有限Figma内嵌AI设计稿转代码设计驱动团队中大幅减少翻译成本但依赖设计稿规范程度选型背后有一个原则团队如果本来就靠设计稿驱动千万别为了蹭AI把流程改成“让AI从零生成全站”那会引入大量不可控反过来如果团队没有专职设计生成式工具反而是最优解因为它直接给了你一个还过得去的视觉起点。我见过太多团队在选型上花三周实际写完一个页面只花三天。先把流程固定下来工具细节再慢慢调。3. 5分钟掌握“说UI”的核心技巧从一句话需求到可用页面3.1 需求拆解和提示词设计我用的五要素法拿我最近做的一个真实需求举例做一个“运维监控数据大屏”。如果直接跟AI说“帮我做一个数据大屏”大概率会得到一个好看但没什么用的模板因为模型缺少上下文。我平时用“角色、场景、布局、风格、功能”五要素拆需求角色页面给谁看内部运维人员还是领导汇报这决定信息密度和展示层级。场景核心指标是什么有没有实时刷新、异常告警这类动态需求。布局头部放什么、侧栏放什么、主视觉区放什么大概分几块。风格深色还是浅色、圆角大小、信息密度、品牌色是什么。功能需要筛选、下钻、导出、翻页吗交互有哪些约束下面这条提示词我实际用过效果比较稳定你可以直接抄再按真实需求改请帮我生成一个“运维监控数据大屏”页面使用React Tailwind CSS ECharts。 角色给内部运维团队使用需要一屏展示核心状态。 布局顶部是总览统计栏显示在线主机数/告警数/平均负载中间主区是一张大图表展示24小时CPU使用率趋势底部左右两栏左边是最近告警列表右边是服务状态列表。 风格深色主题主色用蓝绿色圆角小信息密度高中文界面。 功能告警列表和状态列表需要支持滚动顶部统计数字用动态占位数据将来接入接口。 先给我完整可以运行的代码包含一个示例数据文件不省略任何部分。这条提示词有效的关键是给了模型四个硬约束技术栈、布局结构、风格偏好、功能边界。尤其是“不省略任何部分”这句能有效防止AI在长回复里截断代码。如果你不用React技术栈把技术栈换成“用HTML/CSS/JS”就好思路完全一致。3.2 一次只改一个区块的迭代方法论AI生成的第一版永远不可能完美关键是“按区块迭代”。一次只提一个区域的修改要求千万别一次性丢五个目标过去模型容易顾此失彼。比如第一版出来你觉得告警列表太挤就说“告警列表区块改成卡片布局每张卡片显示告警级别、主机名和时间去掉原表格”。等卡片布局稳定了再改下一处。这里有个细节每次修改后务必让AI把完整文件重新输出一遍再整体检查。对话式工具在长上下文里很容易只给差异片段你拿去直接拼接反而会漏东西。迭代到中后期如果发现AI开始“变笨”比如改一个地方导致另一个地方回退不要犹豫直接另开新对话把已经确认的完整版本贴回去告诉它“基于这个版本继续改”。这招能省下大量时间算是我和生成式工具相处最重要的一条经验。3.3 把AI产物接入真实项目四步走完整流程生成完只是第一步接入真实项目才是见真章的地方。我按四步走。第一步把生成出来的组件代码放进独立文件先本地跑通构建确认依赖都能装、启动无报错。第二步替换数据接口把所有写死的占位假数据改成API调用保持组件Props不变这样后续替换数据源很干净。第三步统一样式变量把AI生成时自带的那套颜色、间距、字体对齐团队项目的设计规范。这一步别偷懒否则三个月后整个项目会充斥着好几个版本的色值。第四步补齐边界态空数据、超长文本、弱网加载失败、权限不足这些业务场景AI大概率生成不全需要人工补。不少新手挂在“AI生成的页面能跑”这个假象上验收时却被“空状态没处理”“超长文本把布局撑爆”这类细节打回很亏。这四步跑通之后AI产物才算真正属于你的项目。4. AI生成UI的翻车现场与排查技巧实录4.1 五类典型翻车现象、判断标准和修复办法先说五类我见得最多的翻车我给你整理成一张速查表遇到问题可以直接对照典型问题表现判断标准修复建议布局层级混乱组件叠在一起、Flex没按预期生效元素没有按预想顺序排列检查容器显式宽高和flex-wrap多列布局补约束样式冗余严重一次生成几百行内联样式或重复class样式文件奇大、改一处颜色要全局替换让AI输出“使用Tailwind”或“使用CSS Modules”class命名随机类名跟需求无关拼不回来后续维护时找不到对应样式要求“类名按区块语义命名”或改用原子化类名交互逻辑假象看着能展开、能切换实际没绑定事件点按钮无任何反应逐个检查onClick/change监听是否真实存在版本依赖冲突AI引用不存在的组件或版本不兼容安装依赖报错、页面白屏提示词里指定技术栈版本如React 18、Ant Design 5.x这几个问题里“布局层级混乱”是最常见的。AI生成多列卡片时经常假设“内容会自动平均分布”结果容器没有显式宽度Flex子项就挤成一团。解决办法不是让AI重写而是在提示词里加一句“每个区块容器要有明确的宽度或flex-basis约束避免换行错乱”。很多问题其实在提示词阶段就能预防。4.2 我的排查顺序与几条避坑清单真出问题时我遵循“先看控制台报错、再看布局盒子、最后看数据流”的顺序。控制台报错能定位语法、依赖这类硬伤布局盒子能定位样式问题数据流决定逻辑是否通。除非是明显逻辑问题否则别一上来就大改代码先缩小范围。下面这份避坑清单是实打实踩出来的别让AI直接改线上文件永远先在本地分支跑通。生成代码要建立最小审查习惯至少扫一遍事件绑定和数据来源。网页端生成式工具导出的项目结构通常和团队规范不一致接入时做好适配。页面卡顿优先检查是不是AI生成的列表渲染缺少key或监听了不该监听的事件。不要在提示词里粘贴带密钥的接口地址、数据库连接串隐私问题不能开玩笑。“UI界面卡顿”这个场景特别值得说。AI生成的页面卡顿十次有八次是渲染问题比如在组件里用setInterval做轮询但组件卸载时没有clear比如一次性渲染上千行表格数据比如做了高频动画但没有节流。修复思路很明确把AI写的局部逻辑收敛到生命周期里数据量大的地方做分页或虚拟滚动。AI能帮你写80%的代码剩下20%的性能意识和安全直觉还得靠人。5. 进阶玩法多AI协作和AI Agent自动建站5.1 多AI协作关键是约定接口和边界单工具用得再熟也有瓶颈我现在的工作流是“多AI协作”用大模型对话工具做整体方案和提示词设计用AI编程工具在项目里落地代码用生图工具出视觉素材和UI参照图再用Agent工具跑自动化调整。听起来有点复杂核心其实是一条约定好接口和边界。比如我会让A工具输出“组件级别的React加TypeScript代码且类名语义化”让B工具在这份代码的基础上继续改样式和逻辑这样两个工具不会互相打架。如果你是个人开发者不需要很强的分工但“谁产出什么、以什么格式交接”这件事提前定好效率差异非常明显。这个思路也适用于Unity的UI框架、桌面端的组件库、低代码平台的可视化界面——凡是“拼界面”的活都可以用同一套逻辑交给机器把“定边界”留给人。5.2 AI建站和Agent工作流的实践心得现在这类工具已经支持相当完整的“一句话建站”输入需求自动生成页面、路由、部署配置甚至直接发布到线上访问。对个人项目、内部工具、活动落地页来说效率提升极其可观。我自己做过一个快速原型从输入需求到拿到线上链接前后不到十分钟这在两年前想都不敢想。但我也要泼一盆冷水AI建站适合“用完即弃的页面”和“验证想法的原型”商业级产品还是得回到真实代码库维护。特别提醒一点把AI Agent托管到生产环境前务必做好权限控制和操作审计自动化流程一旦跑偏补救成本比手动做高得多。有人问AI生成UI是不是意味着前端要失业了我的看法恰恰相反当UI生成变成基础设施前端真正值钱的反而是审美、架构、性能和业务理解这些AI短期学不会的东西。我现在的日常里绝大部分页面的第一版都来自AI。我负责的是把需求拆清楚、把结构定对、把交互边界想好然后盯住AI产出的那部分关键代码。自打想通这件事我再也没“拼过UI”反而开始认真研究怎么跟AI把话说明白提示词比写代码难多了因为代码有明确的编译规则而提示词面对的是一个概率模型。如果你想试试别从复杂项目开始拿一个内部小页面跑通全流程你会回来感谢自己省下来的时间。最后分享一个小习惯每生成一个页面我都会让AI顺便写一句“这个页面的设计思路”对后续维护的人来说这行字往往比代码注释更救命。