1. 面试间里的割裂感当简历上写满“AI 协作”却写不出一段冒泡排序过去大半年我陆陆续续面了三十多个 2025 届之后的应届生岗位从后端开发到 Agent 应用工程都有。面试流程基本固定先聊项目再写一道中等难度的算法题最后针对他们简历上写的技术栈做深挖。但最近这几个月我明显感觉到一种割裂感——简历上项目经历写得花团锦簇什么“基于大模型的智能体编排”“多 Agent 协作完成复杂任务”“用 Cursor 从零搭建全栈应用”关键词密度高得吓人可一旦让他们脱离 AI 工具、在白板上手写一段最基础的逻辑场面就变得非常尴尬。有个候选人让我印象特别深。简历上写着“独立开发了一个基于 Agent 的自动化代码审查系统”我让他讲讲这个系统的核心调度逻辑是怎么设计的他支支吾吾半天最后说“就是让 AI 自己规划步骤然后调用工具”。我追问“那如果两个 Agent 同时修改同一个文件你怎么处理冲突”他愣了一下说“这个……AI 应该会自己处理吧”。我又问“你项目里用的 Agent 框架是哪个它的执行循环是怎么实现的”他回答“我用的是 Cursor 的 Agent 模式具体底层我不太清楚。”这不是个例。我面过的这批人里超过一半的简历都提到了 Vibe Coding 相关的工具——Cursor、Windsurf、VS Code Copilot、Trae还有各种 Agent 框架。他们能熟练地描述“怎么用自然语言让 AI 生成一个 React 组件”能说出“提示词要写得具体一点”但当你问到“这个组件为什么用 useEffect 而不是 useMemo”“你写的这个 Agent 工具调用链如果某个工具返回了非预期格式你的容错逻辑在哪”他们往往就卡住了。我并不是要否定 AI 编程工具的价值。我自己每天都在用 Cursor 和 Copilot它们确实把很多重复性工作的效率提升了不止一个档次。但问题在于当“会用 AI 写代码”变成一种可以写在简历上的核心竞争力而底层的基本功却被大面积跳过时一种危险的“虚假繁荣”就出现了——候选人看起来什么都能做实际上什么都做不深。这篇文章我想从面试官的视角拆解这种虚假繁荣是怎么形成的、它在实际工作中会暴露哪些问题以及如果你正在这条路上该怎么把自己从“AI 操作员”变成真正的工程师。2. Vibe Coding 的甜蜜陷阱为什么“能跑就行”正在毁掉基本功2.1 从“写代码”到“描述代码”的范式转移Vibe Coding 这个概念最早出圈的时候核心主张是“你只需要描述你想要什么AI 负责把它变成代码”。这个理念本身没有问题它确实降低了编程的门槛让更多人可以快速把想法变成可运行的原型。但问题在于很多应届生把这个理念当成了学习的终点而不是起点。我观察到一个很典型的学习路径一个学生想做一个个人博客以前他需要学 HTML、CSS、JavaScript理解 DOM 操作、事件循环、HTTP 请求可能要花一两个月才能做出一个像样的东西。现在他打开 Cursor输入“帮我做一个个人博客要有文章列表、详情页、暗色模式”十分钟后一个能跑的页面就出来了。他觉得很爽觉得自己“学会了全栈开发”。然后他把这个项目写进简历面试的时候被问到“你这个博客的 SEO 怎么做的”“首屏加载时间是多少”“有没有做服务端渲染”他就答不上来了。这里的关键区别在于以前的学习路径是“遇到问题—理解原理—解决问题”现在的路径变成了“描述需求—获得代码—运行通过”。中间那个“理解原理”的环节被跳过了。而恰恰是这个环节才是一个工程师真正成长的地方。2.2 面试中暴露的三个典型断层我把这几个月面试中遇到的情况做了个归类发现断层主要集中在三个地方。第一个断层是调试能力。AI 生成的代码不是永远正确的尤其是当项目复杂度上升之后各种边界情况、依赖冲突、环境差异都会导致问题。但很多候选人遇到报错的第一反应不是去读错误信息、定位问题而是把错误信息复制粘贴回给 AI让 AI 再生成一版。如果 AI 连续几次都没解决他们就束手无策了。我遇到过一个候选人项目里有一个空指针异常他花了两个小时跟 AI 来回对话都没修好最后是我提示他“你看看这个变量在什么情况下会是 null”他才恍然大悟。第二个断层是代码阅读能力。AI 生成的代码往往用了很多他们不熟悉的语法糖、设计模式、第三方库。能跑通不代表能维护。我让一个候选人解释他项目里的一段代码那段代码用了Promise.allSettled和Array.prototype.reduce的组合他看了半天说“这是 AI 写的我知道它能把数据处理好但具体怎么实现的我不太清楚”。这种代码如果出了问题他根本无从下手。第三个断层是系统设计能力。AI 擅长生成单个函数、单个组件但一个完整的系统需要考虑模块划分、数据流、错误处理、性能瓶颈、扩展性。这些是 AI 目前很难替你做的。我让一个候选人设计一个短链接服务他第一反应是“我让 AI 生成一个”然后就开始描述“需要一个生成短码的接口、一个跳转的接口”。我追问“短码怎么保证唯一高并发下怎么避免冲突存储用关系型数据库还是 KV过期策略怎么设计”他就答不上来了。这些问题的答案AI 不会主动告诉你因为你的提示词里没写。2.3 “虚假繁荣”的本质工具能力被误认为个人能力为什么会出现这种情况我觉得核心原因是工具能力被误认为个人能力。一个熟练的 Vibe Coding 使用者确实可以用 AI 快速搭建出一个看起来不错的项目。这个项目能跑、有界面、有基本功能甚至能部署上线。从外部看这个人“会做项目”。但面试官要考察的不是“你能不能做出一个东西”而是“当这个东西出问题的时候你能不能搞定”。这两者之间的差距就像一个人用导航开车和自己认路开车的区别。用导航的时候你不需要知道这条路为什么这么走、哪个路口容易堵、如果前方事故了该怎么绕。但如果你要去一个导航没有收录的地方或者导航把你带到了死胡同你就懵了。AI 编程工具就是那个导航它很好用但它不能替代你对路况的理解。更麻烦的是这种虚假繁荣有很强的自我强化效应。候选人用 AI 做出了项目拿到了面试机会面试中聊项目聊得头头是道因为项目确实是他“做”的如果面试官只停留在“你做了什么”的层面他就能过关。入职之后如果团队里有资深工程师兜底他也能混下去。但一旦遇到需要独立排查的线上问题、需要从零设计的新模块、需要权衡取舍的技术选型他就会暴露。3. 拆解一个真实面试案例从“Agent 项目”到“说不清执行循环”3.1 候选人的项目描述与我的追问路径让我把其中一个案例完整拆开来讲这样你能更清楚地看到问题出在哪。候选人 A某 211 计算机相关专业硕士简历上写了两个项目一个是“基于多 Agent 协作的智能客服系统”一个是“用 Cursor 开发的低代码平台”。技术栈写了 Python、LangChain、AutoGen、React、FastAPI。我问他第一个项目“你这个多 Agent 系统里有几个 Agent各自负责什么”他回答“有三个一个负责理解用户意图一个负责查询知识库一个负责生成回复。”我问“它们之间怎么通信是共享内存还是消息传递”他回答“就是……前一个 Agent 的输出传给下一个 Agent。”我问“那如果知识库查询 Agent 返回了空结果生成回复的 Agent 怎么处理”他回答“这个……我让 AI 加了一个判断如果为空就返回‘抱歉没找到’。”我问“这个判断是在哪个环节加的是 Agent 内部的逻辑还是编排层的逻辑”他沉默了一会儿说“应该是编排层吧我不太确定代码是 AI 写的。”到这里我已经基本能判断出他的水平了。他知道这个系统“大概是怎么工作的”但不知道“具体是怎么实现的”。他能描述数据流动的方向但说不清每个环节的边界条件和异常处理。3.2 为什么“让 AI 写”和“自己会写”之间有巨大鸿沟这个案例很典型。候选人 A 的问题不是他用了 AI而是他把 AI 当成了黑盒。他给 AI 一个需求AI 给他一个实现他运行通过就认为完成了。他没有去读 AI 生成的代码没有去理解每个模块的职责边界没有去思考异常情况怎么处理。这里面的鸿沟在于AI 生成的代码是基于概率的它给你的是一个“看起来合理”的实现而不是一个“经过验证”的实现。它可能用了某个库的某个方法这个方法在当前版本下能用但下个版本就废弃了它可能假设了某个输入永远不会为空但实际业务中就是会为空它可能把两个本来应该解耦的模块耦合在一起因为这样写起来更短。如果你自己会写你在看 AI 生成的代码时能快速判断“这里有问题”“这个写法不优雅”“这个边界没处理”。但如果你自己不会写你就只能看它“能不能跑”。能跑就行这是 Vibe Coding 最危险的心态。3.3 面试官视角的评分逻辑我们到底在考察什么站在面试官的角度我考察一个候选人核心看三件事。第一你能不能把一个问题拆解成可执行的步骤。这考察的是你的逻辑思维和工程思维。AI 可以帮你写代码但不能帮你拆解问题。如果你连“这个功能需要哪几个模块、模块之间怎么交互、数据怎么流转”都说不清楚那你就不具备独立开发的能力。第二你能不能判断代码的质量。这考察的是你的基本功。变量命名是否清晰、函数职责是否单一、错误处理是否完善、性能是否可接受这些判断需要你有足够的代码阅读量和写作经验。AI 生成的代码质量参差不齐你需要有能力去甄别和修改。第三你能不能在没有 AI 的情况下解决问题。这考察的是你的底层能力。面试中我经常会故意断网或者让候选人在白板上写伪代码。不是为了为难你而是因为实际工作中你总会遇到 AI 帮不上忙的时候——比如排查一个线上环境的诡异 bug、比如优化一个性能瓶颈、比如设计一个全新的架构。这些时候你能依靠的只有你自己的知识和经验。4. 虚假繁荣的代价入职之后会发生什么4.1 前三个月的“蜜月期”与之后的“暴露期”我观察过几个通过 Vibe Coding 路线进入团队的应届生他们的表现有一个很明显的曲线。前三个月是蜜月期。他们能用 AI 快速完成一些简单的需求比如加个接口、改个页面、修个样式。因为任务本身不难AI 生成的代码稍微改改就能用所以他们的产出看起来还不错。团队里如果有人带告诉他们“你去改这个文件”“你照着这个例子写”他们也能完成任务。但三个月之后问题开始暴露。任务难度上升了不再是“照着例子改”而是“从零实现一个模块”。这时候他们需要自己设计数据结构、自己划分函数职责、自己考虑异常处理。AI 能帮他们生成代码片段但没法帮他们做这些设计决策。他们开始频繁卡壳一个本来两天能完成的任务拖到一周还没搞定。代码 review 的时候资深工程师发现他们的代码里充满了“能跑但不对”的逻辑——比如没有处理并发、没有考虑事务、没有做输入校验。4.2 团队协作中的“隐形负债”更麻烦的是这些代码会成为团队的隐形负债。AI 生成的代码往往有一个特点局部看起来没问题全局看起来一团糟。因为它是一个函数一个函数生成的每个函数单独看都挺合理但放在一起就发现命名风格不统一、错误处理方式不一致、重复代码到处都是、模块之间耦合严重。我见过一个项目前端用 Cursor 生成了十几个组件每个组件里都有一份自己的数据请求逻辑有的用 fetch有的用 axios有的直接写在 useEffect 里有的封装了一个自定义 hook。结果就是当后端接口变了的时候需要改十几个地方而且很容易漏掉。这种代码维护起来比从头写一遍还累。4.3 对个人职业发展的长期影响从个人发展的角度看虚假繁荣最大的代价是时间窗口的浪费。应届生入职后的前两年是基本功成长最快的时期。这段时间如果你在踏踏实实地写代码、读代码、改 bug、做设计你的能力会有一个质的飞跃。但如果你把这段时间花在了“跟 AI 对话”上你的成长曲线会平缓很多。因为 AI 帮你跳过了那些让你痛苦的环节——调试、重构、优化——而这些环节恰恰是成长的关键。我并不是说不要用 AI。我是说你要把 AI 当成杠杆而不是拐杖。杠杆是放大你的能力拐杖是替代你的能力。如果你自己不会走给你一根拐杖你也能走但你的腿永远得不到锻炼。等你哪天需要跑的时候你就发现自己的腿已经退化了。5. 从“AI 操作员”到“真工程师”一条可落地的自救路线5.1 重新定义 AI 工具的使用姿势先自己想再让 AI 写如果你正在 Vibe Coding 的路上并且意识到自己可能陷入了虚假繁荣那第一步是改变使用 AI 工具的方式。具体怎么做很简单遇到一个需求先不要打开 AI。拿一张纸或者打开一个空白文档自己先想清楚这个功能需要哪几个步骤每个步骤的输入输出是什么有没有边界情况大概用什么数据结构想清楚之后再打开 AI把你的思路告诉它让它帮你生成代码。这样做的好处是你在用 AI 之前已经完成了一次完整的思考。AI 生成的代码你会带着“验证”的心态去看而不是“接受”的心态。你会发现很多时候 AI 生成的代码跟你想的不一样这时候你就要判断是它的写法更好还是你的思路更对这个判断的过程就是成长。5.2 刻意练习“读代码”和“改代码”的能力第二个建议是刻意练习读代码和改代码。AI 生成的代码不要直接运行通过就完事。花十分钟读一遍问自己几个问题这段代码的核心逻辑是什么如果输入变了它会怎么表现有没有冗余的部分有没有潜在的性能问题然后试着改一改——把变量名改得更清晰、把重复的逻辑抽出来、把错误处理补上。这个过程一开始会很慢因为你可能读不懂 AI 写的某些语法。但没关系遇到不懂的就查文档、搜资料。慢慢地你会发现自己的代码阅读速度越来越快对代码质量的判断越来越准。这种能力是 AI 替代不了的。5.3 建立自己的“无 AI 时间”每天至少两小时手写代码第三个建议可能有点反直觉但我觉得非常有效每天留出至少两个小时完全不用 AI手写代码。这两个小时可以用来做算法题、可以用来重写一个你之前用 AI 生成的项目、可以用来读一个开源项目的源码。关键是让手和脑保持“无辅助”状态下的编程能力。我自己到现在还保持着这个习惯。每天早上的第一个小时我会关掉所有 AI 工具手写一段代码。有时候是刷一道 LeetCode有时候是重构昨天写的一个函数有时候是尝试用不同的方式实现同一个功能。这个习惯让我保持对代码的“手感”也让我在遇到 AI 帮不上忙的问题时有足够的底气去自己解决。5.4 把 AI 当成“结对编程伙伴”而非“代写枪手”最后一个建议是改变对 AI 的定位。不要把 AI 当成“代写枪手”——你给它需求它给你代码你复制粘贴。要把 AI 当成“结对编程伙伴”——你有一个想法跟它讨论它给你建议你判断建议是否合理然后一起把代码写出来。结对编程的核心是对话和碰撞。你可以问 AI“我想实现一个功能有 A 和 B 两种方案你觉得哪种更好为什么”你可以让它解释一段代码“这段代码为什么要用这个设计模式有没有更简单的写法”你可以让它帮你 review“我写了这段代码你帮我看看有没有问题。”这种互动方式会让你从 AI 身上学到东西而不是单纯地使用它。6. 给面试官和团队负责人的几句实在话6.1 面试中如何识别“虚假繁荣”候选人站在面试官的角度我总结几个识别虚假繁荣的信号。第一个信号是项目描述很宏大但细节很模糊。候选人说“我做了一个多 Agent 协作系统”你问他“Agent 之间怎么通信”他说“就是传递消息”。你追问“消息格式是什么用什么协议同步还是异步”他就答不上来了。第二个信号是对 AI 工具的依赖程度说不清楚。你问他“这个项目里 AI 帮你写了多少”他说“大部分都是 AI 写的”。你问他“那你负责什么”他说“我负责提需求”。这种候选人基本上没有独立开发能力。第三个信号是遇到不会的问题时第一反应是“我查一下”而不是“我想一下”。面试中遇到不会的问题是正常的但我想看到的是你尝试分析的过程而不是直接放弃。如果候选人说“这个我没接触过但我可以推测一下……”然后给出一个有逻辑的推理即使答案不对我也会给他加分。6.2 团队带新人时怎么补上“基本功”这一课如果你是一个团队负责人正在带一个 Vibe Coding 背景的新人我的建议是前三个月不要让他碰 AI 工具。听起来很极端但很有效。让他手写代码让他读代码让他改 bug。给他一些有明确边界的小任务让他自己设计、自己实现、自己测试。这个过程会很痛苦他会经常卡住会来问你。但正是这些卡住的时刻才是他真正成长的时候。三个月之后再逐步放开 AI 工具的使用。这时候他已经有了基本功AI 对他来说就是杠杆而不是拐杖。他会用 AI 来加速而不是用 AI 来替代思考。6.3 招聘标准的调整从“会用什么工具”到“能解决什么问题”最后我觉得招聘标准也需要调整。过去几年很多公司在招聘时会把“熟悉 AI 编程工具”作为一个加分项。这本身没问题但问题是这个加分项的权重可能太高了。一个候选人如果简历上写了 Cursor、Copilot、LangChain面试官就容易对他产生好感而忽略了他基本功的薄弱。我的建议是把考察重点从“你会用什么工具”转移到“你能解决什么问题”。工具是会变的今天流行 Cursor明天可能流行别的。但解决问题的能力是通用的。一个基本功扎实的工程师给他任何工具他都能快速上手。一个基本功薄弱的工程师给他再好的工具他也只能做表面功夫。7. 我个人的观察与体会面了这么多应届生我最大的感受是AI 编程工具正在加速分化。对于那些基本功扎实的人来说AI 是放大器让他们的产出翻倍对于那些基本功薄弱的人来说AI 是麻醉剂让他们感觉自己很厉害实际上在原地踏步。这种分化在短期内可能看不出来因为大家都能用 AI 做出东西。但三五年之后差距会非常明显。那些把 AI 当杠杆的人会成为团队的核心那些把 AI 当拐杖的人会发现自己除了“会跟 AI 对话”之外没有别的竞争力。我自己也是从手写代码过来的我知道那种调试一个 bug 调一下午的痛苦也知道那种重构完代码之后浑身舒畅的感觉。这些经历塑造了我的工程直觉让我在遇到新问题的时候能够快速定位、快速解决。这种能力AI 给不了你只能你自己去挣。所以如果你正在 Vibe Coding 的路上我的建议很简单用 AI但不要依赖 AI。让 AI 帮你写代码但不要让它替你思考。每天留一点时间关掉所有工具手写一段代码。这个过程可能很慢但它是你从“AI 操作员”变成“真工程师”的必经之路。最后分享一个我自己的小习惯每次用 AI 生成代码之后我都会问自己一个问题——“如果现在断网了我能把这段代码重新写出来吗”如果答案是“不能”我就会把这段代码删掉自己重新写一遍。这个习惯让我保持了对代码的掌控感也让我在面试别人的时候能够一眼看出谁是真的会写谁只是在“描述代码”。 
长河君 · 2026/11/3 16:40:38 · 阅读 1.2k 面试官视角：Vibe Coding虚假繁荣下，如何从AI操作员变真工程师
1. 面试间里的割裂感当简历上写满“AI 协作”却写不出一段冒泡排序过去大半年我陆陆续续面了三十多个 2025 届之后的应届生岗位从后端开发到 Agent 应用工程都有。面试流程基本固定先聊项目再写一道中等难度的算法题最后针对他们简历上写的技术栈做深挖。但最近这几个月我明显感觉到一种割裂感——简历上项目经历写得花团锦簇什么“基于大模型的智能体编排”“多 Agent 协作完成复杂任务”“用 Cursor 从零搭建全栈应用”关键词密度高得吓人可一旦让他们脱离 AI 工具、在白板上手写一段最基础的逻辑场面就变得非常尴尬。有个候选人让我印象特别深。简历上写着“独立开发了一个基于 Agent 的自动化代码审查系统”我让他讲讲这个系统的核心调度逻辑是怎么设计的他支支吾吾半天最后说“就是让 AI 自己规划步骤然后调用工具”。我追问“那如果两个 Agent 同时修改同一个文件你怎么处理冲突”他愣了一下说“这个……AI 应该会自己处理吧”。我又问“你项目里用的 Agent 框架是哪个它的执行循环是怎么实现的”他回答“我用的是 Cursor 的 Agent 模式具体底层我不太清楚。”这不是个例。我面过的这批人里超过一半的简历都提到了 Vibe Coding 相关的工具——Cursor、Windsurf、VS Code Copilot、Trae还有各种 Agent 框架。他们能熟练地描述“怎么用自然语言让 AI 生成一个 React 组件”能说出“提示词要写得具体一点”但当你问到“这个组件为什么用 useEffect 而不是 useMemo”“你写的这个 Agent 工具调用链如果某个工具返回了非预期格式你的容错逻辑在哪”他们往往就卡住了。我并不是要否定 AI 编程工具的价值。我自己每天都在用 Cursor 和 Copilot它们确实把很多重复性工作的效率提升了不止一个档次。但问题在于当“会用 AI 写代码”变成一种可以写在简历上的核心竞争力而底层的基本功却被大面积跳过时一种危险的“虚假繁荣”就出现了——候选人看起来什么都能做实际上什么都做不深。这篇文章我想从面试官的视角拆解这种虚假繁荣是怎么形成的、它在实际工作中会暴露哪些问题以及如果你正在这条路上该怎么把自己从“AI 操作员”变成真正的工程师。2. Vibe Coding 的甜蜜陷阱为什么“能跑就行”正在毁掉基本功2.1 从“写代码”到“描述代码”的范式转移Vibe Coding 这个概念最早出圈的时候核心主张是“你只需要描述你想要什么AI 负责把它变成代码”。这个理念本身没有问题它确实降低了编程的门槛让更多人可以快速把想法变成可运行的原型。但问题在于很多应届生把这个理念当成了学习的终点而不是起点。我观察到一个很典型的学习路径一个学生想做一个个人博客以前他需要学 HTML、CSS、JavaScript理解 DOM 操作、事件循环、HTTP 请求可能要花一两个月才能做出一个像样的东西。现在他打开 Cursor输入“帮我做一个个人博客要有文章列表、详情页、暗色模式”十分钟后一个能跑的页面就出来了。他觉得很爽觉得自己“学会了全栈开发”。然后他把这个项目写进简历面试的时候被问到“你这个博客的 SEO 怎么做的”“首屏加载时间是多少”“有没有做服务端渲染”他就答不上来了。这里的关键区别在于以前的学习路径是“遇到问题—理解原理—解决问题”现在的路径变成了“描述需求—获得代码—运行通过”。中间那个“理解原理”的环节被跳过了。而恰恰是这个环节才是一个工程师真正成长的地方。2.2 面试中暴露的三个典型断层我把这几个月面试中遇到的情况做了个归类发现断层主要集中在三个地方。第一个断层是调试能力。AI 生成的代码不是永远正确的尤其是当项目复杂度上升之后各种边界情况、依赖冲突、环境差异都会导致问题。但很多候选人遇到报错的第一反应不是去读错误信息、定位问题而是把错误信息复制粘贴回给 AI让 AI 再生成一版。如果 AI 连续几次都没解决他们就束手无策了。我遇到过一个候选人项目里有一个空指针异常他花了两个小时跟 AI 来回对话都没修好最后是我提示他“你看看这个变量在什么情况下会是 null”他才恍然大悟。第二个断层是代码阅读能力。AI 生成的代码往往用了很多他们不熟悉的语法糖、设计模式、第三方库。能跑通不代表能维护。我让一个候选人解释他项目里的一段代码那段代码用了Promise.allSettled和Array.prototype.reduce的组合他看了半天说“这是 AI 写的我知道它能把数据处理好但具体怎么实现的我不太清楚”。这种代码如果出了问题他根本无从下手。第三个断层是系统设计能力。AI 擅长生成单个函数、单个组件但一个完整的系统需要考虑模块划分、数据流、错误处理、性能瓶颈、扩展性。这些是 AI 目前很难替你做的。我让一个候选人设计一个短链接服务他第一反应是“我让 AI 生成一个”然后就开始描述“需要一个生成短码的接口、一个跳转的接口”。我追问“短码怎么保证唯一高并发下怎么避免冲突存储用关系型数据库还是 KV过期策略怎么设计”他就答不上来了。这些问题的答案AI 不会主动告诉你因为你的提示词里没写。2.3 “虚假繁荣”的本质工具能力被误认为个人能力为什么会出现这种情况我觉得核心原因是工具能力被误认为个人能力。一个熟练的 Vibe Coding 使用者确实可以用 AI 快速搭建出一个看起来不错的项目。这个项目能跑、有界面、有基本功能甚至能部署上线。从外部看这个人“会做项目”。但面试官要考察的不是“你能不能做出一个东西”而是“当这个东西出问题的时候你能不能搞定”。这两者之间的差距就像一个人用导航开车和自己认路开车的区别。用导航的时候你不需要知道这条路为什么这么走、哪个路口容易堵、如果前方事故了该怎么绕。但如果你要去一个导航没有收录的地方或者导航把你带到了死胡同你就懵了。AI 编程工具就是那个导航它很好用但它不能替代你对路况的理解。更麻烦的是这种虚假繁荣有很强的自我强化效应。候选人用 AI 做出了项目拿到了面试机会面试中聊项目聊得头头是道因为项目确实是他“做”的如果面试官只停留在“你做了什么”的层面他就能过关。入职之后如果团队里有资深工程师兜底他也能混下去。但一旦遇到需要独立排查的线上问题、需要从零设计的新模块、需要权衡取舍的技术选型他就会暴露。3. 拆解一个真实面试案例从“Agent 项目”到“说不清执行循环”3.1 候选人的项目描述与我的追问路径让我把其中一个案例完整拆开来讲这样你能更清楚地看到问题出在哪。候选人 A某 211 计算机相关专业硕士简历上写了两个项目一个是“基于多 Agent 协作的智能客服系统”一个是“用 Cursor 开发的低代码平台”。技术栈写了 Python、LangChain、AutoGen、React、FastAPI。我问他第一个项目“你这个多 Agent 系统里有几个 Agent各自负责什么”他回答“有三个一个负责理解用户意图一个负责查询知识库一个负责生成回复。”我问“它们之间怎么通信是共享内存还是消息传递”他回答“就是……前一个 Agent 的输出传给下一个 Agent。”我问“那如果知识库查询 Agent 返回了空结果生成回复的 Agent 怎么处理”他回答“这个……我让 AI 加了一个判断如果为空就返回‘抱歉没找到’。”我问“这个判断是在哪个环节加的是 Agent 内部的逻辑还是编排层的逻辑”他沉默了一会儿说“应该是编排层吧我不太确定代码是 AI 写的。”到这里我已经基本能判断出他的水平了。他知道这个系统“大概是怎么工作的”但不知道“具体是怎么实现的”。他能描述数据流动的方向但说不清每个环节的边界条件和异常处理。3.2 为什么“让 AI 写”和“自己会写”之间有巨大鸿沟这个案例很典型。候选人 A 的问题不是他用了 AI而是他把 AI 当成了黑盒。他给 AI 一个需求AI 给他一个实现他运行通过就认为完成了。他没有去读 AI 生成的代码没有去理解每个模块的职责边界没有去思考异常情况怎么处理。这里面的鸿沟在于AI 生成的代码是基于概率的它给你的是一个“看起来合理”的实现而不是一个“经过验证”的实现。它可能用了某个库的某个方法这个方法在当前版本下能用但下个版本就废弃了它可能假设了某个输入永远不会为空但实际业务中就是会为空它可能把两个本来应该解耦的模块耦合在一起因为这样写起来更短。如果你自己会写你在看 AI 生成的代码时能快速判断“这里有问题”“这个写法不优雅”“这个边界没处理”。但如果你自己不会写你就只能看它“能不能跑”。能跑就行这是 Vibe Coding 最危险的心态。3.3 面试官视角的评分逻辑我们到底在考察什么站在面试官的角度我考察一个候选人核心看三件事。第一你能不能把一个问题拆解成可执行的步骤。这考察的是你的逻辑思维和工程思维。AI 可以帮你写代码但不能帮你拆解问题。如果你连“这个功能需要哪几个模块、模块之间怎么交互、数据怎么流转”都说不清楚那你就不具备独立开发的能力。第二你能不能判断代码的质量。这考察的是你的基本功。变量命名是否清晰、函数职责是否单一、错误处理是否完善、性能是否可接受这些判断需要你有足够的代码阅读量和写作经验。AI 生成的代码质量参差不齐你需要有能力去甄别和修改。第三你能不能在没有 AI 的情况下解决问题。这考察的是你的底层能力。面试中我经常会故意断网或者让候选人在白板上写伪代码。不是为了为难你而是因为实际工作中你总会遇到 AI 帮不上忙的时候——比如排查一个线上环境的诡异 bug、比如优化一个性能瓶颈、比如设计一个全新的架构。这些时候你能依靠的只有你自己的知识和经验。4. 虚假繁荣的代价入职之后会发生什么4.1 前三个月的“蜜月期”与之后的“暴露期”我观察过几个通过 Vibe Coding 路线进入团队的应届生他们的表现有一个很明显的曲线。前三个月是蜜月期。他们能用 AI 快速完成一些简单的需求比如加个接口、改个页面、修个样式。因为任务本身不难AI 生成的代码稍微改改就能用所以他们的产出看起来还不错。团队里如果有人带告诉他们“你去改这个文件”“你照着这个例子写”他们也能完成任务。但三个月之后问题开始暴露。任务难度上升了不再是“照着例子改”而是“从零实现一个模块”。这时候他们需要自己设计数据结构、自己划分函数职责、自己考虑异常处理。AI 能帮他们生成代码片段但没法帮他们做这些设计决策。他们开始频繁卡壳一个本来两天能完成的任务拖到一周还没搞定。代码 review 的时候资深工程师发现他们的代码里充满了“能跑但不对”的逻辑——比如没有处理并发、没有考虑事务、没有做输入校验。4.2 团队协作中的“隐形负债”更麻烦的是这些代码会成为团队的隐形负债。AI 生成的代码往往有一个特点局部看起来没问题全局看起来一团糟。因为它是一个函数一个函数生成的每个函数单独看都挺合理但放在一起就发现命名风格不统一、错误处理方式不一致、重复代码到处都是、模块之间耦合严重。我见过一个项目前端用 Cursor 生成了十几个组件每个组件里都有一份自己的数据请求逻辑有的用 fetch有的用 axios有的直接写在 useEffect 里有的封装了一个自定义 hook。结果就是当后端接口变了的时候需要改十几个地方而且很容易漏掉。这种代码维护起来比从头写一遍还累。4.3 对个人职业发展的长期影响从个人发展的角度看虚假繁荣最大的代价是时间窗口的浪费。应届生入职后的前两年是基本功成长最快的时期。这段时间如果你在踏踏实实地写代码、读代码、改 bug、做设计你的能力会有一个质的飞跃。但如果你把这段时间花在了“跟 AI 对话”上你的成长曲线会平缓很多。因为 AI 帮你跳过了那些让你痛苦的环节——调试、重构、优化——而这些环节恰恰是成长的关键。我并不是说不要用 AI。我是说你要把 AI 当成杠杆而不是拐杖。杠杆是放大你的能力拐杖是替代你的能力。如果你自己不会走给你一根拐杖你也能走但你的腿永远得不到锻炼。等你哪天需要跑的时候你就发现自己的腿已经退化了。5. 从“AI 操作员”到“真工程师”一条可落地的自救路线5.1 重新定义 AI 工具的使用姿势先自己想再让 AI 写如果你正在 Vibe Coding 的路上并且意识到自己可能陷入了虚假繁荣那第一步是改变使用 AI 工具的方式。具体怎么做很简单遇到一个需求先不要打开 AI。拿一张纸或者打开一个空白文档自己先想清楚这个功能需要哪几个步骤每个步骤的输入输出是什么有没有边界情况大概用什么数据结构想清楚之后再打开 AI把你的思路告诉它让它帮你生成代码。这样做的好处是你在用 AI 之前已经完成了一次完整的思考。AI 生成的代码你会带着“验证”的心态去看而不是“接受”的心态。你会发现很多时候 AI 生成的代码跟你想的不一样这时候你就要判断是它的写法更好还是你的思路更对这个判断的过程就是成长。5.2 刻意练习“读代码”和“改代码”的能力第二个建议是刻意练习读代码和改代码。AI 生成的代码不要直接运行通过就完事。花十分钟读一遍问自己几个问题这段代码的核心逻辑是什么如果输入变了它会怎么表现有没有冗余的部分有没有潜在的性能问题然后试着改一改——把变量名改得更清晰、把重复的逻辑抽出来、把错误处理补上。这个过程一开始会很慢因为你可能读不懂 AI 写的某些语法。但没关系遇到不懂的就查文档、搜资料。慢慢地你会发现自己的代码阅读速度越来越快对代码质量的判断越来越准。这种能力是 AI 替代不了的。5.3 建立自己的“无 AI 时间”每天至少两小时手写代码第三个建议可能有点反直觉但我觉得非常有效每天留出至少两个小时完全不用 AI手写代码。这两个小时可以用来做算法题、可以用来重写一个你之前用 AI 生成的项目、可以用来读一个开源项目的源码。关键是让手和脑保持“无辅助”状态下的编程能力。我自己到现在还保持着这个习惯。每天早上的第一个小时我会关掉所有 AI 工具手写一段代码。有时候是刷一道 LeetCode有时候是重构昨天写的一个函数有时候是尝试用不同的方式实现同一个功能。这个习惯让我保持对代码的“手感”也让我在遇到 AI 帮不上忙的问题时有足够的底气去自己解决。5.4 把 AI 当成“结对编程伙伴”而非“代写枪手”最后一个建议是改变对 AI 的定位。不要把 AI 当成“代写枪手”——你给它需求它给你代码你复制粘贴。要把 AI 当成“结对编程伙伴”——你有一个想法跟它讨论它给你建议你判断建议是否合理然后一起把代码写出来。结对编程的核心是对话和碰撞。你可以问 AI“我想实现一个功能有 A 和 B 两种方案你觉得哪种更好为什么”你可以让它解释一段代码“这段代码为什么要用这个设计模式有没有更简单的写法”你可以让它帮你 review“我写了这段代码你帮我看看有没有问题。”这种互动方式会让你从 AI 身上学到东西而不是单纯地使用它。6. 给面试官和团队负责人的几句实在话6.1 面试中如何识别“虚假繁荣”候选人站在面试官的角度我总结几个识别虚假繁荣的信号。第一个信号是项目描述很宏大但细节很模糊。候选人说“我做了一个多 Agent 协作系统”你问他“Agent 之间怎么通信”他说“就是传递消息”。你追问“消息格式是什么用什么协议同步还是异步”他就答不上来了。第二个信号是对 AI 工具的依赖程度说不清楚。你问他“这个项目里 AI 帮你写了多少”他说“大部分都是 AI 写的”。你问他“那你负责什么”他说“我负责提需求”。这种候选人基本上没有独立开发能力。第三个信号是遇到不会的问题时第一反应是“我查一下”而不是“我想一下”。面试中遇到不会的问题是正常的但我想看到的是你尝试分析的过程而不是直接放弃。如果候选人说“这个我没接触过但我可以推测一下……”然后给出一个有逻辑的推理即使答案不对我也会给他加分。6.2 团队带新人时怎么补上“基本功”这一课如果你是一个团队负责人正在带一个 Vibe Coding 背景的新人我的建议是前三个月不要让他碰 AI 工具。听起来很极端但很有效。让他手写代码让他读代码让他改 bug。给他一些有明确边界的小任务让他自己设计、自己实现、自己测试。这个过程会很痛苦他会经常卡住会来问你。但正是这些卡住的时刻才是他真正成长的时候。三个月之后再逐步放开 AI 工具的使用。这时候他已经有了基本功AI 对他来说就是杠杆而不是拐杖。他会用 AI 来加速而不是用 AI 来替代思考。6.3 招聘标准的调整从“会用什么工具”到“能解决什么问题”最后我觉得招聘标准也需要调整。过去几年很多公司在招聘时会把“熟悉 AI 编程工具”作为一个加分项。这本身没问题但问题是这个加分项的权重可能太高了。一个候选人如果简历上写了 Cursor、Copilot、LangChain面试官就容易对他产生好感而忽略了他基本功的薄弱。我的建议是把考察重点从“你会用什么工具”转移到“你能解决什么问题”。工具是会变的今天流行 Cursor明天可能流行别的。但解决问题的能力是通用的。一个基本功扎实的工程师给他任何工具他都能快速上手。一个基本功薄弱的工程师给他再好的工具他也只能做表面功夫。7. 我个人的观察与体会面了这么多应届生我最大的感受是AI 编程工具正在加速分化。对于那些基本功扎实的人来说AI 是放大器让他们的产出翻倍对于那些基本功薄弱的人来说AI 是麻醉剂让他们感觉自己很厉害实际上在原地踏步。这种分化在短期内可能看不出来因为大家都能用 AI 做出东西。但三五年之后差距会非常明显。那些把 AI 当杠杆的人会成为团队的核心那些把 AI 当拐杖的人会发现自己除了“会跟 AI 对话”之外没有别的竞争力。我自己也是从手写代码过来的我知道那种调试一个 bug 调一下午的痛苦也知道那种重构完代码之后浑身舒畅的感觉。这些经历塑造了我的工程直觉让我在遇到新问题的时候能够快速定位、快速解决。这种能力AI 给不了你只能你自己去挣。所以如果你正在 Vibe Coding 的路上我的建议很简单用 AI但不要依赖 AI。让 AI 帮你写代码但不要让它替你思考。每天留一点时间关掉所有工具手写一段代码。这个过程可能很慢但它是你从“AI 操作员”变成“真工程师”的必经之路。最后分享一个我自己的小习惯每次用 AI 生成代码之后我都会问自己一个问题——“如果现在断网了我能把这段代码重新写出来吗”如果答案是“不能”我就会把这段代码删掉自己重新写一遍。这个习惯让我保持了对代码的掌控感也让我在面试别人的时候能够一眼看出谁是真的会写谁只是在“描述代码”。