Vibe Coding时代，只会用AI写代码的程序员正在失去什么

2025年初，vibe coding这个词突然从技术圈的小圈子一路炸到了大厂周会和创业公司的融资PPT里。它描述的是一套看起来特别“未来”的开发方式：你不再逐行敲代码，而是像指挥一个水平不错的实习生一样，用自然语言描述需求—— “帮我写一个用户登录接口，用JWT，Token过期时间设两小时”，然后AI刷刷刷把代码吐出来，你点几下一路Tab接受，肉眼扫一眼没报错就算过了。整个过程顺畅得像在抖音刷到一条沉浸式解压视频，代码自己长出来了。

我一开始也觉得这是效率革命。直到我在实际项目中连续接手了几个“AI一行行喂出来”的系统，又陆续面试了一批“只会Vibe Coding”的候选人，才意识到一个更尖锐的现实：真正危险的，不是AI会写代码。危险的是，只会用AI写代码、把“代码能跑”当成“事情办妥”的那批程序员，正在亲手把自己变成系统的局外人。今天这篇不是劝退文，也不是要你把IDE里的AI助手卸了回到石器时代。我想认真拆解一下：Vibe Coding 到底替我们承担了什么、留下了哪些无人负责的暗区，以及为什么说“淘汰”远比我们以为的更近、更安静。

1. 先搞清楚：Vibe Coding 到底在“vibe”什么

1.1 这个词是怎么火起来的

说 Vibe Coding 之前，得先交代一下它火起来的路径。它最初火起来，不是因为国内某个公众号造了个概念，而是因为前OpenAI研究员、特斯拉前AI总监 Andrej Karpathy 在一次公开分享里随口用了这个说法——大意是“我现在写代码已经不太像在编码了，更像在跟着感觉走，AI负责写，我负责围观，它写得不对就改一句提示词让它重新来”。这段描述在推特上病毒式传播，因为它实在太精确地踩中了无数程序员在2024年底到2025年初的真实生产力场景：

• 几个主流IDE陆续把AI补全从“按一下出一行”升级成了“写完一个函数甚至一个文件”；
• Agent形态的编码工具开始能自己读代码库、自己跑测试、自己迭代修复报错；
• “首页一堆代码”从段子变成了日常，很多人一上午的工作量，在一杯咖啡时间内就被AI压缩完了。

于是“跟着感觉走，代码自己长”这个体验，被正式贴上了一个标签。Vibe Coding 这个词本身是有生命力的，它描述的是编程范式的一次肉眼可见的左移：从“你写代码”变成了“你指挥代码”。指挥这个动作，看起来轻松，但极少有人追问过一个问题：指挥的质量由什么决定？答案是——你对问题的理解深度。如果你自己都不知道这个系统为什么存在、边界在哪里、挂了之后谁负责，那AI产出的那些代码，本质上只是你一秒钟想出来的模模糊糊想法的“快速投影”而已。

1.2 真正被外包出去的是什么，留下的又是什么

我以前带过一个实习生，用Vibe Coding的方式写一个内部数据导出工具，非常流畅，两个下午就交付了第一版。代码能跑，能导出Excel，能筛选日期。但等我接手一看：没有分页处理，十万行数据一导就内存溢出；没有对并发导出的锁，两个人同时点“导出”就会生成半个文件；文件名用的是系统时间戳，重复导出容易覆盖。这些问题没有一个是AI凭空“制造”的——是需求描述里根本没有提到这些约束，而实习生本人也完全没有意识到这些约束存在。

这就是关键：Vibe Coding 廉价化的，是“把规格翻译成代码”的翻译层，而这层恰恰是过去很多初级程序员赖以生存的岗位壁垒。以前一个需求从产品经理嘴里的“做一个导出功能”到真正的代码落地，中间需要大量显性的工作量：字段映射、分页边界、权限校验、日志埋点、性能取舍。这些工作量以前是写进代码里的，现在AI帮你写了。因为它写得快，你甚至会产生一种错觉：这部分工作消失了。

实际上这部分工作一分钱都没消失——它只是从“你输入的代码里”转移到了“你没输入的prompt里”。你不说，AI不问，代码就成了。但问题不会因为AI没有问就不存在。那些没被描述的边界、没被提及的约束、没被想清楚的状态，最后全都留在了线的另一端：线上报警、凌晨值班、客户投诉、数据对不上。翻译层被工具吸收之后，程序员剩下来的工作，恰恰是更硬、更原始、更没法外包的那部分：把模糊的业务语言精炼成明确的问题描述，在不确定中拍板取舍，以及对一个自己没全写过的系统承担最终责任。

