上周有个朋友兴致勃勃地跟我讲他三天就做出了一整个项目原型全程都在 Vibe Coding——代码全部交给 AI 生成他自己一行都没细看。我顺口问了句如果某个页面出了问题你打算怎么定位他答得理直气壮把报错信息粘回去让 AI 自己修。听完这句话我突然明白杰瑞米·霍华德最近那场对谈里为什么抛出了一个扎眼的比喻Vibe Coding 就像在拉老虎机而 AI 正在剥夺人类获得直觉的权利。这句话值得每一个天天念叨“AI 生成代码真香”的人停下来想一想。不是说不能用 AI 写代码而是我们大多数人现在用它的方式本质上不是在提效而是在把自己训练成一个只会摇杆、不看赔率表的赌徒。今天这篇文章我想把这个观点掰开揉碎老虎机比喻为什么精准、直觉到底是怎么来的、失去直觉之后行业会面临什么以及我目前在实操中摸索出的“用 AI 但不过度依赖 AI”的边界策略。1. Vibe Coding 突然火了但大家都在避而不谈一个代价1.1 什么是 Vibe Coding从“描述”到“交付”的体验Vibe Coding 这个词在最近一两年迅速走红形容的是一种新的写代码方式开发者不再逐行编写和阅读代码而是用自然语言描述自己的需求交给 AI 编程助手生成实现然后运行、看结果、再继续对话调整。整个过程更像是在“沟通”而不是在“编码”。一个典型的 Vibe Coding 工作流大概是这样的你打开编辑器在对话框里输入“帮我写一个 Python 脚本读取这个 CSV 文件按日期聚合销售额输出一张趋势图。”AI 噼里啪啦生成几十行代码。你运行一下图出来了差不多能用好下一件事。遇到报错直接把红色报错信息复制回去“这个错误怎么解决”AI 给出补丁你贴上再跑一遍通过了。整个过程里你像一个项目经理AI 是你的程序员而你唯一要做的判断是——屏幕上出现的东西“看起来对不对”。这种体验确实有一种解放感。语法记不清楚没关系第三方库的 API 用不明白也没关系甚至不理解的算法都可以让 AI 先写一版再慢慢调。对很多非计算机背景、或者刚入门不久的人来说Vibe Coding 把“写程序”的门槛从“会写代码”降到了“会描述需求”。1.2 为什么程序员会沉迷这种工作方式很多人最初接触 Vibe Coding 是抱着“试试看”的心态但一旦上手就停不下来。原因很简单即时反馈带来的爽感太强了。传统写代码的流程是想清楚逻辑、写代码、编译、遭遇报错、查资料、修改、再编译一个循环下来可能小半天就过去了。而 Vibe Coding 的节奏是把反馈周期从“小时级”压缩到“秒级”。你打字AI 出代码你运行看到结果再继续整个过程像是和一个反应极快的助理配合。这种短反馈循环本身就会触发大脑的兴奋感。再加上 AI 生成结果的不确定性——有时候非常惊艳有时候非常离谱这种“开盲盒”式的节奏比单调的确认性工作更让人上瘾。很多人嘴上说“我只是用它写点样板代码”实际使用时长却一路飙升最终变成几乎所有代码都让 AI 写。大家不愿意承认的是我们沉迷的不是“把事情做好”而是“看着代码源源不断被生成”的刺激感。这种刺激感背后掩盖着一个正在发生但很少有人讨论的代价——我们正在失去对自己所编写系统真实状态的理解能力。1.3 代价不是“AI 会出错”而是“你不再看代码”最常见的辩护是“AI 写的代码有问题我让它改就是了。”这句话听起来合理但实际上暗含了一个致命的假设——你有能力判断 AI 改得对不对。判断能力从哪里来从对代码本身的理解来。当 Vibe Coding 成为唯一的编程方式你从头到尾都没有阅读、推演、验证过这段代码的内在逻辑你的判断依据就只剩“运行结果是否符合预期”。在简单场景下运行结果确实能说明一切可一旦代码涉及并发、权限、数据一致性、边界条件运行结果正常根本不能代表代码正确。真正的问题不在于 AI 会写出有 bug 的代码这个大家都知道。真正的问题是Vibe Coding 让开发者彻底丧失了发现问题的伏笔和判断修复是否得当的能力。我们后面要聊的“直觉”被剥夺就是从这个节点开始的。2. “拉老虎机”比喻为什么精准随机奖励正在重塑你的工作习惯2.1 老虎机的核心机制不是“赢钱”而是“不确定”杰瑞米·霍华德用拉老虎机来形容 Vibe Coding很多人以为他想说“AI 生成质量不稳定像是赌博”。这个理解对了一半另一半更值得深挖老虎机真正厉害的地方不在于它让玩家“赢不到”而在于它用不可预测的奖励机制让人深陷其中无法停下来。心理学里把这种模式叫“可变比率强化”当奖励出现是完全不可预测的但整体概率又不是完全为零时行为会变得极其顽固。鸽子实验里鸽子在随机投喂的装置面前啄按钮的次数远超在固定投喂条件下赌场里老虎机让人反复拉杆的理由恰恰是你永远不知道下一把会不会中。这就是拉老虎机的微妙之处。如果每次拉杆都输你不会玩超过三次如果每次拉杆都赢你很快会腻。真正让你上瘾的是那种“也许这次不一样”的期待。Vibe Coding 完美复刻了这种心理节律。2.2 Vibe Coding 的奖励回路提交、等待、随机中奖亲手 Vibe Coding 过的人都体验过这种起伏有时候你给出一个模糊的需求AI 生成了八九成可用的代码你觉得自己像个预言家有时候同样清晰的指令AI 给出一个看起来完美实则漏洞百出的实现你花掉双倍时间去调更有甚者AI 一本正经地胡诌一个不存在的函数报错信息又长又绕让人瞬间烦躁。而这种起伏恰好是老虎机的宝藏配方间歇性的成功最让人上瘾。问题在于长期处于这种随机奖励回路里的人大脑会逐渐把“写代码”的心理体验从“有序思考”转变成“碰运气”。你不再觉得编程是一个逻辑推演的过程而是一场“猜对了就有奖”的抽彩。杰瑞米说要警惕正是因为在这样的机制下工作习惯会被悄悄重塑——你开始期待神奇时刻而不是期待理解。2.3 随机结果让你永远无法建立稳定的心智模型更深层的后果是如果你长期面对随机射出的箭你永远不会在脑中构建一个稳定的心智模型。什么是心智模型就是你不需要查文档也能大致猜到一个函数会怎么表现不需要跑完整套测试也能预估改动这段代码会波及哪里。它是长期处理稳定规律系统后沉淀下来的“判断力”。可 Vibe Coding 的系统不是稳定规律的。同样一个需求今天 AI 给的是一种风格明天是另一种同一个错误上一次它能精确修复这一次它可能南辕北辙。当你面对的是一个随机输出的系统你的大脑不会努力去归纳它的规律因为我们的大脑很聪明——面对不可预测的系统学习的收益极低放弃理解反而划算。于是你不再试图理解代码只关心这次能不能过。这正是“直觉”开始萎缩的信号。3. 直觉不是天赋是长期“读代码”换来的肌肉记忆3.1 “编程直觉”到底是什么东西在老派工程师的语境里“直觉”这个词常被神秘化好像有些人天生就对代码敏感一看到某个模块就觉得“这里会有坑”。其实不是。所谓的编程直觉剥开来看无非是一套高效的模式匹配能力。接到需求时直觉告诉你选 A 方案而不是 B 方案是因为你过去见过太多 B 方案在半个月后引发维护噩梦的案例。看到一段代码直觉让你停下来检查某个位置是因为你曾经在那儿踩过坑大脑把那种痛苦固化成了预警信号。调试时你很快猜出问题不在数据解析层而在状态管理层是因为你已经见过足够多类似症状的系统。这些判断速度之所以快是因为它们不需要每次都从头推演。你调用的不是逻辑链而是经验库。逻辑链只有一条路走到黑才能得出答案经验库却能在瞬间命中相似模式。因此直觉不是天赋而是长期处理真实问题的副产品。3.2 直觉是怎么形成的错误、痛苦和反复阅读具体来说编程直觉来自三件事。第一是大量阅读代码。读别人的代码尤其是高质量代码你的大脑会积累“好的代码长得什么样”的模板。写代码时你会不自觉地拿当前产物和这些模板对比差异越大越觉得别扭。这种“别扭感”就是直觉在报警。第二是大量犯错。人是从错误中学习的但前提是这个错误要经过你的思考和修改。第一次写出死循环、第一次在数据库事务里漏了提交、第一次没考虑时区问题每个坑都会在脑子里刻下一道纹路。犯的错越多你越能预判新的代码在哪里可能出错。第三是深度调试的经验。调试不只是“把 bug 修好”更是逼迫你层层剥开抽象外衣、深入底层机制的过程。一次艰难的调试胜过十次顺畅的编码因为它是用痛点把系统运行规则焊进脑海里。这三个来源有一个共同前提代码必须经过“你的”大脑。Vibe Coding 把这个前提整个移除了。3.3 AI 代写切断了直觉形成的闭环传统编程的闭环是写代码 → 报错 → 分析根因 → 修复 → 理解为什么之前错了 → 内化经验。这是一个完整的“刺激-反应-反馈-沉淀”过程每一次循环都会加深你对系统的理解。Vibe Coding 的闭环则是描述需求 → AI 生成 → 运行 → 如果不对 → 再描述 → AI 再生成。中间完全缺少了“分析根因”和“理解为什么错了”两个环节。错误不再是你需要翻越的山而是你转发给别人的工单。你体验不到代码为何出错自然也就无法形成“这类问题通常藏在哪”的预感。你不读 AI 生成的代码就像你天天请人代读一本书只听复述从不看原著。听完几百本摘要你可能知道剧情梗概但你永远无法品味到文字之间的肌理。这里有个更隐蔽的损失AI 生成代码的行文风格和注重视角会逐渐成为你的唯一参照。如果你只看 AI 写的代码你的“好代码模板”库就变得极其单一。终有一天你不仅不能评判 AI 代码的好坏连自己独立设计代码的能力都会严重退行。杰瑞米强调的“剥夺直觉的权利”指的就是这种不可逆的退化。4. 当直觉消失行业里会发生什么连锁反应4.1 最先滑坡的是调试能力被 Vibe Coding 重度浸润的人最先暴露出来的短板是调试能力。原因很简单调试是所有编码活动中最依赖直觉的。一个没有直觉的开发者面对一个“看起来正常但数据不对”的 bug 时只能从头到尾逐行打印日志或者漫无目的地修改代码然后一次次运行碰运气。而有经验的开发者会先快速锁定几个可疑的方向再精准地设置断点验证。这种“第一直觉猜中方向”的能力恰恰是 AI 代写帮不上忙的地方。更麻烦的是AI 修 bug 的能力在真实场景中非常有限。AI 生成代码出错AI 看到报错信息后给出的修复常常是打一个补丁又一个补丁每个补丁解决表面症状却在深处埋下更隐蔽的问题。没有基础理解力的开发者看到补丁能跑就满足了根本不知道新的炸弹已经埋好。我在实际项目里见过一个典型的例子AI 生成了一段异步处理逻辑偶尔出现竞态条件导致数据错乱。开发者把报错日志发给 AIAI 建议在函数开头加 sleep。加了之后出错频率确实下降了一些——因为 sleep 碰巧规避了竞态窗口。但这根本不是修复只是换了一个更隐蔽的方式掩盖问题。最后这套代码部署上线后在高峰期大规模出现数据错乱排查了整整两天根因正是那个被“睡眠魔法”掩盖的竞态条件。这就是没有直觉的人拿着 AI 补丁盲目修补的恶果。4.2 架构设计和代码维护变成“缝合怪”Vibe Coding 对日常小任务效率提升是很明显的但一旦进入架构层面问题就暴露得让人头秃。架构设计要求的是全局视野模块怎么拆分依赖是向上还是向下数据怎么流转哪些未来可能扩展哪些今天就要做约束。这些决策需要在整体系统层面进行权衡而不是某个局部“能否跑通”。用 Vibe Coding 方式搭出来的系统往往像一床用不同年代碎布拼成的被子。每个局部都是 AI 根据当时的提示词生成的当时的语境是独立的没有全局视角。今天让 AI 写一个订单处理模块明天让 AI 写一个库存同步模块它们各自运行良好但边界处的数据格式不一致、状态同步时序混乱、错误处理逻辑冲突等到联调时才会全面爆发。更让人绝望的维护场景是代码库已经变得无人真正理解。每一个模块都是 AI 生成的任何两个人都不完全清楚模块间的隐含依赖。这时候别说什么重构、优化、架构演进连安全地修改一行代码都变得困难。我把这种状态称为“继承无人代码库”——不是从离职同事那里继承而是从 AI 那里继承且没有任何文档或注释能救你。4.3 初级开发者的成长曲线被 AI 压平了这个连锁反应最终压在最脆弱的人群身上刚入行的开发者。过去初级工程师的成长路径是从写简单的功能开始踩坑读代码遇到搞不懂的问题硬着头皮查源码慢慢积累自己的心智模型。这个过程虽然慢但每一步都扎实三五年后能真正独当一面。Vibe Coding 改变了这一切。新人的工作模式变成给 AI 下指令、接收代码、提交、再下指令。他们确实交付速度飞快但五年后他们的能力储备可能和第一年的自己相差无几。AI 承担了所有需要思考的部分新人未经训练就能产出代码等于跳过了整个发育期。这种“用交付速度换成长速度”的交易对当事人来说很不划算。平台在上升期公司看到的是短期产出而对新人自己来说这笔交易可能是灾难性的因为直觉这种东西一旦错过建立的窗口期后面再想补回来需要付出比当年大得多的代价。还有一层风险是心理层面的。当一个人习惯了“代码由 AI 生成我只做裁判”的工作方式他会逐渐产生一种能力错觉代码是“我”写出来的系统是“我”设计出来的。等到真正需要他独立面对一个从未见过的问题时这种错觉会被瞬间击碎。而击碎的那一刻往往已经在他职业生涯中刻下了难以修复的裂痕。5. 我现在的使用策略把 Vibe Coding 关进笼子里5.1 什么场景我坚决不用 AI 生成被上面的分析说服之后很多人会走向另一个极端彻底不用 AI 写代码。我觉得没必要更不现实。问题的关键不是“用不用 AI”而是“哪些代码必须由人的大脑亲自完成”。我在项目中最核心的几条原则涉及资金、权限、数据一致性的代码绝不直接交给 AI 生成。这类代码的正确性往往要靠严谨的逻辑推演才能保证运行测试通过也不够。架构设计绝不交给 AI。系统边界、模块划分、接口契约必须由人基于业务场景和全局视图来定。复杂算法和性能关键路径也不用 AI 生成初稿。倒不是 AI 写不了而是你如果不亲手推导一遍就永远不会理解它的复杂度边界和适用前提。这几类代码有一个共同特点它们是最需要“直觉”的领域。一旦在这些地方放弃理解出问题的时候你连错误都无法描述更遑论修复。5.2 什么场景我放心大胆地用 AI同时我也发现 AI 在某些场景下确实是利器不用反而亏。样板代码和重复性代码比如写一堆几乎一样的 CRUD 接口、数据模型定义、常规配置项。这类代码价值密度低、模式固定AI 生成质量很稳定用起来没什么心理负担。快速原型验证我想试验一个新想法是否可行AI 生成一版粗糙实现我快速跑通验证概念然后再决定要不要认真做。这里 AI 充当的是草稿纸的角色。前端组件的骨架一个组件页面涉及大量标签、样式、交互细节让 AI 先生成大致框架我再逐个细节调整效率远高于从空白文件写起。测试用例的辅助生成虽然最终测试用例我会认真 review但 AI 帮我想出各种边界条件的出发点经常能补充我忽略的测试场景。这些场景的共同点是什么它们是低判断密度的工作价值在于“快速生成内容”而不是“做出关键决策”。用 AI 恰恰可以把时间节省下来留给那些真正需要人类判断的地方。5.3 一边用 AI 一边保持和强化直觉的日常功课如果你认同“直觉正在被剥夺”的判断但又不能彻底离开 AI那还能做什么我在实践中摸索出一套做法没有什么玄妙的原理胜在可持续。第一所有 AI 生成的代码合并之前必须逐行读一遍。这不仅是纪律也是在最经济的情况下保持代码阅读量的方式。读完顺手改几行你会逐渐形成自己的判断力AI 这里为什么这么写换成我会怎么写哪个更好第二重要的代码先自己想清楚再让 AI 写。我会先在文档或注释里写下自己的思路、伪代码甚至一个粗糙的手写版本然后再让 AI 完善和提速。这样 AI 是执行者而思考者依然是你。第三每周留一天“无 AI 日”。这一天从头到尾不打开任何 AI 工具所有代码、调试、重构全部手写倒逼自己恢复独立思考的状态。刚开始会很不适应但坚持几周之后你会明显感受到“手感”在回来。第四保持手写关键逻辑的习惯。比如核心状态机、复杂条件分支、数据结构转换哪怕 AI 能写得更好我也会自己写一遍。重复练习让那些最关键的思维路径始终处于活跃状态而不是慢慢生锈。第五认真复盘 AI 修过的 bug。每次 AI 给出修复方案不要急着粘贴先要求它讲清楚根因。如果它讲不清楚那你更要自己去看。这个环节是唯一能弥补“缺失的调试训练”的机会。我在团队里也立了一个规矩AI 修的代码Code Review 时必须由提交者逐行讲给评审者听讲不出来就退回去重看。规则听起来费时但执行一段时间后团队整体代码理解深度明显提升。我自己的体会是AI 工具就像一副好用的外骨骼。长时间穿戴可以搬动重物但如果从来没有锻炼肌肉一旦脱下来你可能已经忘了怎么走路。杰瑞米那句话说得很重但他真正反对的或许不是 Vibe Coding 这个工具而是那种放弃思考、沉迷随机回报的工作方式。按下生成按钮前先问问自己这一把我是在优化工作还是在赌运气根据我个人经验答案不同的人三五年后的技术水平会拉开巨大的差距。