1. 从想法到落地：AI 辅助 Web 应用开发的整体思路
这两年 AI 编程工具的发展速度，说实话超出了很多人的预期。我用 AI 辅助开发 Web 应用已经有相当长一段时间了，从最初的“用 AI 写个函数”到现在的“让 AI 帮我搭一整个项目”，整个工作流已经发生了根本性的变化。如果你现在还在犹豫要不要把 AI 纳入你的开发流程，或者试过一些工具但觉得“也就那样”，这篇文章应该能给你一些真正可落地的经验和思路。
先说结论：用 AI 打造高品质 Web 应用，核心不在于“让 AI 自动写代码”，而在于“人机协作的工程化流程”。AI 不是替代你写代码的机器，而是一个能力很强但需要管理的协作者。你负责架构设计、需求拆解、质量把控，AI 负责快速产出代码、处理重复劳动、提供多方案对比。这个定位想清楚了，后面的所有环节都会顺畅很多。
从技术栈选型来看，我个人的经验是：前端用 React 或 Vue 都不重要，重要的是让 AI 能理解你的项目上下文。当前主流 AI 编程助手（包括 Claude、ChatGPT、通义灵码等）对主流框架的支持都非常好，但如果你用的是冷门框架或自定义工具链，AI 的产出质量会明显下降。所以一个务实的建议是：如果你准备在项目中重度使用 AI 辅助，尽量选择 AI 语料覆盖最丰富的主流技术栈。
举个实际例子，我最近做一个中型管理后台项目，技术栈是 React + TypeScript + Ant Design + Spring Boot。这套组合几乎是 AI 训练语料中最丰富的技术组合之一，AI 能准确生成从页面组件到后端接口的完整代码，而且风格非常统一。对比之下，之前用过一个内部自研的 UI 框架，AI 生成出来的代码经常需要我手动调整大部分细节，效率反而下降了。
再来说项目规模的控制。AI 辅助开发非常适合做“中等复杂度”的项目——不大不小，刚好够让 AI 发挥它的效率优势。一个访谈系统、一套后台管理系统、一个数据看板，这些都是 AI 能胜任并且能大幅提升效率的项目类型。但如果你的项目涉及复杂的并发处理、海量数据迁移或者高性能计算，AI 目前的能力边界还是比较明显的，它更适合帮你处理业务层的快速实现，而不是让你完全撒手不管。
还有一个很多人容易踩的坑：不要让 AI 直接生成整个项目。无论是 Cursor 还是其他 AI 编程工具，直接从零生成大型项目往往会得到一堆结构混乱、依赖冗余、风格不统一的代码。正确的做法是：你自己先把项目骨架搭好（入口文件、路由、状态管理、目录结构），然后让 AI 在这个骨架内逐模块填充。这样既能发挥 AI 的效率优势，又能保证项目的整体质量与可控性。
我在实际项目中的工作流大概是这样的：
- 需求分析与技术选型：这个环节完全靠人做，AI 在这里只辅助做资料收集。
- 搭好项目基础结构：手工创建项目、配置路由、确定目录规范。
- 逐页面逐功能模块让 AI 生成：提供清晰的需求描述，让 AI 产出初版代码。
- 代码审查与重构：仔细检测 AI 产出的代码，发现问题马上修复。
- 联调与测试：结合测试用例，发现并修整问题。
这个流程看起来不算革命性，但每一步的执行细节里都有一些 AI 时代的特殊讲究。接下来我会逐环节拆开讲。
2. 核心细节解析：AI 写代码的几个关键秘诀
既然说到了“人机协作”，那协作过程本身肯定有一套方法论。我用这么长时间 AI 辅助开发，最大的体会是：给 AI 的需求描述决定了你代码质量的天花板。换句话说，AI 写得好不好，很大程度取决于你描述得清不清楚。
2.1 需求描述：让 AI 真正听懂你想做什么
很多人用 AI 写代码，上来就是一句“写一个登录页面”。这种描述方式不是不行，但产出的代码大概率比较“泛”。比如你实际项目用的是 React + Ant Design，AI 默认写出来的可能是 Element UI 或者原生 HTML；你需要表单校验，AI 可能只写了基础的输入框。最后你还是要自己动手改一堆东西，体验自然就差了。
我自己的习惯是“结构化提示词”。给它包含以下几个要素：
- 使用的框架与版本（例如 Vue 3 + TypeScript + Pinia）
- UI 组件库（例如 Ant Design Vue 4.x）
- 页面功能与交互细节（需要哪些字段、哪些校验规则、提交逻辑是什么）
- 接口约定（请求方式、路径、入参出参结构）
举个例子，我之前需要 AI 写一个用户管理页面，我的提示词大概是这样的：
用 Vue 3 + TypeScript + Ant Design Vue 4.x 实现一个用户管理页面，包含用户列表、搜索（按用户名和手机号模糊搜索）、新增用户弹窗、编辑用户弹窗、启用/禁用用户切换功能。列表接口 GET /api/users，入参为 page、pageSize、keyword、status，出参为 { records: User[], total: number }。新增和编辑用同一个弹窗组件，提交时进行表单校验（用户名必填、手机号格式校验）。用户状态切换使用 Switch 组件，切换时调用 PUT /api/users/{id}/status。
这样的描述看起来有点长，但换来的是 AI 一次就能生成八九成可用的代码。对比一下，直接说“写个用户管理页面”，AI 可能给你一个连接口地址都没有的半成品。花在提示词上的时间，一定会在修改代码上省回来。
2.2 代码生成：让 AI 学会写代码的原则
除了需求描述，还有一个细节至关重要：给 AI 设定代码风格与规范。AI 的训练语料里充满了各种风格的代码，习惯不同，不约束的话写出来的东西风格可能很飘。比如直接变量命名有时用下划线有时用驼峰；函数定义有时用 function 有时用箭头函数；字符串有时用单引号有时用双引号。这些在单独看一段代码时问题不大，但整个项目累积起来就是灾难。
解决这个问题有两个办法：
一是在对话开始之前，先把项目规范告诉 AI。例如“本项目使用 TypeScript，严格模式，React 函数组件 + Hooks，禁止使用 class 组件，变量命名统一 camelCase，组件文件名用 PascalCase，CSS 统一使用 Tailwind”。把这句话放在每次会话的最前面，AI 生成的代码就会明显更符合项目规范。
二是在生成代码之后，进行一轮“规范审查”。你可以直接问 AI：“请检查一下你刚才生成的代码，看看有没有不符合我们约定规范的地方，并直接修正。”大部分情况下 AI 能够自我修正一部分问题，虽然不能全部解决，但至少能减少不少低级错误。
还有一个技巧值得分享：让 AI 按模块生成，而不是一次性生成整个页面。比如你要做一个表单页面，可以先让 AI 生成表单组件本身，确认没问题后再生成数据请求方法和状态管理逻辑。这样做的好处是每个模块的信息密度更高、错误更少，而且你可以在早期发现方向不对的地方，随时纠正，避免返工。
2.3 代码审查与调试：永远保留人的判断
很多人担心 AI 写了代码后没人审查，容易把 bug 埋进生产环境。这个问题真实存在。我见过有人直接用 AI 生成的代码上线，结果遇到了比较隐蔽的状态更新问题——页面数据改了但视图不更新，排查了很久才发现是因为 AI 在更新数组时使用了 push 方法而不是不可变更新。这类问题用静态检查可能很难发现，必须在实际运行中才能暴露。
所以无论 AI 写得多像模像样，代码审查这个环节绝对不能省。我自己有用一套“三层审查法”，介绍一下供参考：
- 第一层：AI 自审。让 AI 自己检查代码中的逻辑漏洞和潜在问题。
- 第二层：人工审查。自己逐段读代码，重点关注状态变化、异步调用边界、依赖引用是否合理。
- 第三层：运行审查。跑通业务流程，观察控制台报错、网络请求参数和响应结构是否与预期一致。
这三层下来，大部分问题都能在开发阶段被拦截掉。点击发布按钮，心里才有底。
2.4 测试驱动：用 AI 提高代码价值的效率
AI 辅助开发的另一个高效应用场景是编写测试用例。说实话，很多开发团队写测试的意愿度不高，我身边不少朋友的项目测试覆盖率处于“几乎为零”的状态。但现在不一样了，AI 可以把生成单元测试和集成测试的时间从“半天”压缩到“几分钟”。
让 AI 写测试的时候，我会给它看被测代码，然后说“请为这个函数生成完整的测试用例，覆盖正常输入、边界输入和异常输入，并给出使用的测试框架”。AI 生成的测试用例虽然不能完全代替人工设计的边界条件，但它能覆盖大多数典型场景，尤其是那些你平时容易遗漏的头疼分支。
当然，测试用例的质量依然取决于被测代码本身的可测试性。如果函数的依赖过多、状态管理混乱，AI 写出好的测试也很难。但从这个角度看，AI 倒逼我写出更简洁、更模块化的代码，也算是额外的收益。
3. 实操过程：从需求到上线的完整 AI 协作流程
前面聊了不少方法论和技巧，现在用一个真实项目来完整展示一遍整个过程。我选一个比较典型的中小型 Web 项目——“员工访谈登记与管理后台”。
3.1 需求澄清与技术选型
项目需求大概是这样：企业内部的 HR 需要在后台创建访谈计划，给员工发送访谈邀请，员工通过链接填写访谈表，HR 在后台查看统计结果。前端需要两个部分：员工端的填写页面（简单、移动端友好），后台管理端（需要列表、筛选、导出、统计）。后端需要一个简单的管理接口服务，支撑这两个前端的操作。
技术选型是：前端用 Vue 3 + TypeScript + Vite，UI 用 Element Plus；后端用 Spring Boot + MyBatis-Plus + MySQL；部署用 Nginx 反向代理 + Docker Compose。这个组合的好处是：AI 训练语料覆盖很广，几乎每个技术点都有大量示例可以参考，而且整个技术栈在国内的社区活跃度相当高，遇到问题能很快找到答案。
架构上简单分为三层：Nginx 做静态资源代理和反向代理，避免跨域问题；后端提供纯 REST API，没有复杂的微服务架构，因为项目体量不需要。前端通过同一域名下的 /api 路径访问后端接口，Nginx 将其转发到后端的 8080 端口，这样做可以规避开发时的跨域配置，线上也不容易被区块污染端口之类的策略影响。
3.2 搭骨架：手写项目基础结构
这个步骤我是完全手工完成的。项目初始化、依赖安装、目录结构、路由配置，全部自己手写。这样做的原因有两个：一是保证项目结构符合自己的习惯；二是 AI 生成的项目骨架通常会有多余依赖和不用初始化代码，清理成本反而更大。
搭骨架的关键是做好目录规划。我习惯用按业务模块划分的目录结构，而不是按文件类型划分：
src/ api/ // 接口层 assets/ // 静态资源 components/ // 公共组件 router/ // 路由 stores/ // 状态管理 views/ admin/ // 后台管理端视图 employee/ // 员工端视图 utils/ // 工具函数这个结构的好处是：AI 在生成某个页面时，能比较容易地推测出相关文件应该放在哪里，生成代码的“项目感”更强，比紧凑结构更不容易出现“乱放文件”的情况。
3.3 迭代式开发：让 AI 逐模块生成
骨架搭好之后，就进入了 AI 辅助的核心阶段。我按照“后端接口 -> 员工端填写页 -> 后台管理端 -> 联调测试”的顺序来逐个实现。
后端接口这块，我一开始先让 AI 根据字段生成员工访谈表的实体类、数据库建表语句和基本的 CRUD 接口。提示词大概描述“员工访谈需要记录姓名、手机号、部门、职级、访谈日期、访谈状态、备注等字段，请生成 MySQL 建表语句、对应 Java 实体类、Mapper 接口以及前端的 TypeScript 类型定义”。AI 给出的建表语句稍微调整了一下字段长度和索引设置，实体类和 Mapper 基本可以直接用。
这里有一个小提示：如果你用 MyBatis-Plus，一定要在提示词里明确“继承 BaseMapper”“使用 LambdaQueryWrapper”“分页用 Page 对象”，否则 AI 默认可能生成传统 MyBatis 的 XML 映射方式，风格就会跟你项目不一致。
员工端填写页是整个项目中最强调“高品质”的部分。流程是：HR 将链接发给员工，员工打开页面看到访谈计划的基本信息，填写几个表单字段，提交后看到成功页。这个页面的核心要求是简洁、清晰、在手机上也好用。
我的提示词是：
用 Vue 3 + TypeScript + Element Plus 写一个移动端友好的访谈填写表单页。页面顶部展示访谈主题和访谈人信息，中间是表单项：姓名、手机号、所在部门、职位、访谈内容（textarea）、对公司的建议（textarea），底部是一个“提交访谈表”按钮。手机号需要校验，访谈内容必填且最少 20 字。提交时调用 POST /api/interviews，提交成功后显示成功提示并按钮置灰且不可重复提交。页面要适配手机浏览器，页面宽度限制为 480px，居中对齐，有整体圆角卡片风格。
这段提示词基本上定义清楚了页面样式、交互细节、接口路径和校验逻辑。AI 生成出来的页面我除了微调一下间距和颜色，基本没做大的改动。而且关键一点是它生成的代码直接用了