2. 只会 Vibe Coding 的人，通常踩在哪些坑上

2.1 代码能跑，不等于代码是对的

“能跑”和“是对的”，是Vibe Coding时代最容易被混淆的两个词。我见过太多人以“刚才本地测了一下，通了”作为唯一验收标准。可本地点通，只说明代码在一条阳光路径上没摔死。真正的生产环境是平行宇宙：网络会断、磁盘会满、Redis会挂、下游接口会超时、用户会传空字符串、有人会连点三次按钮。

AI生成的代码天然倾向于“写一条理想的逻辑”——它没有经历过一个真实项目里被需求、测试、运维反复蹂躏的过程。它的训练数据里确实包含了大量“如何处理异常”的代码，但它的默认偏好是把最常见路径写顺，至于那些不常见的分支，如果你没有在prompt里明确要求“补充异常处理和边界情况”，它大概率会给你一个肉眼看着很整洁、实际一压流量就崩的版本。

举个我自己的例子。有次我让AI写一个文件上传接口，prompt写了“支持上传图片、返回URL”。生成的代码确实做到了，能上传，能返回URL。但我降了一批压力测试之后发现：没做文件类型MIME校验，传个HTML上去就直接被托管服务当作网页执行了；没做文件大小限制，有人传了个2G的视频，把服务器磁盘直接打爆了；文件名用了前端传来的原始文件名，路径穿越风险拉满。这些问题，任何一个有经验的工程师都心知肚明要问一句“上传接口有哪些安全要求”，但AI没有问，因为——你没说。

这就是核心矛盾：你在用AI提速，但你让AI替你做了所有决策。AI的决策是统计平均值，而你的业务恰恰是平均值之外的例外。如果你只会一句“帮我做个上传”，你就把系统安全、稳定、可维护的全部责任，交给了这个统计平均值。

2.2 三座大山：看不懂、不会修、不敢改

Vibe Coding 用多了，一个特别隐蔽的后遗症会出现：你对自己的代码库越来越陌生。以前你写一行代码，晚饭后翻来覆去想的都是那个循环逻辑。现在呢？提交代码时的感觉，就像在银行柜台上按确认键——签了字，但合同内容你只扫了一眼。

问题在于，没人能永远只签合同不看条款。终于有一天，线上出问题了，你得去查AI给你生成的那段缓存代码为什么不失效，得去看那堆链式调用为什么在某种数据下会NPE。那一刻你面对的，是自己在“加速模式”下批量生产出来的一堆文本。你当时的记忆已经被下一个prompt冲掉了，你根本不知道这段代码里藏着什么假设。这叫“看不懂”。

然后你试着改。你小心翼翼地改了一行，发现测试挂了，你没有把握是哪里连带坏了——因为你没有真正掌握这片代码的地形，这叫“不会修”。最后你只好把它封起来，在旁边又叠一段AI生成的补丁代码，形成一种“头上一层保险丝”的结构，这叫“不敢改”。

这三座大山叠在一起，最典型的画面就是：出了问题，第一反应不是打开编译器和日志，而是打开AI对话框，把报错贴进去，然后等它给一个“看起来差不多”的方案。这种工作方式让程序员从“系统的owner”退化成了“AI的传话筒”。你成了一个中间层，而中间层在产业链里的宿命，是被自动化和压缩。

2.3 长期后果：堆代码和系统性腐化

再往深说一层。单次生成的代码就算小问题不断，至少还能改。最怕的是整个系统的架构水准，被Vibe Coding悄悄拉低。AI按单点需求逐段生成代码，你逐段接受，代码库就自然地朝着“扁平、重复、碎片化”的方向发展。

典型特征我列一下：同样的一个数据转换逻辑，在系统里出现了七八份，因为每次都是重新描述需求让AI写；一个输入校验，有的地方放在Controller里，有的地方放在Service里，还有的地方压根没有；系统里出现了三个并存的“用户状态”概念，AI在生成时自动匹配了最近的、可能并不是真正正确的那个。长期下去，系统会变得“像是一锅乱炖”：功能都能用，但没人说得清某块逻辑到底在哪儿定义、被谁依赖。这种代码比“写得丑”可怕得多——“写得丑”至少是人写的，有一定的个人风格和一致性；而AI分片生成的代码，没有一致性，没有全局观，它只对单次prompt负责。

