从“邪典”到“邪门”:Vibe Coding 狂热,一场走火入魔的“内部测试”
从“邪典”到“邪门”Vibe Coding 狂热一场走火入魔的“内部测试”在 Hacker News 上一篇题为The cult of vibe coding is insane的文章以 534 票冲上热榜。作者 Bram Cohen没错就是 BitTorrent 的发明人用极其尖锐的笔触批判了当下硅谷乃至全球开发者圈中一种愈演愈烈的风气“氛围编程”Vibe Coding。如果你还没听过这个词它大致描述的是这样一种场景开发者不再严谨地设计架构、编写测试、思考边界条件而是靠着一种“感觉”——一种玄学般的“氛围”——疯狂堆叠代码然后指望 AI 或某种神秘的“第六感”来拯救项目。Cohen 将这种风气称为“邪教”Cult并直言这是“内部测试Dogfooding失控后的产物”。什么是“Vibe Coding”—— 当编程变成一场“行为艺术”让我们先拆解一下这个让 Bram Cohen 如此恼火的概念。“Vibe Coding”并非一个严谨的工程术语它更像是一种亚文化现象。其核心信条包括直觉至上不写文档不画架构图。全凭“我觉得这样写应该没问题”来推进。测试靠信仰单元测试集成测试那是老古董的玩具。真正的“氛围程序员”相信只要代码能跑通一次它就永远是好的。重构即重写当代码变得一团糟时不选择重构而是推倒重来。每次都像在玩俄罗斯轮盘赌赌自己下次能写出更“有感觉”的代码。AI 是救世主大量依赖 Copilot、ChatGPT 等工具生成的代码块并且几乎不做审查。他们相信“AI 写的代码应该比我写的更懂我”。看到这里你可能会觉得这像是一种行为艺术。但实际上这种风气正在真实地侵蚀着大量初创公司和初级开发者的工作流。有趣的是我搜索“Cult”这个词时发现了一个有趣的平行宇宙。在电影领域“Cult Film”邪典电影的定义是“在小圈子内被支持者喜爱并推崇拍摄手法独特题材诡异剑走偏锋风格异常带有强烈的个人观点富有争议。通常是低成本制作不以市场为主导的影片。”你发现了吗“Vibe Coding”和“Cult Film”在精神内核上惊人地相似——它们都是小众的、反主流的、高度依赖“信徒”狂热情绪的产物。但区别在于一部邪典电影拍砸了最多浪费你两小时的电影票钱而一个“邪典项目”搞砸了可能毁掉一个团队几个月的努力甚至葬送一家公司。为什么说它是“Dogfooding Run Amok”Bram Cohen 在文章中用了“Dogfooding run amok”这个短语。Dogfooding内部测试本意是“吃自己的狗粮”即开发者自己使用自己写的软件以便尽早发现问题。这是一个非常好的工程实践。但当“Dogfooding”失控run amok时就变成了“Vibe Coding”。失控体现在哪里1. 把“能用”当成了“好用”氛围程序员最常说的话是“你看运行起来没问题啊” 他们把自己当作唯一的用户在一个极其狭窄的、理想化的环境下测试。他们没有意识到软件的生命周期不是从“写完”到“跑通”就结束了。真正的挑战在于当用户数量从1变成1000时当数据量从1KB变成1TB时当并发请求从1变成10000时代码是否还能保持稳定2. 混淆了“探索”与“交付”在项目的早期探索阶段快速原型、试错、甚至写一些“一次性”的垃圾代码都是可以接受的。但“Vibe Coding”的问题在于它把这种探索阶段的心态永久化了。它拒绝承认代码是需要被维护、被阅读、被他人理解的。它把“写代码”这个工程行为降格为一种纯粹的、即时的个人表达。3. 对技术债的极端漠视技术债Technical Debt是一个老生常谈的话题。但“氛围程序员”对待技术债的态度不是“借债”而是“赖账”。他们不认为混乱的代码结构、缺失的错误处理、硬编码的魔数会在未来产生利息。他们天真地以为只要“氛围”在一切问题都能靠“重写”来解决。一个真实的“邪典”代码案例让我们来看一个典型的、带有“Vibe Coding”风格的 Python 代码片段。假设我们要实现一个简单的用户注册功能检查用户名是否被占用。“氛围程序员”版本伪代码# 我感觉这样写很酷defcheck_user(name):# 用AI生成的看起来很高大上importsqlite3 connsqlite3.connect(users.db)cconn.cursor()# 我懒得写参数化查询了直接格式化吧反正就我一个人用c.execute(fSELECT * FROM users WHERE username {name})resultc.fetchone()conn.close()ifresult:return用户已存在else:# 我觉得直接插入也行省得再调一次函数cconn.cursor()# 等等连接已经关闭了# 啊算了反正报错了我再修c.execute(fINSERT INTO users (username) VALUES ({name}))conn.commit()conn.close()return注册成功这段代码充满了“邪典”气息使用字符串格式化拼接 SQLSQL 注入风险那是别人的问题。在检查函数里直接做插入操作单一职责原则不存在的。连接管理混乱甚至尝试在关闭的连接上执行操作。没有异常处理没有事务控制。工程化版本importsqlite3fromcontextlibimportclosing DB_PATHusers.dbdefis_username_taken(username:str)-bool:检查用户名是否已被注册使用参数化查询防止SQL注入withclosing(sqlite3.connect(DB_PATH))asconn:withclosing(conn.cursor())ascursor:cursor.execute(SELECT 1 FROM users WHERE username ?,(username,))returncursor.fetchone()isnotNonedefregister_user(username:str)-bool:注册新用户如果用户名已存在则返回Falseifis_username_taken(username):returnFalsewithclosing(sqlite3.connect(DB_PATH))asconn:withclosing(conn.cursor())ascursor:try:cursor.execute(INSERT INTO users (username) VALUES (?),(username,))conn.commit()returnTrueexceptsqlite3.IntegrityError:# 处理并发情况下的竞态条件returnFalse对比之下工程化版本虽然代码量多了但它是可预测的。是安全的。是可测试的你可以轻松 mock 数据库连接。是可维护的每个函数只做一件事。“Vibe Coding”最大的问题就是它把不确定性当成了创造性。在工程领域不确定性是灾难的源头。初级开发者的“邪典陷阱”为什么你容易被蛊惑作为初级开发者你可能觉得“Vibe Coding”听起来很诱人。它承诺你快速获得成就感不用写测试不用想架构噼里啪啦敲完跑通了爽摆脱枯燥的工程规范不用学设计模式不用看文档全凭“感觉”写代码多自由拥抱“AI 魔法”把难题丢给 AI自己当“提示词工程师”多省事但请记住这些承诺背后隐藏着一个巨大的陷阱。陷阱一把“运气”当“实力”当你用“氛围”写完一个功能并且它跑通了你会产生一种错觉我很厉害。但事实上你可能只是运气好没有触发隐藏的边界条件和并发问题。这种错觉会让你在错误的道路上越走越远。陷阱二错过真正的成长编程不仅仅是“让代码跑起来”。真正的成长来自于设计如何把复杂问题拆解成简单模块抽象如何写出可复用的代码测试如何证明你的代码是正确的调试当代码出错时如何系统性地定位问题“Vibe Coding”跳过了所有这些环节。它让你沉迷于“写代码”的快感却剥夺了你“思考代码”的能力。长期以往你可能会成为一个“熟练的代码打字员”而不是一个“软件工程师”。陷阱三成为团队中的“孤岛”软件工程是团队协作的产物。你的代码需要被其他人 review、修改、维护。一份充满“氛围”的代码对其他人来说就是一团迷雾。没有注释没有测试逻辑混乱。最终你可能会成为团队中那个“只可远观不可合作”的存在。如何从“邪典”回归“工程”Bram Cohen 的批判虽然尖锐但他并没有给出具体的解药。这里我结合自己的经验给初级开发者一些务实的建议把“写代码”和“做工程”分开在探索阶段允许自己“氛围”一下快速验证想法。但在交付阶段必须切换到“工程”模式补全测试、重构代码、撰写文档。学会在不同模式下切换是成熟开发者的标志。拥抱“无聊”的工程实践类型注解、单元测试、代码审查、CI/CD 流水线……这些实践看起来很“无聊”但它们是你代码的“安全带”。没有安全带飙车再爽也迟早会翻车。把 AI 当作“高级自动补全”而不是“代码作者”Copilot 和 ChatGPT 是极好的工具但你必须审查、理解、修改它们生成的每一行代码。如果你不理解一段代码的逻辑就不要把它放进生产环境。养成“写完后读一遍”的习惯在提交代码前把自己当作代码审查者通读一遍自己写的代码。问自己这段代码是否清晰是否有冗余是否可能在某些情况下出错很多“氛围”问题在通读一遍时就会暴露。寻找“反氛围”的导师找一个代码风格严谨、注重工程质量的同事或前辈多向他请教。让他 review 你的代码并认真对待他的每一条意见。真正的大神不是写代码最快的人而是写代码最稳的人。结语保持热情但别沦为“信徒”我理解每一位开发者内心的“邪典”冲动。那种在深夜戴着耳机听着音乐全凭直觉和灵感写代码的感觉确实很迷人。它让人觉得自己像一个艺术家而不是一个工匠。但请记住软件首先是工程其次才是艺术。一个没有地基的摩天大楼无论外观多么酷炫都注定会倒塌。“Vibe Coding”作为一种探索方式有其存在的价值。但当它被奉为圭臬成为一种“邪教”般的信仰时它就变成了毒药。正如 Bram Cohen 所言这是“内部测试失控”的表现。它让开发者沉迷于自我感动却忘记了软件的根本目的可靠、可维护、可交付地解决用户的问题。所以下次当你想要“跟着感觉走”的时候不妨停下来问自己一句“我是在创造价值还是在创造技术债”保持对编码的热情但请永远对“邪典”保持警惕。做一个理性的工程师而不是一个狂热的信徒。