你有没有过这种经历需求文档翻来覆去就一句话“做个列表页”你却在 Figma 里拖了三个小时控件对不齐、配色丑、交互屎最后还被产品经理说“感觉差点意思”。我干前端这些年说句实话真正让我头疼的从来不是逻辑代码而是那些一眼看过去不复杂、但极其磨人心智的 UI 拼装工作。直到我把 AI 正式拉进开发流程这个局面才彻底变了个样。这篇文章想聊的不是“AI 能不能帮我把页面搞出来”这种口号而是我实际用了大半年后形成的一套用 AI 从零搭建界面、甚至完整前端项目的可落地流程。包括提示词怎么写、会遇到什么妖魔鬼怪的 bug、怎么排查、哪些环节 AI 是真的能打、哪些环节它还是个坑。如果你也是被 UI 折磨的开发、设计或独立开发者这篇值得你花十分钟看看。1. 整体设计与思路拆解1.1 “拼 UI”到底拼的是什么以及 AI 能替代哪部分在聊 AI 怎么干活之前先得搞清楚“拼 UI”这件事本身是什么结构。我理解下来传统的 UI 拼装工作大概能拆成四层视觉层配色、间距、字号、阴影、圆角这层决定了东西好不好看。结构层页面怎么分区、组件怎么嵌套、布局怎么响应式伸缩这层决定了东西稳不稳。逻辑层点击按钮发生什么、表单校验在哪做、弹窗状态怎么管理这层决定了东西能不能用。脚手架层路由配置、状态管理初始化、文件夹划分、组件按需引入这层是纯重复劳动但写起来最烦。过去的问题是视觉层结构层讲究审美逻辑层讲究思考脚手架层讲究耐心——而一个前端往往只擅长其中一两样。AI 进来之后最大的变化不是哪一层的效果变好了而是脚手架层被完全压缩逻辑层被大幅兜底。你只需要把视觉期望表述清楚AI 能把结构和脚手架一次给你铺完。我自己现在的分工很简单AI 出稿我改稿设计验收。听起来很常规但真正跑起来你会发现效率的差距不在“能不能出”而在“你喂进去的信息够不够”。1.2 为什么我不想再手动拼了说一个很真实的场景。之前接了一个后台管理系统的界面重构里面大概一百来个页面。如果按老办法一个开发得先把公用组件库撸一遍表格、弹窗、表单、分页、菜单、面包屑再写布局骨架层最后才是接业务逻辑。仅仅是“基础界面能跑通”这一步我排了整整两周的开发量。用 AI 介入之后我把组件库设计规范、业务字段命名、路由规则、页面清单一次性作为上下文丢给模型让它按我定的规范批量输出页面代码。第一版出来的东西当然不能直接上线——有各种视觉细节、交互边界的问题但骨架全部是对的组件命名是对的接口字段的对接点是明确留出来的。剩下的工作从“从零写”变成了“改问题”这两周的开发量直接压缩到了四天。后来我总结出来了想让 AI 帮你拼 UI你需要的不是一句“帮我写个登录页”那玩意儿三年前也能写但拼出来的东西是死的。真正值钱的是建立一套**“需求描述 → 规范注入 → 分步生成 → 局部精修”**的协作机制。后面我的核心步骤全部围绕这套机制展开。2. 核心细节解析与实操要点2.1 把“别人看的 UI”翻译成“AI 能懂的输入”我发现大部分人说“AI 写不好界面”问题根本不在 AI而在输入。人的脑子里想的是“做一个清新的、带点质感的个人中心页面”但 AI 收到这句话是要发懵的——什么叫清新什么叫质感它没法判断。这里要引入一个概念给 AI 的提示词本质上是在描述约束而不是描述愿望。我自己的模板是这样的给你直接抄我需要你帮我生成一个页面级别的 UI 代码。以下是约束条件 【页面类型】 个人中心页 【功能区划分】 - 顶部用户信息卡片头像、昵称、等级、编辑入口 - 中部资产概览余额、优惠券、积分三个数据卡片 - 下部菜单列表订单管理、收货地址、联系客服、设置图标文字 【技术栈】 React TypeScript Tailwind CSS函数组件 Hooks 【页面风格】 整体浅色主色蓝色#2563EB圆角偏大12px-16px避免大面积纯白要有轻微层次阴影 【交互要求】 - 点击头像区域跳转 /profile/edit - 资产卡片 hover 时轻微上浮 - 菜单列表支持点击反馈和路由跳转 【响应式】 桌面端三栏布局移动端单栏。你看这里没一个形容词是虚的全部是可落地的客观描述。实测下来给到这种输入AI 输出的第一版完成度能直接到 70 分省下的时间全部拿去改细节而不是重构结构。实操心得不要只给它一个页面的描述而是给它“一份页面描述 三份示例代码文件比如你现在项目里已有的一个页面组件”。AI 会主动去参考示例里的命名风格、导出方式、样式写法生成的代码和你现有项目耦合度会高非常多。这一步能省掉后面 80% 的“样式风格不一致”修改工作。2.2 工具选型的底层逻辑工具这件事很多新人纠结“哪个最好”。我自己的观点是不存在最好的 AI UI 工具只有最适合你工作流的。我把常见工具分成两类——交互生成类和代码生成类它们的适用场景完全不一样。类型代表工具强项短板合适人群交互生成类Figma AI 插件、v0.dev、Lovable能直接看到视觉稿、支持在线微调生成代码偏样板化定制逻辑能力弱设计师、产品经理、独立开发者代码生成类Claude、GPT 系列、Cursor、通义灵码代码精度高、能嵌进项目、符合既有规范需要自己构建提示词工程肉眼看不到实时效果前端开发、全栈工程师我现在的日常主力是代码生成类。C 端页面用 CursorB 端后台用 Claude 大上下文对话写复杂交互的时候再把局部代码甩给支持长上下文的模型去打磨。踩坑提示用 v0.dev 这类交互生成工具务必在生成之前确认你的组件库基础设施。这类工具默认生成的是 Tailwind 风格或自带 CSS如果你项目里用的是 Ant Design 或 Element Plus导入阶段会有一堆样式冲突。我早期犯过这个错后来所有辅助工具产出的代码全部要过一遍“是否是现有组件库实现”的检查风险直接降为零。2.3 AI 写 UI 时必须要留的“人控点”AI 不是万能这件事其实不用多说但在 UI 开发这个领域有几处是 AI 现阶段必定会翻车的必须由你来兜底品牌色和调性的微差AI 对“高级感”“克制感”这类感受性词汇的理解非常有限它输出的是大众审美均值。如果你的品牌调性是那种“有点颓废的冷淡风”AI 大概率给你铺一版“标准小清新”。复杂的业务状态比如权限控制的按钮显隐、角色专属的数据展示这类和业务强耦合的逻辑AI 写出来的边界条件永远是漏的。无障碍与可访问性标签、键盘操作顺序、焦点管理这些内容不写在提示词里它基本不会主动实现。所以我的原则是AI 负责“把 90% 的重复长板打满”我负责“把 10% 的决策点全部锁死”。协作的边界越清晰后面翻车概率越低。3. 实操过程与核心环节实现接下来是我这段时间用得最顺的一套完整流程拿一个“移动端充电桩显示页面”做示例这个项目是我之前朋友公司真实的需求可视化大屏和移动端都要做我主要演移动端这条线。3.1 第一步搭画布先把需求拆成 AI 友好的目录不管做什么页面第一步永远不是写代码而是把需求拆成一份“目录式的结构描述”。这个习惯是从一次惨痛教训里养成的——我直接丢了一整份 PDF 需求文档进去AI 输出的时候自己选了它“觉得重要”的内容结果页面层级和我预期差了十万八千里。现在我的做法是给它一个非常明确的页面结构信息树这个树状描述就是 AI 生成的骨架依据。比如充电桩项目我给的输入长这样请基于以下页面结构生成一个移动端充电桩详情页 页面结构自上而下 - 顶部状态栏充电桩名称、在线状态绿色圆点/灰色圆点 - 充电信息卡片 - 当前输出功率大字展示 - 充电时长、已用电量、当前费用三列数据 - 实时数据模块 - 电压 / 电流 / 温度 三个仪表盘使用 Canvas 环形进度组件 - 充电参数配置区 - 充电模式选项卡快充/标准/充满自动停 - 每个模式对应的说明文案 - 底部操作区开始充电 / 结束充电 按钮固定在最底部 技术栈Vue 3 Vant 4 TypeScript 样式深色背景 高对比数据展示 科技感数字用等宽字体这一步做完AI 出来的代码结构已经相当接近我脑中的预期了。为什么必须用树状描述因为 AI 是概率模型它非常擅长在结构信息的引导下做填充但如果不给它结构只给它概念它大概率会把你的需求“平均化”输出。3.2 第二步让 AI 按你的方式“对齐格式”生成代码之前我会先给 AI 一个“格式约束”它被称为**“代码风格契约”**。这个契约也许很多人忽略但体验差别巨大。重要编程规范 - 所有组件必须使用 script setup langts 语法 - 样式只能用 scoped禁止全局样式 - 不能使用 any 类型接口类型必须定义在 types.ts 文件里 - 请求封装统一调用 /utils/request 中的 request 方法 - 组件库中已存在的 Button、Cell、Dialog 不允许重复造轮子 - 注释使用中文关键逻辑必须写注释把这份契约放在明确的独立位置每次开工前先“喂”一遍。你可以理解为给 AI 立规矩先立规矩再干活和先干活再整改消耗的时间完全不是一个量级。我用这个方法之后AI 产出的代码能在第一次就往现有工程规范上靠。3.3 第三步分步产出而不是一次梭哈很多人怕 AI 生成得少喜欢一次性让它输出一个完整的大页面全部代码。但一次梭哈出来的代码文件之间互相引用错了、组件漏定义了、依赖没引入的情况非常频繁。我现在推崇的方法是——“按模块分批生成”。还是拿充电桩这个页面举例第一轮只要“顶部状态栏 充电信息卡片”这两个区块输出完整代码。第二轮把“实时数据模块”的 Canvas 环形仪表盘单独生成重点让它处理数据更新的动画逻辑。第三轮生成“充电参数配置 底部按钮操作区”。最后一轮把所有模块喂回给 AI让它统一输出页面组合代码并做一次“依赖检查”。这么做的好处有三个出问题时定位快、每个模块都能独立精修、即便某一轮效果不好也无需推倒重来。3.4 第四步人工重构的关键时机AI 生成完代码只完成了“初稿”真正的工程化要从人工重构开始。重点重构顺序如下先跑一遍 TypeScript 语法的严格检查AI 生成的代码经常在小地方类型不准比如 enum 用混了、部分回调函数漏了参数类型。这一步过了后面报错能少 60%。替换数据结构为真实接口字段AI 默认用的数据全是 mock 的需要把字段名、嵌套结构替换成后端定义的实体。凡是后端字段名和 AI 字段不一致的地方全部以真实字段为准优先保证不穿透 mock 层。检查状态管理是否泄漏AI 习惯把 useState / ref 挂在组件内部但当数据需要跨模块共享时要人工把它提升到全局状态里。我那个充电桩页面就有这个问题——充电状态这个数据在顶部状态栏要用、在底部按钮区也要用AI 一开始给我生成了两份独立状态结果这边点了开始充电那边状态根本没变。走一遍交互异常路径比如网络失败提示、按钮防重复提交、空数据占位AI 生成的代码默认把一切考虑得太顺利了这些是需要你人工补的。3.5 第五步把修正意见“喂回去”形成闭环这一步是很多人不知道的高效技巧。大部分人的流程是“让 AI 生成 → 人工改 → 完事”但我的流程是“AI 生成 → 人工改 → 把修改意见作为增量信息喂回 AI → 让它生成第二版拿去做回归对比”。举例来说我改完充电桩页面的元数据字段后会追加一段提示词第一版代码已人工修正。修正点如下 1. 充电状态从组件内 ref 提升为 Pinia store 中的状态命名为 useChargingStore 2. 接口字段从 currentPrice 改为实时结算接口的实际字段 totalCost对应类型已在 types.ts 更新 3. 原代码中缺少对断网状态的处理已统一加入 requestErrorHandler 请基于以上修正点重新生成该页面的完整版本并确保不再出现第一版中存在的三个问题。这一轮出来的代码通常质量会高出另一截因为 AI 在概率生成时会刻意避开已经标注的错误点。后期跑起回归测试来省心太多。4. 常见问题与排查技巧实录4.1 生成的界面“看起来很 AI”这个词现在已经成了我们团队的黑话——“看起来很 AI”意指一套页面没有精神、没有差异、像无数模板拼出来的标准件。这类问题通常和提示词里缺少视觉约束有关。排查思路我说一下第一检查底色和字体。AI 默认给的大多是白底黑字或者浅灰底深灰字这套组合安稳但平庸。如果要差异直接把背景色、卡片色、文字色这种具体 hex 值写死进去比如“页面背景 #0F172A卡片 #1E293B主文字 #E2E8F0”。一套深色调进去AI 尖锐的前沿感立刻上来了。第二检查圆角体系。所有组件圆角一致看起来就会“钝”。主动把大卡片、按钮、输入框、标签的圆角拆开给具体数值例如卡片 16px、按钮 8px、输入框 4px层次立刻分出来。第三检查阴影层级。AI 生成的默认阴影很浅几乎看不清边界。自己在约束里加一句“卡片阴影使用 elevate 两级普通态 subtle、悬浮态强阴影”视觉深度会完全不一样。4.2 AI 生成 UI 适配不了移动端这是另一个高频事故AI 默认输出偏 PC 习惯给它 375px 宽度的移动端适配需求时它经常给你生成“带 hover 效果的按钮”或者布局上用 flex 写了 5 列横向排列——物理上桌子都放不下五个菜。我现在的处理方式是一个土办法请严格按照移动端 375px 基准宽度设计布局参考 iPhone 安全区域所有可点击元素最小宽度至少 44px。这句话几乎固定在我的每一个提示词里。而且生成完之后我会自动追加一次检查“请你过一遍代码找出所有在移动端可能出现视觉溢出或触摸目标过小的区域并自行修正后输出”。实测能规避掉 80% 的移动端布局问题。4.3 表格类页面生成的效率反而不高这里有个反直觉的结论AI 最擅长的不是表格页面而是卡片和展示类页面。因为表格页面的逻辑复杂度极高——列显隐、排序、筛选联动、分页策略、行内编辑、合计栏——AI 面对这么多交错的状态生成质量会直线下滑经常出现“看起来各功能都有连起来全是裂缝”的情况。如果你要做后台管理系统里的复杂表格我的建议是让 AI 只生成“表格的纯静态部分”列定义、基础渲染、空数据占位交互逻辑完全自己来写或引入成熟的表格页面方案。给 AI 提供“交互状态清单”让它按清单实现不要让它自由发挥。行为列表越详细PDF 合同它越能照着填自由发挥只会给你造坑。我自己踩过最狠的一次坑是让 AI 写一个包含“批量操作 跨页勾选 动态列配置”的表格页第一版代码初看没什么问题实际一跑全选、反选、记忆选中这一套全乱了。排查期间光状态同步就花了一天。现在凡是涉及复杂状态同步的表格交互我都是手动起代码骨架AI 只做局部件填充。这个坑写在这里各位引以为戒。4.4 常见问题速查表现象大概率原因处理手段生成代码风格跳跃和项目现有代码不搭没有喂“代码风格契约”补齐示例代码 风格规范约束再重新生成组件引用了不存在的依赖上下文里没有项目依赖清单显式列出可用的依赖包和版本状态不同步按钮和展示区各自独立AI 未识别共享数据人工将状态提升到全局作为修正点回投页面在窄屏下布局崩坏缺移动端响应式约束提示词中固定 375px 基准 最小点击区域交互只覆盖理想路径未提示异常边界人工补齐请求失败、空状态、重复提交等兜底逻辑首次生成太慢或中途卡死上下文过长导致模型超时拆成模块分批生成避免一次性梭哈大页面4.5 一个高效的兜底方案让 AI 自己审自己做完了上面的兜底优先级之后还有一个特别实用的小技巧让 AI 以“资深前端评审专家”的角色重新审视自己生成过的代码。你会得到一个措辞和评价角度完全不同于它“创作视角”的回复。通常它会抓到一些类型定义不严谨、条件判断遗漏、命名不规范的问题。我最近这个充电桩项目里AI 自审发现了一个主题色变量没走到正式入口、而只是被硬编码在组件里的瑕疵——这种问题让我自己一行行查估计得熬到半夜。但也提醒你们自审不是把代码丢回给它说“检查下 bug”那只会得到流水账式的表面建议。你需要给它一个明确的范围比如现在请你以资深前端评审专家的角色重点审查此文件中 - 类型定义是否有 any 或与实际接口不匹配的情况 - 状态更新是否有异步竞态隐患 - 样式类是否有多余或重复定义 - 是否存在影响页面性能的重复渲染 按优先级列出你审查发现的问题并给出具体修改后的代码。配合这个动作整个流程基本就闭环了。最后分享一点个人心得体会。这段时间用下来我越来越觉得AI 改变的不是“会不会做 UI”这件事而是把“做 UI 的能力门槛”大幅下调了。过去一个不会设计的前端做出来的页面丑是硬伤而现在只要你愿意在提示词里多写两行约束、多给两个参考文件AI 就会硬生生把你的下限拉到中等偏上的水平。但同时也要清醒一点它拉低的是下限天花板依然由你的审美、你对业务的理解、你对状态和交互的敏感度来决定。所以我现在的态度是——不再把 UI 当苦力活去拼而是把它当决策活去管。该偷懒的重复工作直接甩给 AI该拍板的细节一个都别松手。如果这篇文章对你有启发我的建议是别再拿“做个登录页”当测试用例了直接打开你现实里最磨人的那个后台页面按上面的流程跑一遍。感受一下从“拖拽三小时”到“写清楚约束十分钟出稿”的落差。跑完你大概就明白我标题里那句“不想再拼 UI 了”是啥意思了。
AI辅助前端UI开发实战：从提示词到完整项目的落地流程
你有没有过这种经历需求文档翻来覆去就一句话“做个列表页”你却在 Figma 里拖了三个小时控件对不齐、配色丑、交互屎最后还被产品经理说“感觉差点意思”。我干前端这些年说句实话真正让我头疼的从来不是逻辑代码而是那些一眼看过去不复杂、但极其磨人心智的 UI 拼装工作。直到我把 AI 正式拉进开发流程这个局面才彻底变了个样。这篇文章想聊的不是“AI 能不能帮我把页面搞出来”这种口号而是我实际用了大半年后形成的一套用 AI 从零搭建界面、甚至完整前端项目的可落地流程。包括提示词怎么写、会遇到什么妖魔鬼怪的 bug、怎么排查、哪些环节 AI 是真的能打、哪些环节它还是个坑。如果你也是被 UI 折磨的开发、设计或独立开发者这篇值得你花十分钟看看。1. 整体设计与思路拆解1.1 “拼 UI”到底拼的是什么以及 AI 能替代哪部分在聊 AI 怎么干活之前先得搞清楚“拼 UI”这件事本身是什么结构。我理解下来传统的 UI 拼装工作大概能拆成四层视觉层配色、间距、字号、阴影、圆角这层决定了东西好不好看。结构层页面怎么分区、组件怎么嵌套、布局怎么响应式伸缩这层决定了东西稳不稳。逻辑层点击按钮发生什么、表单校验在哪做、弹窗状态怎么管理这层决定了东西能不能用。脚手架层路由配置、状态管理初始化、文件夹划分、组件按需引入这层是纯重复劳动但写起来最烦。过去的问题是视觉层结构层讲究审美逻辑层讲究思考脚手架层讲究耐心——而一个前端往往只擅长其中一两样。AI 进来之后最大的变化不是哪一层的效果变好了而是脚手架层被完全压缩逻辑层被大幅兜底。你只需要把视觉期望表述清楚AI 能把结构和脚手架一次给你铺完。我自己现在的分工很简单AI 出稿我改稿设计验收。听起来很常规但真正跑起来你会发现效率的差距不在“能不能出”而在“你喂进去的信息够不够”。1.2 为什么我不想再手动拼了说一个很真实的场景。之前接了一个后台管理系统的界面重构里面大概一百来个页面。如果按老办法一个开发得先把公用组件库撸一遍表格、弹窗、表单、分页、菜单、面包屑再写布局骨架层最后才是接业务逻辑。仅仅是“基础界面能跑通”这一步我排了整整两周的开发量。用 AI 介入之后我把组件库设计规范、业务字段命名、路由规则、页面清单一次性作为上下文丢给模型让它按我定的规范批量输出页面代码。第一版出来的东西当然不能直接上线——有各种视觉细节、交互边界的问题但骨架全部是对的组件命名是对的接口字段的对接点是明确留出来的。剩下的工作从“从零写”变成了“改问题”这两周的开发量直接压缩到了四天。后来我总结出来了想让 AI 帮你拼 UI你需要的不是一句“帮我写个登录页”那玩意儿三年前也能写但拼出来的东西是死的。真正值钱的是建立一套**“需求描述 → 规范注入 → 分步生成 → 局部精修”**的协作机制。后面我的核心步骤全部围绕这套机制展开。2. 核心细节解析与实操要点2.1 把“别人看的 UI”翻译成“AI 能懂的输入”我发现大部分人说“AI 写不好界面”问题根本不在 AI而在输入。人的脑子里想的是“做一个清新的、带点质感的个人中心页面”但 AI 收到这句话是要发懵的——什么叫清新什么叫质感它没法判断。这里要引入一个概念给 AI 的提示词本质上是在描述约束而不是描述愿望。我自己的模板是这样的给你直接抄我需要你帮我生成一个页面级别的 UI 代码。以下是约束条件 【页面类型】 个人中心页 【功能区划分】 - 顶部用户信息卡片头像、昵称、等级、编辑入口 - 中部资产概览余额、优惠券、积分三个数据卡片 - 下部菜单列表订单管理、收货地址、联系客服、设置图标文字 【技术栈】 React TypeScript Tailwind CSS函数组件 Hooks 【页面风格】 整体浅色主色蓝色#2563EB圆角偏大12px-16px避免大面积纯白要有轻微层次阴影 【交互要求】 - 点击头像区域跳转 /profile/edit - 资产卡片 hover 时轻微上浮 - 菜单列表支持点击反馈和路由跳转 【响应式】 桌面端三栏布局移动端单栏。你看这里没一个形容词是虚的全部是可落地的客观描述。实测下来给到这种输入AI 输出的第一版完成度能直接到 70 分省下的时间全部拿去改细节而不是重构结构。实操心得不要只给它一个页面的描述而是给它“一份页面描述 三份示例代码文件比如你现在项目里已有的一个页面组件”。AI 会主动去参考示例里的命名风格、导出方式、样式写法生成的代码和你现有项目耦合度会高非常多。这一步能省掉后面 80% 的“样式风格不一致”修改工作。2.2 工具选型的底层逻辑工具这件事很多新人纠结“哪个最好”。我自己的观点是不存在最好的 AI UI 工具只有最适合你工作流的。我把常见工具分成两类——交互生成类和代码生成类它们的适用场景完全不一样。类型代表工具强项短板合适人群交互生成类Figma AI 插件、v0.dev、Lovable能直接看到视觉稿、支持在线微调生成代码偏样板化定制逻辑能力弱设计师、产品经理、独立开发者代码生成类Claude、GPT 系列、Cursor、通义灵码代码精度高、能嵌进项目、符合既有规范需要自己构建提示词工程肉眼看不到实时效果前端开发、全栈工程师我现在的日常主力是代码生成类。C 端页面用 CursorB 端后台用 Claude 大上下文对话写复杂交互的时候再把局部代码甩给支持长上下文的模型去打磨。踩坑提示用 v0.dev 这类交互生成工具务必在生成之前确认你的组件库基础设施。这类工具默认生成的是 Tailwind 风格或自带 CSS如果你项目里用的是 Ant Design 或 Element Plus导入阶段会有一堆样式冲突。我早期犯过这个错后来所有辅助工具产出的代码全部要过一遍“是否是现有组件库实现”的检查风险直接降为零。2.3 AI 写 UI 时必须要留的“人控点”AI 不是万能这件事其实不用多说但在 UI 开发这个领域有几处是 AI 现阶段必定会翻车的必须由你来兜底品牌色和调性的微差AI 对“高级感”“克制感”这类感受性词汇的理解非常有限它输出的是大众审美均值。如果你的品牌调性是那种“有点颓废的冷淡风”AI 大概率给你铺一版“标准小清新”。复杂的业务状态比如权限控制的按钮显隐、角色专属的数据展示这类和业务强耦合的逻辑AI 写出来的边界条件永远是漏的。无障碍与可访问性标签、键盘操作顺序、焦点管理这些内容不写在提示词里它基本不会主动实现。所以我的原则是AI 负责“把 90% 的重复长板打满”我负责“把 10% 的决策点全部锁死”。协作的边界越清晰后面翻车概率越低。3. 实操过程与核心环节实现接下来是我这段时间用得最顺的一套完整流程拿一个“移动端充电桩显示页面”做示例这个项目是我之前朋友公司真实的需求可视化大屏和移动端都要做我主要演移动端这条线。3.1 第一步搭画布先把需求拆成 AI 友好的目录不管做什么页面第一步永远不是写代码而是把需求拆成一份“目录式的结构描述”。这个习惯是从一次惨痛教训里养成的——我直接丢了一整份 PDF 需求文档进去AI 输出的时候自己选了它“觉得重要”的内容结果页面层级和我预期差了十万八千里。现在我的做法是给它一个非常明确的页面结构信息树这个树状描述就是 AI 生成的骨架依据。比如充电桩项目我给的输入长这样请基于以下页面结构生成一个移动端充电桩详情页 页面结构自上而下 - 顶部状态栏充电桩名称、在线状态绿色圆点/灰色圆点 - 充电信息卡片 - 当前输出功率大字展示 - 充电时长、已用电量、当前费用三列数据 - 实时数据模块 - 电压 / 电流 / 温度 三个仪表盘使用 Canvas 环形进度组件 - 充电参数配置区 - 充电模式选项卡快充/标准/充满自动停 - 每个模式对应的说明文案 - 底部操作区开始充电 / 结束充电 按钮固定在最底部 技术栈Vue 3 Vant 4 TypeScript 样式深色背景 高对比数据展示 科技感数字用等宽字体这一步做完AI 出来的代码结构已经相当接近我脑中的预期了。为什么必须用树状描述因为 AI 是概率模型它非常擅长在结构信息的引导下做填充但如果不给它结构只给它概念它大概率会把你的需求“平均化”输出。3.2 第二步让 AI 按你的方式“对齐格式”生成代码之前我会先给 AI 一个“格式约束”它被称为**“代码风格契约”**。这个契约也许很多人忽略但体验差别巨大。重要编程规范 - 所有组件必须使用 script setup langts 语法 - 样式只能用 scoped禁止全局样式 - 不能使用 any 类型接口类型必须定义在 types.ts 文件里 - 请求封装统一调用 /utils/request 中的 request 方法 - 组件库中已存在的 Button、Cell、Dialog 不允许重复造轮子 - 注释使用中文关键逻辑必须写注释把这份契约放在明确的独立位置每次开工前先“喂”一遍。你可以理解为给 AI 立规矩先立规矩再干活和先干活再整改消耗的时间完全不是一个量级。我用这个方法之后AI 产出的代码能在第一次就往现有工程规范上靠。3.3 第三步分步产出而不是一次梭哈很多人怕 AI 生成得少喜欢一次性让它输出一个完整的大页面全部代码。但一次梭哈出来的代码文件之间互相引用错了、组件漏定义了、依赖没引入的情况非常频繁。我现在推崇的方法是——“按模块分批生成”。还是拿充电桩这个页面举例第一轮只要“顶部状态栏 充电信息卡片”这两个区块输出完整代码。第二轮把“实时数据模块”的 Canvas 环形仪表盘单独生成重点让它处理数据更新的动画逻辑。第三轮生成“充电参数配置 底部按钮操作区”。最后一轮把所有模块喂回给 AI让它统一输出页面组合代码并做一次“依赖检查”。这么做的好处有三个出问题时定位快、每个模块都能独立精修、即便某一轮效果不好也无需推倒重来。3.4 第四步人工重构的关键时机AI 生成完代码只完成了“初稿”真正的工程化要从人工重构开始。重点重构顺序如下先跑一遍 TypeScript 语法的严格检查AI 生成的代码经常在小地方类型不准比如 enum 用混了、部分回调函数漏了参数类型。这一步过了后面报错能少 60%。替换数据结构为真实接口字段AI 默认用的数据全是 mock 的需要把字段名、嵌套结构替换成后端定义的实体。凡是后端字段名和 AI 字段不一致的地方全部以真实字段为准优先保证不穿透 mock 层。检查状态管理是否泄漏AI 习惯把 useState / ref 挂在组件内部但当数据需要跨模块共享时要人工把它提升到全局状态里。我那个充电桩页面就有这个问题——充电状态这个数据在顶部状态栏要用、在底部按钮区也要用AI 一开始给我生成了两份独立状态结果这边点了开始充电那边状态根本没变。走一遍交互异常路径比如网络失败提示、按钮防重复提交、空数据占位AI 生成的代码默认把一切考虑得太顺利了这些是需要你人工补的。3.5 第五步把修正意见“喂回去”形成闭环这一步是很多人不知道的高效技巧。大部分人的流程是“让 AI 生成 → 人工改 → 完事”但我的流程是“AI 生成 → 人工改 → 把修改意见作为增量信息喂回 AI → 让它生成第二版拿去做回归对比”。举例来说我改完充电桩页面的元数据字段后会追加一段提示词第一版代码已人工修正。修正点如下 1. 充电状态从组件内 ref 提升为 Pinia store 中的状态命名为 useChargingStore 2. 接口字段从 currentPrice 改为实时结算接口的实际字段 totalCost对应类型已在 types.ts 更新 3. 原代码中缺少对断网状态的处理已统一加入 requestErrorHandler 请基于以上修正点重新生成该页面的完整版本并确保不再出现第一版中存在的三个问题。这一轮出来的代码通常质量会高出另一截因为 AI 在概率生成时会刻意避开已经标注的错误点。后期跑起回归测试来省心太多。4. 常见问题与排查技巧实录4.1 生成的界面“看起来很 AI”这个词现在已经成了我们团队的黑话——“看起来很 AI”意指一套页面没有精神、没有差异、像无数模板拼出来的标准件。这类问题通常和提示词里缺少视觉约束有关。排查思路我说一下第一检查底色和字体。AI 默认给的大多是白底黑字或者浅灰底深灰字这套组合安稳但平庸。如果要差异直接把背景色、卡片色、文字色这种具体 hex 值写死进去比如“页面背景 #0F172A卡片 #1E293B主文字 #E2E8F0”。一套深色调进去AI 尖锐的前沿感立刻上来了。第二检查圆角体系。所有组件圆角一致看起来就会“钝”。主动把大卡片、按钮、输入框、标签的圆角拆开给具体数值例如卡片 16px、按钮 8px、输入框 4px层次立刻分出来。第三检查阴影层级。AI 生成的默认阴影很浅几乎看不清边界。自己在约束里加一句“卡片阴影使用 elevate 两级普通态 subtle、悬浮态强阴影”视觉深度会完全不一样。4.2 AI 生成 UI 适配不了移动端这是另一个高频事故AI 默认输出偏 PC 习惯给它 375px 宽度的移动端适配需求时它经常给你生成“带 hover 效果的按钮”或者布局上用 flex 写了 5 列横向排列——物理上桌子都放不下五个菜。我现在的处理方式是一个土办法请严格按照移动端 375px 基准宽度设计布局参考 iPhone 安全区域所有可点击元素最小宽度至少 44px。这句话几乎固定在我的每一个提示词里。而且生成完之后我会自动追加一次检查“请你过一遍代码找出所有在移动端可能出现视觉溢出或触摸目标过小的区域并自行修正后输出”。实测能规避掉 80% 的移动端布局问题。4.3 表格类页面生成的效率反而不高这里有个反直觉的结论AI 最擅长的不是表格页面而是卡片和展示类页面。因为表格页面的逻辑复杂度极高——列显隐、排序、筛选联动、分页策略、行内编辑、合计栏——AI 面对这么多交错的状态生成质量会直线下滑经常出现“看起来各功能都有连起来全是裂缝”的情况。如果你要做后台管理系统里的复杂表格我的建议是让 AI 只生成“表格的纯静态部分”列定义、基础渲染、空数据占位交互逻辑完全自己来写或引入成熟的表格页面方案。给 AI 提供“交互状态清单”让它按清单实现不要让它自由发挥。行为列表越详细PDF 合同它越能照着填自由发挥只会给你造坑。我自己踩过最狠的一次坑是让 AI 写一个包含“批量操作 跨页勾选 动态列配置”的表格页第一版代码初看没什么问题实际一跑全选、反选、记忆选中这一套全乱了。排查期间光状态同步就花了一天。现在凡是涉及复杂状态同步的表格交互我都是手动起代码骨架AI 只做局部件填充。这个坑写在这里各位引以为戒。4.4 常见问题速查表现象大概率原因处理手段生成代码风格跳跃和项目现有代码不搭没有喂“代码风格契约”补齐示例代码 风格规范约束再重新生成组件引用了不存在的依赖上下文里没有项目依赖清单显式列出可用的依赖包和版本状态不同步按钮和展示区各自独立AI 未识别共享数据人工将状态提升到全局作为修正点回投页面在窄屏下布局崩坏缺移动端响应式约束提示词中固定 375px 基准 最小点击区域交互只覆盖理想路径未提示异常边界人工补齐请求失败、空状态、重复提交等兜底逻辑首次生成太慢或中途卡死上下文过长导致模型超时拆成模块分批生成避免一次性梭哈大页面4.5 一个高效的兜底方案让 AI 自己审自己做完了上面的兜底优先级之后还有一个特别实用的小技巧让 AI 以“资深前端评审专家”的角色重新审视自己生成过的代码。你会得到一个措辞和评价角度完全不同于它“创作视角”的回复。通常它会抓到一些类型定义不严谨、条件判断遗漏、命名不规范的问题。我最近这个充电桩项目里AI 自审发现了一个主题色变量没走到正式入口、而只是被硬编码在组件里的瑕疵——这种问题让我自己一行行查估计得熬到半夜。但也提醒你们自审不是把代码丢回给它说“检查下 bug”那只会得到流水账式的表面建议。你需要给它一个明确的范围比如现在请你以资深前端评审专家的角色重点审查此文件中 - 类型定义是否有 any 或与实际接口不匹配的情况 - 状态更新是否有异步竞态隐患 - 样式类是否有多余或重复定义 - 是否存在影响页面性能的重复渲染 按优先级列出你审查发现的问题并给出具体修改后的代码。配合这个动作整个流程基本就闭环了。最后分享一点个人心得体会。这段时间用下来我越来越觉得AI 改变的不是“会不会做 UI”这件事而是把“做 UI 的能力门槛”大幅下调了。过去一个不会设计的前端做出来的页面丑是硬伤而现在只要你愿意在提示词里多写两行约束、多给两个参考文件AI 就会硬生生把你的下限拉到中等偏上的水平。但同时也要清醒一点它拉低的是下限天花板依然由你的审美、你对业务的理解、你对状态和交互的敏感度来决定。所以我现在的态度是——不再把 UI 当苦力活去拼而是把它当决策活去管。该偷懒的重复工作直接甩给 AI该拍板的细节一个都别松手。如果这篇文章对你有启发我的建议是别再拿“做个登录页”当测试用例了直接打开你现实里最磨人的那个后台页面按上面的流程跑一遍。感受一下从“拖拽三小时”到“写清楚约束十分钟出稿”的落差。跑完你大概就明白我标题里那句“不想再拼 UI 了”是啥意思了。