Vibe Coding时代：AI编程工具如何制造应届生能力幻觉

1. 面试间里的怪现象简历光鲜动手就露馅最近两个月我面了大概十几个2025年之后毕业的应届生岗位从Python后端到Agent应用开发都有。说实话面到最后我有点恍惚——不是被候选人的水平震撼而是被一种高度雷同的“能力幻觉”整不会了。这些同学的简历几乎是一个模子刻出来的熟悉Vibe Coding工作流熟练使用Cursor、Windsurf、VS Code Copilot、Trae等AI编程助手有Agent项目开发经验掌握Python做过基于大模型的智能体应用。项目经历里写着“独立完成多智能体协作系统”“基于RAG的知识库问答平台”“自动化数据分析Agent”听起来一个比一个唬人。然后我让他们现场写一段代码题目不难给一个嵌套的JSON结构写个函数把里面所有status字段为active的节点路径提取出来。可以用任何AI工具联网也行查文档也行。结果十几个人里能独立把边界条件处理干净的不超过三个。有个同学的操作我印象特别深。他打开Cursor敲了一句提示词“写一个Python函数提取嵌套JSON中status为active的节点路径。”AI秒出代码他看都没怎么看就贴到编辑器里运行报错。然后他继续跟AI说“报错了帮我修”AI又给了一版再跑还报错。来回折腾了五六轮最后他抬头看我说“这个AI不太行”。问题出在哪他给AI的提示词里压根没提“嵌套结构可能有多层”“status字段可能不存在”“路径需要包含父级键名”这些关键约束。他自己都没想清楚需求却指望AI替他想清楚。这就是我标题里说的“虚假繁荣”——工具越来越强但使用工具的人对问题的理解越来越浅。Vibe Coding这个概念本身没问题。用自然语言描述意图让AI生成代码人负责审查和调整这个工作流在2025年已经相当成熟。但问题在于很多应届生把“会用AI写代码”等同于“会编程”把“AI能跑通”等同于“我掌握了”。这两者之间隔着一条巨大的鸿沟而这条鸿沟在面试现场会暴露得淋漓尽致。这篇文章我想聊的就是这个现象背后的东西Vibe Coding到底改变了什么没改变什么为什么AI编程工具越普及基础能力的缺失反而越危险以及如果你是一个正在用AI学编程的人怎么避免掉进“虚假繁荣”的坑里。不管你是刚入行的应届生还是带团队的技术负责人或者只是对AI编程感兴趣的自学者这些从面试间里观察到的真实细节应该都能给你一些参考。2. Vibe Coding到底改变了什么又没改变什么2.1 从“写代码”到“描述意图”的范式转移Vibe Coding这个词是Andrej Karpathy在2023年底提出来的核心意思是你不再逐行写代码而是用自然语言描述你想要什么AI帮你生成你负责运行、观察、调整。到了2025年这个工作流已经被Cursor、Windsurf、Trae、VS Code Copilot等工具打磨得相当顺滑。我自己的日常开发也确实变了。以前写一个数据清洗脚本我得打开编辑器import pandas读CSV处理缺失值写循环调试。现在我会在Cursor里敲一段话“读这个CSV把日期列解析成datetime缺失值用前向填充然后按周聚合计算均值输出到新文件。”AI生成的代码我扫一眼改两个参数就能跑。效率提升是实打实的以前半小时的活现在五分钟搞定。但这里有个关键区别我知道我要什么我也知道AI生成的代码哪里可能有问题。日期解析可能遇到格式不一致前向填充在开头有缺失时会留空按周聚合需要确认周起始日是周一还是周日。这些判断来自我过去踩过的坑来自我对pandas行为的理解来自我调试过无数次的肌肉记忆。AI只是帮我把这些判断翻译成了代码它没有替我做判断。应届生的问题恰恰在这里。他们看到的是“AI能生成代码”没看到的是“生成代码之前需要有人把需求想清楚”。他们把Vibe Coding理解成了“我随便说一句AI给我能跑的东西”但实际上Vibe Coding的“Vibe”指的是你用自然语言捕捉意图的能力而不是“凭感觉瞎写”。2.2 AI编程助手的能力边界在哪里我拿几个主流工具做过对比测试场景是“写一个Python函数从嵌套JSON中提取指定字段的路径”。这个任务不算复杂但有几个容易翻车的点嵌套层级不确定、字段可能不存在、路径需要包含父级键名、需要处理列表和字典混合的情况。Cursor在理解“嵌套JSON”这个表述时表现最好它会主动问“是否需要处理列表中的元素”生成的代码用了递归边界条件也考虑到了。Windsurf的补全速度最快但第一版代码漏掉了列表处理需要手动补。VS Code Copilot在简单场景下很稳但面对“路径需要包含父级键名”这种稍微绕一点的约束时第一版生成的结果把键名拼错了。Trae的中文提示词理解不错但生成的代码风格偏保守用了多层循环而不是递归。这些差异说明一件事AI编程助手的能力边界取决于你给它的约束有多清晰。你给它的信息越完整它生成的结果越靠谱。你给它的信息越模糊它就越容易在某个你没注意到的角落翻车。而“知道该给什么约束”这件事恰恰来自你对问题本身的理解深度。我面过的一个同学简历上写着“熟练使用Cursor进行全栈开发”。我让他用Cursor写一个简单的Flask接口接收JSON校验必填字段返回处理结果。他打开Cursor输入“写一个Flask接口”AI生成了一个最基础的hello world。他说“不对要接收JSON”AI加了request.json。他说“要校验字段”AI加了if判断。他说“要返回处理结果”AI加了return。来回改了七八轮最后代码能跑但字段校验的逻辑是错的——AI把if name in data写成了if data[name]字段不存在时会直接抛KeyError。他全程没有看过一眼生成的代码逻辑只是在用自然语言“遥控”AI。这就是典型的“虚假繁荣”他以为自己在编程其实只是在做需求翻译而且翻译得还不准确。2.3 被AI掩盖的基础能力缺口我整理了一下这十几个应届生的面试表现发现几个高频出现的缺口几乎都和AI使用习惯有关。第一个缺口是调试能力。AI生成的代码报错时很多人的第一反应是“把错误信息贴给AI让它修”而不是自己看traceback。有个同学遇到TypeError: unhashable type: dict他直接把错误贴给AIAI建议“把dict转成tuple”他照做了但没意识到问题根源是他用字典做了集合的元素。这种“贴错误给AI”的习惯短期能解决问题长期会让人丧失定位问题的能力。第二个缺口是数据结构理解。嵌套JSON、树形结构、图遍历这些概念在AI生成的代码里经常出现但很多人只是“知道AI写了递归”说不清递归的终止条件为什么那样设。我让一个同学解释他项目里“多智能体协作”的代码他支支吾吾半天最后说“这是AI写的我主要负责调通”。第三个缺口是边界条件意识。AI生成的代码在正常输入下通常没问题但遇到空值、超长输入、并发访问时就容易崩。面试时我特意给了一个包含空列表和缺失字段的测试用例超过一半的人代码直接抛异常。他们不是不会处理是压根没想到要处理。这些缺口在AI辅助下被暂时掩盖了——代码能跑项目能演示简历能写。但一到面试现场面对一个没有标准答案的问题面对一个需要自己定义约束的场景缺口就暴露了。AI可以帮你写代码但不能帮你理解问题。而理解问题恰恰是编程的核心能力。3. 面试现场的三个真实切片3.1 切片一提示词写不明白因为需求没想清楚第一个切片来自一个简历很漂亮的同学某211计算机专业有两段大厂实习经历项目栏里写着“基于多智能体的自动化测试平台”。我让他现场用AI工具写一个函数给定一个目录路径递归找出所有.py文件统计每个文件的行数按行数降序输出。他打开Cursor输入“写一个Python脚本统计目录下所有py文件的行数。”AI生成了代码用了os.walk但只统计了当前目录没有递归。他看了下说“要递归”AI改了用了os.walk的递归。然后他说“要按行数排序”AI加了sorted。最后他说“要输出文件名”AI加了print。代码能跑但有几个问题没有处理文件读取异常没有排除__pycache__目录排序时没有处理行数相同的情况。我问他“如果目录里有几千个文件这个脚本会有什么问题”他想了半天说“可能会慢”我说“os.walk本身没问题但你每个文件都打开读一遍如果遇到二进制文件或者权限不够的文件会直接崩。”他愣了一下说“AI没写异常处理。”这就是典型的“需求没想清楚就开写”。他给AI的提示词里没有提“异常处理”“排除缓存目录”“大目录性能”这些约束因为他自己就没想过这些。提示词的质量直接反映你对问题的理解深度。你写不出好的提示词不是因为你不懂AI是因为你不懂问题。提示用AI写代码之前先花两分钟把需求拆成“输入是什么、输出是什么、边界情况有哪些、异常怎么处理”四个问题。这四个问题想清楚了提示词自然就清晰了。3.2 切片二AI说“已修复”但问题真的解决了吗第二个切片更典型。一个同学用Windsurf写一个Flask接口接收POST请求解析JSON校验username和email字段返回校验结果。AI生成的代码用了request.get_json()但没处理Content-Type不是application/json的情况。他测试时用Postman发了正确的请求通过了。我让他用curl发一个不带Content-Type的请求接口直接返回400。他把错误贴给AIAI说“已修复”加了request.get_json(forceTrue)。再测通过了。我问他“forceTrue是什么意思”他说“就是强制解析吧。”我说“如果请求体不是合法JSON呢”他试了一下发了一个纯文本接口抛了BadRequest异常没有返回友好的错误信息。AI的“已修复”只是针对他贴的那个错误做了修补没有从根本上解决“输入校验”这个问题。AI擅长修症状不擅长治根因。如果你自己不清楚根因是什么就会陷入“报错-贴给AI-修复-再报错”的循环。这个循环转得越快你离真正的理解就越远。我后来跟这个同学聊他说他平时做项目就是这样遇到报错就贴给AIAI说修好了就继续往下写。项目能跑起来但代码里全是这种“打补丁”式的修复。面试时我问他“如果让你重新设计这个接口你会怎么做”他答不上来因为他从来没想过“设计”只是在“修补”。3.3 切片三离开AI编辑器手写代码就卡壳第三个切片是我特意设计的环节。我让每个候选人关掉所有AI工具用最朴素的文本编辑器写一个函数判断一个字符串是否是合法的括号序列支持()、[]、{}三种括号。这个题目不难LeetCode简单难度。但十几个应届生里能独立写出来的只有四个。有个同学写了二十分钟用了栈但边界条件写错了——空字符串返回了False应该返回True。还有个同学压根没写出来他说“平时都是用AI写这种算法题好久没手写了”。我问他“你简历上写的‘熟悉Python’具体熟悉到什么程度”他说“能用AI写出能跑的代码。”我说“那如果AI挂了或者你遇到一个AI没见过的场景呢”他沉默了。这个切片暴露的问题最直接AI编程工具正在让一部分人丧失“裸写代码”的能力。裸写代码不是说要你背语法而是说你要能在没有外部辅助的情况下把一个问题拆解成可执行的步骤用代码表达出来。这个能力是编程的底层能力AI可以加速它但不能替代它。我自己的习惯是每周至少有一次关掉AI工具用纯文本编辑器写代码。不是为了“复古”是为了保持手感。就像健身的人不能只靠器械也得做自重训练。AI是杠铃自重训练是你的核心力量。杠铃能让你举得更重但核心力量不够杠铃会压垮你。4. 虚假繁荣的根源工具越强人越容易偷懒4.1 AI编程工具的“甜蜜陷阱”我观察到一个很有意思的现象AI编程工具越智能使用者越容易放弃思考。Cursor的Tab补全太顺滑了你敲几个字符它就猜出你要写什么你按Tab接受就行。Windsurf的Agent模式能自动改多个文件你描述一个需求它帮你把整个功能实现了。Trae的中文理解很好你用中文说“帮我写个爬虫”它直接给你能跑的代码。这些体验都很“甜”。甜到你不知不觉就把“思考”这个环节外包给了AI。你不再问“这个数据结构选什么合适”因为AI会选。你不再问“这个边界条件要不要处理”因为AI会处理。你不再问“这个算法的时间复杂度是多少”因为AI会优化。但问题是AI的选择不一定对AI的处理不一定全AI的优化不一定适合你的场景。当你把思考外包出去你就失去了判断AI输出质量的能力。你只能看“代码能不能跑”不能看“代码写得好不好”。而“能跑”和“好”之间隔着十万八千里。我面过一个同学他用Cursor写了一个“智能客服Agent”项目演示很流畅。我问他“你的Agent怎么处理用户意图识别错误的情况”他说“AI会重新识别。”我说“如果重新识别还是错呢”他说“那就再识别。”我说“有没有兜底策略比如转人工或者返回默认回复”他说“AI没写这个。”他的Agent在演示场景下表现很好因为演示的输入都是精心设计的。但真实场景下用户会说各种奇怪的话意图识别错误是常态。没有兜底策略的Agent上线第一天就会被用户骂死。AI帮他实现了“能跑”但没帮他实现“能用”。而“能用”需要的是产品思维、异常处理意识、对真实场景的理解这些AI给不了。4.2 从“我会写”到“AI会写”的能力空心化我对比过两批人一批是2020年左右入行的程序员他们学编程时AI辅助还很弱必须自己啃文档、调bug、读源码。另一批是2025年后的应届生他们从第一天起就用Cursor、CopilotAI是他们学习编程的“第一任老师”。前一批人的知识结构是“树状”的从语法到数据结构从算法到系统设计一层一层往上长。后一批人的知识结构是“点状”的他们知道“用AI能写出Flask接口”但不知道Flask的请求生命周期他们知道“用AI能写出爬虫”但不知道HTTP协议的状态码含义他们知道“用AI能写出Agent”但不知道Agent的决策循环是怎么设计的。这种“点状知识”在AI辅助下能完成很多任务但一旦遇到AI没见过的场景或者需要跨知识点串联的问题就会卡住。因为他们的知识之间没有连接无法形成推理链。我面试时喜欢问一个开放问题“如果让你设计一个系统每天处理100万条用户评论做情感分析你会怎么设计”这个问题没有标准答案但能看出候选人的知识结构。有人会从数据采集、存储、批处理、模型推理、结果展示一层层拆有人会直接说“用AI写个脚本”。前者是“树状知识”后者是“点状知识”。注意AI编程工具是加速器不是替代品。你可以用AI加速学习但不能用AI替代学习。就像计算器可以帮你算数但你不能因此不学数学。4.3 面试官视角我们到底在考察什么站在面试官的角度我其实不太在意候选人会不会用Cursor。工具这东西入职一周就能学会。我在意的是三件事问题拆解能力、代码调试能力、知识迁移能力。问题拆解能力就是拿到一个模糊需求能不能把它拆成清晰的输入、输出、约束、边界。这个能力AI帮不了你因为AI需要你先把需求描述清楚。代码调试能力就是代码报错时能不能自己定位问题、提出假设、验证假设。这个能力AI能辅助但不能替代因为AI不知道你的运行环境、你的数据特征、你的业务逻辑。知识迁移能力就是遇到一个没见过的问题能不能用已有的知识去类比、推理、解决。这个能力AI给不了因为AI只能基于训练数据生成不能真正“理解”新问题。这三个能力恰恰是Vibe Coding时代最稀缺的。因为AI把“写代码”这个环节的门槛降低了很多人就直接跳过了“理解问题”和“调试代码”的环节直奔“生成代码”。结果就是代码能跑但人没成长。我面过一个同学他的项目是一个“自动化数据分析Agent”用户上传CSVAgent自动做数据清洗、统计分析、生成图表。演示很流畅。我问他“如果CSV里有中文列名你的Agent怎么处理”他说“AI会处理。”我说“如果中文列名有编码问题呢”他说“应该不会吧。”我说“你试过吗”他说“没有。”这个Agent在英文CSV上表现很好因为AI训练数据里英文CSV多。但中文CSV的编码问题、列名对齐问题、日期格式问题AI不一定能处理好。AI的“能处理”是基于概率的不是基于保证的。你需要自己测试、验证、兜底。而测试和验证的能力来自你对问题的理解。5. 给不同阶段读者的实操建议5.1 应届生怎么用AI学编程而不被AI废掉如果你是一个正在用AI学编程的应届生我的建议是把AI当老师别当枪手。当老师的意思是你用AI来提问、来验证、来拓展。比如你学Python的装饰器不要直接让AI写一个装饰器给你用而是让AI解释“装饰器的执行顺序是什么”“带参数的装饰器怎么实现”“装饰器在Flask路由里怎么用的”。然后你自己写一个写完让AI review问它“这段代码有什么问题”“有没有更好的写法”。当枪手的意思是你让AI替你写代码你只负责复制粘贴和运行。这样你永远学不会编程只会学会“指挥AI”。而指挥AI这件事门槛会越来越低低到不需要专门学。具体操作上我建议你养成三个习惯。第一个习惯是先自己想再问AI。遇到一个问题先花十分钟自己想思路哪怕想不出来也要把“我卡在哪”想清楚。然后再问AI这样你能对比“AI的思路”和“你的思路”差在哪。第二个习惯是让AI解释代码。AI生成代码后不要直接跑先让AI逐行解释然后你复述一遍。如果你复述不出来说明你没理解。第三个习惯是关掉AI手写。每周至少有一次关掉所有AI工具用纯文本编辑器写代码。哪怕写得慢哪怕写得丑也要写。这是保持手感的方式。提示AI生成的代码至少要能回答三个问题才算过关——这段代码的输入输出是什么边界条件怎么处理的如果输入异常会怎样答不上来就回去问AI直到答上来。5.2 转行者AI降低了入门门槛但没降低精通门槛如果你是一个转行者通过AI编程工具入了门我的建议是补基础别跳步。AI确实降低了编程的入门门槛。以前学Python你得装环境、配路径、学语法、调bug每一步都可能卡住。现在你用Cursor描述一个需求代码就出来了跑起来就能用。这种正反馈很爽爽到让你觉得“编程不过如此”。但入门门槛降低不代表精通门槛降低。你还是要学数据结构还是要学算法还是要学操作系统还是要学网络协议。这些基础知识AI可以帮你理解但不能帮你跳过。因为它们是编程的“底层操作系统”没有它们你的知识就是散的遇到复杂问题就串不起来。我建议转行者的学习路径是用AI做项目用传统方式补基础。做项目时用AI加速遇到不懂的概念就停下来用传统方式学——看文档、读源码、做练习。比如你用AI写了一个Flask接口那就花时间把Flask的官方教程过一遍理解路由、请求上下文、蓝图这些概念。你用AI写了一个爬虫那就花时间学HTTP协议、HTML解析、反爬策略。项目是应用基础是内功。应用可以速成内功必须慢练。5.3 技术负责人怎么面试Vibe Coding时代的候选人如果你是一个技术负责人正在面试Vibe Coding时代的候选人我的建议是别考八股考场景。传统的八股文面试——问HashMap原理、问JVM内存模型、问TCP三次握手——在AI时代依然有价值但价值在降低。因为这些知识AI都能回答候选人背一背就能过。你真正要考察的是候选人面对一个模糊问题时的思考过程。我的面试流程是这样的先给一个模糊需求比如“设计一个短链接系统”让候选人用AI工具现场做。观察他怎么拆解需求、怎么给AI提示词、怎么审查AI的输出、怎么调试报错。然后关掉AI给一个算法题看他的裸写能力。最后问一个开放问题比如“你最近用AI解决的最难的问题是什么”看他的反思深度。这个流程能筛掉那些“只会指挥AI”的人留下那些“会用AI但不止于AI”的人。AI时代的技术负责人要招的不是“会用AI的人”而是“知道AI什么时候会出错的人”。前者是操作员后者是工程师。6. 我自己的Vibe Coding工作流说了这么多问题不是要否定Vibe Coding。我自己每天都在用AI编程工具效率提升是实打实的。关键是怎么用用得好是杠杆用不好是拐杖。我的工作流分四步。第一步是需求拆解关掉AI用纸笔把需求拆成输入、输出、约束、边界、异常五个部分。这一步不写代码只写自然语言。第二步是AI生成把拆解好的需求喂给Cursor或Windsurf让它生成第一版代码。第三步是人工审查逐行看AI生成的代码重点看边界条件、异常处理、性能瓶颈。第四步是手动调试自己跑测试用例遇到报错先自己定位定位不了再问AI。这个工作流的核心是AI负责“写”我负责“想”和“验”。想清楚需求验证代码质量。这两件事AI替不了我我也不想让AI替。我试过完全放手让AI写结果就是代码能跑但质量堪忧后期维护成本极高。我也试过完全不用AI结果就是效率太低被同行甩开。最好的状态是“人机协作”人做判断AI做执行。判断的质量决定代码的质量而判断的质量来自你的经验、你的知识、你对问题的理解。最后分享一个小技巧我每次用AI生成代码后会问它一个问题——“这段代码在什么情况下会失败”AI通常会列出几个边界情况我再针对这些情况写测试用例。这个习惯帮我省了很多调试时间也帮我发现了不少AI自己都没意识到的坑。Vibe Coding不是洪水猛兽也不是银弹。它就是一个工具像当年的IDE、Git、Stack Overflow一样。工具本身没有好坏关键看用工具的人。用得好的人效率翻倍用不好的人能力空心。我希望你是前者。