那些年，AI帮我们写的bug

上周看同事跑测试，一个用AI coding助手"搞定"的PR。

测试跑崩了——不是普通的失败，是那种让初级程序员看了会怀疑人生的那种。没有配API key，接口返回的JSON格式完全不对，认证中间件形同虚设。

提交信息写的是："搞定用户登录流程 🍕"

那个披萨表情包，现在想想真是预警信号。

这不是一篇说AI有多烂的文章。AI代码生成确实让我的工作效率提升了不少。

这篇文章想聊的是：那种「看起来很靠谱」的AI输出，危险就危险在它太像那么回事了。 包装得太完美，反而没人会在上线前质疑它——直到凌晨两点生产环境炸了。

AI不会反驳你

有个事大家都不爱说：AI coding助手就是终极马屁精。

它不会怼你，不会追着你问"你确定要这么干吗？"，不会在凌晨三点提醒你"这个需求其实应该先问产品经理"。

你问它要一段代码，它给你。你没说清楚，它就自己猜着给你。反正出来的玩意儿看着挺像那么回事。

你团队里那个老开发可能会说"等等，这么搞有问题，因为……"——那个人在你的IDE里不存在。有的只是你、一个自动补全引擎、还有那10000行"看起来没问题"的代码，直到你真的跑起来才发现全是坑。

这就是陷阱所在。

走阻力最小的路，就是直接接受AI的建议。 就像任何你不用的肌肉会萎缩一样，评估架构决策的能力也会悄悄退化，等你反应过来的时候，可能已经稀里糊涂地批准了几个月烂代码了。

测试这件事，没人认真对待

说个让所有技术经理都应该警觉的数据：研究表明，开发者花在真正测试自己代码上的时间，还不到20%。

现在把这堆代码换成AI生成的——恭喜，你得到了一个灾难配方。

AI写代码的时候，它从来没在你的环境里跑过、没碰过你的数据库、没跟你的第三方依赖打过交道。

代码活在真空里——语法没问题，上下文一片空白。

解法不是不用AI。

解法是养成一个近乎虔诚的习惯：永远不要合并没有在自己本地环境手动测试过的代码。

对，这样慢。对，这样感觉在跟AI的生产力承诺对着干。

但是你想啊——那个吹上天的10倍效率提升，你要是出bug的速度比修bug还快，它就是个负数。

认知卸载的悬崖

把AI辅助想象成数学里的计算器。

计算器没有让人变蠢——它把人从繁琐计算里解放出来，去理解更高层的概念。

但如果你从来没学过竖式除法，计算器给你一个答案的时候，你根本不知道它算的是什么、怎么算的。

软件开发也一样。

你让AI帮你写"无聊的部分"，自己从来不理解那些部分在干嘛，总有一天你会到那个节点：你根本判断不了AI输出的对不对。

你只能选择相信机器说的，这跟闭着眼睛让车自己开进施工路段有什么区别。

这不是什么"编程是门手艺活"的理想主义情怀。

这是关于保持最基本的能力——在灾难到达用户之前亲手拦住它。

怎么找到平衡点

我不是说AI不好。在NameOcean，我们的Vibe Hosting平台就是靠AI帮开发者提速的。

工具本身没问题——问题是把它当成人类判断的替代品，而不是放大器。

跟AI coding助手健康相处的姿势是这样的：

• 用AI生成模板、脚手架、初稿
• 用AI探索不熟悉的API和文档
• 不要用AI代替你理解自己的代码库
• 一定要测完AI写的东西再让它上生产
• 把AI的建议当成code review意见——有用的输入，不是圣经

那个提交没测就跑测试的同事——他不是懒，也不是菜。

他只是掉进了整个行业目前都在给自己挖的坑里：速度的诱惑，让人忘了质量也是要成本的。

快速上线、快速试错、快速迭代——这是行业圣经。

但走着走着，我们好像忘了：坏了的东西修起来，花的是真钱、真用户、真信任。

最后说两句

AI coding助手对现代开发的意义，就像错别字检查对写作的意义。

有用，能抓小毛病，但告诉不了你论点本身成不成立。

"这个功能我们到底该不该做？""这真的解决用户问题了？"

这种问题，还是得人脑来问。

能在这个时代混得好的开发者，不是用AI用得最多的那批人。

是用AI用得最聪明的，同时让自己的基本功保持锋利的那批人。

是那种虽然不用手动拧每个螺丝，但知道发动机怎么转的那批人。

AI不是问题。

觉得有了AI就可以不需要人类把关——这才是问题。

所以，想怎么用AI快速跑MVP都行。

但点merge之前记住一句话：凌晨收到500报错的用户，可看不到你commit信息里那个可爱的披萨表情包。