Vibe Coding 为何批量制造屎山？认识论根源与工程实践-北京尧图网络

1. 从“能跑就行”说起Vibe Coding 到底在解决什么问题“Vibe Coding”这个词最近在开发者圈子里出现的频率越来越高。它的核心主张其实特别简单你不需要逐行写代码只需要用自然语言把想要的效果描述出来让 AI 帮你生成你凭感觉判断“跑起来对不对”对了就继续不对就再描述一遍让它改。整个过程强调的是一种“跟着感觉走”的流畅状态而不是传统意义上先设计架构、再写单元测试、最后做代码审查的严谨流程。我第一次接触这种模式的时候说实话是有点上头的。你脑子里有个想法比如“帮我做一个能读取本地 CSV 文件、按某一列分组统计、然后画出柱状图的小工具”几秒钟之后代码就出来了复制粘贴运行报错把报错信息丢回去再改一版跑通了。那种即时反馈的快感确实很像在跟一个反应极快的搭档对话而不是一个人对着编辑器苦思冥想。但问题也恰恰出在这里。当“跑通”成为唯一的验收标准时代码的质量、可维护性、可扩展性这些在传统工程实践里被反复强调的东西就被系统性地忽略了。你得到的是一堆“当下能跑”的代码片段它们之间可能没有任何统一的抽象命名风格混乱错误处理缺失边界条件全靠运气。更麻烦的是当你用这种方式不断叠加功能时每一轮对话都在已有的混乱之上再糊一层最终形成的东西用圈内的话说就是一座“屎山”。这篇文章想做的事情不是简单地批判 Vibe Coding 这个行为本身而是从认识论的角度去拆解为什么这种工作方式会系统性地生产出难以维护的代码它的认知根源在哪里以及作为一个务实的开发者我们能不能在享受它带来的效率红利的同时避开那些最致命的坑适合读这篇内容的人是那些已经在用 AI 辅助写代码、或者正准备尝试的开发者。无论你是刚入行的新手还是带过团队的老手只要你在实际项目里用过这种方式大概率都遇到过“当时跑通了过两天自己都看不懂”的情况。我会尽量把背后的逻辑讲清楚同时给出一些可以直接落地的操作建议。2. Vibe Coding 的认识论根源为什么“感觉对了”会骗人2.1 自然语言的模糊性与代码的精确性之间的鸿沟自然语言和编程语言之间有一个根本性的差异自然语言天生是模糊的、依赖语境的而代码是精确的、无歧义的。当你说“帮我处理一下用户数据”的时候你脑子里可能想的是“过滤掉无效邮箱、去重、按注册时间排序”但 AI 接收到的只是“处理一下”这四个字。它会根据自己的训练数据里最常见的模式去补全你的意图而这个补全结果很可能跟你的真实需求有偏差。在传统开发流程里这个偏差会被需求文档、接口定义、测试用例这些中间产物逐步消除。但在 Vibe Coding 的模式下这些中间产物被跳过了你直接看运行结果。问题是运行结果只能告诉你“这次跑通了”不能告诉你“逻辑是否正确”。一个排序算法如果恰好对当前这组数据输出了正确顺序你就以为它是对的换一组数据可能就崩了。我见过一个很典型的例子有人让 AI 写一个“计算订单总价”的函数AI 生成的代码里把折扣逻辑写成了先乘折扣率再减优惠券。对于大多数订单来说这两种顺序的结果是一样的所以测试的时候没发现问题。直到有一天出现了一个折扣率很高、优惠券面额也很大的订单两种顺序算出来的价格差了好几百块才暴露出问题。这就是“感觉对了”的欺骗性它只在你测试过的输入上是对的。2.2 即时反馈循环如何抑制深度思考Vibe Coding 的另一个认知陷阱在于它的反馈循环太快了。你描述一个需求AI 生成代码你运行看到结果不满意就再描述一遍。这个循环可能只需要几十秒。在这种节奏下你的大脑处于一种“快速反应”的模式而不是“深度思考”的模式。心理学上有个概念叫“认知卸载”意思是当外部工具能够快速给出答案时人会倾向于停止内部思考。你本来应该去想“这个功能的边界条件是什么”“数据结构选得对不对”“以后要扩展的话会不会很麻烦”但因为 AI 秒回了一个看起来能用的方案你的大脑就自动把这些更深层的问题搁置了。一次两次没关系但如果整个项目都是这样堆起来的那些被搁置的问题就会在某个时刻集中爆发。更隐蔽的是这种快速循环会给你一种“进展很快”的错觉。你一天之内加了五个功能每个都跑通了感觉很爽。但实际上这五个功能之间可能没有任何统一的架构它们只是五块各自为政的代码碎片。等到你需要修改其中一个功能的时候你会发现牵一发而动全身因为当初根本没有考虑过它们之间的耦合关系。2.3 “跑通即正确”的验证标准为什么不可靠在传统工程实践里验证一个功能是否正确需要经过多层检查代码审查看逻辑是否合理单元测试覆盖各种边界条件集成测试看模块之间是否协调最后还有人工验收。这套流程看起来很繁琐但它的核心目的是用多重独立的视角去交叉验证同一个东西。Vibe Coding 把这套流程压缩成了“跑通”这一个标准。而“跑通”这个标准的问题在于它只验证了“在当前环境下、当前输入下、当前依赖版本下程序没有崩溃并且输出了某个结果”。它没有验证这个结果是不是你真正想要的也没有验证换一个环境、换一组输入、换一个依赖版本之后还能不能跑通。我自己的经验是用 Vibe Coding 方式写出来的代码在第一次运行成功之后如果不再做任何额外的检查和加固它在真实使用场景下的首次故障时间通常不会超过一周。这个数字当然不精确但那种“当时好好的怎么突然就不行了”的体验相信用过的人都懂。3. 屎山是如何被批量制造的四个典型的认知陷阱3.1 抽象缺失每一轮对话都在重新发明轮子Vibe Coding 最典型的产物就是“没有抽象层的代码”。因为你是按功能逐个描述的AI 也是按功能逐个生成的所以每个功能都自带一套完整的逻辑哪怕这些逻辑在其他功能里已经出现过。比如你让 AI 写一个“获取用户列表”的接口它生成了一套数据库连接、查询、格式化的代码。然后你让它写一个“获取订单列表”的接口它又生成了一套几乎一模一样的数据库连接、查询、格式化的代码。两套代码之间没有任何共享改一个地方要改两遍。在传统开发里有经验的工程师会在写第二个类似功能的时候停下来把公共部分抽成一个函数或者一个类。但在 Vibe Coding 的节奏下你满脑子想的是“下一个功能是什么”而不是“这两个功能之间有什么共同点”。AI 也不会主动提醒你“嘿你刚才写过类似的代码要不要复用一下”它只是忠实地执行你当前的指令。这种抽象缺失的后果是累积性的。一开始只是两段重复的代码后来变成十段再后来你根本不知道哪些地方有重复因为代码量已经大到你看不过来了。每次改需求你都要在几十个文件里搜索相关的代码片段生怕漏掉一处。3.2 命名腐化当变量名变成随机字符串命名是编程里最难的事情之一也是 Vibe Coding 最容易忽略的事情之一。当你用自然语言描述需求时你关注的是功能本身而不是变量该叫什么名字。AI 生成的代码里变量名往往是data、result、temp、item这种极度泛化的词或者是从你的描述里直接抠出来的词比如你说“处理用户数据”它就生成一个叫user_data的变量至于这个变量里到底装的是什么结构只有天知道。更糟糕的是随着你不断让 AI 修改代码同一个变量可能会经历多次重命名。第一轮叫user_data第二轮你让它“把过滤后的数据单独存一下”它可能改成filtered_data第三轮你让它“把排序后的结果返回”它又改成sorted_result。到最后代码里充斥着各种语义相近但含义模糊的变量名你根本分不清哪个是原始数据、哪个是中间结果、哪个是最终输出。我见过最离谱的一个案例是一个项目里同时存在data、data1、data2、new_data、final_data、processed_data六个变量它们之间的区别只有当初写代码的那个人如果还能找到的话才知道。这种代码别说别人维护了作者自己过两周回来看都得重新捋一遍。3.3 错误处理的集体缺席AI 生成代码时有一个非常明显的倾向它默认一切都会顺利。你让它写一个读取文件的函数它会直接open()然后read()不会考虑文件不存在怎么办、权限不够怎么办、文件格式不对怎么办。你让它写一个网络请求它会直接发出去然后解析响应不会考虑超时、断网、返回格式异常这些情况。在 Vibe Coding 的模式下你测试的时候通常是在一个理想环境里文件就在那里网络是通的返回的数据格式也是对的。所以你不会发现错误处理缺失的问题。但一旦部署到真实环境各种意外情况就会冒出来而代码里没有任何机制去应对它们结果就是程序直接崩溃或者更糟——静默地产生错误结果。更麻烦的是当你发现崩溃之后让 AI 去“加上错误处理”它往往只是在最外层包一个 try-catch把异常吞掉然后返回一个空值或者默认值。这种处理方式比不处理还危险因为它把错误掩盖了让你以为一切正常实际上数据已经丢了。3.4 依赖蔓延每一轮对话都可能引入新的库Vibe Coding 还有一个隐蔽的坑AI 在生成代码时会倾向于使用它训练数据里常见的库和框架。你让它写一个日期处理它可能引入一个日期库你让它写一个 HTTP 请求它可能引入一个请求库你让它写一个数据可视化它可能引入一个图表库。每一轮对话都可能引入新的依赖而你作为人类往往不会去审查“这个库是不是必要的”“这个库和已有的库是不是功能重叠”。结果就是一个本来只需要标准库就能完成的小工具最后依赖了十几个第三方包。这些包之间可能存在版本冲突可能有的已经不再维护可能有的体积巨大拖慢启动速度。更可怕的是你根本不知道哪个功能依赖了哪个包因为 AI 在生成代码时不会告诉你“我用了 X 库来实现 Y 功能”它只是默默地在文件顶部加了一行 import。这种依赖蔓延在项目初期不会有什么明显问题因为你的开发环境里可能已经装了很多包。但当你需要把项目部署到一台干净的机器上时各种“ModuleNotFoundError”就会让你抓狂。而且第三方库的供应链安全问题也是真实存在的你引入的每一个包都可能成为攻击面。4. 从认识论到工程实践如何与 Vibe Coding 共存4.1 把 AI 当作“快速原型生成器”而不是“最终代码生产者”认清 Vibe Coding 的定位是避免屎山的第一原则。我的做法是用 AI 来生成原型但绝不把原型代码直接放进正式项目。具体来说当我需要实现一个新功能时我会先让 AI 生成一版能跑的代码然后我自己从头到尾读一遍理解它的逻辑找出其中的问题然后基于这个理解自己重新写一版干净的代码。这个过程看起来比直接复制粘贴慢但实际上省时间。因为 AI 生成的原型帮我快速验证了“这个思路可行”我不需要从零开始摸索。而我自己重写的那一版因为经过了思考会有更好的命名、更合理的抽象、更完善的错误处理。后续维护的时候我面对的是自己写的代码而不是一堆 AI 生成的陌生片段。提示如果你实在不想重写至少要做到“逐行审查”。把 AI 生成的代码当成一个初级工程师的提交你需要像做代码审查一样问自己这行代码在做什么为什么需要它有没有更简单的写法边界情况处理了吗4.2 建立“对话前设计、对话后审查”的工作流Vibe Coding 的问题不在于“和 AI 对话”而在于“只和 AI 对话”。一个更健康的工作流是在对话前后加入设计环节和审查环节。对话前花几分钟想清楚这个功能的输入是什么、输出是什么、有哪些边界条件、和现有代码怎么衔接。你可以把这些想法写成一个简短的注释或者一个伪代码片段然后把它作为提示词的一部分发给 AI。这样 AI 生成的代码会更有针对性而不是泛泛地给你一个“通用方案”。对话后不要急着运行。先通读一遍代码检查几个关键点变量命名是否清晰、函数职责是否单一、错误处理是否到位、有没有引入不必要的依赖。如果发现问题不要直接让 AI “改一下”而是自己动手改。自己改的过程就是你理解代码、建立心智模型的过程。4.3 用“最小可运行单元”控制复杂度增长屎山不是一天堆成的它是一层一层叠出来的。控制复杂度的关键是每次只让 AI 处理一个“最小可运行单元”。什么意思呢就是不要一次性让 AI 生成一个完整的功能模块而是把它拆成若干个独立的小步骤每一步都确保能单独运行、单独测试。比如你要做一个“用户注册”功能不要直接说“帮我写一个用户注册模块”。你可以拆成第一步写一个验证邮箱格式的函数第二步写一个检查邮箱是否已存在的函数第三步写一个把用户信息写入数据库的函数第四步把这些函数串起来。每一步都单独让 AI 生成你单独审查、单独测试确认没问题了再进入下一步。这样做的好处是每一步的代码量都很小你容易看懂、容易发现问题。而且因为每一步都是独立的即使某一步出了问题也不会影响其他步骤。最终组装起来的时候你已经有了一套经过验证的积木而不是一堆纠缠在一起的乱麻。4.4 给 AI 立规矩用系统提示词约束输出风格如果你经常用 AI 辅助写代码可以给自己准备一套“系统提示词”在每次对话开始前发给 AI约束它的输出风格。比如变量命名使用有意义的英文单词禁止使用 data、temp、result 这类泛化名称每个函数只做一件事函数长度不超过 30 行所有外部调用必须包含错误处理禁止裸奔的 try 块优先使用标准库引入第三方库前必须说明理由生成的代码必须包含关键注释解释“为什么”而不是“是什么”这套提示词不能保证 AI 每次都遵守但至少能提高输出质量的下限。而且当你把要求明确写出来之后你自己在审查代码时也有了更清晰的检查标准。5. 实操复盘一个真实项目的屎山清理记录5.1 项目背景与初始状态前段时间我接手了一个内部工具项目功能很简单从几个数据源拉取数据做一些清洗和聚合然后生成一份日报。项目最初是一个同事用 Vibe Coding 的方式快速搭起来的大概花了两天时间功能确实能跑。但当他离职之后这个项目就没人敢动了因为代码实在太乱谁改谁背锅。我拿到代码的时候项目大概有 2000 行 Python分布在 15 个文件里。没有 README没有测试没有依赖清单。我试着运行了一下报错因为缺少几个包。我根据报错信息逐个安装装到第五个的时候发现有两个包版本冲突一个要求pandas1.5另一个要求pandas1.4。这就是典型的依赖蔓延问题。5.2 清理过程从“能跑”到“能维护”我的清理过程分四步。第一步是“冻结现状”我把当前能跑的环境完整地导出成一个依赖清单包括每个包的精确版本号。这样至少保证我清理的过程中不会因为环境变化而引入新的问题。第二步是“画地图”我通读了所有代码画了一张数据流向图标出每个文件的职责、每个函数的输入输出、以及它们之间的调用关系。这一步花了我大半天时间但非常值得因为它让我对项目的整体结构有了清晰的认知。第三步是“拆解重构”我把代码按功能重新组织成三个模块数据获取、数据处理、报告生成。每个模块内部我把重复的逻辑抽成公共函数把泛化的变量名改成有意义的名称给所有外部调用加上错误处理。这个过程我没有用 AI而是自己一行一行改的因为只有自己改才能真正理解每一处逻辑。第四步是“加护栏”我给关键函数写了单元测试覆盖了正常情况和几种典型的异常情况。然后加了一个简单的 CI 脚本每次提交代码时自动运行测试。这样以后再有人改代码至少能保证不会把已有的功能改坏。5.3 清理前后的关键指标对比指标清理前清理后代码行数约 2000 行约 1200 行文件数量15 个6 个第三方依赖23 个9 个单元测试覆盖0核心逻辑 80%首次运行成功率需要手动装 5 个包一条命令完成修改一个功能的平均耗时2 小时以上20 分钟左右这个对比不是要说明“AI 生成的代码一定不好”而是要说明Vibe Coding 产出的代码如果不经过人工的整理和加固它的维护成本会高得离谱。而整理和加固的成本往往比从头写一遍还要高。5.4 从这次清理中总结的三条经验第一条经验是AI 生成的代码必须经过“人类翻译”才能进入正式项目。所谓人类翻译就是你自己理解一遍然后用自己习惯的风格重写。这个过程不能省省了后面就要加倍还回来。第二条经验是依赖管理要趁早。项目一开始就要有明确的依赖清单每引入一个新包都要问自己“真的需要吗”。我现在的习惯是任何第三方包如果标准库能实现类似功能就坚决不用。标准库可能写起来麻烦一点但它稳定、无依赖、不会突然不维护。第三条经验是测试是屎山的唯一解药。你不需要一开始就追求高覆盖率但核心逻辑一定要有测试。有了测试你才敢改代码敢改代码代码才不会变成没人敢碰的化石。6. 常见问题与排查技巧实录6.1 AI 生成的代码跑不通怎么办这是最常见的问题也是最容易让人烦躁的问题。我的建议是不要直接把报错信息丢回去让 AI 改而是先自己读一遍报错定位到具体的文件和行号理解错误类型。常见的错误无非几种缺少导入、变量名拼写错误、参数数量不对、类型不匹配。这些错误你自己修通常比让 AI 修更快因为 AI 可能会在修改的过程中引入新的问题。如果错误确实比较复杂比如涉及第三方库的用法你可以把相关的代码片段和报错信息一起发给 AI但要求它“只修改这一处不要动其他代码”。这样可以避免它把整个文件重写一遍引入不必要的变更。6.2 如何判断 AI 生成的代码有没有隐藏问题隐藏问题通常藏在几个地方边界条件、异常路径、并发场景、资源释放。你可以针对这几个方面做针对性的检查。比如对于边界条件你可以问自己如果输入是空列表会怎样如果输入是 None 会怎样如果输入是一个超大文件会怎样对于异常路径你可以问如果网络断了会怎样如果文件被删了会怎样如果数据库连接超时会怎样一个很实用的技巧是让 AI 自己解释它生成的代码。你可以问它“这段代码在输入为空的时候会怎么处理”“这个函数如果被并发调用会不会有问题”。虽然 AI 的回答不一定完全准确但它能帮你发现一些你没想到的角度。6.3 项目已经变成屎山了是重写还是继续维护这是一个经典的工程决策问题。我的判断标准是看“修改成本”和“重写成本”的比例。如果你修改一个功能需要的时间已经超过了从头实现这个功能的时间那就说明维护成本太高了重写可能更划算。但重写之前一定要确保你理解了原项目的所有功能包括那些没有文档、只存在于代码里的“隐藏功能”。另一个判断标准是看“测试覆盖”。如果原项目有比较完善的测试那重写的风险会小很多因为你可以用测试来验证新实现是否和旧实现行为一致。如果原项目完全没有测试那重写之前最好先补一些测试把现有行为固定下来然后再动手。6.4 常见问题速查表问题现象可能原因排查方法解决建议代码跑不通报 ImportError缺少依赖或依赖版本不对检查 import 语句和已安装包列表安装缺失包锁定版本代码跑通了但结果不对逻辑错误或边界条件未处理用多组输入测试对比预期输出补充边界处理加单元测试改了一个功能另一个功能坏了代码耦合太紧缺少抽象检查两个功能之间是否有共享状态抽取公共逻辑降低耦合代码越改越乱不敢动了缺少测试没有安全网评估核心逻辑的测试覆盖先补测试再重构部署到新环境跑不起来依赖蔓延环境不一致对比开发环境和目标环境的差异使用依赖清单容器化部署6.5 一个容易被忽略的坑AI 的“自信幻觉”AI 在生成代码时语气通常非常自信它会说“这是一个完整的实现”“这段代码可以正确处理所有情况”。但实际上它可能只是生成了一个看起来合理的框架里面的逻辑经不起推敲。如果你因为它的自信语气而放松了审查就很容易被带进沟里。我的应对方法是不管 AI 说得多肯定我都假设它生成的代码有至少一处问题然后带着“找茬”的心态去审查。这个心态听起来有点极端但实测下来它确实能帮我发现很多原本会忽略的问题。而且当你找到问题之后你对这段代码的理解也会更深一层。7. 一些个人体会用 AI 辅助写代码这件事本身没有对错。它就像一把刀用得好能提高效率用不好会切到手。Vibe Coding 的问题不在于“让 AI 写代码”而在于“只让 AI 写代码自己不动脑子”。当你把思考的责任完全交给 AI 时你得到的代码就注定是一座屎山因为 AI 没有你的项目上下文没有你的长期维护计划也没有你对代码质量的追求。我现在的习惯是用 AI 来探索可能性用自己来打磨最终方案。AI 帮我快速验证“这个方向行不行”我负责把可行的方向做成“能长期维护的东西”。这个分工让我既能享受 AI 的速度又能保持代码的质量。最后分享一个很小但很实用的技巧每次让 AI 生成代码之后不要直接复制到项目里而是先粘贴到一个临时文件里通读一遍改掉明显的命名问题补上缺失的错误处理然后再复制过去。这个“中转”步骤只多花几分钟但能帮你挡掉大部分低级问题。踩过几次坑之后你会发现这几分钟花得特别值。

Vibe Coding 为何批量制造屎山？认识论根源与工程实践

相关推荐

加窗傅里叶变换详解：频谱泄漏原理与Matlab窗函数实战

网络安全学习与安全运维：从漏洞原理到Web加固的合规路径

Spring Boot + Vue 考勤系统前后端分离实战

更多资讯

全栈液冷方案如何破解AIDC高密度散热与PUE难题

AI协同工作流：从复制粘贴到技能调用的效率革命

AI Agent全自动社交媒体运营：架构设计、实现细节与踩坑实录

深度信念网络详解：从受限玻尔兹曼机到无监督预训练与微调

逆向实战：破解发帖接口mouse_pwd参数与鼠标轨迹模拟生成

全像素密集三维追踪：世界坐标系下的前馈式轨迹预测全解析

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？