2025年初vibe coding这个词突然从技术圈的小圈子一路炸到了大厂周会和创业公司的融资PPT里。它描述的是一套看起来特别“未来”的开发方式你不再逐行敲代码而是像指挥一个水平不错的实习生一样用自然语言描述需求—— “帮我写一个用户登录接口用JWTToken过期时间设两小时”然后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 常见问题速查表现象本质原因最好的解法本地点通上生产就崩忽略了异常路径与边界条件在prompt里明确“处理边界情况、补充负载与并发约束”AI生成的代码看不懂没读过、没重构过只是接受强制自己复述一遍代码逻辑说不清就重写出了问题只会贴报错给AI没有建立对系统调用的整体认知先查日志与监控用“输入输出”来判断问题所在代码库重复逻辑爆炸每个需求都被当作一个孤立任务生成做代码抽象定期重构让AI在统一抽象上继续迭代安全漏洞漏过验收prompt没提安全要求默认所有对外接口都要做鉴权、校验、限流逐项核对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出来的每一行代码都保持这种“怀疑之后的确认”你已经在往不会被淘汰的方向走了。
2025年初vibe coding这个词突然从技术圈的小圈子一路炸到了大厂周会和创业公司的融资PPT里。它描述的是一套看起来特别“未来”的开发方式你不再逐行敲代码而是像指挥一个水平不错的实习生一样用自然语言描述需求—— “帮我写一个用户登录接口用JWTToken过期时间设两小时”然后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 常见问题速查表现象本质原因最好的解法本地点通上生产就崩忽略了异常路径与边界条件在prompt里明确“处理边界情况、补充负载与并发约束”AI生成的代码看不懂没读过、没重构过只是接受强制自己复述一遍代码逻辑说不清就重写出了问题只会贴报错给AI没有建立对系统调用的整体认知先查日志与监控用“输入输出”来判断问题所在代码库重复逻辑爆炸每个需求都被当作一个孤立任务生成做代码抽象定期重构让AI在统一抽象上继续迭代安全漏洞漏过验收prompt没提安全要求默认所有对外接口都要做鉴权、校验、限流逐项核对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出来的每一行代码都保持这种“怀疑之后的确认”你已经在往不会被淘汰的方向走了。
