这两年Web 开发圈最不缺的就是关于 AI 的讨论。我用 AI 写过几个页面也用 AI 调试过半夜的报错可真正让我对“AI 写 Web 应用”这件事改观的是最近完整走完的一套企业级 Web 项目从立项、技术选型到前后端实现、测试、部署上线AI 几乎参与了每一个环节。这篇文章想把整套打法整理出来讲清楚 AI 在 Web 开发里的真实位置、好用的工具链以及那些容易翻车的细节。不管你是在做 AI Web 应用开发还是传统企业级 Web 开发只要你已经在用、或者准备用 AI 辅助写代码这篇应该能帮你少踩几个坑。我下面不会只吹 AI 有多强也会把 AI 写得不够好、需要人来兜底的地方摊开讲毕竟“高品质”三个字从来不是靠一句提示词就能换来的。1. 先想清楚AI 在 Web 项目里到底解决什么问题1.1 为什么说 AI 是“高级外包”不是“全能工”我比较喜欢把 AI 比作一个“高级外包”。什么意思呢你请外包写模块不可能只丢一句“做个商城”就完事必须给需求文档、接口约定、验收标准、测试用例。AI 也一样。很多人一上来就让它“给我写一个系统”结果换来一堆看似完整、实际跑都跑不起来的半成品。这不是 AI 没用而是你还没把任务拆到它能执行的最小颗粒。真正好用的方式是让 AI“按我定义的接口实现这个函数”或者“把这段 HTML 改成 Vue 组件保持样式一致”再或者“帮我生成一组覆盖正常和异常场景的测试用例”。只要验收标准够清晰AI 的产出质量会高到离谱反过来如果需求本身模糊AI 只能靠猜猜出来的东西自然没法直接上生产。还有个容易被忽略的点AI 擅长生成代码但不擅长理解业务上下文。比如“订单超时自动关闭”这个需求AI 可以给你写定时任务但“超时时间设多久、是否要通知用户、退款流程怎么走”这些业务规则必须由人来定。所以我的经验是AI 负责把执行成本打下来人负责把决策质量提上去。两者配合才能叫 AI 打造 Web 应用而不是 AI 替你做项目。1.2 适合 AI 切入的 Web 开发环节从实操来看下面这些环节让 AI 切入性价比最高脚手架与模板代码初始化 Spring Boot 项目、Vue 项目、Dockerfile、Nginx 配置AI 几秒钟就能给你一份能跑的版本。页面骨架与样式还原把设计稿描述给 AI它能生成结构清晰的 HTML/CSS或者直接生成 Vue/React 组件。通用 CRUD 接口单表的增删改查、参数校验、分页查询这类重复劳动是 AI 的舒适区。单元测试与接口测试让 AI 根据函数签名和业务描述生成测试用例能大幅提高覆盖率。Bug 排查与日志解读把报错堆栈、日志片段、相关代码贴给它往往能快速定位问题。技术方案初稿比如“要做单点登录比较 JWT 和 Session 的选型”AI 能帮你整理信息但最终选型还是要人拍板。不适合交给 AI 的是核心业务规则、多系统集成方案、复杂性能优化、以及需要审美和同理心判断的交互细节。我见过太多团队让 AI 生成核心交易代码结果对账逻辑少判了一个状态上线后数据一团糟。记住一个原则代码可以 AI 写责任不能 AI 扛。2. 工具选型解析AIWeb 开发的“搭积木”方案2.1 编码助手与 AI Agent 怎么选现在 AI 编程工具非常多我的选择标准很简单看你要做的是“补全一段代码”还是“自动完成一个任务”。如果只是写函数、写测试、写注释行内补全类工具就够用如果需要 AI 跨文件修改、主动跑命令那要上 Agent 型工具。类型代表工具适合场景使用注意行内补全GitHub Copilot、通义灵码写函数体、单测、注释、样板代码要对生成结果保持怀疑别无脑 Tab对话型ChatGPT、Claude 等方案讨论、报错解读、批量代码生成给足上下文包括代码片段、技术栈、约束Agent 型Cline、Codex 等自动改文件、执行命令、多步骤任务必须控制范围每次改动看 diff防止依赖被乱升IDE 整合Cursor、JetBrains AI Assistant文件级重构、跨文件分析注意对话上下文长度长项目要按模块分拆企业级集成Spring AI 等框架能力把大模型接入后端服务统一调用关注模型密钥管理、超时、限流、降级工具用得好不好关键不在于选哪个而在于你有没有建立“AI 输出→代码审查→测试验证”的闭环。我团队里有一条硬规矩AI 生成代码必须走 Git diff 评审不允许直接提交。Agent 型工具尤其危险它可能会为了“完成目标”顺手升级一个依赖或者改掉一个你没注意到的公共方法。所以我一般让它一次只改一个文件改完立刻查看 diff再决定要不要继续。2.2 前端生成、后端接口与 AI 能力的接入前端这块我习惯让 AI 先产出纯静态页面确认视觉和交互没问题再转成 Vue 或 React 组件。不要一上来就让 AI 生成整个框架工程否则视觉、交互、状态管理全混在一起出了问题非常难调。实际操作时我会给它一段很具体的提示词“生成一个手机优先的页面顶部是输入框和提交按钮下方是历史记录时间线需要有加载状态、空状态、错误提示颜色用浅色系卡片采用圆角设计。”这样产出的页面基本能直接用但表单校验、按钮防重复提交这些细节还是要人工检查。后端接入大模型如果你的技术栈是 Java我目前最推荐 Spring AI。它相当于把 OpenAI、通义、Claude 等多家模型接口又包了一层切换供应商很方便。比如要让 AI 回复一句话代码极其简单ChatClient chatClient; String reply chatClient.prompt() .user(用户说我今天很累请给我一句鼓励) .call() .content();如果团队以 Python 为主FastAPI 配 LangChain 也是常见组合。工具没有绝对好坏关键是后端要有统一的模型调用层、密钥管理和限流机制不能每个页面都私自去调大模型接口否则密钥一旦泄漏账单会非常感人。2.3 从页面到跨端Capacitor 和 iOS WebView 的定位现在很多 Web 项目做完后老板会说“顺便做个 App 吧”。如果时间紧Capacitor 是目前比较稳的跨端方案。它的思路很简单把 Web 应用打包进一个原生壳里本质还是跑 Web 页面但通过桥接层提供了相机、推送、本地存储等原生能力。热词里经常问“Capacitor 如何生成 web”其实顺序反了你要先有 Web 应用然后执行npx cap add ios/npx cap add android再通过npx cap sync把最新构建出来的dist目录同步到原生工程里。这里有个容易踩的坑Capacitor 项目里生成 Web 文件本质是把前端代码 build 成静态资源然后拷贝到原生目录。很多人一上来就去找“怎么生成 web”搞错了方向结果一直在折腾原生配置。记住流程先写 Web 应用再构建再同步再打包原生。WebView 里的兼容性问题也不少下文第 4 部分我会专门讲。3. 实操过程实录用 AI 从零做出一个可上线的 Web 应用理论说了不少我拿最近做的“AI 心情树洞”小工具当例子完整走一遍。这个项目本身不难但足够覆盖 Web 应用开发的完整链条需求拆解、数据模型、前端页面、后端接口、AI 能力接入、部署上线。3.1 需求拆解与数据模型设计先别急着写代码功能清单要先定清楚。我让 AI 帮我把原始想法拆成了三块用户输入一条心情记录系统调用大模型生成情绪标签和一段有温度的文字回复。用户能查看历史记录以及近期情绪类型占比。记录可以匿名分享但分享后不能知道具体是谁。数据表设计同样可以问 AI但必须自己审视。AI 给的第一版表结构经常缺字段比如没有status状态字段、没有created_at创建时间、没有租户或用户归属字段。最终我使用的是类似这样的结构CREATE TABLE mood_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id VARCHAR(64) NOT NULL, content TEXT NOT NULL, emotion VARCHAR(16), reply TEXT, is_public BOOLEAN DEFAULT FALSE, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_user_created (user_id, created_at) );这里有两个细节一是user_id必须建索引因为高频查询是“某个用户的记录按时间倒序”二是“是否公开分享”要有独立字段后续做 Feed 流时可以直接通过is_public TRUE过滤而不是去查所有记录再判断权限性能和安全都好很多。3.2 用提示词驱动前端页面生成前端我用的是 Vue3 Vite让 AI 生成一个手机优先的单页核心提示词大概长这样请用 Vue3script setup语法生成一个心情记录页面。 功能顶部一个多行文本输入框、一个提交按钮下方是历史记录时间线每条记录显示内容、情绪标签、AI 回复、发布时间。 要求包含加载状态、空状态、错误提示提交后清空输入框并刷新列表样式采用浅色系、卡片圆角布局适合手机屏幕。AI 生成的页面通常已经包含基础结构但我发现了几个普遍问题按钮没有防重复提交用户连续点击会发多次请求异常处理不够完善接口失败时只弹了个alert没有引导用户重试。这些我都要在代码评审里指出来要求 AI 补上loading状态和请求锁。让 AI 改代码时最好直接告诉它“用 disabled 控制按钮状态请求期间不可重复提交”它改起来很快。3.3 后端 API 与 AI 能力接入后端我用的 Spring Boot并接入了 Spring AI 来调大模型。核心接口是这样的PostMapping(/moods) public MoodRecord create(RequestBody MoodRequest request) { MoodRecord record new MoodRecord(); record.setUserId(SecurityUtils.currentUserId()); record.setContent(request.content()); MoodAnalysis analysis chatClient.prompt() .user(buildPrompt(request.content())) .call() .entity(MoodAnalysis.class); record.setEmotion(analysis.emotion()); record.setReply(analysis.reply()); return moodRepository.save(record); }其中MoodAnalysis是一个结构化的输出对象包含emotion和reply两个字段。这种写法比让 AI 返回一大段文本再去正则解析要稳定得多。如果不用 Spring AI也可以通过 JSON 序列化来解析但代码会啰嗦不少。这里最容易踩的坑是大模型接口超时或限流。用户写了一条心情正等着回复呢结果模型服务超时不能让他整个请求失败。我在代码里加了一层降级策略捕获异常后走一个默认文案例如“我收到了你的记录愿你今天慢慢好起来。”这样既不影响主流程也不会让用户觉得产品坏了。真实项目里的 AI 交互永远要考虑“模型挂了怎么办”。3.4 联调、部署与上线前端构建出来是静态文件后端是 Java 服务我直接用 Nginx 托管前端并把/api反向代理到后端容器。部署用的是 Docker Compose配置大致如下services: web: image: nginx:alpine volumes: - ./dist:/usr/share/nginx/html - ./nginx.conf:/etc/nginx/conf.d/default.conf ports: - 80:80 depends_on: - api api: build: ./backend environment: SPRING_AI_OPENAI_API_KEY: ${API_KEY} DB_URL: jdbc:mysql://db:3306/mood这里必须提醒API Key 不能写死在 Dockerfile 或代码仓库里用环境变量注入是底线。部署完成后要做冒烟测试注册、登录、写一条记录、查看历史列表四个主流程各跑一遍确保静态资源、接口、数据库、外部模型调用全部正常这个项目才算真的能交付。4. 工程化细节AI 生成内容最容易忽略的四个地方4.1 渲染性能与实时场景AI 生成的页面往往“看起来很美跑起来很卡”。尤其是 web 端实时视频、Web 预览 CAD 这类大体量场景AI 根本不会替你考虑性能。比如它可能给出一个“解析所有数据再渲染”的方案一上来就把浏览器内存吃满。我的经验是性能优化必须从架构层面做人肉判断。像 CAD 在线预览正确思路是后端把 DWG 转成 SVG 或 PDF前端按需加载、懒渲染实时视频则要考虑走 WebRTC 推流、HLS 分发而不是简单拉一个大视频文件。AI 可以帮你生成 Web Worker 分片解析的代码但“谁来分片、分片多大、内存如何释放”这些问题必须先由人来定。别期待 AI 能直接生成一个高性能架构它能做的是在你确定方案后把执行代码快速写完。4.2 Web 页面的 PDF 打印热词里有个“web 页面 pdf 打印”这个场景在实际项目里非常常见但 AI 常常处理得不好。你让 AI 做一个打印功能它大概率只给你写一句window.print()然后完事。结果打印出来的 PDF 里导航栏、按钮、空白页全混在一起根本不能交差。正确做法是在 Prompt 里加要求打印时隐藏非内容区域通过media print设置display: none。卡片不要跨页断裂使用page-break-inside: avoid。如果是 Canvas 生成图片导出的清晰度要乘上设备的像素比否则高清屏上会模糊。我每次拿到 AI 生成的打印页面都会先实际打印一次 PDF再逐页核对样式。这个步骤虽然繁琐但客户拿到的 PDF 就是最终交付物品质不能打折扣。4.3 WebView 与跨端兼容在一些企业级项目里Web 页面经常被嵌到 App 的 WebView 里或者是用 Capacitor 打包成原生应用。AI 生成的代码在这种环境经常翻车。最常见的是登录态丢失页面用 localStorage 存 token但 WebView 清理缓存就把 localStorage 清掉了用户被迫反复登录。要解决这个问题就不能只依赖 localStorage而是设计“短期 token 刷新 token”的机制由服务端校验会话有效性。另外WebView 环境里很多浏览器特有 API 可能不可用比如 File System Access API。用 Capacitor 打包时需要原生能力的地方要显式通过 Bridge 调用不能在 Web 层假装能直接访问文件系统。AI 可以帮你生成 Capacitor 配置但“哪些能力走 Web、哪些能力走原生”一定要人判断。4.4 权限、日志与配置管理AI 生成代码还有一个通病不管权限、不管日志、不管配置。一些团队用 AI 生成后台管理系统生成完发现任何登录用户都能看到别人的订单这就很危险。权限模型可以让 AI 生成初版但“谁能看什么数据”的业务规则必须人来定义。日志方面我要求所有接口必须有请求 ID、用户 ID、操作结果这样出事时能顺着链路查。配置方面本地、测试、生产环境要分开AI 生成的代码经常把数据库地址、密钥直接写死在配置里上线前必须全部改成环境变量。这些事听起来不性感但恰恰是企业级 Web 开发里“AI 帮不了你”的部分做不好就是事故。5. Web 安全AI 能帮你“查漏”不能替你“兜底”5.1 一次用 AI 做安全自查的实践有一次我把一段老代码贴给 AI让它帮我做安全审查。那段代码是直接用字符串拼接 SQLString sql SELECT * FROM user WHERE name name ;AI 几乎是瞬间就指出来这是典型的 SQL 注入风险应该改成 PreparedStatement 参数化查询。这种基础漏洞AI 识别得又快又准。但你也别高估它AI 也常常产生“自信的误报”把正常代码判成高风险或者漏掉业务逻辑漏洞比如“用户 A 能通过修改请求参数访问用户 B 的数据”这种越权问题。所以我做安全自查时会要求 AI 输出一个风险表格按风险等级排序并给出修复建议。然后我拿到表格后再结合业务流程人工验证。AI 是很好的“代码扫描助手”但真正的攻击面评估和漏洞验证必须靠人。5.2 Web 应用安全加固清单我给自己项目定的安全底线大概是这样风险类型AI 能做什么人的责任SQL 注入把拼接 SQL 改成参数化查询逐一排查所有动态 SQL包括排序字段XSS增加输出编码或使用富文本白名单过滤确认白名单允许哪些标签不允许的必须拦截CSRF添加 Token 校验、SameSite Cookie确认跨域策略与第三方回调场景越权访问根据接口文档生成测试请求手动模拟不同角色调用接口核对返回数据敏感信息泄漏扫描硬编码的 AK/SK、密码轮换受损密钥纳入扫描流水线依赖漏洞建议升级有 CVE 的依赖版本评估版本升级对业务兼容性的影响这里要强调一下AI 能做的偏“技术点”层面而 Web 安全更需要的是安全意识和流程。比如升级依赖不是无脑升最新版而是要看是否影响线上功能密钥一旦泄漏光改代码还不够必须去云平台轮换密钥。安全没有银弹能补一个洞就少一个风险。5.3 给 AI 提安全需求的提示词模板有朋友问我怎么让 AI 做安全审查才更有效我常用的模板是这样请从安全视角审查下面代码重点检查 SQL 注入、XSS、CSRF、越权访问、硬编码密钥。请按风险等级输出表格包含风险名称、影响范围、修复建议。只输出表格不要解释过程。实测下来结构化输出比直接问“这段代码安全吗”要靠谱得多。如果你在早期开发阶段还可以让 AI 生成一组安全测试用例基于这个接口文档生成一组测试请求覆盖未登录、普通用户、管理员三种角色并指出每个用例应该断言的字段。安全测试用例的价值在于它把“安全意识”变成了可执行的测试开发过程中能及时发现问题。记住AI 生成的安全建议要经过评审不能直接照做。比如它可能建议加一个很严格的密码规则结果把用户全挡在外面这种产品层面的权衡还是要人来拍板。6. 避坑实录AI 生成 Web 项目的常见问题与排查技巧6.1 项目跑不起来的三个高频原因“web 前端项目运行显示 network unavailable 怎么解决”这个问题几乎每周都有人问。我先说结论这个提示大概率不是“前端代码有问题”而是浏览器无法访问目标资源。排查顺序我一般是打开浏览器开发者工具看是哪个请求失败是页面本身 404还是接口跨域还是静态资源加载失败。确认后端服务是否真的启动了端口是否被占用是否监听在127.0.0.1而不是0.0.0.0外部请求可能访问不到。确认前端代理配置比如 Vite 的server.proxy有没有把/api转发到正确后端地址。最后再排查本机网络代理、防火墙、DNS 这类环境因素。另外一个高频原因是依赖问题。AI 生成的package.json经常包含很新的依赖版本而本机 Node 版本不兼容导致安装失败。遇到这类问题不要盲目升级 Node先看报错里提示的 engine 要求再决定是降依赖版本还是升 Node。还有时候是缓存问题清了 npm cache 再重装就好了。6.2 部署到 Tomcat 与容器时的经典报错Java 项目里还是有很多人用 Tomcat 部署。AI 生成的代码未必能直接打个 war 包扔进 Tomcat常见的问题包括packaging配成了jar没有打成 warpom.xml里少了内嵌 Tomcat 的 provided 依赖部署后 404多半是 context path 不对或者前端静态资源写在src/main/webapp外。排查时先看logs/catalina.out重点找Deployment of web application archive是否成功再访问http://ip:8080/项目名/看路径是否正确。容器化部署也有自己的坑。AI 生成的 Dockerfile 我见过最多的三个问题使用过旧的基础镜像没有设置时区日志时间差 8 小时缺少健康检查服务挂了半天负载均衡还在转发流量。我都会在 Dockerfile 里补上时区设置和 HEALTHCHECK别小看这些细节线上故障往往就出在这种地方。还有一次遇到 Harness 做流水线时的报错failed to load plugins web boot。我第一反应不是去重装而是看插件版本和平台版本是否匹配。这类报错通常是插件入口没有在 Web 启动阶段正常激活一般升级插件版本、清掉构建缓存就能解决。如果还不行就去看 runner 日志定位是配置加载失败还是权限不足。排障原则是先定位是哪个环节失败再动手别一上来就重装全盘。6.3 IDEA 2024 里创建 Web 项目的正确姿势有些朋友习惯用 IDEA 2024 的新项目向导但选错模板导致代码跑不起来。我的建议分两种情况如果你做的是新项目直接用 Spring Boot 模板勾选 Spring Web、Validation、MySQL Driver、Lombok 等依赖生成后点一下运行按钮就能起来省事很多如果你偏偏要写传统 Java Web再考虑 Maven 项目加 Jakarta Servlet 依赖。还要注意 AI 生成的pom.xml里packaging是jar还是warscope是provided还是runtime这些直接决定打包结果。IDEA 里的 Artifact 配置也容易踩坑我一般建议直接用 Maven 的package命令来构建少碰 IDEA 的 Artifact 配置。6.4 让 AI 排查问题的正确姿势最后分享一个效率技巧别直接把报错丢给 AI 就完事。我见过很多人问“这段代码为什么报错”然后贴了 20 行代码AI 给的答案既宽泛又不准确。正确姿势是给足上下文包括项目结构、技术栈、操作步骤、期望结果、实际结果、日志片段然后明确要求“按可能性从高到低排列原因并给验证方法”。这样的对话效果会好很多。还有一个细节AI 给的排查建议里如果涉及升级依赖或改架构先不要照做。AI 看不到你的完整项目它基于经验判断的方案可能在另一个场景下水土不服。先让它给出最保守的验证步骤确认问题原因后再让它帮你写修复代码。这个顺序能少踩很多坑。最后再说一点个人体会。AI 把重复劳动干掉之后Web 开发者的工作重心越来越偏向需求定义和质量保障。我之前也担心自己会不会被替代但完整跑完几个项目后发现能把模糊想法拆成清晰任务的人交付速度确实比只会手写代码的人快太多而且质量更稳。所以我现在团队里的规矩很简单AI 生成的代码必须经过评审必须补测试必须走安全自测。高品质不是 AI 单方面给的是人的判断力、流程约束和工具杠杆一起作用的结果。AI 真正帮我省下来的时间我都拿去盯那些它搞不定的边界情况了。