1. 简历里写着“AI提效”的人我首先看什么这半年我们前端团队扩招前后我面了三十来个候选人投高级前端岗位的简历里十有八九会提到“AI提效”。有的写得很克制附带了场景和结果有的写得很玄幻比如“借助AI提升开发效率50%”问到他具体是怎么提效的他自己都圆不上。所以我今天想聊一个非常实操的问题当简历里的AI提效成为标配作为负责考核的技术面试官我会怎么面这个人。先说结论我不会因为候选人写了“AI提效”就直接加分也不会因为他没写就看低一眼。我会把它当成一个必须被验证的假设。验证的起点不是面试现场而是看简历的十分钟里我能不能从中找出三个信号场景具体、量化可信、限制明确。这三个信号几乎能筛掉一半的“AI口头党”。1.1 为什么“AI提效”成了高级前端的默认标签AI辅助编程这件事本身已经常态化。GitHub Copilot、Cursor、Claude加上各类IDE插件写代码的方式确实变了。哪怕是一个两三年的前端也很容易在自己的工作流里加入AI工具。问题是“会用AI”和“用AI做工程”是两码事前者是技能后者是方法论。当“会用AI”成为高级前端简历的标配时它对岗位筛选的意义已经很低了。我见过不少候选人简历上写着“熟练使用AI工具提效”但细问起来大部分场景其实是“让AI帮我写一个函数然后我复制粘贴”。这不叫提效这叫换一种方式搜索代码。真正的高级前端应该知道AI什么时候能帮他省时间什么时候会让他花更多时间比如审查生成结果、修复边界条件、处理团队协作里那些工具看不到的上下文。如果一个人只强调“用AI很快”却讲不清楚“快在哪里、代价是什么”那他大概率只是在追热点。所以我的第一关其实是“如何写AI提效”。这个写法本身就在透露候选人的思考深度而不是干活深度。1.2 我在简历里找的三个关键信号先说我最喜欢的写法。有个候选人写的是“在后台管理系统中沉淀了一套基于AI的CRUD页面生成流程把重复性页面的交付周期从两天缩短到半天同时建立了生成代码的review checklist上线后没有因为生成代码引入过严重事故。”这段话我看了很久因为它同时给了场景、量化结果和工程化控制手段。反过来我最反感的写法是通篇都是“借助大语言模型辅助开发”“大幅提高编码效率”“熟悉AI时代的前端工作流”但没有一个具体的项目名、模块名、量化口径。这类描述放在高级前端简历里面试官基本无法追问因为它不是一条可以回溯的证据链更多是一种姿态表达。我自己的筛选标准可以拆成三点场景具体候选人能不能说出“我在哪条业务线、哪个功能模块里用了AI帮了什么忙”如果不能说明他可能只是在自己练习项目里玩过。量化可信效率提升有没有单位有没有对比口径“从两天到半天”是一个可信口径“效率提升50%”是不可验证的口径因为没人知道基线是什么。限制明确候选人是否愿意承认AI不可用的场景比如“AI生成代码在复杂状态流转下不可控所以我们规定核心交易流程不允许直接用生成代码”。愿意写限制条件的人通常真的和AI协作过知道它的边界在哪。我还会特别关注一个细节候选人写的是“我用了AI”还是“我们团队沉淀了AI使用规范”。后者意味着他有团队视角不是自己在工位上偷偷玩模型。高级前端岗位需要的不只是个人产出还有带人、建流程、定规范的能力。哪怕他只是在一个小项目里尝试了一套prompt模板这件事背后体现的工程组织意识比“我会用AI”值钱得多。2. 第一道题让候选人“治理”一段AI生成的代码简历看完之后我会安排一轮技术面试。这一轮里有一个保留环节我把它叫作“垃圾代码治理”。流程很简单我会给候选人一段标注为“同事用AI生成的商品列表页面”的React组件不要求他从零写功能而是先做代码评审再挑一个最关键问题重构。限时三十分钟。这道题几乎不走样地测出一个人的真实水平因为它模拟了AI进入日常开发后最常见的场景你拿到一段看起来能跑、但到处是坑的代码你的第一反应是什么你准备怎么改。2.1 我设计的“垃圾代码”样例长什么样这个组件不算太长大概一百多行功能是一个带搜索框的商品列表支持分页可以点击添加购物车。代码风格看起来很像AI默认输出整齐、注释少、变量命名还算清楚但在核心数据流上埋了好几个雷数据请求写在useEffect里依赖数组只填了[query]但请求函数内部还依赖page和size导致翻页时闭包读到的是旧值。搜索框的输入直接驱动请求完全没有防抖用户每按一个键就发一次请求。请求返回后没有做卸载保护组件已经切走时仍然会在回调里调用setState产生警告不说严重时会造成内存浪费。列表item的key直接用了index增删排序时表现不可控。购物车是一个全局Context每次添加商品都往同一个数组里push导致整个页面树重渲染。这些代码在本地跑起来没有任何语法错误demo状态下甚至不会暴露问题但只要接上真实接口、数据量上来立刻就会变成线上事故。我故意选择这些“AI常犯的错”因为AI生成代码最典型的特征就是主流程正确、边界处理缺失。候选人能不能看出这层问题直接反映他有没有真正对AI产出负责。2.2 候选人拿到题目后的三种表现根据我面的三十多个人这道题的表现基本可以分成三类。第一类是逐行解释型。他会从头到尾跟我讲这段代码做了什么然后指出一些表面的命名问题、重复代码甚至会把一些不是问题的地方当成问题。比如有人会纠结“addToCart这个命名不够语义化”但他没有注意到请求竞态。这类候选人大概率把AI当成搜索引擎看到一段代码出来之后只会“用”不会“盘”。你可能觉得他代码写得还挺认真但一个看不懂数据流的人在高级岗位上是没法承担核心模块维护责任的。第二类是动手狂改型。他能识别出一部分真正的问题比如“依赖数组不对”“没有防抖”但一上来就摊开重写。你问他先改哪个、为什么他答不上来。这类候选人执行力很好问题在于缺乏优先级判断。在真实团队里这种“看到问题就冲”的风格很危险因为AI生成代码堆积起来的债务往往不是一个下午能还清的必须按风险排序、分步处理。第三类是我期待看到的表现。他会先沉默一会儿然后给我一个清单第一个要修的是卸载后setState和请求竞态因为这会直接导致数据错误第二个是搜索防抖它影响体验key和Context属于维护性问题可以放到下一轮迭代。他还会补一句“这个组件如果只是demo线上不会有问题但接真实接口后前两个是必现的。”这句话一出来我已经知道他具备高级工程师的审核意识。2.3 这道题真正的评分逻辑评分不看他改了多少行代码而是看他有没有在动手之前完成“问题分类”和“风险排序”。我会专门追问一句“这里面哪个问题是AI造成的哪个问题是你认为原本设计就复杂、AI只是放大了复杂度”这个问题很关键。把责任全部推给AI的候选人说明他对工具的理解还停留在“工具背锅”的阶段没有意识到AI只是放大器——一段本来就乱的状态管理设计无论谁写都会出问题。我更看重另一个动作候选人能不能把“人工检查清单”和“AI生成代码”结合起来。比如他会说“以后团队里如果允许用AI生成这种列表页我会在review时强制检查请求取消、依赖数组、key、错误边界。这几条是AI最容易漏掉的。”这种表述说明他已经在脑海里建立一个“AI产出质检流程”。AI能帮团队把重复代码赶出来但最终守住质量入口的还是这个能列清单的人。所以这道题考的与其说是React基础不如说考的是“对AI产出的治理能力”。高级前端在AI时代的第一职责不是写更多代码而是确保AI写的那些代码不会成为系统的定时炸弹。3. 现场实战AI辅助实现一个前端需求我全程在看哪些细节光靠代码评审还不够我会再加一轮现场实战。这轮实战的环境非常明确给候选人一个接口文档、一个移动端页面需求、一个可用的AI对话工具限时九十分钟。需求是做一个带搜索防抖、分页、请求取消和骨架屏的商品列表页接口文档给了字段但没有给现成的封装。有人会问面试允许用AI题目难度会不会名存实亡恰恰相反一旦允许AI工具自由使用我反而能看到更多真实工作习惯。过去我们看一个人编码能力强弱只能看他键盘上敲多少代码现在AI能代写大部分代码我看的是他在AI辅助之下能不能保持工程可控性。3.1 限定条件下的实战题设计这个题我故意不要求“从零手写”因为现实世界的开发也不鼓励重复造轮子。候选人可以打开AI工具让它生成部分代码也可以先写一个粗糙版本再用AI做代码Review。时间限制也比较宽松九十分钟足够完成一个完整功能页面。关键设计在于我把AI工具放在明面上这样候选人不会因为“怕被当成作弊”而隐藏真实工作流。他一旦拿到AI生成结果后续一连串行为就完全暴露了他是直接复制粘贴还是先读懂再改他遇到报错是贴回去让AI改还是先用自己脑子定位问题他在拿到需求之后是先花两分钟拆解成几个子任务还是原封不动把整个需求扔给AI这道题的核心不是看他最后能不能跑通页面而是看他在AI辅助下的协作姿态。3.2 重点观察环节提示词、上下文、报错处理我会用三个环节来判断。第一是需求拆解。高级候选人拿到题目后通常会先动手梳理接口字段标注出哪些数据是可空、哪些需要兜底状态然后才决定让AI生成哪一部分。他会把需求拆成几个小块比如“先帮我生成一个带loading状态的商品卡片组件”“再帮我写一个带防抖的搜索逻辑”。这种拆解动作说明他知道AI擅长处理局部任务而不是一次性把整个页面交出去。第二是代码校验。AI生成完代码之后他不会立刻用而是先看关键函数。我记得一个很好的候选人他让AI生成了请求函数自己读了一遍然后问了我一句“这个接口的分页参数是page还是pageNum”说明他没有把AI当权威他拿回来的是一个待审的PR不是一个神圣答案。第三是报错处理。观察他在报错后怎么调整提示词很重要。糟糕的表现是同一个报错贴三遍只改一点措辞然后反复试。这样的候选人没有debug框架他的思路完全是“AI应该替我解决问题”。好的表现是他会自己打开浏览器控制台定位到报错行判断是接口数据格式问题还是渲染问题然后告诉AI“这个字段可能是字符串帮我处理一下空值”。报错处理的过程最能看出一名工程师是否具备独立解决问题的肌肉记忆。3.3 优秀与危险信号对照表我把这道题的观察维度整理成一个表方便团队里其他面试官复用也方便候选人对照自测观察环节加分表现危险表现需求拆解先列接口字段、边界状态分步生成把整段需求直接复制给AI代码生成分模块让AI生成逐段校验一次性要完整页面复制粘贴就跑校验结果会主动检查请求、loading、空状态只验证主流程可点击不关心异常报错处理先定位到报错行再修正prompt重试同一报错连续重贴不读浏览器日志事后表达能清楚地讲出生成代码的逻辑与取舍说不清核心函数怎么工作这张表之所以好用是因为每一条都不是“能力高低”的直接评价而是“工作流是否成熟”的外在表现。AI时代的高级工程师工作流必然包含对工具的驾驭、质疑和校验。要是我在实战里看到一个人全程独自敲代码、完全不用AI我也不会觉得他很牛只会觉得他不适合我们的协作方式反过来如果一个人全程把AI当拐杖连报错都不自己看那他就算写出了页面我也不敢把生产环境交给他。4. 剥离AI外壳后基础能力怎么追问面试进入最后一个环节我会把AI从场景里剥出去开始追问基础。为什么一定要剥因为简历里大谈AI提效的人很容易让人误以为他已经站稳了高级岗位的技术底盘。但AI工具在基础知识这件事上有巨大的迷惑性——它能替人写出看起来正确的代码却代替不了人对代码背后机制的理解。高级前端在关键时刻要能解释、能排障、能兜底这三件事都依赖扎实的基础能力。我不喜欢用“你知道React diff算法吗”这种背概念题来考人。我更喜欢拿着刚才实战代码或者代码评审题里的一段内容顺着追问让他为自己的决策辩护。4.1 渲染与性能不允许“背答案”要现场推演我会拿刚才的商品列表页继续问“如果这个页面数据量到三千条之后滚动开始卡顿你第一个排查的是什么环节”很多人会回答“用useMemo优化”。这个回答本身没错但我要听的是推演过程他知不知道卡顿可能来自渲染次数过多、列表没有虚拟滚动、图片请求没有懒加载、还是父组件的状态变化影响了整个列表一名高级前端应该能画出一条排查链路比如先打开性能面板看Long Task再看Network请求再看组件渲染日志。我更会接着追问另一件事“AI写代码时经常在每个函数外面套useMemo和useCallback你觉得这对吗”这个问题很容易暴露认知深浅。低级答案是“大家都这样写应该是对的”。高级答案则是“useMemo不是免费的它有自己的内存占用。只有计算成本高、依赖稳定的地方才值得用。如果只是给一个简单数组做map增加useMemo反而增加阅读成本。”能聊到这个层面的人说明他真的懂渲染性能不是背了几个API名词。4.2 状态管理与前端架构为什么引入某个库另一个必问点是状态管理。候选人如果在简历里提到“引入AI辅助技术选型”我会很好奇地问他“AI建议你使用Redux Toolkit你凭什么判断这个建议适合你的项目”我要听的不是“因为redux很流行”而是他要能自己说出决策依据项目有没有跨页面共享的复杂状态有没有团队维护成本上的考虑有没有替代方案比如Zustand、Jotai或者直接用Context有一次面试里一个候选人给出了很清晰的拆解“商城项目有三个模块需要共享用户信息、购物车、订单状态跨页面通信频繁而且团队有五六个人维护引入Redux Toolkit是为了调试工具和可预测性。但如果只是做一个展示型站点我不会上全局状态库AI的建议我会听一半。”这段话信息量很大他懂业务体量与方案的匹配关系能独立思考AI的建议也知道为团队规模考虑。4.3 “如果没有AI你会怎么完成”是灵魂拷问这一阶段我会直接抛出一个近乎残忍的问题“假设现在没有AI工具也没有代码补全插件你要怎么完成刚才那道搜索页”这个问题听上去像废话但它能非常准确地把候选人的知识边界挖出来。一种危险回答是“那我就不知道怎么做了平时我都是先让AI生成再改一改。”这种回答等于直白地告诉我他没有真正理解自己负责的项目。代码生成工具可以替代手指打字但不能替代大脑里的设计图纸。一个高级前端如果没有AI就不能完成基本的前端任务那他在面对AI输出错误、工具失效、生产事故时连兜底的方向都没有。另一种回答是“我会从之前组件库里找一个列表模板再手写一个useDebounce封装接口请求部分其实不用AI我一样能写。”我听的不是手写速度而是他有没有属于自己的实现路径。AI提效的前提是人有方案兜底。只要候选人有兜底方案AI对他而言才是放大器而不是假肢。5. 聊“成本与权衡”高级候选人和普通候选人最明显的分水岭有一类问题我一般放在面试最后看起来像是随口聊天其实是我最在意的部分。我问的内容很直接“项目里哪个环节最适合用AI哪个环节你坚决不用你有没有因为AI生成代码引入过线上问题复盘之后你改变了什么”这三连问几乎能把候选人的“AI观”完整地逼出来。普通的回答是“我觉得AI都很适合我很信任它”。高级的回答往往带着一个关键词——成本。5.1 我在面试中得到的几个值得记住的回答有一次面试一个候选人提到他绝不用AI直接生成涉及权限判断和支付状态的代码。他说“因为这类代码最容易表面正确。权限边界一旦出错不是代码质量的问题是事故。AI可以帮我生成表单、列表、布局这些偏展示的部分但涉及金额计算、权限流转、订单状态迁移我会手写核心逻辑再让AI帮我做review补充。”这段话让我当场就觉得这个人非常清醒他知道AI在哪一个层面可以进入生产环境。另外一场面试里候选人讲了一个真实事故“我们用AI生成了一批表单组件当时跑得很顺利上线两周后有人反馈某个可编辑表格在连续操作之后会出现保存成功提示但数据没有真正提交。后来定位发现是AI生成的代码没有处理提交中的竞态。”他没有把锅甩给AI而是说“后来我们规定所有AI生成的代码必须经过同事交叉review才能在主干合并。”这个反思过程非常关键。他不是承诺“我再也不用AI了”而是建立了一个防范机制。反面的常见回答是“我觉得AI比人靠谱它有大量训练数据出错的概率更低”。这种回答不是完全错但它暴露出候选人没有亲身经历过“AI自信地给你一段错误代码”的时刻。只要在真实项目里用过AI辅助写代码的人一定被那种流畅但错误的产物坑过。如果一个人到现在还没有成本意识说明他要么没有真正在复杂项目里用AI要么从来没有仔细审查过AI的输出。5.2 简历里如何描述AI提效才算不惹人反感聊天聊到这里我会回到简历这件事。因为大部分候选人以为简历里写“AI提效”等于“我很前沿”但面试官真正想看的是“你在AI协作中学会了什么”。我建议候选人这样写不要写“熟练使用AI编程工具提高开发效率。”可以写“在三个后台项目中用AI生成重复表单与列表代码减少约40%的模板工作量同时定义了一套AI输出审查规范重点检查请求竞态、异常处理与可访问性。”前一种写法是感受后一种写法是证据。前者是“我用了AI所以我很行”后者是“我在AI带来的效率之外同样付出了工程管理上的思考”。高级前端岗位的面试官每天面对几十份简历对“效率提升50%”这类话已经有了免疫力。他们真正想看到的是一个候选人有没有能力把AI引入团队同时不破坏代码质量和业务稳定性。我也会特别告诉候选人一个反向技巧在简历里主动写一句“AI目前无法替代我做什么”。比如“复杂状态机的流转设计、跨团队接口冲突的协调、以及涉及用户数据安全的策略仍然需要我深度介入”。这句话一下就让人知道你清楚AI的边界而不是把它当成万能答案。6. 这类面试里我愿意发Offer的人长什么样面到这里基本可以形成判断了。我发Offer的人通常不是AI用得最炫的人也不是简历里“提效”百分比最高的人而是那些让我确信“AI在他手里是一个放大器不是一颗拐杖”的人。6.1 五个可复用的判断特征我复盘下来这类候选人通常具备五个特征有信任梯度。他脑海里有一张清单知道哪些任务可以完全交给AI哪些需要人工复核哪些坚决不能碰。这张清单不是别人教给他的是他自己在项目里摔过跤总结出来的。能把AI的建议翻译成自己的观点。他不会张嘴说“AI说要这么写”而是会讲“我为什么认同这个方案”。哪怕这个方案最初来自AI他也能用自己的语言解释一遍这说明他理解了背后的逻辑。对边界不无感。他会主动聊到AI生成代码在错误处理、安全性、可访问性上的不足而不是只夸AI效率高。有团队意识。他不只自己用AI还能沉淀prompt、写review清单、帮团队建立AI使用规范。基础能力兜底。哪怕我把AI完全拿走他依然能给出一个可落地的技术方案。他的技能树没有寄托在具体工具上。6.2 给面试官和候选人的最后建议对面试官同行我想说不要把“AI提效”当成一个撒谎标记看见就本能地降低印象分也不要因为候选人说“会用AI”就高看。你要做的是把它当作一个中性话题沿着具体的项目细节往下挖挖到场景、工具、产出、成本、反思答案自然就出来了。真正的问题是候选人有没有独立解决问题的能力而不是他有没有用过AI。对候选人我会给一个非常实际的建议在简历里提“AI提效”之前先问自己三个问题。第一你到底在哪个具体环节提效了第二这个效率有没有可验证的产出比如交付周期、代码量、线上事故率第三如果明天AI全部不可用你还能不能做这份工作这三个问题想清楚了简历上写什么都会更有底气。这几年面下来我越来越觉得“AI提效”这个词会像当年的“面向对象经验”一样逐渐变成一种默认能力。真正有区分度的不是你会不会用AI而是你有没有驾驭AI的判断力。高级前端在AI时代最值钱的能力永远不是打字速度而是判断一段看似完美的生成代码里藏了多少边界漏洞以及知道什么时候该听AI的、什么时候该关掉AI。如果你也想把AI提效写进简历我建议你先写出一个具体到能让人追问的“证据时刻”比如“我曾从AI生成的代码里抓出一个请求竞态bug”。一个真实的项目故事比一百句“效率提升50%”都有说服力。