当 AI 编程变成一种宗教：Claude 代码泄露背后，最荒唐的不是代码烂
最近，Claude 源代码泄露引发了一波围观。互联网上最不缺的就是热闹：有人截图吐槽代码重复、结构混乱，也有人幸灾乐祸地说，“原来最会写代码的 AI 公司，自己代码也不过如此”。
但如果只把这件事看成一次普通的“翻车”，那就有点低估它了。BitTorrent 发明人、也是技术圈老炮的 Bram Cohen 写了一篇火药味很重的文章，标题就很不客气：《The Cult Of Vibe Coding Is Insane》。他真正批评的，不是某一段写得难看的代码，而是 AI 编程时代一种越来越流行的心态：既然有模型能生成代码，人类就最好不要“作弊”，不要深入看，不要碰底层，甚至不要认真理解系统内部到底在发生什么。
这才是整件事最值得警惕的地方。代码泄露只是一个窗口，照出来的却是行业里某种近乎宗教式的狂热。
“氛围编程”走火入魔：狗粮吃得太猛，也会反噬自己
科技公司喜欢讲一个词，叫 dogfooding，也就是“吃自己的狗粮”——自己先用自己的产品。这个原则本来没什么问题，甚至是好事。微软、谷歌、Meta 都长期推崇这种文化，因为只有自己天天用，产品的缺陷才会更快暴露。
问题在于，一种正确的方法，一旦被推到极端，就容易变味。Bram Cohen 认为，Claude 团队的问题恰恰出在这里：他们太想证明“AI 可以自己写代码”，以至于把“人类少干预”变成了一种信条。不是“尽量让 AI 多做”，而是“人类最好连看都别看”。在这种逻辑下，开发者仿佛成了和模型聊天的主持人，代码本身反而成了一个不该打开的黑箱。
这就是近两年在社交媒体上被包装得很时髦的“vibe coding”——你给出模糊意图、提需求、聊想法，让模型把系统一点点“长出来”。听上去很优雅，像是从手工业进入自动化时代；但如果把它理解成“完全不理解也没关系”，事情就开始危险了。
Cohen 的一个判断很犀利：所谓“纯粹的 vibe coding”，其实是神话。因为你根本不可能完全不做人的工作。你还是在定义规则、写计划文件、拆任务、设置技能模块、梳理流程。只不过这些工作不再表现为手敲代码，而是以更抽象的方式存在。换句话说，人没有消失，人只是换了一种姿势干活。
这就像有人说自己不是在做饭，只是在指挥厨房。可问题是，菜单、火候、食材搭配还是你在决定。最后菜炒糊了，也不能全怪锅。
真正荒唐的，不是代码乱，而是“看代码都算作弊”
这场争论里最让人哭笑不得的一点，是代码本身并不神秘。Bram Cohen 提到，那些被外界嘲笑的内容，很多就是肉眼可见的重复、混乱分类和结构冗余。比如同一类东西既被定义成 agent，又被定义成 tool，功能边界重叠得很明显。
这类问题在传统软件项目里太常见了。任何做过工程的人都知道，项目早期赶进度、需求反复、多人协作，最后总会长出一点“技术债”。这不稀奇。真正稀奇的是，既然现在 AI 明明很擅长做代码清理、结构整理、批量审计，为什么团队不去做？
Cohen 给出的答案很辛辣：因为他们不愿意“往引擎盖下面看”。看内部实现，似乎会破坏某种叙事——如果 AI 真能自己完成开发，那人类就不该频繁介入，更不该亲自翻代码、指出具体问题。于是，一个本来可以靠几十分钟人工审查就发现的大坑，被放任成了外界围观的笑柄。
这让我想到过去几年自动驾驶行业的一些宣传口径。最乐观的时候，总有人暗示“系统会自己学习一切，人类规则正在退出历史舞台”。结果现实很快给出答案：边界条件、罕见场景、异常状态，恰恰是最需要人类经验和明确约束的地方。AI 编程也一样。生成代码并不等于生成工程纪律，更不等于自动生成高质量软件文化。
一个成熟团队真正该做的，不是迷信模型“自己会变好”，而是敢于把脏活拿出来清：哪里重复了，哪里命名混乱，哪里职责不清，哪里历史包袱太重。AI 可以是清洁工、修补匠、加速器，但它不是自动诞生秩序的魔法。
AI 最擅长的，其实不是“无中生有”，而是“有人带着它收拾烂摊子”
Cohen 在文中说了一个很朴素、但特别像一线开发者经验的话：AI 不太会自发意识到“这里已经是一团意大利面代码了，我得主动整理一下”；但如果你明确告诉它这里很乱，并和它来回讨论一轮，它往往能把清理工作做得相当不错。
这其实点中了当下生成式 AI 在软件工程中的真实位置。今天的大模型，最强的能力之一不是从零创造一个完美系统，而是在一个已有系统里做归纳、重构、补全、迁移、对齐风格、找重复逻辑、补测试、扫死代码。简单说，它更像一位精力无限、速度惊人的高级助理，而不是一个可以脱离管理的“自运行公司”。
很多团队已经在这么用了。比如先让模型扫描代码库，找不可达代码和重复模块；再由工程师挑几个典型案例，告诉它哪些设计应该保留、哪些必须废弃；双方反复讨论后，再让 AI 出一个重构计划，然后自动执行。这不是“纯自动”，但它非常高效。人负责判断与边界，模型负责体力与规模。
这个模式听上去不那么性感，因为它没有“AI 完全替代程序员”那么抓眼球。但它更接近现实，也更接近工程文明的本质。技术进步从来不是把人从系统里删掉，而是把人的精力从重复劳动中解放出来，转去做那些需要判断、取舍和责任承担的事。
行业里现在最大的问题之一，可能正是把“减少手工劳动”误解成“减少理解与审查”。这是两回事。前者是进步，后者是摆烂。
这件事为什么重要：它暴露了 AI 软件工程最危险的岔路口
如果这只是某家公司一份不好看的内部代码，那它不值得讨论这么久。真正重要的是，它发生在一个很微妙的时间点：AI 编程工具已经从演示玩具，进入到企业生产流程。
GitHub Copilot 之后，Cursor、Windsurf、Devin、Claude Code 这类产品不断把“自然语言写软件”往前推。现在很多创业公司和大厂团队都在重新设计开发流程：需求是不是先写给模型看？PR 是不是先让 AI 过一轮？重构是不是能全自动跑？测试、文档、部署脚本是不是都能交给代理完成？这是当下软件行业最热的实验场之一。
也正因如此，Claude 源码争议才格外有象征意义。它提醒所有人：如果一家最懂模型、最会做 AI 产品的公司，都可能在“让 AI 自己写自己”这件事上走向失控，那其他团队更该小心。不是每一次“哇，它自己搞定了”都值得鼓掌。你得追问一句：它搞定的是功能，还是搞砸了结构？
更尖锐的问题在于，未来的软件质量责任到底算谁的？如果工程师没有认真读过大部分代码，却默认代码能上线；如果组织为了追求更快迭代，把“可解释性”和“可维护性”都当作次要指标；如果出了事故，最后说一句“是模型写的”，这显然不成立。模型没有法务，没有值班，没有职业声誉，最后背锅的还是公司和人。
所以，AI 编程时代最需要建立的，不是更夸张的神话，而是新的工程伦理：哪些环节可以放手给模型，哪些环节必须有人签字，哪些代码允许先跑起来，哪些系统绝不能靠“感觉差不多”上线。
我越来越觉得，接下来几年，真正拉开团队差距的不是“谁用上了 AI”，而是“谁建立了和 AI 协作的工程纪律”。会用提示词不稀奇，能把模型纳入可审计、可维护、可回滚的流程里，才是本事。
写在最后：烂软件从来不是 AI 的专利，只是 AI 把人的问题放大了
Bram Cohen 文章里有一句话很刻薄，但我觉得很真实：糟糕的软件质量，归根结底是一个选择。你可以怪赶工、怪组织、怪人才结构、怪历史包袱，也可以怪 AI 生成得太快、太多、太散，但最终决定“这些代码是否值得进入生产环境”的，仍然是人。
这也是我看完整件事后最强烈的感受。今天很多人一边嘲笑 AI 生成的屎山代码，一边又忘了，在没有 AI 的时代，人类程序员亲手写出的屎山同样堆积如山。区别只是，AI 让垃圾生产速度更快，也让修垃圾的速度同样变快。它像一台功率巨大的发动机，方向盘却还在人手里。
如果方向盘松手了，车冲进沟里，不该惊讶。
所以，别把“vibe coding”当成一种时髦身份标签了。它可以是创意阶段的助推器，是快速验证的捷径，是让独立开发者飞起来的翅膀；但一旦进入真正的软件工程，它就必须和审查、重构、规则、测试、责任一起工作。否则你得到的不是未来，而是一座更大、更快、更会自动生长的数字垃圾场。