上周有个朋友兴致勃勃地跟我讲，他三天就做出了一整个项目原型，全程都在 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 生成了一段异步处理逻辑，偶尔出现竞态条件导致数据错乱。开发者把报错日志发给 AI，AI 建议在函数开头加 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 这个工具，而是那种放弃思考、沉迷随机回报的工作方式。按下生成按钮前，先问问自己：这一把，我是在优化工作，还是在赌运气？根据我个人经验，答案不同的人，三五年后的技术水平会拉开巨大的差距。
