1. 为什么写这份试水报告我把AI塞进了前端日常先说清楚这篇报告在干什么。过去五个多月我把AI系统地用进了前端开发的日常链路从搭后台页面、写表单组件、封装请求层到排查WebSocket推送的时序问题再到处理老项目里JSON.stringify的耗时卡顿、Docker部署镜像体积爆炸这种杂活全都试了一遍。不是拿AI写个hello world也不是看官方demo觉得“未来已来”就完事而是把它当成团队里随时能调用的新同事硬塞进真实迭代里跑了几轮。我所在的小团队前端一共四个人日常维护一个后台管理系统、一个H5活动页项目还有一堆给业务方用的配置端小工具。这个画像应该能覆盖大多数前端同学的共感业务急、技术债多、没时间做专项优化。所以我试水AI的目标非常世俗——能不能让我把活干得更快质量不降级少加班。试水下来先说几个反直觉的结论AI写页面组件确实快但第一次给出的代码大概率不能直接上线AI Agent能跨文件改代码但review成本没你想象的低AI给的性能优化建议里有一部分是听起来高级但完全不适合你项目的伪优化但AI处理报错、写测试骨架、把八股文变成场景题面试官确实比我预期中靠谱得多。下面这份报告把我试过的每个场景、喂给AI的原始输入、它产出的结果、我踩的坑、最终留下的方案都摊开讲。为了让结果可复现我把最接近实际操作的方式都写了出来包括那些“AI说得头头是道但我没采纳”的著名坑位。2. 第一个真实试水生成后台表格页代码能用但不敢直接上线2.1 我把一个完整需求丢给了AI第一次正经试水我选了一个团队里反复出现的活儿加一个用户列表页。需求是标准的后台模板页包含搜索表单、分页表格、编辑弹窗、删除二次确认。我给AI的原始需求描述是这样的你是资深前端工程师。用Vue 3 TypeScript Element Plus写一个用户列表页。 功能要求 1. 顶部搜索表单用户名输入框、状态下拉框启用/禁用、搜索/重置按钮 2. 中间表格列字段为username、email、status、createdAt、操作列 3. 操作列包含编辑、删除 4. 编辑弹窗表单字段为username、email、status保存时提交给后端 5. 删除要二次确认确认后调用删除接口 6. 接口路径为 /api/users分页参数用 page 和 pageSize 7. 列表加载时要有loading态 字段说明username是字符串email是字符串status是枚举值 1 启用 2 禁用createdAt是字符串。这里有我故意埋下的几个细节给了字段类型、给了接口路径、给了分页参数名。铺垫越多AI输出跑偏的概率越低。2.2 第一轮产出看着不错细看问题一大堆AI给出的页面代码结构很完整el-form、el-table、el-dialog、分页组件都齐了甚至单独抽了api/user.ts方法命名也规范。第一眼看过去我确实觉得“这活AI能干”。但仔细过了一遍代码问题立刻浮现编辑弹窗的表单校验规则里没有对email做格式校验只写了必填判断重置搜索时分页页码没有reset到第一页只清空了表单字段删除接口请求期间没有“删除中”状态用户连点两次会发两次删除请求createdAt字段后端实际返回的是时间戳数字AI当成字符串排序处理搜索状态的枚举值AI写的是字符串1和2而后端接口接收的是数字类型这正好印证了一个判断AI写出来的后台列表页相当于一个理解能力不错的新人第一次交的代码。业务需求的主线它抓住了但边界条件、类型一致性、交互细节这些“前端的命”全丢了。2.3 我用三步把AI代码推进到“可用态”这一步很关键也是整个报告里最值得抄作业的部分。我没有推翻AI的代码重写而是把它当实习生代码来救。第一步喂真实数据结构。我把后端接口实际返回的JSON复制给AI让它把所有用到的字段、类型、枚举值按真实数据重写一遍。这一步直接消灭了“字符串和数字类型混用”和“createdAt排序错误”两个问题。第二步把浏览器报错和运行时现象贴回给AI。生成的代码必然有import漏写、组件属性名拼错、接口字段对不上的问题。我不自己找把跑起来之后的报错原文、出错的一次调用栈、对应代码片段三样东西一起贴过去让它先解释报错原因再修改。实测下来针对报错的修改准确率比它自由发挥高一个量级。第三步针对边界条件反向提问。这是我自己总结的你干过几个项目就能列出那些“新人必漏”的问题接口返回空数组怎么办、接口超时怎么办、删除失败要不要提示、编辑数据没保存就关弹窗要不要拦截。我把这些问题当清单逐条问AI让它补逻辑。结果是能补上大部分但有个别它也会一本正经地写出“参数为null时返回空对象”这种安慰性代码完全不解决业务问题。所以这步只能靠你的经验把问题列全AI只是执行者。我最后的结论是AI生成的后台模板页能节省大约60%的时间但这60%省在“搭骨架”阶段后面40%的边界填充、类型核对、交互状态完善永远需要靠一个真正干过活的人来兜底。3. 硬场景试水性能优化、大文件上传与部署脚本第2章说的是AI擅长的事但这章才是“前端当前最痛苦的那批问题”。我在团队里试水了三个场景一个序列化性能问题、一个500MB大文件上传、一个Docker部署脚本。这三个场景里AI发挥的水平参差不齐但都给了我不错的启发。3.1 JSON.stringify性能问题AI帮我搭分析框架决策还得靠人老项目里有个功能要把用户自定义的“表格列配置”缓存到localStorage。列多到一定程度JSON.stringify(config)加上写入localStorage这一步在低端设备上能卡到100多毫秒。用户感受就是“切列配置的时候页面一顿”。我让AI分析为什么卡。它列出的原因包括配置对象过大、包含大量冗余字段、JSON.stringify深拷贝整棵对象树耗时、localStorage同步写入阻塞主线程。AI给出的优化方向倒是不错我还真按它的思路做了个测试。它建议我对比三种序列化方案的耗时JSON.stringify、structuredClone、手写精简字段序列化。我写了一段测试脚本用一个模拟配置对象跑1万次结果如下方案1万次耗时说明JSON.stringify(完整对象)约1200ms序列化所有字段包含冗余action列表JSON.stringify(精简字段白名单)约350ms只序列化必要的列配置字段structuredClone约1800ms性能最差且结果不是纯JSON不能直接存localStorage这里说实话AI的“白名单精简字段”思路很简单但我之前没想过朝这个方向做。真正让它落地的还是我自己动手——把配置里hiddenColumns、columnWidths这些必须字段列进去把lastSelectedRowData、tableLayoutCache这种冗余字段全部排除序列化体积直接降了一半以上耗时降到了可用范围。更重要的是AI还提示了我“分层序列化”的思路高频读写的场景只缓存一份精简配置需要完整历史记录时再单独全量序列化。这个思路我采纳了落地后收益最大。但“哪些字段是高频繁使用的、哪些是必须持久化的”这种业务判断它是做不了的只能靠你给它讲清楚。3.2 大文件上传Web Worker的经典陷阱AI给我踩了个正着团队要新增一个上传功能让业务方把动辄四五百MB的Excel压缩包传到后台做数据导入。主线程直接读整个File必然卡死所以方案定为切片上传配合Web Worker在后台计算每片哈希支持断点续传。我让AI生成一个基于Web Worker的分片上传工具第一版代码长这样核心逻辑简化// AI第一版把整个File对象postMessage到worker里 // worker.ts self.onmessage async (e) { const file e.data.file; // 整个File对象被post进来 const chunkSize 2 * 1024 * 1024; for (let start 0; start file.size; start chunkSize) { const chunk file.slice(start, start chunkSize); // 在worker里算hash、上传... } };这个版本最大的问题在于postMessage传输File对象会触发结构化克隆相当于在内存里复制一份完整数据。500MB的文件主线程一份、worker里一份内存直接到GB级别低配用户打开页面整个浏览器直接卡死。这是一个非常典型的“AI知道模式、但不懂运行时约束”的例子。它知道该用Web Worker处理耗时任务但不知道这个场景下主线程和worker之间的通信成本可能比计算本身还高。我的正确版本是主线程负责用File.slice切成切片再把Blob传给workerworker只负责算hash并上传。这样主线程索引的是文件的引用不会复制整份数据到内存里。切片后的Blob因为放进了worker内部做计算网络请求也可以直接在worker里发不再占用主线程。其实这里还有一层优化但AI没提如果不需要绝对可靠的唯一性用采样hash做“秒传”预判比全量hash快得多。AI给的方案是全量哈希每一片这在500MB文件场景下初试上传没问题但秒传场景完全没必要。这个案例最大的收获是AI给的代码必须在自己脑内过一遍运行时的数据流特别是涉及内存、IO、通信的部分不能用“它说了用worker所以对”这种心态。3.3 WebSocket/SignalR连接状态里的“玄学”AI帮我理清了分支团队有个项目用了SignalR做实时推送但总出现“浏览器断网重连之后页面收不到补推数据”的玄学问题。这类问题最愁人的是状态时机不好抓调试工具难用前端社区资料也散。我的做法是让AI把SignalR的连接生命周期完整梳理成状态分支。我把我自己总结的“断线重连后可能进入的若干状态”贴给AI让它按状态列出每个分支应该怎么处理场景页面通过SignalR接收工单状态变化。网络断线超过30秒重连成功。 重连成功后我需要向后端补传一个上次收到的消息ID让后端把中断期间的消息补推给我。 请按状态分支列出正常推送、断线中、正在重连、重连成功、重连失败、完全掉线。 对每个状态说明前端应该做什么、不应该做什么、需要哪些变量。AI的回答不花哨但给我的启发很大它明确指出“重连成功”事件触发时不应该立刻把历史未收到的消息标记为丢失应该等一次服务端ACK还指出“正在重连”状态下前端不能重复调用start()否则会触发SignalR内部状态错乱。我照这个思路改写了连接管理代码把事件订阅和状态分发拆开用一个ConnectionState字段加一个事件总线来驱动UI层。这个场景里AI表现比较好原因是问题领域相对封闭事件分支清晰AI能通过训练数据里大量SignalR/WebSocket代码总结出合理模式。但这里也藏着一个坑它给的代码里有一处把“重连失败”和“完全掉线”当一回事了实际场景里一个是还有希望自动重连一个需要用户手动恢复连接。这种区别只要不了解业务场景你就发现不了。所以让AI梳理状态机时一定得把业务字段比如补推ID和期望行为比如重连成功后请求补数据都喂进去它会给你接近可用状态的代码。3.4 用AI试出一个反常理的Dockerfile前端现在不能只会写页面部署上线也得懂一点。我们的H5项目要从老服务器迁到Docker我让AI生成了一版Dockerfile结果连续踩了好几个坑。AI第一版给的思路是这样的用node:20-alpine作为基础镜像npm install后跑npm run build然后拷贝dist目录到nginx:latest镜像里。听起来很顺。结果构建的时候项目里的node-sass版本不兼容alpine直接编译失败报错信息是一大段关于python和make的缺失提示。AI给的修复方案是在镜像里装python3 make g这确实解决了构建问题但代价是构建镜像的体积暴涨到1.2GB。后来我换了个思路不再让AI“生成一个Dockerfile”而是让它“给出一个最小化且包含nginx gzip和history路由回退配置的生产环境部署方案”。这次它给了两阶段构建的方案构建阶段用带完整工具链的node镜像运行阶段只拷贝dist到nginx镜像里。最终版本干净很多# 构建阶段 FROM node:20-slim AS build WORKDIR /app COPY package.json pnpm-lock.yaml ./ RUN npm install -g pnpm pnpm install COPY . . RUN pnpm build # 运行阶段 FROM nginx:alpine COPY --frombuild /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80 CMD [nginx, -g, daemon off;]nginx配合的配置文件里最容易被忽略的是history路由回退和gzipserver { listen 80; server_name _; gzip on; gzip_types text/plain application/javascript application/json text/css; root /usr/share/nginx/html; index index.html; # 前端history路由回退 location / { try_files $uri $uri/ /index.html; } # 静态资源带hash可以长缓存 location /assets/ { expires 1y; add_header Cache-Control public, immutable; } }这几行配置解决的是Vue Router使用history模式刷新后404的问题以及首屏资源加载体积的问题。AI第一版完全没提这两个点它只盯着“镜像能不能跑起来”没想“跑起来之后前端路由能不能用、加载快不快”。这类问题你得比AI多想一步让它给部署方案时提前把项目用了history路由、需要gzip、需要静态资源缓存这几个要求写清楚它才能输出对齐的配置。4. 让AI Agent干跨文件重构的活省力但别当甩手掌柜4.1 我让它把散落的请求统一改成封装实例第3章说的是AI当“问答机器”和“补全器”这章聊更重一点的场景跨多文件的重构任务。现在不少前端工具把AI包装成了“能自己跑代码”的Agent形态我就拿这种能力试了一个具体任务。老项目的请求层很原始几十个页面直接import axios from axios发请求。我让AI Agent做一次统一改造扫描所有页面里直接axios.get/post的代码替换成项目里已有的request实例同时处理拦截器和类型。执行过程我只能说Agent确实能自动扫描和批量替换我不用挨个文件打开CtrlH了。大概扫了三十多个文件它一口气改了二十来个。这类机械替换它做得很好但改到中途我发现了问题有个登录页因为不需要带token原本绕开了统一拦截器Agent直接给套上了有个utils/request.ts文件里自带的axios.create配置Agent认为它是“旧代码”直接删了但那个配置里有一个其他模块依赖的自定义超时时间它替换import路径时对相对路径的深度计算从没出错这点比我预想强但对某个目录做了文件夹重命名的旧引用它没找到最终我review加上修复它引入的问题花的时间大概相当于自己亲手改的60%。看起来确实是省了40%的体力活但“两次review”的成本一点没省因为Agent替你做的每一个决定你都要重新拍板一遍。4.2 试出来的边界Agent适合执行指令不适合做决策我试完这次跨文件改造给Agent的使用边界画了一条很清晰的线适合给Agent做的任务把A组件里某个props的命名从X改成Y并同步所有引用按已有代码风格把直接写死的接口地址替换为环境变量批量删除某个已被废弃的工具函数并检查还有没有引用将某个组件从选项式API迁移到组合式API业务逻辑不变不适合给Agent做的任务“让请求层更健壮”这种开放性重构命题——它有权利选择重写方式但你不知道它会删掉什么业务细节涉及多业务方权限差异的接口改造——它看不到完整的业务上下文对老代码里“看起来没用但线上还在跑”的兼容逻辑做删除我给Agent喂的指令越接近“搜索这套代码里符合某特征的所有片段按我给出的模板替换然后用TypeScript编译器检查结果”它的成功率越高。只要让它做判断幻觉率就上来了。我个人的建议是如果你准备用AI Agent做跨文件改动先给仓库建一个最小可编译的检验入口比如tsc --noEmit或pnpm run lint让编译器当第一道防线。Agent改完后你review的重点不是“它改的位置对不对”而是“它没改的那些地方是否应该改”这种检查只能靠人。5. AI在测试和面试准备里的价值比预期高不少5.1 让AI写单元测试初稿能当骨架但别直接提交最近团队要推动项目接入单元测试我第一反应就是拿AI试水。我挑了一个带防抖逻辑的表单组件让AI生成Vitest测试用例。它给的初稿长这样// AI初版测试 import { debounce } from ./debounce; import { describe, it, expect, vi } from vitest; describe(debounce, () { it(should call the callback after waiting, () { const fake vi.fn(); const debounced debounce(fake, 100); debounced(); expect(fake).toHaveBeenCalledTimes(0); // 这个断言其实等于没测 }); });问题很明显它用“等100ms后fake不应被调用”来证明防抖生效但压根没等定时器结束也没用vi.useFakeTimers()去控制时间。这个测试跑起来确实会绿但一点回归保护能力都没有。不过AI给的初稿好在骨架清晰把每个场景的mock对象、调用过程都铺好了。我的做法是在它的基础上替换断言// 我手动加强后的测试 describe(debounce, () { it(应该在停止调用后500ms才执行回调, () { vi.useFakeTimers(); const fake vi.fn(); const debounced debounce(fake, 500); debounced(); vi.advanceTimersByTime(400); expect(fake).toHaveBeenCalledTimes(0); vi.advanceTimersByTime(100); expect(fake).toHaveBeenCalledTimes(1); }); });我试了三个组件AI生成的测试初稿覆盖了主路径包括正常渲染、触发表单校验、分页触发回调这些骨架没问题。但断言质量普遍偏低基本只断言“这个方法被调用了”不校验传参内容、不校验链路结果、不覆盖异常分支。你让AI写测试等于招了一个“知道怎么写测试但不知道为什么要写测试”的实习生。所以我的最终用法是让AI写第一版“能跑通主流程”的测试骨架然后我用半小时把所有断言一个个重写成有拦截能力的强断言再手动补上“接口返回错误、空数组、超时”等边界case的测试。这样效率最高也不会让测试沦为一堆只会变绿的表面摆设。5.2 用AI当模拟面试官比刷八股文有用另一个试水场景是准备前端面试。我很久没有正儿八经地面试了想快速过一遍基础知识和场景题。我几乎没用什么“AI刷题网站”直接把AI当面试官。我是这样给指令的你现在是一个前端技术面试官。我简历写的是3年前端经验主要做Vue和React。 请按下面方式面试我 1. 一次只问一个问题不要一次抛多个 2. 从“事件循环和宏任务微任务”这个主题开始 3. 我回答完之后你先指出我哪里答得不对再追问一个更深入的问题 4. 每个问题最后再给一个标准答案我用来对照这个模式跑下来效果超出预期。AI作为面试官最擅长的是“追问”——它会顺着我回答里的漏洞继续往深挖比如我刚说完“Promise本身是同步执行的then的回调是微任务”它立刻追问“那Promise里套一个setTimeout输出顺序是什么”。这在真实的面试里很正经。但AI当面试官也有一个必须小心的点它偶尔会一本正经地给出错误结论尤其在浏览器API行为、渲染机制这类细节上。我遇到过它把“宏任务和微任务执行顺序”解释反了的情况。所以我的习惯是AI给的标准答案一定当成参考答案不盲信自己再手写小demo跑一跑验证。它最大的价值不在于给你标准答案而是让你发现自己理解里的空洞。这个试水和“前端八股文”正好呼应。AI能把八股问题转成场景题让你真正理解底层机制而不是靠背面试题集锦。但最终裁决者永远是浏览器的实际行为不是AI的回答。6. 五个月试水总结AI在前端开发里的边界、收益、真香与真痛6.1 一套目前在我团队里验证过的“AI辅助开发”工作流试水了几个月我沉淀了一套团队能直接执行的协作流程适合大多数中后台/前端业务页面开发也适合性能优化和老项目改造把任务拆到“单文件/单函数”粒度。不要让AI生成整个项目让它生成一个组件、一个hook、一个函数。粒度越小AI给出的代码质量越高。喂足上下文再问。技术栈、接口字段、既有代码片段、报错信息能贴多少贴多少。AI回答的质量和上下文数量几乎是线性关系。先用真实数据对一遍第一版代码。所有AI生成的第一版代码默认按“新手交付”对待用真实接口、真实字段去对不凭观感验收。拿编译器和浏览器控制台当第一道裁判。TypeScript的tsc --noEmit、ESLint、浏览器console报错这些不花钱的校验器比任何review流程都严格。针对边界条件反向提问。把空数据、超时、连续点击、断网重连、权限不足这些问题列成清单逐条问AI有没有处理再检查它的处理是否合理。review时重点看“它替你做的决定”。AI替你新增了抽象、替你删了某个逻辑、替你改了字段类型这类地方是你最需要警惕的。这套流程执行下来AI在前端项目里最稳的收益区域是生成样板页面、写正则和字符串处理、类型补全与重构、翻译古早代码、快速梳理报错原因、生成测试用例骨架。6.2 真正不适合AI的场景我拿真金白银验证过试水的价值一半在知道什么能交给AI另一半在知道什么必须自己干。根据我这几个月的记录下面的场景AI表现最差架构与方案选型AI会不自觉地往“流行的方案”靠比如让它在Vue生态里选状态管理库它永远推Pinia但你老项目里几十个页面都是Vuex迁移成本远超它预估。后端接口字段设计AI生成的字段看起来逻辑自洽但往往不符合团队约定和实际业务流程比如分页字段一会儿用current一会儿用page。安全与权限相关逻辑用户角色、按钮权限、越权判断AI生成出来的代码表面花哨实际漏洞一堆。删除死代码AI经常会高估“这个功能没有用”把只在线上一小段时间才会触发的兼容逻辑删掉。还有一个雷区我得单独说AI给的“优化建议”里凡是要求你改数据流、状态流、换第三方库的默认先质疑。比如它会建议你把所有localStorage读写拆成web worker方案听起来很专业但实际收益可能微乎其微还会引入大量维护成本。我试过几次之后养成了一个习惯让AI在建议里补充“收益量化方法”凡是不自证收益的建议优先搁置。6.3 把AI当“读百本书但没经验的同事”之后协作舒服多了如果在五个月前有人问我对前端用AI怎么看我会觉得是锦上添花的东西。现在试了五个月我的想法变成它是团队的“一个读过海量代码但毫无业务经验的同事”。你给它清晰的任务边界、给它上下文、给它一个验收标准它能干得很快快到你怀疑自己是不是马上要被替换但你要让它独自负责一个模块的设计和落地它就会在业务盲区里一顿拳打脚踢最后还得你来收拾。我个人最后再分享一个冷门但极其实用的技巧当你卡在一个bug里把报错原文、相关代码片段、你期望的行为三样东西一起发给AI不要只写“我有bug帮我看看”。这种提问方式能让AI的定位效率提升非常大它给的排查线索往往比你自己盯着控制台猜要快。但记住它给的答案永远只是线索最终验证权在浏览器和你的测试用例手里。保持质疑实测为王。