AI 辅助前端代码生成先给边界再谈效率一、代码生成不是把需求丢给模型AI 写前端代码很快但快不等于能进项目。很多生成结果看起来像那么回事实际一接入就暴露问题组件边界乱、状态到处传、样式命名随意、可访问性缺失、异常态没有、和现有设计系统不一致。前端不是截图工程生成代码必须服务可维护性。我更愿意把 AI 当作“初稿加速器”而不是“自动提交机器人”。让它生成组件可以但必须先给边界使用哪个组件库、状态从哪里来、样式规范是什么、哪些交互不能省、哪些浏览器要支持。不给边界模型就会用一堆看似聪明的默认值污染项目。二、生成链路约束先于代码flowchart TD A[需求描述] -- B[组件边界] B -- C[设计系统约束] C -- D[AI 生成初稿] D -- E[人工 Review] E -- F[测试与接入]这条链路里最重要的是前两步。需求如果只是“做一个用户列表”模型会自由发挥如果补上数据结构、空态、加载态、分页、权限按钮和设计系统生成结果才有接近生产的可能。三、提示模板把约束写成清单请生成 React 组件 - 使用 TypeScript 和现有 Button/Table 组件 - 不引入新状态管理库 - 支持 loading、empty、error 三种状态 - 所有 props 显式定义类型 - 不写内联样式使用 CSS Module - 输出组件代码和最小单元测试这类模板不花哨但有效。它把模型的自由度限制在项目能接受的范围内。前端代码最怕“差不多”因为差不多的组件会在后期变成到处修补的样式债。四、工程边界生成代码必须进 ReviewAI 生成的代码要按普通代码审查不要因为“是 AI 写的”就降低标准。重点看四类问题状态是否可追踪组件是否过度耦合样式是否泄漏异常态是否完整。能跑只是底线能维护才是目标。取舍方面AI 适合生成重复结构、类型定义、测试样例和样式初稿不适合独立决定架构边界。复杂页面的状态设计、数据流和性能优化仍然需要工程师判断。让 AI 直接设计整页常常会得到一个“漂亮但脏”的组件树。还要建立项目级提示词库。不要每个人都自己写一套 Prompt。把组件规范、命名约定、测试要求沉淀成模板生成质量会稳定很多。AI 代码生成真正的收益不是一次写得快而是团队能持续生成一致风格的代码。接入流程也要设计清楚。AI 生成的代码不要直接写进业务分支可以先进入草稿区或临时分支由开发者挑选、修改、补测试后再提交。这样既保留效率又避免模型一次生成的大段代码绕过团队标准。生成越快Review 越不能省。还要关注依赖污染。模型很喜欢顺手引入新库比如日期、动画、表单、图标。一个小组件引入一个新依赖项目很快就臃肿。提示词里应明确“不新增依赖除非说明理由”Review 时也要检查 package 变化。前端包袱就是这样一点点长出来的。最后把失败样例也沉淀下来。哪些生成结果被拒绝为什么拒绝是状态乱、样式不合规还是测试缺失这些样例反过来能优化提示词。AI 生成不是一次性买工具而是团队持续打磨工程入口。还要防止生成代码绕过无障碍要求。按钮要有可理解文本表单错误要能被读屏感知弹窗焦点要正确回收。AI 很容易生成视觉上像样、可访问性糟糕的组件。前端工程化不能只服务眼睛也要服务真实用户。这条底线不能让。五、总结AI 辅助前端代码生成先给组件边界、设计约束和测试要求再让模型写初稿。生成代码必须进入 Review 和测试流程。效率可以要但不能拿项目洁净度去换。