用AI重构Web应用开发：从编码到部署的安全与性能实践

这两年我做 Web 应用的节奏明显被 AI 改变了。以前接手一个管理系统或者企业级前端项目光是搭骨架、写增删改查、调样式就要耗掉大半时间现在这些事一半以上都能交给 AI 打底我再花精力去审代码、补业务逻辑、盯安全和性能。但这里必须说清楚一件事“用 AI 打造高品质 Web 应用”不等于让 AI 全自动出活更不是简单地把 ChatGPT 的答案复制进项目里。真正的价值在于把 AI 嵌进需求分析、技术选型、编码、测试、部署、排查的全流程把它当成一个经验丰富但偶尔会犯错的结对程序员而不是一台无脑生成代码的机器。这篇内容我打算结合自己最近做过的几个项目从开发工作流的重构图、用 AI 搭骨架写代码、AI 功能模块落地、部署缓存、安全防线、高频问题排查这几个角度聊聊我踩过的坑和沉淀下来的方法。不管你是刚入门的前端新人还是带团队的企业级 Web 开发者只要你在用或准备用 AI 做 Web 相关项目这篇应该都能给你一些可以直接抄作业的思路。我说的这些操作也都基于真实开发环境不是纸上谈兵。1. AI 在 Web 开发里的角色不是取代而是重构1.1 我把 AI 用在哪些环节收益最大先给大家看一张我最近整理的工作表这是我每个月做项目复盘时都会过一遍的清单。左侧是 Web 开发里的常见任务右侧是我目前让 AI 介入的程度以及我会花多少精力去人工复核。开发环节AI 介入程度我的复核重点需求分析与技术选型高确认方案符合业务约束不盲目追新项目脚手架与目录结构高依赖版本、构建配置是否合理业务 CRUD 与接口代码高字段校验、事务边界、权限控制前端页面与组件高交互细节、响应式表现、可访问性单元测试与测试数据中断言是否覆盖真实业务场景部署脚本与运维配置中环境变量、缓存策略、回滚方案安全审查与漏洞排查中越权、注入、XSS 等专项检查代码解释与团队协作文档高文档是否与代码保持同步从这张表可以看出来AI 现在不是“能不能用”的问题而是“哪些环节最值”的问题。我个人的体感是越是重复度高、套路化明显的工作AI 越能干越是依赖业务上下文、需要拍板取舍的决策越需要人来兜底。很多人用 AI 写代码觉得不好用往往是因为把 AI 用在了需要决策的地方而把需要机器干的苦力活留给了自己。我举一个具体例子。上个月要给一个内部资产管理项目生成“资产借用审批”模块我直接把接口文档草稿和表结构丢给 AI它几分钟就给我生成了后端 service、前端表单和列表页的初版。换作以前这个模块从建表到页面能跑通至少得大半天。但 AI 生成的代码里把“审批状态流转”这种核心业务逻辑写得偏简单没有考虑驳回后重新提交的场景也没有记录审批历史的需求。这种问题说明什么说明 AI 能帮你把“骨架”搭好但“肉和筋”还得靠你对业务的理解去补。1.2 为什么“全自动生成 Web 应用”还不现实现在网上有很多“一句话生成网站”“AI 自动开发平台”的噱头我也试过几个。它们在做演示场景的时候确实惊艳比如生成一个落地页、一个博客系统效果都不错。但一旦进入真实的业务项目马上就会遇到几个绕不开的问题。第一个问题是上下文窗口有限。真实的企业级 Web 应用动辄几十个表、上百个接口、复杂的权限矩阵。AI 模型的上下文再大也不可能把整个项目的代码一次性装进去你只能分模块、分文件地和它协作。这个过程中最怕的就是“驴唇不对马嘴”——AI 用了一个别处的工具函数或者生成了和现有代码风格完全不一致的内容这种隐性成本最后都要你来买单。第二个问题是 AI 的“幻觉”会直接砸在业务逻辑里。我给 AI 描述过一个需求“用户角色分为管理员、审计员、普通成员审计员只能查看不能修改。”AI 生成的接口里确实做了角色判断但只判断了“是不是管理员”把审计员的只读权限完全漏掉了。这种漏洞如果发生在真实的生产环境就是越权事故。所以我现在养成了一个习惯凡是涉及权限、金额、状态流转的代码AI 生成后我必须逐行 review并且要求 AI 自己再写一遍越权测试用例。这就引出了 AI 时代 Web 开发者最核心的能力——代码审查和需求表达能力而不是打字速度。第三个问题是维护成本。AI 一次性生成的“爽文式代码”往往把所有逻辑都塞在一个文件里函数几千行变量命名天马行空。项目跑起来没问题但下个月加需求的时候你看着那堆代码头都是大的。所以我会要求 AI 严格按照项目现有的分层结构和命名规范来生成宁可在 prompt 里多写几句约束也不让它放飞自我。高品质 Web 应用的本质从来不是功能堆砌而是可维护、可扩展、可协作。2. 从 0 到 1用 AI 搭骨架、定架构、写核心代码2.1 先让 AI 做需求拆解和技术选型而不是直接写代码很多人用 AI 开发的第一句话就是“帮我写一个某某系统”然后期待奇迹发生。我试过结果就是得到一堆模板代码看着能用细看全是坑。正确的姿势是先把 AI 当成一个需求分析师和技术顾问让它帮你把模糊的想法拆成清晰的任务。我常用的 prompt 模板大概是这样的我正在规划一个【资产管理】Web 应用目标用户是公司内部员工和管理员。 核心功能包括资产入库、领用/归还、借用审批、盘点、报表导出。 约束条件 - 后端团队熟悉 Java希望用 Spring Boot 3 MyBatis-Plus - 前端希望用 Vue 3 Element Plus管理端和员工端用同一套代码 - 需要对接企业微信通知审批流程要支持多级 - 部署环境是内网服务器不能依赖外网服务。 请帮我完成三件事 1. 输出一份需求拆解清单标注每个功能模块的优先级P0/P1/P2 2. 给出数据库核心表的设计建议包括字段和表关系 3. 指出这个项目里最容易踩坑的 3 个技术点并说明风险。你别说这一套组合拳下来AI 给出的结果相当能打。它会把“审批流程”拆成“发起申请、直属领导审批、资产管理员确认、流程超时提醒”这样的子任务也会提醒你内网部署环境需要考虑企业微信回调的连通性。这些东西虽然你不一定全盘接受但它能帮你把大脑里的“一团乱麻”变成“一张地图”。我现在的习惯是拿到 AI 的拆解结果后先花 30 分钟做人工修正把不符合团队现状的部分删掉再拿着这份清单去排期。选型这一步同样可以先问 AI。比如你在纠结“用前后端分离还是服务端渲染”“用 MySQL 还是 PostgreSQL”“用 Restful API 还是 GraphQL”这些开放性问题非常适合让 AI 给你列出权衡表。但它给的结论只能当参考你说你们团队就 MySQL 熟练那 AI 说 PostgreSQL 再好也不能成为你换库的理由。技术选型的最终拍板永远要回到团队能力和业务场景这两个维度上。2.2 业务模块生成的实操套路以资产管理系统为例技术选型定了之后就到了大家最熟悉的“让 AI 写代码”环节。这里我总结了一套我自己一直在用的实操套路分了四步缺一不可。第一步是接口契约先行。不要一上来就写 Controller而是先把接口文档的需求描述给 AI让它产出 RESTful 接口定义包括路径、方法、请求参数、响应结构。这一步能最大限度地避免前后端“鸡同鸭讲”。第二步是数据库表和实体类同步生成。把第一步的接口定义喂回去让 AI 生成建表 SQL、实体类、Mapper 接口和 XML。这里要特别提醒AI 生成的字段注释经常写得模棱两可比如“状态”字段备注是“0/1”你必须让它改成“0-待审批1-已通过2-已驳回”否则下个月你自己都看不懂。第三步是按业务场景逐段生成。别图省事让 AI 一次性“把整个项目写完”我建议按“资产入库 → 领用申请 → 审批流 → 盘点导出”这样的业务模块逐个推进每完成一个模块就本地跑一遍通过后再进入下一个。这样出了问题你能立刻知道是哪个环节的事而不是对着几千行代码大海捞针。第四步是让 AI 自测和补测试用例。这是最容易被人忽略的一步。我会直接对 AI 说“请为这个审批接口生成 5 个测试用例包括正常流程、权限不足、参数校验失败、审批人不是上级、资产已被领用。”AI 生成的测试代码虽然不一定完全符合 JUnit 的规范但把测试思路摆出来了你照着补全很快。顺带说一句现在很多人用 IDEA 2024 创建 Web 项目时还停留在老办法里手动建目录、手动加依赖、手动配 Tomcat。其实你可以让 AI 帮你生成一份“从一个空白 Spring Initializr 项目到可运行的 Web 项目”的步骤清单包括依赖坐标、目录结构、启动类、配置文件照着操作比看文档高效得多。前端项目也一样Vite 脚手架的创建命令、依赖安装、代理配置这些高频操作AI 回答得又快又准。2.3 Spring AI企业级 Java 项目接入大模型的正确姿势聊到 AI 应用开发就绕不开 Spring AI 这个框架。很多做 Java 后端的朋友问过我项目里想集成 AI 能力是直接调 HTTP 接口好还是用 Spring AI 这种框架好。我的答案是如果做的是企业级 Web 应用而不是临时验证 demoSpring AI 这类抽象框架价值很大。Spring AI 的核心价值在于它把“和大模型对话”这件事做成了 Spring 生态里的标准组件。你不需要自己写 HTTP 调用、处理流式响应、管理对话历史它都帮你封装好了。我前几天在一个 Spring Boot 3 项目里集成 Spring AI 的 OpenAI ChatClient核心配置就这么点spring: ai: openai: api-key: ${AI_API_KEY} chat: options: model: gpt-4o-mini temperature: 0.7Java 代码里注入ChatClient就能直接发对话请求。如果你想做流式输出把返回值从String换成FluxString前端用 SSE 接住就行Web 页面上那种“一个字一个字蹦出来”的打字机效果就这么来的。如果你团队用的是国产模型或者私有化部署的模型Spring AI 也提供了统一的接口抽象切换模型厂商的时候不用把业务代码翻个底朝天。但这里我要给一个非常诚恳的提醒Spring AI 解决的是“接入”问题不解决“业务”问题。你该做的提示词管理、上下文窗口控制、敏感信息过滤、审核策略一样都少不了。框架能让你少写代码但不能让你少思考。尤其在企业项目里AI 返回的内容可能包含不合规的信息你必须在大模型前面再加一层“业务侧的安全阀”这个后面我会专门讲。3. AI 驱动的功能模块怎么落地3.1 做 AI 聊天和 Agent 模块先想清楚审核与鉴权标题里既然是“用 AI 打造高品质 Web 应用”那 AI 功能本身怎么在产品里落地肯定要展开聊。现在最热的就是两类AI 聊天助手和 AI Agent。先说说 AI 聊天网页版。我说的不是那种“不用登录就能聊”的演示站——那种东西技术上确实简单但做给真实用户用的产品登录、鉴权、限流一个都不能省。最近老有团队跟我说想做个“无限制聊天 AI”来吸引流量我都是两个字别做。一方面是没有内容审核和身份管理的产品迟早会被恶意用户灌垃圾、刷接口、绕限制根本撑不住另一方面是平台和法规都不允许“没有边界”的 AI 产品存在。真正高品质的 AI 聊天功能应该是“登录 → 鉴权 → 限流 → 上下文管理 → 输出审核”这个完整链路走下来。技术落地的时候我建议把对话历史和业务数据分开存。对话历史建议放 Redis 或者 MongoDBTTL 设置成 30 分钟到 24 小时别一股脑写进 MySQL 业务表里不然数据量涨起来你哭都来不及。在前后端交互上优先用 SSEServer-Sent Events去做流式输出比 WebSocket 简单很多而且天然适合“服务端单向推送”这种场景。我在项目里做的就是后端用 Spring AI 的FluxString流式返回前端用EventSource接口接数据大概五十行代码就能搞定一个体验很流畅的聊天框。再来说 AI Agent。Agent 的想象力确实大让 AI 自己规划任务、调用工具、操作浏览器听起来很酷。但在 Web 应用里接入 Agent我强烈建议先给“工具调用”上锁。什么意思你的 Agent 如果需要操作数据库、调用第三方接口、读写文件这些工具函数必须做白名单管理并且关键操作一定要有“人工确认”这一步。我见过一个项目AI Agent 自动把测试环境的数据清空了原因就是给 Agent 配了一个不带条件的删除接口工具。这种坑出一次团队对 AI 的信任就崩了。3.2 Web 端实时视频、CAD 预览、PDF 打印这些硬骨头AI 怎么帮除了聊天和 AgentWeb 开发里还有一堆“硬骨头”功能Web 端实时视频、在线预览 CAD、页面打印 PDF。这些功能以前是很多前端工程师的噩梦现在 AI 能帮上不少忙但前提是你得知道怎么问。Web 端实时视频底层基本绕不开 WebRTC。你让 AI 给你写 WebRTC 的点对点连接代码它写得很快但真正落地时坑全在细节里STUN/TURN 服务器的配置、ICE 候选的交换、房间信令服务怎么搭、断线重连怎么处理。我给 AI 的 prompt 会带上明确约束“请使用 Socket.IO 作为信令服务器使用 mediasoup 或 simple-peer 作为 WebRTC 封装服务器部署在内网无法使用公共 STUN请给出 TURN 服务器配置建议。”这样 AI 给的代码才是有实战价值的而不是把 MDN 文档复述一遍。CAD 在线预览核心思路是让浏览器直接渲染 CAD 文件。最靠谱的方案是 DXF 格式因为它本质上是文本文件前端可以用dxf-parser解析然后丢给 Canvas 或 WebGL 渲染。如果是.dwg这种闭源格式就得上服务端转换了比如用 AutoCAD 的转换服务把它转成 DXF 或 PDF 再在前端展示。AI 在这方面能帮你生成解析代码的骨架以及告诉你不同格式之间的转换链路但你不要指望它无中生有处理好所有 CAD 的怪异边缘情况。PDF 打印这个功能我重点说。很多人第一反应是引入jspdf这种库在前端生成 PDF但体验真的不好中文乱码、样式错乱、分页困难都是家常便饭。我现在更推荐的做法是页面正常用 HTML/CSS 排版打印时用 CSS 的media print规则来隐藏导航、调整布局然后直接用浏览器的打印功能或者在后端用 Playwright/Puppeteer 把页面渲染成 PDF。AI 非常擅长帮你写这类的打印样式你只需要告诉它“打印时要隐藏侧边栏表格要跨页显示表头A4 纸纵向”它就能给你一套完整的 CSS。这套方案生成的 PDF 干净、清晰还能保留矢量文字比 jspdf 硬画高到不知道哪里去了。3.3 给 AI 写需求上下文的万能模板上面这些场景不知道大家注意到没有我给 AI 的 prompt 都有一个共同点给了足够的背景约束。我总结了一个万能模板大家可以保存下来以后给 AI 描述前端或全栈任务时直接套用我正在开发一个【项目类型】例如“企业资产管理 Web 应用”。 技术栈是【前端框架 UI 库 后端框架 数据库】。 当前要实现的模块是【模块名】它需要满足以下业务规则 1. 【业务规则 1】 2. 【业务规则 2】 3. 【业务规则 3】 请按照以下要求输出代码 - 遵循【项目里既有的目录结构/命名规范】 - 关键逻辑需要添加中文注释 - 同时给出对应的【测试用例/接口文档/前端页面】 - 特别提醒注意处理【你担心的边界情况如并发、跨域、权限】。别小看这个模板它解决的是 AI 协作里最核心的“上下文缺失”问题。你给的约束越具体AI 的答案越接近生产可用。反过来你就给一句“帮我写个资产管理系统”AI 只能给你一套最普通、最模板化的东西这不是 AI 不行是你的输入质量决定的。通俗点说AI 就像一个新来的同事你交代需求时只说“做个审批”他当然只能按自己的想象做做出来不对你再来回改但你告诉它“审批分两级第一级直属领导第二级资产管理员驳回要填原因审批记录要留存”它一次就能做对一大半。4. 部署、缓存与中间件AI 能帮你少踩多少坑4.1 Tomcat 部署 Web 项目与前后端分离的正确姿势开发环境跑通了下一步就是部署。很多团队问我Tomcat 部署 Web 项目到底有什么讲究。我先说结论如果你是传统的 Spring MVC 单体项目打成 War 包丢进 Tomcat 的 webapps 目录就行如果是前后端分离项目我强烈建议不要用 Tomcat 去托管前端静态资源而是把前端构建产物交给 Nginx后端接口继续由 Tomcat 提供。原因很简单Nginx 处理静态文件、并发连接、反向代理的能力比 Tomcat 强太多了。前端打包后的 index.html 和静态资源放在 Nginx 的 html 目录里接口路径用/api/前缀Nginx 里配一句proxy_pass http://127.0.0.1:8080;就能把动态请求转给后端的 Tomcat。这套部署架构在 AI 时代仍然是绝对的主流它稳定、好排查、容易扩展。Tomcat 部署这步有些细节必须注意。War 包的名字决定了访问路径比如你的包叫asset.war那访问路径就是http://ip:8080/asset/想要根路径访问就把包名改成ROOT.war。生产环境记得把 Tomcat 默认的 8080 端口改掉同时关掉它的管理后台避免暴露不必要的接口。JVM 内存参数也要根据机器配置调一下常见的是在catalina.sh里设置JAVA_OPTS-Xms512m -Xmx1024m这些基础事项你可以直接用 AI 帮你生成一键部署脚本先让它给思路再自己斟酌确定。4.2 Linux 缓存与性能调优Nginx、Redis、HTTP 缓存一起上部署上线之后性能是永远绕不开的坎。我先说最容易被忽略的HTTP 缓存。很多人一谈性能就想上 Redis、加服务器但实际上把静态资源的缓存头配好效果立竿见影。Nginx 里加一段配置就够了location ~* \.(js|css|png|jpg|jpeg|gif|svg|woff2?)$ { expires 30d; add_header Cache-Control public, immutable; }这样用户在第一次访问后30 天内再打开页面这些静态资源直接从本地磁盘加载连请求都不会发到服务器。前端项目的构建工具通常会在文件名里带上 hash所以静态资源可以放心设置长缓存——文件名变了浏览器自然会去拉新版本。对于动态数据Redis 缓存是主力。高并发场景下热点数据先查 Redis没有再查 MySQL查完回填 Redis这是最经典的缓存模式。但这里有个特别容易踩的坑缓存穿透和缓存雪崩。AI 生成的缓存代码经常不处理这两个问题所以我每次都额外要求它处理一下缓存空值防止穿透给过期时间加随机值防止雪崩。缓存过期时间也不要随便拍脑袋你要根据业务容忍的“脏数据时间”来定。比如资产库存数据允许最多 5 分钟的延迟那缓存时间就设 300 秒别设成 1 小时。另外如果你的应用用到了 HBase 这类大数据组件它的 Web 界面也要了解一点。HBase 的 Web UI 默认在 16010 端口可以看 Region 分布、请求延迟、存储情况。当应用变慢时先看这里再看应用日志能省不少排查时间。这些运维命令和排查思路你完全可以问 AI比如“HBase Web UI 显示某个 Region 的请求延迟很高可能是什么原因”它能给你列出七八种原因你再按图索骥去确认比一个人瞎翻日志高效很多。4.3 Linux 下常见缓存命令AI 能帮你整理成脚本缓存服务日常运维命令不算复杂但频率很高。我之前经常在几个固定场景里反复敲查看 Redis 内存和 key 数量、清理 Nginx 缓存目录、分析 Tomcat 日志里的慢请求。后来干脆让 AI 帮我把这些常见操作整理成一个运维脚本合集每个脚本都带注释和参数校验用起来顺手多了。这里分享一个直接能用的思路让 AI 写一个cache_tool.sh支持三个参数redis显示 Redis 信息nginx清空 Nginx 缓存目录log分析当天请求日志里响应时间超过 3 秒的接口 Top10。AI 用 Shell 和 awk 就能做到代码量不大但非常实用。关键是你让 AI 写完之后一定要在自己机器上跑一遍脚本里常见的坑包括路径写死、没有判断命令是否存在、权限没有加执行位等实地跑一遍就能发现。这种把高频小工具的编写交给 AI 的做法本质上是在“搬砖”和“思考”之间做了正确选择。你花 5 分钟描述需求AI 花 10 秒生成脚本你花 5 分钟验证修改。就算最后花了 20 分钟也比你从零手写快得多。而这些脚本沉淀下来就是团队运维资产的积累。5. Web 安全AI 辅助时代更不能省的一环5.1 让 AI 做安全代码审查重点查这四个方向Web 安全这块说实话很多开发者都有侥幸心理觉得“我们是内部系统不会被攻击”。我做过的项目的经验告诉我越是内部系统越容易被忽略而内部系统的数据往往更敏感。AI 在这里能扮演一个非常尽职的“安全巡检员”但前提是你得告诉它要查什么。我每次都会让 AI 对生成代码做一轮定向安全审查重点就四个方向第一是 SQL 注入。虽然 MyBatis-Plus 这类框架帮我们挡住了大部分拼接 SQL 的风险但如果你用了${}拼接、或者自己写了复杂查询就一定要看输入有没有校验可能带来的注入问题。第二是 XSS前端把后端返回的内容当成 HTML 直接渲染时最容易中招审查时要看有没有做转义。第三是越权也就是我前面说的那个例子A 用户是否能操作 B 用户的数据这是 AI 代码里高频出现的漏洞点。第四是敏感信息泄露代码里有没有硬编码的数据库密码、API Key、密钥这个 AI 一眼就能扫出来。我常用的安全审查 prompt 是这样的请对以下代码做安全审查重点检查 1. 是否存在 SQL 注入风险特别是字符串拼接的地方 2. 是否存在 XSS 风险用户输入是否被安全处理 3. 是否有越权漏洞当前用户能否操作不属于自己的数据 4. 是否有硬编码的密钥、密码、Token 5. 是否缺少必要的输入校验和权限校验。 请列出每个问题的代码位置、风险等级和具体修复建议。AI 给出的结果不一定 100% 准确但它的存在能有效避免“灯下黑”。一个人 review 自己的代码总是会下意识觉得“我写的没问题”让 AI 从另一个角度挑毛病往往能发现一些被忽略的盲点。尤其在企业级 Web 开发里安全审查从“上线前抽检”变成“每个 PR 必查”这个习惯能挡掉绝大多数常见攻击。5.2 从 Cloudflare 拦截到 CTF 入门理解攻击者思维才能防御前几天有个朋友跑来找我说他部署在服务器上的网站突然打不开了浏览器提示“your last request has been blocked for security purposes. please contact web”。他第一反应是服务器挂了。我让他先别慌这个报错其实是 Cloudflare 这类 CDN/WAF 服务的安全拦截页面意思是“你的这次请求触发了防护规则被拦下了”并不代表网站崩溃。这类情况通常有三种原因一是你的 IP 被防火墙规则盯上了可能是短时间内请求频率过高二是请求特征触发了 WAF 规则比如路径里包含了可疑参数三是浏览器环境异常被当成自动化脚本。排查的时候不要盲目去改防火墙规则先看是不是自己误操作再看是不是有异常流量在扫你的站。这里也要提醒一句做应用防护的时候可以用这类 CDN 的安全能力但不要把它当成万能挡箭牌应用自身的鉴权、校验、审计还是得做扎实。说到安全我还挺建议大家去玩一玩 CTFCapture The Flag夺旗赛里面的 Web 方向。CTF 里的 Web 题目标就是在给定的靶场网站里找到那个“flag”字符串通常藏在一个漏洞后面。比如 CTFShow 平台上面的 Web 入门题就是为新手设计的由浅入深的 Web 安全训练场。做这类题目对普通开发者有什么好处它能在短时间内让你理解攻击者的思维方式——原来一个看似无害的输入框可以变成注入的入口原来一个上传点可以直接拿到服务器权限。我特别推荐 Web 开发者尤其是负责后端接口的同事抽出一点时间刷 CTF 入门题。当你亲手把一道题打穿、找到 flag 的那一刻你对代码里“为什么这里要做参数校验”“为什么要过滤特殊字符”的理解会超过你读十篇安全文章。这不是让你去攻击别人而是让你知道攻击是什么样的才能写出有防御力的代码。AI 在这一块也能当教练你完全可以把一道不会做的题目的源码发给 AI让它帮你分析漏洞原理然后再练习验证 AI 给出的思路是否成立这比自己对着教程死磕效率高多了。5.3 AI Agent 的工具权限与内容合规必须在一开始就想清楚现在很多 Web 应用都在尝试接入 AI Agent但如果你们准备做 Agent我建议先想清楚两件事再动工工具权限和内容合规。工具权限指的是 Agent 能调用哪些系统能力。这个问题必须在一开始就确定边界。我给团队的建议是把工具按权限级别分成三类只读工具查数据库、查库存、写入工具创建单据、发送消息、高危工具删除数据、修改权限、转账。Agent 只能默认使用只读工具需要用到写入工具时必须经过用户确认高危工具干脆就直接禁用。这种分级方案可以一开始就在代码层面约束好不要等 Agent 出了事故再补救。我见到过最惨烈的例子是某团队测试 Agent 时因为它自动调用了定时任务工具循环发送了大量重复消息差点触发服务商的封禁机制。内容合规这个问题最近被越来越多团队问到尤其是那些想做“无限制 AI 聊天”“无审核生成式 AI”的产品。我的观点非常明确“无限制”“无审核”从来就不是产品卖点而是产品灾难。一个面向公众的 AI 应用如果不做内容审核、不做身份管理、不做输出限制那就等于把一把没有保险栓的枪交给所有人。技术上ChatGPT 这类大模型本身已有安全对齐但我们在业务侧还必须再做一层审核输入侧过滤提示词注入类的恶意指令输出侧用关键词库结合模型分类器做内容合规检测再叠加上限流和敏感操作二次确认。把这些做好了产品才能长期稳定跑下去而不是上线没几天就被关停。6. 高频问题排查与避坑实录6.1 前端项目运行报 network unavailable怎么一步步查这个报错应该是 Web 前端新手最常遇到的心头痛了。好不容易从网上拉下一个项目npm install装完依赖npm run dev一跑浏览器里却提示“network unavailable”。遇到这种问题我建议先按下面这个顺序排查先确认开发服务器是不是真的起来了。看命令行里有没有Local: http://localhost:5173/这样的输出端口号是多少有没有因为端口被占用自动换端口。如果服务器没起来往下看报错原因如果起来了再去浏览器里访问别用file://协议直接打开index.html那肯定跑不起来。接着看是不是代理配置的问题。现在的前端项目普遍配置了接口代理比如 Vite 的server.proxy指向后端地址。如果你的后端服务没启动或者代理地址写错了页面能打开但接口请求全是 network unavailable。这时打开浏览器的开发者工具F12切到 Network 面板看请求是不是把错误状态显示为网络层错误。解决办法是把代理目标改成http://127.0.0.1:8080这类实际可访问的地址还要检查 CORS 是否正确配置了相关跨域响应头。最后还要考虑防火墙和权限问题。开发环境跑在 Windows 上时端口号是私有 IP 且没有入站规则或者公司网络策略拦截了本地端口也会出现类似现象。纯前端项目一般不会特别复杂按“服务器 → 代理 → 网络环境”这个顺序排查百分之八十的情况都能解决。我把这套排查思路存成了一个笔记遇到问题就直接按步骤过一遍而不是瞎点乱试。AI 在这方面也能帮忙你把命令行报错截图贴给它它能很快定位到问题是出在依赖安装还是端口冲突。6.2 AI 生成代码的常见翻车现场我替大家踩过了说句公道话AI 写代码平常很靠谱但翻车翻起来也是花样百出。我把自己和团队里遇到的真实案例整理了一下给大家做个避坑参考。第一个翻车现场是依赖版本冲突。AI 生成的项目里pom.xml 或 package.json 里的依赖版本经常是随手填的结果一跑npm install或者 Maven 构建各种依赖不兼容报错一片红。现在我的习惯是AI 给出依赖后我会要求它注明“该依赖适用于哪个版本组合”或者干脆让它基于某个固定的 Spring Boot 版本或 Node 版本来生成减少版本漂移带来的不确定性。第二个翻车现场是环境差异。AI 在回答时默认你用的是主流环境比如 JDK 17、Node 18、MySQL 8.0但你的服务器上可能装的是 JDK 8、MySQL 5.7。于是 AI 生成的代码里可能用了var关键字或者用了新版 MySQL 才支持的语法部署上去直接报错。这个问题的根源在于你没在 prompt 里交代环境所以我强烈建议把环境信息写进项目说明每次对话都带上。第三个翻车现场是“看起来对实际上抄错 API”的幻觉。AI 可能会虚构一个并不存在的类名、方法名或者配置项看起来有模有样编译也过不去。尤其是冷门框架或者框架的新版本AI 的知识可能滞后会出现这种张冠李戴的情况。遇到编译报错第一反应不要质疑自己第二反应也不要全信 AI 的解释直接去官方文档确认 API 是否存在。用 AI 写代码的人必须养成一个习惯AI 给的代码你至少要能看懂七成剩下的三成要么问它要么查文档不能闭眼复制。闭眼复制那一刻就是你埋下生产事故隐患的时刻。6.3 关于“降 AI 率”工具我要泼一盆冷水最后聊一个可能有些朋友会关心的话题降 AI 率。现在网上有一堆“降 AI 率工具”号称能把 AI 写的文字改得像是人写的还有人要求技术博客、项目文档必须“像人写的”。对这个事我的态度很明确别把力气用错地方。在企业级 Web 开发里代码和文档的价值在于“能不能跑”“别人能不能看懂”而不是“像不像 AI 写的”。你花时间研究怎么让 AI 生成的代码显得更像人工手写不如花时间把注释写清楚、把变量命名规范、把测试补全。而且说实话AI 生成的代码如果质量高保留它本来就是合理的选择就像你不会因为“Excel 做表太快”而故意用计算器吧工具就是工具关键看你怎么用。当然我也理解大家的焦虑。如果这件事确实困扰你我做技术内容时的一个经验是多写项目背景、踩坑经历、个人思考少写正确的废话。深度内容天然就是个性化的而准确、具体、有判断力的技术产出本来就是“高 AI 率”的反面。归根到底回归问题本质AI 是这时代最有生产力的工具我们真正要说的事情是——“用 AI 打造高品质 Web 应用”核心价值是它能不能帮你稳定高效地交付一个用户真正爱用的产品而不是纠结它是不是 AI 写的。这几年实操下来我自己最大的体会是AI 把 Web 开发的门槛降低了不少但天花板反而更高了。以前你是被重复劳动淹没的“搬砖工”现在你更像一个“架构师”把拆解需求、验证方案、审查代码、守护安全这些真正需要判断力的事情抓在自己手里把生成、检索、改写、排查这些活儿交给 AI。最开始用 AI 写代码的时候我总觉得它在跟我抢饭碗后来想明白一件事被替代的从来不是某个职业而是那种“只会机械执行、不思考为什么”的工作方式。你如果愿意多问一个为什么多花十分钟 review 一遍多想想边界条件和异常场景AI 就永远只是你的放大器而不是你的替代品。最后再分享一个我自己的小习惯每完成一个模块我都会把“这次和 AI 协作时踩到的坑、用顺手的 prompt、修正过的代码模板”记录下来存成团队共享的提示词库。这个东西用起来越攒越值钱下次遇到类似的需求直接调模板改参数就行不用再从头跟 AI 解释一遍上下文。如果你刚起步我建议也从今天开始攒这个库三个月后你回头看会发现那些反复折腾的时间全都省下来了。