前阵子有位在深度学习圈子里摸爬滚打多年的开发者在一次公开对话里聊到了一个很敢说的观点Vibe Coding 的过程跟拉老虎机越来越像而 AI 正在慢慢拿走人类获得直觉的资格。这段话传出来之后技术群都炸了锅。有人觉得这是老派保守观念在贩卖焦虑也有人真的静下来面对了一个自己都不太愿意承认的问题我到底是在开发还是在不断下拉杆、听响声、消耗幻觉我自己的状态其实经历过从“AI 怎么写都对”到“AI 怎么写我都得盯着”两个极端。今天想把这件事彻底展开聊清楚Vibe Coding 为什么让人上瘾它到底从哪里偷走了判断力以及如果你还希望把能力留在大脑里到底应该怎么继续用这些模型而不是被它们带着跑偏。全文没有什么高深理论只有我亲身踩过的坑、试过的纠正方法以及给不同水平开发者的可落地建议。1. 用感觉写代码这碗饭到底吃不吃得下1.1 Vibe Coding 是什么又是怎么冒出来的先给没接触过的读者补个底。Vibe Coding 不是某个平台上的专属功能也不是一个严谨的学术名词而是一种逐渐自然形成的开发方式。简单说就是你把自己的“氛围”和“情绪”押给 AI打开对话模型描述一下需求把报错信息贴进去复制它生成的代码跑一下发现测试通过就默认这个功能完成了。整个流程的关键词不是严谨而是反馈快。它最早的形态其实是很多人早已在用的“AI 结对编程”。但 Vibe Coding 更极端一点你甚至可以不知道代码为什么能跑只要它“看起来没问题”你就能往下走。这种风格在一部分人眼里是未来在另一部分人眼里是灾难。但不管怎么看它已经在大量开发者的日常工作中占了很大比例。为什么它会突然冒出来大模型在代码生成上的表现确实到了一个可用的临界点。以前写一个复杂的正则表达式你要翻文档、试好多次现在一句话就能给你生成得七七八八。以前搭一个完整的前端页面骨架你先得规划组件结构现在模型直接帮你铺好。对项目早期探索阶段来说AI 这种降低行动门槛的能力带来的是肉眼可见的效率增长没人能忽视它。我见过不少团队用这种方式把演示项目周期从三周压到三天这种收益体验是实实在在的。但也正因为如此它特别容易让人上头一不小心就变成一种依赖。1.2 为什么大家对它上瘾从心理机制上看Vibe Coding 的上瘾特征非常明显它同时满足了好几个即时奖赏条件。第一个是即时生成带来的完成假象。以前写完一个功能要编译、要调试、要处理边界问题过程是漫长的。现在你敲一句需求描述十秒钟之后就能看到一段完整代码这种“小步快跑”的节奏会不断制造“我在快速产出”的满足感。第二个是试错成本骤降带来的随意感。以前改一个关键模块你得顾虑改动会不会连带破坏其他东西。现在你把报错丢给 AI让它自己改改完再跑一遍就行了。试错的门槛低到几乎不存在于是你会越来越倾向于“先试再说”而不是“先想清楚再说”。第三个是反馈回路极短带来的刺激感。老虎机之所以让人沉迷不是因为它能稳定赢钱而是因为它的结果不可预知但每次开奖都很快。Vibe Coding 也有这种“开奖感”你发出一个 prompt等着代码回来就像等着转轮停住。有时候结果很好有时候莫名其妙而你想再接再厉的心思会被这种不确定性勾得越来越强。这不是道德评判而是实事求是的心理分析。作为开发者要知道自己在用什么心态工作才能知道什么时候该抽身。1.3 它解决的问题和它回避的问题Vibe Coding 确实解决了非常实际的问题这一点我完全承认。它适合的场景包括早期原型探索、内部工具开发、一次性脚本编写、数据清洗和格式转换、跨语言代码翻译。这些需求通常边界模糊对代码质量要求不高核心目标是“先跑起来看看”。用 AI 来打头阵性价比很高。但它同时回避了工程里真正难啃的那部分结构性设计、边界情况处理、安全校验、并发与状态问题、长期可维护性。AI 生成代码有个明显倾向它会沿着“看起来正确的路径”走把异常分支写得又粗又浅。如果开发者本身不做深度审视这些问题就会沉淀下来变成项目里的隐形定时炸弹。所以我的判断是Vibe Coding 作为一种“探索工具”是有效的作为一种常态化的“交付方式”则非常危险。它应该是你思考链条里的一环而不是思考本身。2. 拉老虎机的体验是爽感还是陷阱其实不重要2.1 一次押注、一次开奖的运行结构把 Vibe Coding 比作拉老虎机不是单纯的比喻它们的运行结构确实有很强的相似性。老虎机的基本操作是投币、拉杆、看结果。Vibe Coding 的基本操作是写需求、按回车、看结果。关键在“看结果”这个动作上。结果出来以后如果代码直接可用你会得到一种正反馈觉得自己这个 prompt 写得很好。如果代码报错你会进入下一轮拉杆换个说法或者追加更详细的描述直到开出一个“能跑”的结果为止。这个过程最有迷惑性的地方是你全程都在做动作所以会产生一种“我在努力解决问题”的错觉。但实际上真正在解决问题的很可能不是你而是模型在训练数据里见过的相似代码模式。你的思维方式没有参与到问题的拆解里你只是在操控一个概率机器。说得难听一点这种开发方式里真正有技术含量的部分也就是定义问题边界那一步被压缩得越来越小。而拉杆的动作也就是重复告诉 AI“你不对重新来”占据了大量时间。2.2 赢钱的情况确实存在但只是让你更不想离开有人肯定会说AI 确实帮我写出了很多能用的代码这你怎么解释我不否认这一点。尤其是那些重复度高的开发工作比如写 CRUD 接口、做表单校验、翻译旧代码逻辑AI 生成的能力已经非常稳定。在这些场景下它的确能省掉大量时间像是老虎机偶尔也会吐出一堆让你尝到甜头的硬币。问题在于这种“赢钱”很容易让你把功劳记在自己手里从而忽略了一个事实这些能赢的场景本质都是低风险、高重复、强规则的任务。它们能赢不是因为你的判断力有多强而是因为模型的训练数据里积累了足够多的标准答案。更值得警惕的是一旦你习惯了这种稳定赢钱的感觉就会开始不自觉地扩大拉杆的范围把它用到高风险的场景里。比如安全权限判断、金融金额计算、核心调度逻辑。然后某一天你会突然发现 AI 给出的代码在测试环境上完美运行却在生产环境里漏掉了一个关键分支造成不小的损失。我身边就有真实的例子某朋友负责一个内部管理系统的权限模块图省事把权限判断逻辑全交给 AI 生成测试用例也是 AI 生成的。结果上线当天就被一个普通账号绕过权限直接访问到了管理接口。代码逻辑看起来很完整但偏偏漏掉了“是否对同租户资源做隔离”这一层判断。你说这是 AI 的问题吗不这是把高需求复杂度任务错误地当成了低需求复杂度任务。2.3 一个我印象深刻的“伪成功”案例去年我给一个内部小工具做数据导出的功能当时图快用了一段 AI 生成的前端代码。功能很简单前端选择列后端返回 JSON前端把数据转成 CSV 下载下来。我用测试环境那几条简单数据跑了一遍下载的文件格式看起来完全正确字段顺序、内容数量都对当时就交付了。结果真实用户一用就炸了。用户选了一个包含复杂字段的视图某些字段值里本身带逗号和换行符CSV 导出后这些字段没有做转义处理导致整个表格错位。更隐蔽的问题是AI 生成的映射逻辑里用硬编码的字符串去匹配 JSON 字段名一旦后端新增一个字段前端就静默地把数据丢掉了不报错、不提醒。这个问题的根源不是 AI 不聪明是我根本没有做验证只看到表面结果正常就交付了。如果我当时坐下来认真读一遍生成的代码读 10 分钟就能发现这两个问题。而事实上我连读都没读直接复制粘贴跑通就完了。这个过程跟拉老虎机看到“三个图案接近对齐”就觉得自己要赢了一样只是一种错觉。2.4 散点式的成功如何慢慢磨掉判断力人类建立对某个领域的判断力依赖的是一个完整的感知闭环先观察到现象然后提出假设再通过验证来判断假设是否成立。这三个步骤缺一不可。传统的编程工作天然就在训练这个闭环。你写一段代码跑起来结果不对你观察你猜原因你再写测试去验证。一整个循环下来你对这门语言和系统的理解就加深了一层。但 Vibe Coding 把中间最关键的一步——“提出假设”——整个删掉了。你观察到代码报错然后你就把错误丢给 AI让 AI 猜。AI 给出一个修改你跑结果对了你接着走。整个过程里你没有建立任何因果关系的心智模型。你的大脑没有参与“为什么错”和“怎么改才对”的推理只是扮演了一个令牌搬运工的角色。短期看你完成任务的速度快了。长期看你对代码底层逻辑的敏感度会不断下降。因为你不再需要知道为什么只需要知道能不能跑通。这就是那位开发者说的“剥夺直觉”的核心意思直觉不是凭空来的是千百次有效验证堆出来的而你现在把验证的过程外包了直觉自然就萎缩了。3. 直觉不是玄学而是你对错误的嗅觉3.1 程序员的直觉到底是怎么形成的好多非技术读者可能会觉得“直觉”这个词在编程里显得很玄好像是一种天赋。实际上程序员的直觉更像是长期与错误打交道之后形成的模式识别能力。举个例子一个写 Java 写了很多年的人看到一段可能发生空指针的代码会本能地觉得“这里不对劲”。他不会每次都真等到报错才知道有问题而是在看到代码的第一眼就泛起一种模糊的不安。这种感觉不是天生的是因为他过去真的踩过无数次空指针的坑大脑把失败案例里的共性模式提取了出来存进了潜意识。同样一个写并发程序的老手看到共享变量被多个线程无保护访问会立刻警觉。一个处理过线上事故的人看到一个没有设置超时时间的 HTTP 调用心里也会“咯噔”一下。这些反应速度非常快快到不经过逻辑推理所以被叫作直觉。但本质上是长期错误经验在大脑中形成的快速索引。AI 没有这个东西它也不会教你这个东西。你只有自己去看、去试、去错才能建立这种索引。这也是为什么我认为AI 时代的程序员最宝贵的资产反而是那些“踩坑踩出来的敏感度”。3.2 AI 帮你取消试错也帮你取消了对错误的感知现在我们回到 Vibe Coding 的语境。你写一个功能把需求交给 AI。它帮你写好了你跑通过了。如果你全程没有参与推理你就错过了从“运行结果”到“原因假设”之间那段最重要的神经连接。这不是危言耸听这叫反馈缺失。就好比你想学会判断一道菜熟没熟如果每次都由别人帮你尝好了再告诉你“可以出锅了”你永远学不会自己判断。你可能知道做菜流程但你没有形成关于火候的直觉。因为你没有亲自体验过“糊了是什么感觉”“生的是什么感觉”“恰到好处是什么感觉”。代码也是同理。你不知道边界情况下会发生什么不是因为你的智商不够是因为 AI 已经把错误处理的部分替你“填平”了。你以为代码很健壮其实只是 AI 生成的路径恰好覆盖了测试用例根本没有把异常路径暴露给你看。这种隐藏的粗糙最终会在某个意想不到的角落里爆发而且爆发的时候你因为缺乏直觉往往连原因都找不到。3.3 年轻组员、老手和 AI 之间的三角关系在团队场景里这个问题会变得更加微妙。老手通常带着过去十几年积累的错误模型来使用 AI他们看到 AI 生成的代码能快速分辨出哪些部分有隐患。而年轻组员没有这种根基他们把 AI 当成标准答案看到生成结果的第一反应不是审视而是接受。这就导致了一个很尴尬的局面老手在帮 AI 善后年轻组员在给老手制造善后需求。我见过不少团队引入 AI 协作之后新人写代码的速度显著提升但代码出 bug 的比例不降反升。原因很简单新人不懂这些 bug 为什么是 bug因为 AI 替他们把能踩的坑都伪装成了平路。这不是年轻人的错也不是 AI 的错而是训练方式出了问题。新人需要的不是“避免碰 AI”而是“带着批判心态用 AI”。我在带模拟项目 X 的实习生时强制要求他们AI 生成的每段代码必须自己写三行注释解释各自的部分是什么并且画出数据流向。一开始他们觉得麻烦但一个月后明显能感觉到他们对代码的理解深度比纯 AI 流水线模式要扎实得多。3.4 一个更通俗的类比开车、做饭、写代码关于直觉这件事我经常爱用做饭来打比方。你学做饭的时候师父告诉你“大火收汁”。你第一次做了汁糊了你才知道“大火”到底是多大。第二次你注意了又发现收得太干。第三次你看到锅里冒泡的状态突然明白了“哦原来到这个程度就该关火”。这个从茫然到熟练的过程靠的就是一次次亲手失败后形成的反馈。码农的直觉真的是这样一次一次磨出来的。另一个类比是开车。老司机开进一条窄路不看后视镜也知道车尾的大概位置这种距离感也是撞过几次、刮过几次之后才长的。如果每次倒车都让 AI 帮你操作你可能倒得很好但你永远不会长距离感。把这两个类比落回代码上意思就很清楚了AI 可以帮你把代码写出来但它不能帮你把“错误和原因之间的连接”长在你脑子里。这一部分只有通过你自己亲历错误才能慢慢累积出来。4. 边用 AI 边攒直觉我是怎么给自己兜底的聊了这么多风险不是让你把 AI 扔了回到手写码农时代。那既不现实也没必要。AI 作为工具用好了是效率放大器。关键是怎么用而不被反噬。下面分享几个我实践了大半年觉得真正有效的方法。4.1 写 prompt 之前先写下自己的答案我自创的一个流程现在每天都在用。当你准备把需求丢给 AI 时不要直接在对话框里长篇大论。先在旁边新建一个空白文档用自然语言写一遍你期望的行为注意几个点这个功能的核心输入是什么输出是什么。边界情况可能有哪些你目前能想到的最坏输入是什么。如果代码跑不通你打算从哪里入手排查。写这些东西不需要花很长时间但它的意义重大。它逼着你在向 AI 求助前先把问题在你自己脑子里跑一遍形成属于自己的初步假设。哪怕你写出来的假设是完全错的它也是你的推理起点。当你把这份“初始答案”贴给 AI 之后得到的回应就不是凭空而来的而是和你刚才的思考发生了碰撞。这种碰撞才有价值它让你能在 AI 的回馈中看到“我没想到的那部分”而不是被动接受一团完整方案。我自己的经验是只要每次写给 AI 的需求里附带三行以上“我认为应该注意的风险点”最终代码质量就会明显不一样。AI 会顺着你提醒的方向去补足防御逻辑而不是天真地沿着主路径一路写到底。4.2 给 AI 划出边界别让它包办所有事很多人的误区是把 AI 当成全能助手什么都丢给它写。我的建议是你必须先自己定义一个任务分配矩阵给 AI 划定明确的“禁区”和“允许区”。我的习惯是分三类 允许区可以直接交给 AI 一次性生成但需要人审阅。这类通常是独立模块的接口定义、简单的表单页面、标准 CRUD、代码注释生成、旧代码的跨语言翻译。因为它们结构清晰、边界分明、问题定位容易AI 的失误成本低。 受限区AI 可以生成但必须人工重写核心逻辑。这类包括字符串解析、正则表达式、序列化/反序列化逻辑、并发控制。AI 可以给你参考思路但真正进仓库的代码必须由你亲手敲一遍或者至少逐行重构过。因为这些地方太容易出隐蔽 bug而且一旦出问题排查成本极高。 禁区绝不允许 AI 直接生成。安全权限判断、支付金额计算、所有和真实用户隐私相关的处理我全部要求人工编写再让 AI 做评审而不是反过来。原因很简单这些代码的正确性关系到整个系统的底线出了事不是“改一行”能补救的。AI 的职责是帮你挑毛病而不是帮你写骨干。这套分级制度可能会让一些人觉得保守但我在多个模拟项目里验证过它的必要性。凡是我不设禁区、全交给 AI 的项目后面维护时几乎都要多花两到三倍的时间去补洞。4.3 定时“裸读”AI 生成的代码还有一个习惯是我从踩坑里总结出来的每天下班前把今天所有由 AI 生成并提交的代码单独复制到一个临时文件里关掉侧边栏的自动补全逐行读一遍。这个动作不需要写代码只有两件事要做高亮出所有你看不懂、不确定“为什么这么写”的地方。把 AI 代码和项目里已有的代码风格做对比找出节奏不一致的部分。为什么非要做这一步因为 AI 有它自己的表达习惯。它特别擅长写“看起来严谨”的代码但某些写法会和项目上下文格格不入。比如它在修改旧代码时经常在不必要的地方引入新命名或者把一个很简单的逻辑写成多态形式。你如果不读这些“异质逻辑”就会沉淀在仓库里越积越多最后整个项目变成一团不可维护的混搭体。我要求自己每一段 AI 生成的关键代码至少能用自己的话复述一遍“这里做了什么、为什么这么做”。如果复述不了说明我还没懂那就不允许提交。这个习惯让我在享受 AI 效率的同时身体的时刻保持在代码里而不是漂浮在提示词表面。4.4 每周固定两小时“裸写”训练这个方法我推荐给了不少开发者甚至包括零基础转行的朋友。我把它叫“裸写”每周固定抽两小时关掉所有 AI 工具包括自动补全和代码片段库只靠自己的脑子和双手写代码。选择的任务不需要复杂小而精最好。比如实现一个自定义的日期校验函数、手写一个 LRU 缓存、用某语言重写一个排序算法的边界版本。重点不是任务本身而是强制让大脑回到“没有外援”的状态重新体验从问题到解决方案的完整推理路径。有人可能会问我平时已经很累了为什么还要故意做这种低效练习原因很简单肌肉需要重训大脑的推理链路也需要。如果长期只用关键词和 AI 交流你大脑里负责“代码与现实映射”的回路会慢慢变钝。每周两小时的裸写就是给这条回路做一次有氧训练。我自己这么做了一段时间以后最大的感受是对边界条件的敏感度明显回升读 AI 生成代码时能更快地指出那些“不对劲”的地方。4.5 建立一份“直觉日志”最后推荐一个有点另类的做法写直觉日志。不用很复杂可以是一个本地文档或者一页笔记记录你每次和代码直觉相关的念头。日志内容分为三类最近三个月里你犯过的、最有代表性的 bug 是什么。你在第一次看到某段代码时心里冒出的“这里有问题”的预感后来是否被证实。AI 生成代码时哪几次的失败让你印象最深失败原因是什么。坚持半年以后你回头看这份日志会发现自己其实已经有了一套非常个性化的错误模式识别库。你会清楚地看到自己在哪类场景下直觉最准在哪类场景下容易盲目自信。这份对自我的认知比任何 AI 工具都更能帮你在代码世界里避险。我自己的日志里最高频的三类问题是类型隐式转换、空值假定、并发下的共享状态。后来我再让 AI 写相关代码时会特别提醒它注意这三类问题。这实际上是把我个人直觉不足的地方用人工校验补齐。5. 常见问题排查遇到这些坑我怎么办5.1 为什么一整段需求丢给 AI它总是处理错这不是技术问题是工作方法问题。如果你把一整段包含多步骤的需求一次性丢给 AI它往往会在中间某个环节自作主张把逻辑链条接错。解决方案是拆。一个复杂需求拆成函数粒度的子步骤逐段让 AI 实现。每实现一段先读一遍再验证通过再继续下一步。等到都完成再回头读一遍全貌。这个过程看着比一次性生成慢但返工率低很多整体反而是快的。5.2 组里的新人代码变成了“AI 味”怎么办我见过不少团队遇到这个问题年轻开发者提交的代码风格统一得像同一个 AI 写的函数命名、注释风格、异常处理方式全是一个模板。最难受的是一旦代码有问题新人完全没有自己的排查思路。我的应对方法是立规矩AI 生成的代码提交前必须由提交者本人写一段“结构说明”用自然语言讲清楚这个模块的数据流、边界判断依据和异常处理策略。如果没有这段说明不允许进代码评审。强制让他们动脑之后代码质量会肉眼可见地提升。因为一旦需要解释他们就必须去理解 AI 到底写了什么而不是只做复制粘贴。5.3 怎么判断这个功能该不该交给 AI我自己用一个很朴素的三问测试来判断。第一问这个逻辑如果出错了多久能发现如果错误会在下一秒的测试里直接爆出来那交给 AI 没大问题反正错也错得明显。第二问这个逻辑是否有明确的正确性标准如果答案是可以形式化描述那 AI 生成的把握就大。第三问这个逻辑出错以后损失范围是可控的吗如果只影响一个临时报表问题不大如果影响核心业务流程那就必须人写。一句话总结把低风险、高重复、强规则的任务外包给 AI把高风险、复杂耦合、弱规则的判断留给自己。这就是我和 AI 协作的边界感。5.4 拉老虎机上瘾导致时间失控怎么办如果你发现自己在“让 AI 改错”的循环里消耗了大量时间试试这么操作。先设一个硬性的时间盒一个大任务最多连续和 AI 交互 25 分钟。到时间还没解决强制停下来离开屏幕十分钟画一张简单的失败原因图再回到座位重新开始。另一个有效做法是不管 AI 报什么错先自己写出一组具体的输入输出样例然后直接告诉 AI“照着这个样例实现或者修复”。这会把你的注意力从无脑拉杆拉回到实际问题本身。当你开始关注具体样例你的推理引擎也会重新启动。5.5 我怎么判断自己的直觉有没有退化一个非常简单的自查方法关掉所有辅助给你一大段完全没有注释的 AI 生成代码你只凭阅读能不能在五分钟内指出三处潜在问题如果能说明你的直觉还在。如果读完了毫无感觉还觉得“这不挺好的嘛”说明你已经太久没有用自己的眼睛去看代码了。这时候别急着怪 AI先回头把前面说的“裸读”和“裸写”捡起来练一段时间再说。6. 我想说的是工具决定不了下棋的人我一直有一个朴素的看法代码模型本质上是放大器。你用它来放大什么取决于你自己的底子是什么。如果你有清晰的推理能力和丰富的错误经验AI 能帮你把这些能力十倍地释放出来。如果你的大脑已经退化成“只会提需求”的状态AI 也只是让你更快地生产垃圾。那位开发者说“AI 正在剥夺人类获得直觉的权利”我理解他的潜台词是AI 给了你一条不需要直觉也能短期存活的路你会本能地选这条路而一旦你选了你就放弃了那种只能在亲手试错中生长出来的能力。但我不觉得这是不可逆的。工具本身没有剥夺的能力真正做出选择的始终是我们自己。是在每一个可以用 AI 的瞬间我们都停下来多问一句“这里我懂了吗”还是在提示词里一路狂奔、把交付当理解。这几年 AI 写代码的能力只会越来越强直接考验的、被单靠效率裹挟的程度也越来越大。正因如此那些仍然愿意花时间读书面结构、跑调试、手动写测试的人才会在未来的技术浪潮里站得更稳。最后分享我每天在做的一个小练习每次拿到 AI 完成的关键功能不管时间多紧张我都要求自己用大白话在那段代码前写一份简短的原理解释。这份解释要能讲给一个完全不懂代码的朋友听或者可以写进项目的 README 里。如果我发现解释不顺畅哪怕只是一点点别扭我都会停下来重新读那段代码直到把它真的弄明白。这个方法我推荐每个人都试一下。它不一定立竿见影但坚持下来你会发现和 AI 之间的关系会从“拉杆和开奖”慢慢变成真正意义上的“结对编程”。到那时候直觉不但不会被剥夺反而会在和 AI 的碰撞里长出新东西来。