1. 我为什么会想“去问AI这件事本身”前端圈最近隔三差五就有人讨论AI会不会让工程师失业尤其在某个新模型发布之后群里的气氛总是一会高潮一会低谷。我本来对这种话题已经麻木了但那天加班改一个订单筛选逻辑改到烦突然冒出一个念头与其天天听别人怎么猜不如直接去问AI——就让它用“AI自己的视角”告诉我它到底能不能把我这段工作接过去。这个念头听起来像玩笑实际上认真想是有道理的。我们讨论“取代”的时候绝大多数人根本没把问题定义清楚。是要取代谁刚入行的初级工程师还是带过多个项目、能拍板的资深工程师是在什么场景下取代一个从零搭建的业务系统还是在一个跑了五年的老项目里加一个筛选条件“取代”又是指什么程度是完全不再需要人的代码还是把写代码的时间从十小时压缩到两小时这些问题不拆开讨论就永远是情绪输出。所以我做了一件事把“AI能不能取代前端”这个大标题拆成一组小问题然后逐个扔给AI。后来我又把这组问题换了几种问法对比它给出的答案有没有实质性差异。整个过程最有意思的地方不是它最后说了什么而是我发现——不管你怎么引导它在关键结论上都倾向于给你一个“安全、积极、让你舒服”的答案。这本身就值得玩味。这篇文章就是我这轮提问和实测的记录。我不打算只停留在“AI说它不会取代前端”这种层面因为AI自己的回答不一定是真的它可能只是在顺着你的预期说。我要做的是把它的回答当成线索拿到真实的代码场景里去验证一遍哪些环节它真的很强哪些环节它纯粹是在“一本正经地胡说”哪些环节它虽然能干但需要人盯着收拾残局。看完之后你会有自己的判断。2. 我问了AI什么它又回答了什么先说提问设计。我第一轮问得很直接“你会取代前端工程师吗”这种问法注定得不到有信息量的答案因为它太宽泛、太抽象而且带着明显的情绪预设。AI大概率会给你一段“人类工程师有独特价值”的温和回复里面塞满了诸如“创造力”“同理心”“复杂决策”这样的词。这些话听着没错但没有任何可验证性。于是我换了策略把问题改成几个具体角度如果我要组建一个十人前端团队其中五个工作量可以交给AI完成你认为哪些任务优先自动化请列举前端工程师日常工作中你作为AI模型“当前还做不好”的五个具体环节并说明为什么做不好。有一个稳定的旧项目需求文档缺失线上有一个偶现白屏问题你会给出怎样的排查思路如果要给一个5年经验的前端工程师写一份“防被AI替代”的能力清单你会写什么这几轮回答质量明显不同。它给出的内容有一些共识我梳理出来大概集中在几点第一它承认“代码生成只是前端工作的一小部分”。这句话其实很关键很多人以为前端工作就是“把设计稿变成页面”实际上这只是最表层的一部分。真正消耗精力的是需求沟通、方案设计、边界处理、兼容性验证、性能调优、以及上线之后的各种线上问题定位。第二它反复提到自己“没有业务上下文”。这个词第一次出现时我没太在意后来发现它是对“AI能不能取代前端”这个问题最本质的回答。所谓业务上下文不只是说“不知道接口返回什么字段”而是说它不理解这个产品的用户是谁、哪些功能是最核心的、哪些可以砍、哪些页面性能必须卡在某个阈值内。这些决策面前AI就像一个只知道单词不知道语境的人能造句但不知道该说什么。第三它很明确地说责任归属仍然是人。代码出问题了公司不会起诉模型只会找到工程师。AI可以帮你生成一段看起来合理的代码但那个对结果负责的人还是你。这不是技术能力问题是信任和追责机制决定的。第四它提到“创意和审美”是它的弱项。这个说法我不完全买账因为很多前端场景的“审美”其实是有规律可循的AI在视觉还原上已经能做到相当不错。真正难的地方不是审美本身而是“审美的决策权”——设计师给的是一个方向产品经理给的是另一个方向你要在冲突里找一个折中方案并且让两边都愿意接受。这个过程里大量用到语言技巧、人际判断和产品理解这是AI给不了的东西。看完这些回答我有一个很直接的感受它说得都对但都停留在“正确”的层面。就像一个聪明的实习生背书很熟能给你列出一条一条的要点但你只要追问一句“那具体到我这个项目里该怎么办”它就开始露怯。带着这个怀疑我把三个典型前端场景扔给了它让它直接给出代码和排查思路。3. 别急着信它的判断先拿代码说话3.1 实测任务一给老项目加一个筛选组合条件我随便挑了一个在做的后台管理系统页面作为背景一个表格页有几十列数据现在要加一组筛选条件包括关键词搜索、下拉选择状态、日期范围三个条件支持组合使用。我把这个需求原封不动描述给AI让它给出实现方案。它的回复速度很快代码也像模像样拿到三个筛选参数拼进请求体请求接口渲染列表。单看这段代码你可能会觉得“AI写代码已经能直接用了”。但放到真实项目里至少有三个问题它是不会主动考虑的。第一个问题是数据缓存。这个页面的列表数据在切到详情再返回之后应该保留上一次的筛选状态。AI给出的代码是从空值开始的没有考虑状态保持每次重新进页面所有条件都会清空。你可能会说“那我可以在需求里写清楚”但真实的业务需求经常不会写这么细甚至提需求的人默认“你本来就应该会处理”。第二个问题是筛选条件的联动和重置。比如状态选了一个值日期范围清空了这时候另一个条件对应的选项可能会有变化。AI生成的代码只会机械地把三个条件拼在一起不会处理“某个条件变化后是否需要重置其他条件”这种隐含逻辑。第三个问题是性能和防抖。关键词搜索若不做防抖用户每敲一个字符就发一次请求能直接把后端打挂。AI版本完全没提这回事。我后来把这三个问题喂回去问它“你刚才的实现里有这些问题怎么改”它能答上来而且改得还挺快。但这恰恰说明一个核心问题AI目前更像一个“写代码很快但需要别人告诉它哪里有坑”的工具而不是一个能自己把坑找出来的工程师。3.2 实测任务二排查一个偶现白屏问题第二个场景我选了一个特别磨人的问题某后台系统里用户反馈偶尔打开某个页面是白屏但刷新一次就能恢复。没有稳定的复现路径有时候一天遇到一两次有时候好几天不出现。我把这个现象描述给AI问它的排查思路。它给了一个非常标准的排查清单看控制台报错、检查接口返回、检查静态资源加载、看路由配置、看是否有JS异常、看是不是某些浏览器兼容性问题……都很对但没有任何一样能直接解决我的问题。真实的排查过程是另一种画风。我当时的记录大致是这样的先看了线上错误日志抓到一个疑似压缩后的报错信息指向某个组件里调用了一个异步方法。但这个组件在正常路径下不会执行到这里说明某个前置条件异常触发了这段代码。继续追下去发现是某个第三方统计脚本在特定环境下初始化顺序不对导致全局对象上挂载的方法被覆盖组件里调用时拿到的是undefined。这个问题的根因依赖的是对代码执行时序的理解、对第三方脚本的了解、以及把日志里的线索和源码对应起来的能力。AI能不能通过我给的报错信息往这个方向猜也许能。但前提是我得先把关键线索提炼出来喂给它。换句话说AI在做的是“顺着人给出的线索做推演”线索断了它也就停了。而一个前端工程师的价值恰恰在于能从一堆看似无关的现象里找到那条线索。3.3 实测任务三重构一段“能跑但没人敢动”的页面代码老项目里最痛苦的部分不是写新代码而是改旧代码。我挑了一段真实的Page代码一个方法里塞了二十几行逻辑更新筛选状态、校验两个输入的依赖关系、触发一次埋点、更新三个组件的显示状态、手动改两个全局变量的值。这段代码的特点是“没有文档、没有测试、改一点就可能影响别处”。AI接到这个任务后第一步是把代码内容做了函数拆分然后很规整地抽了几个子函数出来。代码结构确实变好了但它不知道的是这段代码里某些逻辑之间存在隐藏的执行顺序依赖比如其中一个全局变量必须在特定分支下先被赋值另一个组件才能正确渲染。AI拆分之后把某个赋值动作挪到了一个看起来更合理的函数尾部表面逻辑没变实际运行顺序变了。这个风险AI自己是完全感知不到的因为它只看到了局部代码没看到整条执行链路。这个例子给我的启发是重构不是语法题是系统题。牵一发而动全身的前提是你得知道哪里连着什么。AI可以帮人把“物体表面”清理干净但哪些“线”不能碰还是只有实际在这个系统里摸爬滚打过的人才知道。4. AI回答里漏掉的东西恰恰是前端护城河4.1 上下文理解它只看到了文档没看到人AI可以读懂你贴给它的代码片段可以理解一段详细的接口文档但它很难理解“这个页面是给谁用的”“这个按钮为什么必须放在这里”“产品经理为什么坚持要这个交互”这些语境。需求文档写下来的只是决策的结果那些没有写下来的讨论过程、妥协理由、历史包袱才是一个项目的真实脉络。举一个很常见的例子某个页面当时之所以用强制同步加载是因为业务上要求必须第一时间展示某个数据模块不能有白屏等待。后来新人接手觉得异步加载性能更好改完之后首屏是快了但那个数据模块的曝光时机变了数据报告就不准了。负责的人可能被叫去解释了半天。这种“代码之外的约束”AI是不会自动感知到的只有当人明确告诉它“这里不能异步”它才会照着做。所以上下文理解的本质不是“能不能理解一句话”而是“能不能理解一句话背后没有被说出来的那一堆背景”。这堆背景存在于会议纪要里、聊天记录里、发布评审里甚至在一个人的脑子里。指望一个模型把这些东西全自动串起来还差得很远。4.2 决策与责任代码写错可以改方案定错要背锅前端工程师的日常不只是把功能做出来还要在各种维度之间做取舍开发周期紧是先用一个临时方案顶上还是硬憋一个更彻底的方案团队里几个产品同时提需求先做哪个后做哪个某个老技术方案大家都知道该换但换了成本高风险大是保持现状还是推进升级这些问题没有标准答案全看当时的目标和资源约束。AI也许可以帮你分析每种方案的优缺点但最终选哪个、为什么选这个、出了事谁来解释都得人自己扛。这套“决策-责任”机制是职场和社会运行的基础规则AI作为一个工具不可能替代人去承担这个角色。4.3 “幻觉”在代码里的真实面目一本正经地错最后聊聊AI在代码场景里的“一本正经地错”。不是说你给它一个需求它会编一个不存在的API给你——这种情况现在并不多了——更多时候是它会在你“不知道要往哪个方向想”的地方犯错。典型的例子就是老的依赖版本。某个项目里还在用一个旧版本的UI组件库它的某个API和最新版本行为不同。AI经过大量训练之后默认给你的是新版本的用法编译不报错但运行时行为和你预期的完全不一样。你如果对旧版本不熟就会在错误的思路上浪费很长时间。另一个例子是边界情况。AI写一段遍历逻辑通常只覆盖最常见的路径空数组、null字段、并发请求重复提交这些情况它经常只会敷衍地加一个判断甚至不加。如果你不主动追问“这里如果用户重复点击怎么办”它的代码就是有漏洞的。这就是为什么我一直强调AI写代码需要人做代码评审相当于开车需要一个驾驶员AI是个很快的副驾驶路况复杂的时候需要人接管方向盘。5. 不同阶段前端工程师的真实处境5.1 初级工程师效率红利与“伪熟练”陷阱对于刚入行的初级工程师AI带来的帮助和危险同样明显。帮助是可以少走很多弯路不熟悉某个API直接问AI不太确定某个写法是否合适可以让AI给一个对比方案。相当于身边多了一个随时在线的老师而且这个老师不嫌你烦。危险则在于“伪熟练”。很多人开始依赖AI直接生成代码需求来了复制粘贴跑通了就算完事。这样做了半年能应对日常开发但一旦要排查复杂问题、做系统设计就会露馅。身体里没有一个牢固的知识体系只能靠AI的答案拼凑这种状态很脆弱。所以我给初级工程师的建议很朴素AI给的东西一定要自己读一遍、理解一遍、在其中至少找一个可以优化的点。你可以不用自己从头写但必须知道每行代码为什么这么写。5.2 中级工程师从“写代码”到“评方案”到了中级工程师这个阶段核心工作会发生一次明显转变从“把需求做成代码”到“评审和决策”。这时候日常工作不再是别人把需求定义好、你只管实现而是要参与方案讨论要给出技术选型建议要评估一个改动的影响范围。这个阶段AI反而是最好的“助理”。写一版实现不需要从零开始AI可以给你一个基础盘你要做的是把自己的系统知识、业务约束、团队规范加进去。换句话说AI把“从无到有”的成本降到很低真正拉开差距的是“判断这段产出是否靠谱”的能力。这需要你对框架原理、浏览器机制、网络协议、数据结构有足够深的理解。这些不是能靠提示词解决的。5.3 高级工程师系统设计与跨端经验没法速成高阶前端工程师的价值往往不在代码量而在于能跨多个端去设计一整套方案知道在什么场景下该用什么样的架构能预判一个看似简单的需求背后隐藏的复杂依赖。这些能力需要大量的项目积累靠的是在真实环境里踩坑、复盘、再踩坑养成的直觉。AI可以帮你写代码、解释报错、提供优化建议但它没法替你经历那些项目的完整生命周期。一个人的判断力是长在一次又一次“上线出问题、复盘、下次避免”的循环里的。这种经验没法被压缩成几段提示词也不会因为模型能力变强而自动转移给模型。6. 把AI变成杠杆前端工程师的四个升级方向与其继续焦虑“AI会不会取代我”不如换个角度它来了我怎么利用它让自己更值钱。基于前面的实测我觉得下面四个方向是当前最值得投入精力的。第一深化某一垂直领域。跨端、性能优化、数据可视化、低代码平台、编辑器、音视频处理这些方向都既有深度又有门槛不是简单让AI生成几段代码就能搞定的。选一个深耕下去你会发现自己和AI之间的距离在持续拉开。第二练就“评审AI产出”的能力。给AI设定一个角色让它产出一段包含组件拆分的方案然后你要能判断这个方案里的组件边界是否合理、会不会导致不必要的重渲染、异步逻辑放在了什么地方、异常处理是否完整。我之前做过一个简单自查表组件职责单一吗状态变更路径清晰吗内存清理逻辑有没有边界条件覆盖了吗可访问性有没有被忽略这套东西AI自己不会做要人来推动。第三把AI当作一个“快速迭代想法的沙盒”。写代码之前先让AI产出几种不同的方案雏形你基于自己的经验和业务约束来筛选。这就像让团队里多了四个可以随时喊来开头脑风暴会的人不怕得罪人、没有废话、随叫随到。不过你仍然是那个做决定的人。第四也是最容易被忽视的一点提升沟通和项目管理能力。前端工程师越往后走越需要跟产品、设计、后端、运营、测试反复对齐。AI再强大它也没办法替你坐在评审会上跟产品经理争论一个交互改动的合理性。这些软技能到了AI时代反而更重要因为技术实现的门槛在被压低而“把一件事推动落地”的能力依然稀缺。能力方向为什么难被替代怎么练垂直领域深度AI能写通用代码但复杂场景要靠真实项目经验选一个有门槛的方向系统性项目实践评审与决策AI产出需要人来判断可用性和优先级做代码评审时多追问“为什么不这样写”跨端与性能经验真机验证、异常分布、兼容性表现无法从文本里凭空得出多部署、多真机测试、沉淀问题案例库沟通与项目管理协调冲突、对齐预期是人与人的互动无法模型化主动参与评审会、需求评审、复盘会我自己的体会是AI出现之后前端工程师的门槛没有消失只是从“能不能写出来”变成了“知不知道为什么这么写”。工具可以越来越顺手但那个握着工具往前走的工程师才是最终对结果负责的人。下一次再有人告诉你“AI要取代前端了”你大可以请他把你的真实项目需求发给AI再让AI在那堆历史代码和隐藏约束里完成任务。我试过了——它没那么神但它确实是个好帮手关键是你要知道怎么用好它。