这就好比你装修房子，每一间屋子都请了一个不同的施工队，管道线路每间都是最优解，但整栋楼的承重和管线集成，没人想过。Vibe Coding 时代没有“系统性”这个概念，是最危险的。因为系统级的设计能力，恰恰是人类工程师区别于AI生成器的最后根据地，而让它长出大量重复代码，等于你亲手把根据地里的草烧了。

2.4 常见问题速查表

3. 淘汰的临界点，不是“AI会写代码”，而是“你还会什么”

3.1 AI替代的边界在“问题空间”，不在“代码空间”

先明确一件事：AI确实在吃掉代码生成这个环节，而且吃得很干净。十年前，写一个登录注册是初级程序员练手的正餐；五年前，写一个增删改查接口是外包公司按天计费的工作量；今天，这套东西你在Vibe Coding模式下跟AI用自然语言说五分钟，它就全部给你弄好，还能给你配上漂亮的注释。

所以如果你认为“程序员的工作=把接口写出来”，那你的确有充分的理由焦虑。但如果你后退一步看，会发现编程工作里其实一直有价值分层：最底层是“用代码表达已知方案”，中间层是“在多个方案间做取舍”，最上层是“在未知和模糊的问题里定义出什么是‘对’”。AI极速压缩的，目前来看主要是底层；中层正在被部分渗透，但依然需要人类来做约束和裁决；而顶层的“问题定义”，到目前为止AI还没有真正接手——它顶多是在你做完了定义之后，流畅地帮你补充实现细节。

这个分层结构是理解“淘汰”的关键。淘汰从来不是“AI会不会替代我”，而是“我的不可替代性恰好位于哪一层”。一个人如果全部价值都押在“会用AI把需求变成代码”，那需求从产品经理嘴里说出来的时候，AI可以直接接住——产品经理开始成为更大的受益者。那个人被谁淘汰的？不是被AI淘汰的，是被他能做的那个环节的“市场价归零”淘汰的。

3.2 什么样的程序员最危险

基于我这些年的观察，最容易看到天花板、最先感到水温不对的，往往是这三类人：

第一种，毕业两三年、靠Vibe Coding把日常CRUD全部外包、自己却连一个排序算法都要靠AI现写的。他们的问题不在于“代码写得少”，而在于基本盘太薄。你没有手动写过轮子，就很难理解AI生成代码里的复杂度从哪里来；你没亲手排过一个并发队列，就不会知道AI给你的那几行Thread.sleep其实是非常粗野的补偿策略。一旦AI生成的代码需要深入调试，他们直接抓瞎。

第二种，只会在“顺风局”里做开发的人。需求清晰得像说明书，字段都对接好了，prompt一发，代码一收，完事。可一旦遇到需求本身是矛盾的、目标和约束在打架的情况——产品说要快速上线，运营说要完整追踪，客户说要低延迟——他们就完全没有能力通过代码层面的取舍来平衡这些张力，只能不停地把冲突抛回给会议。这种“问题空间里的导航能力”，恰恰是AI最不愿意揽的活，也是这类人最薄弱的环节。

第三种，最隐蔽也最可惜的，是那些其实有很好的底子和经验、但因为太信任AI输出而彻底放松“审视”的人。他们并不是不会，而是长期不做最后把关者，导致嗅觉钝化。就像一个开了十年车的老司机，突然换了自动驾驶，然后全程刷手机。等系统的某个细微异常已经蔓延失控时，才发现自己已经很久没有“上手”了，已经不具备那种在崩溃前几秒钟把方向盘拉回来的肌肉记忆。

3.3 不会被替代的部分，是“扛事的能力”

跟上面的危险画像对应的，是那些在Vibe Coding时代反而越来越值钱的能力。说到底一句话：AI负责把“说出口的需求”写成代码，人类负责把“没说出口的问题”变成说出口的需求，并为结果负责。你没说出口的问题包括：这个功能真的有必要做吗？如果用户点了两次会怎样？如果上游数据里混进了脏数据，我们是修数据还是修代码？如果明天要支持多语言，这个表结构会不会成为瓶颈？

这些问题没有标准答案，每一个都需要把业务逻辑、系统现状、团队成本、时间窗口放在一起权衡。AI给出的“答案”再多，也只是生成器，它不会在凌晨三点被叫醒去面对客户的数据事故，不会为一句不靠谱的“我觉得这样做应该没问题”背锅。而恰恰是“敢拍板、敢负责、扛得住事”这三个字，构成了程序员的职业护城河之一。可能讽刺的地方在于：当AI把所谓“技术活”的门槛碾平之后，这个“扛事能力”的权重反而会变得更高。

