AI 辅助前端代码生成：先给边界，再谈效率
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 - 输出组件代码和最小单元测试这类模板不花哨，但有效。它把模型的自由度限制在项目能接受的范围内。前端代码最怕“差不多”，因为差不多的组件会在后期变成到处修补的样式债。
四、工程边界：生成代码必须进 Review
AI 生成的代码要按普通代码审查，不要因为“是 AI 写的”就降低标准。重点看四类问题：状态是否可追踪，组件是否过度耦合，样式是否泄漏，异常态是否完整。能跑只是底线，能维护才是目标。
取舍方面，AI 适合生成重复结构、类型定义、测试样例和样式初稿；不适合独立决定架构边界。复杂页面的状态设计、数据流和性能优化，仍然需要工程师判断。让 AI 直接设计整页，常常会得到一个“漂亮但脏”的组件树。
还要建立项目级提示词库。不要每个人都自己写一套 Prompt。把组件规范、命名约定、测试要求沉淀成模板，生成质量会稳定很多。AI 代码生成真正的收益，不是一次写得快，而是团队能持续生成一致风格的代码。
接入流程也要设计清楚。AI 生成的代码不要直接写进业务分支，可以先进入草稿区或临时分支，由开发者挑选、修改、补测试后再提交。这样既保留效率，又避免模型一次生成的大段代码绕过团队标准。生成越快，Review 越不能省。
还要关注依赖污染。模型很喜欢顺手引入新库，比如日期、动画、表单、图标。一个小组件引入一个新依赖，项目很快就臃肿。提示词里应明确“不新增依赖，除非说明理由”，Review 时也要检查 package 变化。前端包袱就是这样一点点长出来的。
最后，把失败样例也沉淀下来。哪些生成结果被拒绝，为什么拒绝，是状态乱、样式不合规，还是测试缺失？这些样例反过来能优化提示词。AI 生成不是一次性买工具，而是团队持续打磨工程入口。
还要防止生成代码绕过无障碍要求。按钮要有可理解文本，表单错误要能被读屏感知，弹窗焦点要正确回收。AI 很容易生成视觉上像样、可访问性糟糕的组件。前端工程化不能只服务眼睛，也要服务真实用户。
这条底线不能让。
五、总结
AI 辅助前端代码生成，先给组件边界、设计约束和测试要求，再让模型写初稿。生成代码必须进入 Review 和测试流程。效率可以要，但不能拿项目洁净度去换。