先说明一个现状过去两年我调研过市面上几乎所有主流 AI 编程工具从 GitHub Copilot 到 Cursor 再到通义灵码国内国外几款头部模型都深度用过。按理说这些工具的能力已经足够强了但真正用 AI 开发出一个高品质的 Web 应用而不是一个 demo——能把性能、代码结构、可维护性、安全都拉满的那种——仍然需要一套完全不同的打法。这篇文章我想聊聊自己在这条路上积累的心得从需求拆解、架构设计、代码编写到测试部署AI 究竟在哪些环节能真正提效哪些环节千万不要交给 AI以及如何用一套稳定的流程让 AI 产出可持续演进的高质量 Web 应用。不管你是前端、后端还是目前正在入门的新手这篇文章没有停留在AI 能写代码这个层面而是展示如何在真实项目中用好 AI。1. AI 在 Web 开发流程里能做什么不能做什么先打破一个误区很多人把 AI 当成自动写码机这是对 AI 能力最大的浪费。我在多个项目里验证下来AI 在 Web 开发中最可靠的三个输出是方案设计、代码骨架生成、重复代码批处理。而最不可靠、需要全程把关的恰恰是最容易让人依赖 AI 的部分——复杂业务逻辑。1.1 AI 真正擅长的是信息综合与骨架搭建当我说方案设计时指的并不是让 AI 凭空决定你的技术栈而是把你已经想清楚的需求喂给它让它输出几种可行方案的对比并给出每个方案的利弊。比如我接一个企业官网项目时会把需要 SEO 支持、CMS 管理后台、多语言、预计日活 5000这些条件先列清楚然后问 AI基于这些限制条件静态生成、服务端渲染、客户端渲染三种方案分别的优劣势是什么这时候 AI 给出的分析往往比搜索引擎翻十几篇文章要逐条方便得多。代码骨架生成是 AI 另一个大杀器。我做过一个比较典型的实验让 AI 生成一个带有 JWT 认证的 Express 后端脚手架包含用户注册、登录、token 刷新、权限中间件结果只用了 4 分钟就拿到了完整可运行的代码。如果手写这套东西至少得大半天。骨架代码的价值不在于拿来即用而在于把重复劳动压缩到极限让你把精力花在真正有业务价值的部分。1.2 AI 不能做的替代工程师判断复杂业务语义有个真实教训某次我在做一个移动端支付相关的 H5 页面把支付成功后的回调处理逻辑交给 AI 去写模型很顺利地生成了几段很漂亮的代码——异常处理、重试机制、日志埋点全都有。但我 review 的时候就发现一个问题AI 对支付回调这种涉及金钱交易的接口采用了一种收到通知先改状态再通知订单服务的顺序。这违背了支付回调最基本的原则必须先校验签名和金额再决定要不要更新状态。类似这种隐含在行业经验里的规则AI 是完全不知道的。它只能从公开代码中学习到长得像支付回调的代码长什么样但学不到为什么这一行校验不能省。所以我给自己定了一条铁律AI 可以产出任何代码但涉及业务决策、安全边界和资金交易的代码工程师必须做全量、逐行的 review。AI 是提效工具不是决策者。2. 项目启动需求拆解和模块规划是 AI 提效的关键前提在 AI 编程里有一个隐藏但极其重要的结论你给 AI 的需求越结构化AI 产出的代码质量越高。这一点在多个模型上反复验证过草率的几句话丢给 AI得到的就是草率的代码而把需求拆解成角色 任务 约束 交付物的格式AI 的产出会惊人地成型。2.1 用上下文提示词把需求结构化我现在的习惯是在建项目之前先花 15 分钟给 AI 一个需求上下文文档内容包含如下几个部分项目定位这个项目给谁用解决什么问题最重要的 3 个功能是什么。技术约束确定了的技术栈、运行环境、浏览器兼容范围、部署平台。模块清单一览每个模块的边界、输入输出、期望的数据模型。交互和视觉要求页面布局偏向是否需要响应式部分组件的行为预期。举个例子之前做一个数据可视化看板时我发给 AI 的模块规划是这样的模块 A数据接入层 - 输入数据库连接参数需要支持 MySQL 与 PostgreSQL - 功能读取销售数据并按日期聚合 - 输出结构为 { date: string; revenue: number; orders: number } 的数组 - 约束只读权限不涉及写操作数据量大时需要分页接口加了这样一段描述后AI 生成的代码从理论上是对的直接转变为直接可以接线的。更重要的是它生成的字段命名、函数边界和后续模块的接口风格高度一致联调成本骤降。2.2 让 AI 帮你做模块依赖分析需求拆解出来之后下一步是明确模块间的依赖关系。这一步也比较适合丢给 AI。我会把自己的模块清单发给 AI让它整理出哪些模块必须先做、哪些可以并行、哪些模块之间的接口是互相影响的。AI 产出的依赖清单可能有小瑕疵但作为一份待 review 的初稿效率远超自己对着白板画半天。依赖分析的价值在于如果你让 AI 先写了依赖底层的基础模块再写上层业务代码那么生成的代码在编译和运行阶段都不会出现地基没打好上面全要返工的问题。反过来如果一上来就写页面AI 会因为接口没定下来生成一堆假设这里有个 API的假代码。3. 实战AI 辅助开发企业级 Web 应用的完整流程下面的内容来自我最近一个比较完整的中型项目实操记录项目是一个带权限管理、内容发布和操作日志审计的企业内部管理系统。技术栈没有追赶时髦用了 Spring Boot Vue 3 MySQL比较典型也比较适合大部分团队参考。3.1 第一步让 AI 生成带数据字典的后端工程启动 Spring Boot 项目的环节传统做法是去 start.spring.io 选依赖或者自己配 pom现在这一步几乎是秒级的。我让 AI 直接按以下约束生成了基础工程Spring Boot 3.xJava 17MySQL MyBatis PlusSpring Security JWT 认证Redis 做缓存和 token 黑名单Maven 多模块结构common、system、business 三个模块AI 给出的目录结构非常标准直接把它跑起来也没有问题。但这个阶段我最重视的并不是骨架本身而是数据字典的设计。我先让 AI 根据我描述的模块用户、角色、菜单、操作日志设计数据库表结构包括字段注释、索引建议和表关系并输出对应的 SQL 脚本。然后我会逐条 review补上缺失的字段——比如操作日志表需要记录请求 IP、用户代理、耗时这些细节 AI 往往第一次不会自动补齐。这个 review 过程用不了太久但意义重大。因为数据模型是整个应用的地基这里的每一个错误到了开发后期都会被放大。3.2 第二步前端骨架和 API 封装同时推进后端骨架落地的同时前端工程也可以并行。我会给 AI 提两组任务一组负责生成 Vue 3 项目骨架包含路由、状态管理、axios 封装和统一的响应拦截器另一组负责根据后端的接口文档定义生成前端 API 调用模块。这两组任务的产出有一个很关键的衔接点前端 API 模块的参数命名必须和后端实体字段保持一致。为了让 AI 做到这一点我会明确告诉它后端的字段风格驼峰命名、日期时间格式、分页参数名并在 API 模块生成后抽查几个关键接口。这里比较值得注意的一个做法是直接让 AI 根据数据库表结构反推 API 文档再基于 API 文档生成前端调用代码——这个链路比两边各自发挥要稳得多。3.3 第三步核心业务功能的人工确认环节到了业务功能阶段我会把节奏放慢。像用户管理这种 CRUD 功能AI 可以非常高效地生成全套接口和页面。但像角色权限分配这种有校验规则、有数据范围限制的功能我会自己先写一版核心逻辑或者手写整个函数的伪代码然后交给 AI 补全边界条件和异常处理。一个实际例子权限校验中有一个超级管理员可以查看所有部门数据普通管理员只能查看本部门数据的需求。这个规则本身不难但 AI 很容易把它实现成硬编码判断比如在 Service 层写死roleId 1 时不过滤。短期的确管用但第二天新增一种角色比如部门主管时这段代码就要推翻重写。我的做法是先自己定义一个数据权限策略接口和若干实现类然后让 AI 在这个框架内补全代码。AI 生成的实现类也许无法完全覆盖所有场景但至少不会跑偏到硬编码方向。这一步人工介入的投入产出比极高。3.4 第四步AI 做代码审查和单元测试代码写完之后以前我会花大量时间做代码审查。现在我会把写好的代码片段发给 AI同时提出几个重点审查维度资源是否正确释放、事务注解是否合理、异常是否被吞掉、存在哪些安全隐患。AI 给出的审查建议不一定全部正确但确实能帮我在极短时间内定位到可疑代码。举例来说有一次 AI 审查发现了我代码里一个明显的 bug在一个批量导入功能中我在事务方法内部调用了另一个类的本地方法导致事务没有生效。这种问题让经验不足的开发者来看可能要翻代码很久但 AI 几秒钟就点出来了。这个功能为代码质量兜住了底。单元测试方面我的经验是不要直接让 AI 从头生成全部测试而是让它为已有的核心方法补测试用例。让 AI 读取 Service 方法的代码给出正常路径、边界值、异常条件下应该返回什么我来审核断言是否合理。这样生成出来的测试覆盖率不错且断言不是空转。4. AI 编程中的安全红线与代码质量防线前面说的都是怎么提效但一个成熟团队用 AI 开发时最需要关注的其实不是效率而是安全。一个不小心AI 生成的代码可能把用户信息泄露出去或者暴露一个不该暴露的管理接口。4.1 常见的 AI 生成代码安全问题从我的观察来看AI 生成的 Web 代码容易踩的坑主要集中在以下几类未做输入校验AI 生成的接口可能直接用 del 一个数据库服务中进行无状态调用——通常可以允许多实例部署提升容量。另一个方向是加入消息队列把耗时的邮件发送、报表生成从接口线程中剥离出去。这两项改造完成后IAST 扫描和压测的结果才算真正能看。5.3 可视化监控 日志联动是压测最后的闭环最后一步是监控可视化。我长期使用 Prometheus Grafana 这套组合让 AI 生成面板 JSON 配置时效果不错不用自己一个个找指标名称。核心关注四个指标接口 P99 延迟、数据库连接池活跃数、JVM 堆内存使用、GC 暂停时间。真正到了流量异常时一套好用的日志检索链路会比监控面板更快定位问题。我用的是 Loki Promtail 采集容器日志配合 Grafana 统一查看有了 AI 辅助生成日志查询语句定位效率提升明显比如想查某个用户 ID 在某段时间内的所有操作以前自己拼 LogQL 可能要试好几遍现在一句话就能拿到查询语句。6. 用 AI 做 Web 应用选型时的几个坑我踩过的关于 AI 选型的坑很有代表性。它出现在一次数据库选型讨论中AI 一本正经地推荐某分布式数据库并称其完全兼容 MySQL 协议、业界广泛用于金融交易系统。但事实上那个数据库在强一致性和复杂事务场景下和 MySQL 有本质区别和广泛用于金融的说法有巨大出入。从那之后我定了一条底线对 AI 给出的任何选型结论必须用权威来源二次验证。你可以让 AI 做信息整理和方案比对的初筛但最终拍板依据必须是官方文档、基准测试、社区经验。6.1 技术选型场景下 AI 的幻觉重灾区AI 在技术选型中最常见的幻觉是数据新鲜度不够。同一个问题你用大模型训练截止之后的新版本去问它往往还在推荐几个月前的旧版本而且可能推荐一个已经 deprecated 的 API。此外很多模型的训练语料以英文为主对中文生态中的优秀开源项目覆盖不足导致推荐的最佳方案可能完全不适合国内部署环境。所以我在处理选型问题时会要求 AI 必须标注信息来源并区分官方文档明确支持和社区经验推荐。这样能有效过滤掉很多编造的信息。还有一种方法是让 AI 提供多个版本方案我会拿这些作为线索去官网核对 API 用法和版本支持周期而不是直接采信。6.2 性能参数的合理范围是工程师常识兜底有些 AI 会给出一组看似精确、实则离谱的性能参数。比如我曾见过 AI 声称某个 Web 框架可以轻松达到单机 10 万 QPS但稍微有经验的人都知道这种数字只有在特定硬件、特定测试场景下才可能接近现实中一个带数据库交互的典型业务接口单机 2000 QPS 已经非常不错。在处理这类性能问题时关键不是让 AI 提供精确数字而是让 AI 列出影响性能的所有变量服务器配置、网络带宽、数据库连接数、数据量级、缓存命中率、JVM 参数。这能有效防止按照不现实的预期设计方案也能帮团队在压测前就建立合理的性能基线。7. Web 开发中的 AI 辅助测试革命从单元测试到自动化 E2E测试这一块AI 带来的改变可能是比写代码更大的。曾经写完功能后写测试是最容易被拖延的工作现在 AI 能帮你把测试的架子搭起来甚至在你写功能代码的同时把测试用例自动生成好并集成到 CI 流水线里。这套玩法落地后项目的质量稳定性提升了一个量级。7.1 用 AI 补全单元测试与边界条件写单元测试最大的痛点是覆盖边界条件和异常分支。AI 生成的测试大多覆盖了 happy path对空值、超大值、并发、超时这些场景覆盖不足。解决方法是给 AI 明确的边界条件。以某个分页查询接口为例我给 AI 的测试生成提示词是这样的针对如下接口给出函数代码请扩展生成以下测试 1. 第 1 页page1返回正常数据 2. page 超出最大值时如何触发异常 3. size 为 0 或负数时如何触发参数校验 4. 查询条件为 null 时是否有默认值 5. 数据总量为 0 时返回空列表这样产出的测试用例覆盖质量和手写差距已经很小而且 AI 生成的 Mock 逻辑非常标准不需要额外调试。7.2 E2E 测试与用户路径模拟在端到端测试方面我用 Playwright 比较多AI 的价值体现在可以快速生成一整条用户路径脚本。比如注册新用户 → 登录 → 创建一条内容 → 修改内容 → 删除内容 → 退出登录AI 生成的脚本能直接跑通而且选择器的命名通常也还算规范。不过 E2E 测试有个现实问题选择器会变。每次改动前端结构测试脚本就容易挂掉。我的经验是要求 AI 生成测试脚本时优先使用稳定的数据属性和文本匹配方式同时把页面主要操作封装成一类稳定的页面对象。这样前端重构后E2E 测试的维护成本才能可控。7.3 AI 生成的测试也需要分级验收AI 生成了测试用例不能直接全部塞进 CI 就跑。我会在接入前做三个检查断言有效性检查断言是否真的在验证业务逻辑而不是只检查调用没报错。隔离性确认测试之间不共享可变数据不会出现顺序依赖。运行时长超时过长的测试不进 CI 的主链路标记成 nightly 即可。这套验收流程看起来增加了一点工作量但实际效果非常可观一旦测试体系跑起来后续 AI 生成的每一次代码变更都可以被自动验证回归成本大幅降低。8. AI 赋能 Web 开发效率的前沿方向如果说前面几节讲的是当下可以用的能力这一节我想聊聊很快会用到的方向。AI 编程技术迭代快我尽量说说那些已经有初步实践验证而不是纯概念的方向。8.1 从代码生成到项目语义理解目前很多 AI 工具停留在根据单个文件或函数生成代码。下一代能力是 AI 能理解整个项目的语义比如知道某个模块在全局的作用、数据库表之间的流转关系、数据在哪些服务节点被加工。拥有项目级语义理解之后AI 进行跨模块重构会安全得多也能在修改某个接口时自动提示以下 N 个调用方需要适配。一些头部语言服务器和代码补全工具已经在做这个方向。实际体验中当 AI 能把报错信息结合项目上下文解释时调试速度已经有了肉眼可见的提升。我也会在项目初始化时多投入一些精力做好类型声明和 API 文档这样项目语义越清晰AI 的跨文件补全质量就越高。8.2 AI Agent 在复杂 Web 应用自动化运维中的应用AI Agent 在 Web 开发和运维中的前景比单纯生成代码要大得多。设想一个场景线上接口突然出现高延迟Agent 可以自动抓取最近的发布记录、监控数据、慢查询日志综合分析后输出一份问题定位报告——而不只是告诉你检测到高延迟。这种能力已经在一些小范围部署里得到验证。我预测在不久的将来Web 开发者会花更少的时间在排查问题上而是把精力投入到让 AI 更准确地理解业务规则上。现在多花一些时间维护项目的文档、注释、接口定义本质上是为未来的 AI 协作铺路。8.3 实时协同编程另一个比较受关注的方向是实时协同编程——AI 不再是写完一段才给反馈的模式而是像结对编程伙伴一样在你敲代码的过程中预测你的下一步意图随时给出建议甚至直接补全。目前 AI 在补全速度上已经接近实时但当建议的准确率提升到足够高时开发者与 AI 的协作方式会发生真正的改变——从问答式切割任务变成流式共创。9. AI 时代的 Web 工程师核心能力与最终建议写到这里你会发现我几乎没有推荐哪个具体的 AI 产品也没有把重点放在提示词技巧上。因为我认为AI 编程真正拉开差距的从来不是工具而是使用工具的人的基本功。9.1 工程师最需要守护的四个能力需求拆解能力把模糊的需求变成结构化的任务是 AI 能发挥效用的前提。系统设计能力数据模型、模块边界、接口定义这些设计产物AI 目前还无法独立完成但可以协助查漏补缺。代码审查能力AI 生成代码后逐行 review 的能力是最后一道防线。工程规范能力命名风格、错误处理、日志规范这些看似琐碎的标准决定了 AI 生成的代码能不能长期维护。9.2 一个可复用的高效工作流最后总结一下我目前最顺手的一套 AI Web 开发工作流用文档写下项目定位、模块清单、技术约束让 AI 产出数据模型和数据字典人工复核字段让 AI 生成前后端工程骨架与 API 封装业务核心逻辑由人工设计并实现关键路径AI 补全边界情况提交代码前让 AI 做代码审查和单元测试补全集成测试和部署配置让 AI 起草人工检查安全与资源参数让 AI 生成性能测试脚本与监控配置按测试结果反馈迭代。这套流程的核心意思是AI 的时间很便宜你的时间很贵。把 AI 当成一个超级实习生——它速度快、知识面广但缺少业务常识和判断力。你给它的输入越清晰它的产出越可靠你对它的产出越审慎项目的质量才越有保障。如果你正准备用 AI 开发下一个 Web 应用我的建议非常简单别急着写代码先把需求和模块边界梳理清楚然后让 AI 帮你搭骨架、补细节最后亲手把控每一处关键逻辑。这条路我一路踩坑走到了今天希望你能走得比我顺利。
AI辅助Web开发实战：从需求拆解到安全审查的高质量工程流程
先说明一个现状过去两年我调研过市面上几乎所有主流 AI 编程工具从 GitHub Copilot 到 Cursor 再到通义灵码国内国外几款头部模型都深度用过。按理说这些工具的能力已经足够强了但真正用 AI 开发出一个高品质的 Web 应用而不是一个 demo——能把性能、代码结构、可维护性、安全都拉满的那种——仍然需要一套完全不同的打法。这篇文章我想聊聊自己在这条路上积累的心得从需求拆解、架构设计、代码编写到测试部署AI 究竟在哪些环节能真正提效哪些环节千万不要交给 AI以及如何用一套稳定的流程让 AI 产出可持续演进的高质量 Web 应用。不管你是前端、后端还是目前正在入门的新手这篇文章没有停留在AI 能写代码这个层面而是展示如何在真实项目中用好 AI。1. AI 在 Web 开发流程里能做什么不能做什么先打破一个误区很多人把 AI 当成自动写码机这是对 AI 能力最大的浪费。我在多个项目里验证下来AI 在 Web 开发中最可靠的三个输出是方案设计、代码骨架生成、重复代码批处理。而最不可靠、需要全程把关的恰恰是最容易让人依赖 AI 的部分——复杂业务逻辑。1.1 AI 真正擅长的是信息综合与骨架搭建当我说方案设计时指的并不是让 AI 凭空决定你的技术栈而是把你已经想清楚的需求喂给它让它输出几种可行方案的对比并给出每个方案的利弊。比如我接一个企业官网项目时会把需要 SEO 支持、CMS 管理后台、多语言、预计日活 5000这些条件先列清楚然后问 AI基于这些限制条件静态生成、服务端渲染、客户端渲染三种方案分别的优劣势是什么这时候 AI 给出的分析往往比搜索引擎翻十几篇文章要逐条方便得多。代码骨架生成是 AI 另一个大杀器。我做过一个比较典型的实验让 AI 生成一个带有 JWT 认证的 Express 后端脚手架包含用户注册、登录、token 刷新、权限中间件结果只用了 4 分钟就拿到了完整可运行的代码。如果手写这套东西至少得大半天。骨架代码的价值不在于拿来即用而在于把重复劳动压缩到极限让你把精力花在真正有业务价值的部分。1.2 AI 不能做的替代工程师判断复杂业务语义有个真实教训某次我在做一个移动端支付相关的 H5 页面把支付成功后的回调处理逻辑交给 AI 去写模型很顺利地生成了几段很漂亮的代码——异常处理、重试机制、日志埋点全都有。但我 review 的时候就发现一个问题AI 对支付回调这种涉及金钱交易的接口采用了一种收到通知先改状态再通知订单服务的顺序。这违背了支付回调最基本的原则必须先校验签名和金额再决定要不要更新状态。类似这种隐含在行业经验里的规则AI 是完全不知道的。它只能从公开代码中学习到长得像支付回调的代码长什么样但学不到为什么这一行校验不能省。所以我给自己定了一条铁律AI 可以产出任何代码但涉及业务决策、安全边界和资金交易的代码工程师必须做全量、逐行的 review。AI 是提效工具不是决策者。2. 项目启动需求拆解和模块规划是 AI 提效的关键前提在 AI 编程里有一个隐藏但极其重要的结论你给 AI 的需求越结构化AI 产出的代码质量越高。这一点在多个模型上反复验证过草率的几句话丢给 AI得到的就是草率的代码而把需求拆解成角色 任务 约束 交付物的格式AI 的产出会惊人地成型。2.1 用上下文提示词把需求结构化我现在的习惯是在建项目之前先花 15 分钟给 AI 一个需求上下文文档内容包含如下几个部分项目定位这个项目给谁用解决什么问题最重要的 3 个功能是什么。技术约束确定了的技术栈、运行环境、浏览器兼容范围、部署平台。模块清单一览每个模块的边界、输入输出、期望的数据模型。交互和视觉要求页面布局偏向是否需要响应式部分组件的行为预期。举个例子之前做一个数据可视化看板时我发给 AI 的模块规划是这样的模块 A数据接入层 - 输入数据库连接参数需要支持 MySQL 与 PostgreSQL - 功能读取销售数据并按日期聚合 - 输出结构为 { date: string; revenue: number; orders: number } 的数组 - 约束只读权限不涉及写操作数据量大时需要分页接口加了这样一段描述后AI 生成的代码从理论上是对的直接转变为直接可以接线的。更重要的是它生成的字段命名、函数边界和后续模块的接口风格高度一致联调成本骤降。2.2 让 AI 帮你做模块依赖分析需求拆解出来之后下一步是明确模块间的依赖关系。这一步也比较适合丢给 AI。我会把自己的模块清单发给 AI让它整理出哪些模块必须先做、哪些可以并行、哪些模块之间的接口是互相影响的。AI 产出的依赖清单可能有小瑕疵但作为一份待 review 的初稿效率远超自己对着白板画半天。依赖分析的价值在于如果你让 AI 先写了依赖底层的基础模块再写上层业务代码那么生成的代码在编译和运行阶段都不会出现地基没打好上面全要返工的问题。反过来如果一上来就写页面AI 会因为接口没定下来生成一堆假设这里有个 API的假代码。3. 实战AI 辅助开发企业级 Web 应用的完整流程下面的内容来自我最近一个比较完整的中型项目实操记录项目是一个带权限管理、内容发布和操作日志审计的企业内部管理系统。技术栈没有追赶时髦用了 Spring Boot Vue 3 MySQL比较典型也比较适合大部分团队参考。3.1 第一步让 AI 生成带数据字典的后端工程启动 Spring Boot 项目的环节传统做法是去 start.spring.io 选依赖或者自己配 pom现在这一步几乎是秒级的。我让 AI 直接按以下约束生成了基础工程Spring Boot 3.xJava 17MySQL MyBatis PlusSpring Security JWT 认证Redis 做缓存和 token 黑名单Maven 多模块结构common、system、business 三个模块AI 给出的目录结构非常标准直接把它跑起来也没有问题。但这个阶段我最重视的并不是骨架本身而是数据字典的设计。我先让 AI 根据我描述的模块用户、角色、菜单、操作日志设计数据库表结构包括字段注释、索引建议和表关系并输出对应的 SQL 脚本。然后我会逐条 review补上缺失的字段——比如操作日志表需要记录请求 IP、用户代理、耗时这些细节 AI 往往第一次不会自动补齐。这个 review 过程用不了太久但意义重大。因为数据模型是整个应用的地基这里的每一个错误到了开发后期都会被放大。3.2 第二步前端骨架和 API 封装同时推进后端骨架落地的同时前端工程也可以并行。我会给 AI 提两组任务一组负责生成 Vue 3 项目骨架包含路由、状态管理、axios 封装和统一的响应拦截器另一组负责根据后端的接口文档定义生成前端 API 调用模块。这两组任务的产出有一个很关键的衔接点前端 API 模块的参数命名必须和后端实体字段保持一致。为了让 AI 做到这一点我会明确告诉它后端的字段风格驼峰命名、日期时间格式、分页参数名并在 API 模块生成后抽查几个关键接口。这里比较值得注意的一个做法是直接让 AI 根据数据库表结构反推 API 文档再基于 API 文档生成前端调用代码——这个链路比两边各自发挥要稳得多。3.3 第三步核心业务功能的人工确认环节到了业务功能阶段我会把节奏放慢。像用户管理这种 CRUD 功能AI 可以非常高效地生成全套接口和页面。但像角色权限分配这种有校验规则、有数据范围限制的功能我会自己先写一版核心逻辑或者手写整个函数的伪代码然后交给 AI 补全边界条件和异常处理。一个实际例子权限校验中有一个超级管理员可以查看所有部门数据普通管理员只能查看本部门数据的需求。这个规则本身不难但 AI 很容易把它实现成硬编码判断比如在 Service 层写死roleId 1 时不过滤。短期的确管用但第二天新增一种角色比如部门主管时这段代码就要推翻重写。我的做法是先自己定义一个数据权限策略接口和若干实现类然后让 AI 在这个框架内补全代码。AI 生成的实现类也许无法完全覆盖所有场景但至少不会跑偏到硬编码方向。这一步人工介入的投入产出比极高。3.4 第四步AI 做代码审查和单元测试代码写完之后以前我会花大量时间做代码审查。现在我会把写好的代码片段发给 AI同时提出几个重点审查维度资源是否正确释放、事务注解是否合理、异常是否被吞掉、存在哪些安全隐患。AI 给出的审查建议不一定全部正确但确实能帮我在极短时间内定位到可疑代码。举例来说有一次 AI 审查发现了我代码里一个明显的 bug在一个批量导入功能中我在事务方法内部调用了另一个类的本地方法导致事务没有生效。这种问题让经验不足的开发者来看可能要翻代码很久但 AI 几秒钟就点出来了。这个功能为代码质量兜住了底。单元测试方面我的经验是不要直接让 AI 从头生成全部测试而是让它为已有的核心方法补测试用例。让 AI 读取 Service 方法的代码给出正常路径、边界值、异常条件下应该返回什么我来审核断言是否合理。这样生成出来的测试覆盖率不错且断言不是空转。4. AI 编程中的安全红线与代码质量防线前面说的都是怎么提效但一个成熟团队用 AI 开发时最需要关注的其实不是效率而是安全。一个不小心AI 生成的代码可能把用户信息泄露出去或者暴露一个不该暴露的管理接口。4.1 常见的 AI 生成代码安全问题从我的观察来看AI 生成的 Web 代码容易踩的坑主要集中在以下几类未做输入校验AI 生成的接口可能直接用 del 一个数据库服务中进行无状态调用——通常可以允许多实例部署提升容量。另一个方向是加入消息队列把耗时的邮件发送、报表生成从接口线程中剥离出去。这两项改造完成后IAST 扫描和压测的结果才算真正能看。5.3 可视化监控 日志联动是压测最后的闭环最后一步是监控可视化。我长期使用 Prometheus Grafana 这套组合让 AI 生成面板 JSON 配置时效果不错不用自己一个个找指标名称。核心关注四个指标接口 P99 延迟、数据库连接池活跃数、JVM 堆内存使用、GC 暂停时间。真正到了流量异常时一套好用的日志检索链路会比监控面板更快定位问题。我用的是 Loki Promtail 采集容器日志配合 Grafana 统一查看有了 AI 辅助生成日志查询语句定位效率提升明显比如想查某个用户 ID 在某段时间内的所有操作以前自己拼 LogQL 可能要试好几遍现在一句话就能拿到查询语句。6. 用 AI 做 Web 应用选型时的几个坑我踩过的关于 AI 选型的坑很有代表性。它出现在一次数据库选型讨论中AI 一本正经地推荐某分布式数据库并称其完全兼容 MySQL 协议、业界广泛用于金融交易系统。但事实上那个数据库在强一致性和复杂事务场景下和 MySQL 有本质区别和广泛用于金融的说法有巨大出入。从那之后我定了一条底线对 AI 给出的任何选型结论必须用权威来源二次验证。你可以让 AI 做信息整理和方案比对的初筛但最终拍板依据必须是官方文档、基准测试、社区经验。6.1 技术选型场景下 AI 的幻觉重灾区AI 在技术选型中最常见的幻觉是数据新鲜度不够。同一个问题你用大模型训练截止之后的新版本去问它往往还在推荐几个月前的旧版本而且可能推荐一个已经 deprecated 的 API。此外很多模型的训练语料以英文为主对中文生态中的优秀开源项目覆盖不足导致推荐的最佳方案可能完全不适合国内部署环境。所以我在处理选型问题时会要求 AI 必须标注信息来源并区分官方文档明确支持和社区经验推荐。这样能有效过滤掉很多编造的信息。还有一种方法是让 AI 提供多个版本方案我会拿这些作为线索去官网核对 API 用法和版本支持周期而不是直接采信。6.2 性能参数的合理范围是工程师常识兜底有些 AI 会给出一组看似精确、实则离谱的性能参数。比如我曾见过 AI 声称某个 Web 框架可以轻松达到单机 10 万 QPS但稍微有经验的人都知道这种数字只有在特定硬件、特定测试场景下才可能接近现实中一个带数据库交互的典型业务接口单机 2000 QPS 已经非常不错。在处理这类性能问题时关键不是让 AI 提供精确数字而是让 AI 列出影响性能的所有变量服务器配置、网络带宽、数据库连接数、数据量级、缓存命中率、JVM 参数。这能有效防止按照不现实的预期设计方案也能帮团队在压测前就建立合理的性能基线。7. Web 开发中的 AI 辅助测试革命从单元测试到自动化 E2E测试这一块AI 带来的改变可能是比写代码更大的。曾经写完功能后写测试是最容易被拖延的工作现在 AI 能帮你把测试的架子搭起来甚至在你写功能代码的同时把测试用例自动生成好并集成到 CI 流水线里。这套玩法落地后项目的质量稳定性提升了一个量级。7.1 用 AI 补全单元测试与边界条件写单元测试最大的痛点是覆盖边界条件和异常分支。AI 生成的测试大多覆盖了 happy path对空值、超大值、并发、超时这些场景覆盖不足。解决方法是给 AI 明确的边界条件。以某个分页查询接口为例我给 AI 的测试生成提示词是这样的针对如下接口给出函数代码请扩展生成以下测试 1. 第 1 页page1返回正常数据 2. page 超出最大值时如何触发异常 3. size 为 0 或负数时如何触发参数校验 4. 查询条件为 null 时是否有默认值 5. 数据总量为 0 时返回空列表这样产出的测试用例覆盖质量和手写差距已经很小而且 AI 生成的 Mock 逻辑非常标准不需要额外调试。7.2 E2E 测试与用户路径模拟在端到端测试方面我用 Playwright 比较多AI 的价值体现在可以快速生成一整条用户路径脚本。比如注册新用户 → 登录 → 创建一条内容 → 修改内容 → 删除内容 → 退出登录AI 生成的脚本能直接跑通而且选择器的命名通常也还算规范。不过 E2E 测试有个现实问题选择器会变。每次改动前端结构测试脚本就容易挂掉。我的经验是要求 AI 生成测试脚本时优先使用稳定的数据属性和文本匹配方式同时把页面主要操作封装成一类稳定的页面对象。这样前端重构后E2E 测试的维护成本才能可控。7.3 AI 生成的测试也需要分级验收AI 生成了测试用例不能直接全部塞进 CI 就跑。我会在接入前做三个检查断言有效性检查断言是否真的在验证业务逻辑而不是只检查调用没报错。隔离性确认测试之间不共享可变数据不会出现顺序依赖。运行时长超时过长的测试不进 CI 的主链路标记成 nightly 即可。这套验收流程看起来增加了一点工作量但实际效果非常可观一旦测试体系跑起来后续 AI 生成的每一次代码变更都可以被自动验证回归成本大幅降低。8. AI 赋能 Web 开发效率的前沿方向如果说前面几节讲的是当下可以用的能力这一节我想聊聊很快会用到的方向。AI 编程技术迭代快我尽量说说那些已经有初步实践验证而不是纯概念的方向。8.1 从代码生成到项目语义理解目前很多 AI 工具停留在根据单个文件或函数生成代码。下一代能力是 AI 能理解整个项目的语义比如知道某个模块在全局的作用、数据库表之间的流转关系、数据在哪些服务节点被加工。拥有项目级语义理解之后AI 进行跨模块重构会安全得多也能在修改某个接口时自动提示以下 N 个调用方需要适配。一些头部语言服务器和代码补全工具已经在做这个方向。实际体验中当 AI 能把报错信息结合项目上下文解释时调试速度已经有了肉眼可见的提升。我也会在项目初始化时多投入一些精力做好类型声明和 API 文档这样项目语义越清晰AI 的跨文件补全质量就越高。8.2 AI Agent 在复杂 Web 应用自动化运维中的应用AI Agent 在 Web 开发和运维中的前景比单纯生成代码要大得多。设想一个场景线上接口突然出现高延迟Agent 可以自动抓取最近的发布记录、监控数据、慢查询日志综合分析后输出一份问题定位报告——而不只是告诉你检测到高延迟。这种能力已经在一些小范围部署里得到验证。我预测在不久的将来Web 开发者会花更少的时间在排查问题上而是把精力投入到让 AI 更准确地理解业务规则上。现在多花一些时间维护项目的文档、注释、接口定义本质上是为未来的 AI 协作铺路。8.3 实时协同编程另一个比较受关注的方向是实时协同编程——AI 不再是写完一段才给反馈的模式而是像结对编程伙伴一样在你敲代码的过程中预测你的下一步意图随时给出建议甚至直接补全。目前 AI 在补全速度上已经接近实时但当建议的准确率提升到足够高时开发者与 AI 的协作方式会发生真正的改变——从问答式切割任务变成流式共创。9. AI 时代的 Web 工程师核心能力与最终建议写到这里你会发现我几乎没有推荐哪个具体的 AI 产品也没有把重点放在提示词技巧上。因为我认为AI 编程真正拉开差距的从来不是工具而是使用工具的人的基本功。9.1 工程师最需要守护的四个能力需求拆解能力把模糊的需求变成结构化的任务是 AI 能发挥效用的前提。系统设计能力数据模型、模块边界、接口定义这些设计产物AI 目前还无法独立完成但可以协助查漏补缺。代码审查能力AI 生成代码后逐行 review 的能力是最后一道防线。工程规范能力命名风格、错误处理、日志规范这些看似琐碎的标准决定了 AI 生成的代码能不能长期维护。9.2 一个可复用的高效工作流最后总结一下我目前最顺手的一套 AI Web 开发工作流用文档写下项目定位、模块清单、技术约束让 AI 产出数据模型和数据字典人工复核字段让 AI 生成前后端工程骨架与 API 封装业务核心逻辑由人工设计并实现关键路径AI 补全边界情况提交代码前让 AI 做代码审查和单元测试补全集成测试和部署配置让 AI 起草人工检查安全与资源参数让 AI 生成性能测试脚本与监控配置按测试结果反馈迭代。这套流程的核心意思是AI 的时间很便宜你的时间很贵。把 AI 当成一个超级实习生——它速度快、知识面广但缺少业务常识和判断力。你给它的输入越清晰它的产出越可靠你对它的产出越审慎项目的质量才越有保障。如果你正准备用 AI 开发下一个 Web 应用我的建议非常简单别急着写代码先把需求和模块边界梳理清楚然后让 AI 帮你搭骨架、补细节最后亲手把控每一处关键逻辑。这条路我一路踩坑走到了今天希望你能走得比我顺利。