4. 避免被淘汰的实操路线：从“跟着感觉走”到“带着问题走”

4.1 把 Auto Pilot 调回 Copilot 模式

实操第一件事，调整你和AI协作的方式。很多人用AI写代码，是全程“自动驾驶”心态：prompt一给，输出一收，Tab一按，往下走。我建议所有正在认真对待这个职业的人，立刻把心态拧回“结对编程”：AI是你的结对搭档，不是你的代驾。

具体落地办法：AI每生成一段代码，你接过来的第一件事不是运行，而是读。通读一遍，就像你以前评审同事的PR那样。读的过程中做三件事：标注所有你不确定的函数调用；找到所有TODO/忽略异常的地方；在脑海里用自己的话复述一遍这段代码在干嘛。复述不出来的地方，就是你需要重写或者深入理解的地方。

我自己的习惯是，每段AI输出，至少会手打重写其中的一个关键函数或那一段我自己觉得最别扭的逻辑。这听起来反效率，但你试一周就会发现：一个代码块如果自己重写过，你对它的记忆深度和对系统调用的理解，是“纯接受”方式的十倍都不止。重写不是浪费时间，是在修复你亲手创造出来的“认知债务”。

4.2 五分钟内必做的三轮验收

给自己定一个规则：任何AI生成的代码，上线之前必须过至少三轮检查，每轮五分钟：

第一轮，跑通性验证。启动项目，手工走一遍主要流程，确认核心路径没问题。但这轮只能算“最低门槛”，不能作为验收终点。

第二轮，边界审查。把代码拉出来，逐行问“如果这里的数据是空的怎么办？”“如果用户输入了超长字符串怎么办？”“如果下游接口返回了500怎么办？”对每一个你问出来的“如果”，如果代码里没有对应的处理分支，别让AI自己补，你先想清楚这个分支应该做什么，再让AI补上对应的校验和兜底逻辑。原则上所有对外暴露的入口，必须做三件套：输入校验、鉴权校验、限流或幂等处理。

第三轮，局部风险审计。看看这段代码是不是动了全局状态、有没有在循环里做数据库查询、有没有把大对象直接塞进缓存、有没有在事务里做外部调用。这些Vibe Coding最容易踩的高频雷区，每一处都要亲自盯。把这三轮固化成本能，你会从“AI的验收员”升级成“系统质量的最后一道闸门”。

4.3 给AI下需求，不是描述心情

再一个非常实际的技巧：prompt的写法和普通的聊天完全不一样。你同事跟你说“帮我把导出修一下”，你们还能靠共同的上下文脑补；但AI没有那个上下文——特别是你现在手里的代码，是你自己都没完全搞懂的AI生成代码时，它更无从脑补。所以，给AI下需求，要像写验收单一样：

• 给例子：不要只说“做用户列表页”，给一个最小数据样例，列出输入字段、预期输出格式、异常输入的长相；
• 给约束：明确“这个接口单秒最多500QPS，失败要快速失败，不允许拖死主线程”，这样AI才可能在生成时把性能策略考虑进去；
• 给验收标准：告诉它“写完要用这三个测试用例验证，覆盖正常、边界、异常三种情况。少一个我都算你没做完”。

这套描述习惯练下来，你会逐渐发现两件事：第一，你收到的AI代码质量明显上升；第二，也是更重要的，你会被迫把所有模糊的、隐藏的、说不出口的需求一点点显性化。这本身就是高级工程师的核心训练。你是在用AI这个“提问机”逼自己把业务想清楚。

4.4 每天手写一点代码，守住基本功

最后一个建议，听起来有点土，但所有我在现实里见过“稳稳站住”的AI时代老工程师都在默默地做：每天留出30分钟到1小时，不碰AI，纯手写。不是写业务CRUD，是写那种需要动脑的数据结构、缓存淘汰策略、并发限流器、状态机。有没有实际产出不重要，重要的是保持“裸手编程”的脑回路通畅。

