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'，他直接把错误贴给AI，AI建议“把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。

他把错误贴给AI，AI说“已修复”，加了request.get_json(force=True)。再测，通过了。我问他：“force=True是什么意思？”他说：“就是强制解析吧。”我说：“如果请求体不是合法JSON呢？”他试了一下，发了一个纯文本，接口抛了BadRequest异常，没有返回友好的错误信息。

AI的“已修复”只是针对他贴的那个错误做了修补，没有从根本上解决“输入校验”这个问题。AI擅长修症状，不擅长治根因。如果你自己不清楚根因是什么，就会陷入“报错-贴给AI-修复-再报错”的循环。这个循环转得越快，你离真正的理解就越远。

我后来跟这个同学聊，他说他平时做项目就是这样，遇到报错就贴给AI，AI说修好了就继续往下写。项目能跑起来，但代码里全是这种“打补丁”式的修复。面试时我问他“如果让你重新设计这个接口，你会怎么做”，他答不上来，因为他从来没想过“设计”，只是在“修补”。

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、Copilot，AI是他们学习编程的“第一任老师”。

前一批人的知识结构是“树状”的：从语法到数据结构，从算法到系统设计，一层一层往上长。后一批人的知识结构是“点状”的：他们知道“用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”，用户上传CSV，Agent自动做数据清洗、统计分析、生成图表。演示很流畅。我问他：“如果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一样。工具本身没有好坏，关键看用工具的人。用得好的人，效率翻倍；用不好的人，能力空心。我希望你是前者。