Vibe Coding用3个月逼走核心开发，代码一致性全崩了

---

去年3月那会儿，我在推特上刷到好几个大佬狂吹 Vibe Coding，什么“用嘴写代码”“AI帮你扛80%重复劳动”，看得我热血上头。正好我们团队20个人，做SaaS的，React + Node.js那套，我在周会上拍着桌子跟CTO说这东西能让开发效率翻倍——对，我当时真这么说的，现在想想脸上都发烫。

结果呢？三个月之后，两个核心开发提离职，代码库烂成一锅粥，项目延期了六周。

今天把这段血泪史扒开给你们看。不整那些虚的。

等等，这里我要更正一下——其实不是两个人都提离职，是一个真提了，另一个聊完之后决定先留两个月看看情况。我得说准确点，不然显得我在编故事。

第一个坑：把Vibe Coding当银弹使

前两周是真爽。我记得特别清楚，4月8号那天，我用Cursor搞了个用户管理模块，需求描述写了几句，AI唰唰唰给我干出来三百多行，CRUD全套，连表单校验都写好了，手机号正则、邮箱格式、密码强度——它全给整上了。我当时截图甩团队群里，说“兄弟们以后不用手写样板代码了”，群里炸了一堆表情包。

乐极生悲。

第三周出事了。一个后端哥们用Vibe Coding搞支付模块的退款逻辑，他给AI描述需求的时候漏了个边界条件——部分退款时优惠券怎么分摊。AI按最常规的路子生成代码，测试环境跑得溜，结果上生产第三天，财务那边直接冲到我们办公区，说17笔退款金额对不上。总共差了4372块。

查了两天bug。那代码读起来巨痛苦，变量名全是tempData、resultList、finalVal这种，函数拆得莫名其妙，跟我们团队的风格完全不搭——我们平时命名都是refundOrderItems这种一眼能看懂在干嘛的。最后定位到问题：AI把优惠券全额算到第一件商品头上了，而不是按比例分摊。

那个后端哥们跟我说：“我以为AI会cover这种情况。”

我当时就想抽自己。因为启动会上我原话是“AI生成的代码基本不用改”，他是信了我才没细看逻辑。

第二个坑：代码一致性崩了

这个最头疼。

我们团队本来有一套自己的规范，比如错误处理统一用自定义的AppError类，API请求统一走我们封装的request层。但Vibe Coding生成的代码不认这套，它按训练数据里的“最佳实践”来——有时候try-catch，有时候.catch()链式调用，有时候直接throw一个字符串。你敢信？throw字符串，连个Error对象都不是。

第一月还好，大家还会手动改改。到了5月中赶进度，人就懒了。AI生成啥用啥，改改变量名就往上推。两个月下来，我们的代码库变成缝合怪——同一个项目里三种错误处理方式、四种API请求写法、useState和Redux混着用，状态管理搞出五种花样。

新人入职那天我到现在都记得。7月15号，周一，新来的前端看了三天代码之后问我：“咱们项目的架构原则是什么？”

我张嘴。闭嘴。愣是没答上来。

已经没有原则了。全是AI的即兴发挥。

第三个坑：开发能力退化

这个坑我最后才意识到，但最要命。大概落地Vibe Coding两个月之后——嗯...这个比较复杂，我觉得可能是5月下旬开始有苗头的——团队出现了一个很奇怪的变化。

大家开始“怕”写代码了。

有一次讨论搜索功能的实现方案，涉及倒排索引和分词策略，说实话这应该是技术团队的基本功对吧？结果几个开发第一反应是“我们先让AI生成几个方案看看”。我说咱们先自己分析下需求，有个前端直接回了句：“现在谁还手写算法啊？”

我当场愣住。

后来我刻意观察，发现好多人已经形成路径依赖了——拿需求喂AI，生成代码改吧改吧能用就行，遇到bug也是先丢给AI修，修不好才自己看。最离谱的一次，8月初，Cursor的API挂了半个小时，有个开发就在那等着，什么都没干。

我等了半天问他：“你就不能手写吗？”

他说：“等它恢复了效率更高。”

我当时血压绝对飙了。

三个月的时候我做了次代码审查，抽查最近两周的提交，60%以上是AI直接生成的，其中将近一半有潜在性能问题。有个查询没加索引，数据量小的时候屁事没有，但我们用户量在涨，这tm就是个定时炸弹。还有个地方循环里套了两次数据库查询，N+1问题搞得明明白白，压测不炸才怪。

到底哪里出了问题

回头琢磨这个事，Vibe Coding本身不是坏东西——我现在也还在用。问题出在我们的落地方式。

我总结了三个致命错误。

第一，没有制定使用规范。什么时候该用、什么时候不该用、生成的代码要经过什么级别的审查、哪些模块能用哪些不行——全都没定义。大家各凭感觉，有人啥都丢给AI，有人完全不用，各自为政。

第二，高估了AI对业务的理解。通用逻辑它能写得很漂亮，但业务场景里那些特殊规则、边界条件、历史遗留的坑，它根本不知道。我们指望它理解我们的业务，这事本身就错了。跟让GPT猜你公司报销流程一样不靠谱。

第三，忽视了团队能力的培养。工具越强，用工具的人越容易变弱——这个悖论我们亲身体验了。我现在觉得Vibe Coding更适合有经验的开发者用来提效，而不是让整个团队无差别依赖。就像你不会让刚学会开车的人直接上F1。

现在的做法

没完全放弃Vibe Coding，但使用方式彻底改了。

现在的规则：核心业务逻辑必须手写，AI生成的代码必须经过至少一次人工review，样板代码和工具函数可以用AI辅助但必须符合团队规范。另外每周搞一次“无AI日”——我学的是那种健身房的无器械日，保持手感——那天所有人关掉AI工具，纯手写。

效果还行。代码质量回升了，那个本来要离职的哥们也留下来了。他跟我说了句话我印象特别深：“现在这种方式让我觉得自己还是个程序员，不是AI的提示词工程师。”

这句话让我想了很久。

你们团队有没有试过Vibe Coding？是踩坑了还是真香了？评论区聊聊，我特别想知道是不是只有我们搞成这个样子。顺便说一句，Cursor现在0.43版本比之前好用多了，但上面说的那些坑跟工具版本没关系，是使用方式的问题——我得把这个说清楚，省得有人觉得我在黑哪个工具。