原因很朴素：判断力需要手感。你只有自己手写过LRU Cache，才能在AI生成一个LinkedHashMap实现但没考虑线程安全时，一眼看出问题；你只有自己排过分布式锁的问题，才知道AI给你的基于数据库时间戳的“锁”在集群环境下有多脆弱。AI可以帮你加速到一百公里，但方向盘上的手感，那些真正负责的微操作，必须长在你自己的肌肉里。这也是我在Vibe Coding浪潮里看见的、最反直觉的规律：越是依赖AI，就越需要手工；离开手工，你的判断力会先于你的代码量衰竭。

5. 常见问题与招聘视角：团队在筛选什么样的人

5.1 面试题正在发生的变化

因为工作原因，我这两年前后面试过上百个工程师，一个特别明显的变化是——面试题不再只问“写一个算法题”，而是开始给一段“特点鲜明”的代码，让候选人指出其中的问题并修复。这些“特点鲜明”的代码，其实就是典型的AI生成代码：命名很规范，注释很完整，逻辑看起来清清楚楚，但它就是有一个致命的边界错误，或者缺少一个关键的安全校验。

我拿一道经典的题举个例子：给一段AI生成的“购物车结算接口”，里面算完总价就直接扣库存、生成订单，看起来没毛病。问题设置得很隐蔽：没有事务控制，扣库存成功但生成订单失败时数据会不一致；没做幂等校验，用户双击提交就会生成两笔订单；没有校验商品是否已下架，先查出商品然后做了一堆计算才发现状态不对。你说它是“业务复杂”吗？不复杂，就是三个边界点。但你会发现，只会Vibe Coding的候选人，会把这段代码读得熟熟的，然后说“我觉得挺好”。而那些有经验、有自己写过代码手感的人，会脱口而出：“这是AI写的吧，三个问题：事务、幂等、状态校验。”

另外一类高频考题是“给定一个场景，现场说出你的方案”。注意，面试官要的不是一个“标准答案”，而是你的取舍逻辑。比如“设计一个排行榜，要求日活千万”，你是用Redis的ZSet，还是用DB的order by，还是用内存+定时刷盘？你不需要在五分钟内写出来，你需要的是快速权衡数据量、实时性、成本，然后拍板。这一刻，AI在哪里？没有AI。这就是纯人肉的“问题空间里导航”，也是Vibe Coding不可能替你带的“驾照”。

5.2 面试官到底在测什么

透过这些题，背后的考察逻辑其实就三个词：验证能力、定位能力、拍板能力。

• “一段AI生成的代码，你能看出哪里不对”——测的是验证能力。你不会读，就发现不了，发现不了就保护不了系统。
• “线上出了诡异的问题，你先查什么”——测的是定位能力。你是先看监控还是先贴报错给AI？前者是工程师，后者是传话筒。
• “两个方案各有优劣，你怎么选”——测的是拍板和取舍能力。AI可以给你十个方案，但敢为其中一个负责的，还是得你。

这三个能力，没有一个是“代码写得快”可以替代的。它们都来自长期跟真实系统较劲的经验积累，来自亲手制造过故障、又亲手把故障一点点排查干净的痛苦回忆。Vibe Coding能让你跳过“制造故障”的部分，但也会让你失去“修复故障”的锻炼机会。这就是为什么过了AI编码这段蜜月期的团队，招人时会更多地考察这些硬功夫。

5.3 给正在焦虑的人一句准话

聊到这里，我可以把最关键的一句准话直接甩给你了：如果你现在只会Vibe Coding，你没有必要恐慌，但一定要意识到，你正在拿“写代码的快感”麻痹自己对系统、对业务、对风险的敏感度。你可以继续用AI写代码，前提是你同时在做第4章那四件事——把它当结对伙伴、做三轮审核、学会需求拆解、每天练手。只要底盘还在，AI对你而言就是杠杆而不是拐杖。

反过来，如果你已经发现自己很久没有读懂一整段代码了，很久没有因为“这代码哪里不对”而兴奋过了——那比“被AI淘汰”更值得你警惕的，是你自己主动把方向盘交了出去。AI时代最珍贵的人，是那些既能让AI干活、又能在AI出错时兜底的人。这支队伍的门槛没有变低，只是入口的位置变了。

我个人在实际工作中的体会是：每次我看到某段让我惊艳的代码，惊喜过后都会习惯性地问一句“它处理异常了吗？它考虑并发了吗？它怎么保证数据一致性？”。这三连问，救过我很多次，也帮我筛过很多人。如果你能从今天开始，对Vibe Coding出来的每一行代码都保持这种“怀疑之后的确认”，你已经在往不会被淘汰的方向走了。