Vibe Coding：蜜月期过了，该聊聊“技术债”了

“Vibe Coding”（氛围编程）像摇滚明星一样闯进了开发者圈子。

那时候，大家都在谈论抛弃僵化的架构图，关掉烦人的 Linter（代码检查器），跟着直觉走。甚至有人鼓吹：别管什么设计模式，让 AI 和你的直觉带飞，写代码应该像玩爵士乐一样随性。

这听起来太诱人了：像写开源项目一样自由，像原型开发一样极速。

但半年过去了，香槟的气泡散尽，宿醉开始袭来。开发者们逐渐意识到：Vibe Coding 确实让起步变得无比丝滑，但当项目进入深水区，它留下的烂摊子也是史诗级的。

我不是来给这个趋势泼冷水的，也不是来唱赞歌的。作为技术人，我们需要通过现象看本质：Vibe Coding 到底在哪儿好用？在哪儿会崩盘？当我们在生产环境里“跟着感觉走”时，到底会发生什么？

---

为什么它一开始让人上头？

Vibe Coding 刚出现时，简直是“企业级开发疲劳”的解药。

在一个充满了 Jira 门票、繁琐流程和“每一行代码都要像发射火箭一样严谨”的世界里，Vibe Coding 对你说：“嘿，放松点，玩起来。”

它给了开发者一个宣泄口。你不需要一开始就想清楚所有的边缘情况，你可以把半成品的想法扔进编辑器，让 Copilot 帮你补全，像即兴演奏一样把功能堆出来。这种 “Vibey Commits”（氛围感提交） 一度成了某种叛逆的勋章——甚至比传统的敏捷开发还要敏捷。

对于被大厂流程压得喘不过气的一线工程师，或者想快速验证想法的独立开发者，这种自由感是无价的。那一刻，代码似乎重新变回了艺术，而不仅仅是产品。

---

裂痕出现在哪里？

好景不长。当项目从“Demo”走向“1.0”，裂痕就出现了。

混乱带来的债务，是要还的。

那些在截图里看起来很酷的代码，到了凌晨两点的 Debug 现场，就变成了灾难。当你的团队试图理清分散在 10 个临时文件里的逻辑时，没人觉得这很“Playful”。

重构的时候，代价更是肉眼可见：

• 依赖关系不明：这里引一个包，那里调一个库，毫无章法。
• 命名随意：变量名充满了当时的“灵机一动”，而不是语义化。
• 架构像胶带粘的：也就是我们常说的“屎山”雏形。

最致命的是，那种让 Vibe Coding 充满魅力的“松散感”，恰恰是阻碍系统扩展的元凶。很多开发者在前期享受了极速开发的快感，后期却不得不花费三倍的时间去“还债”，甚至被迫重写核心模块。

更别提这种模式下，对 AI 辅助编码工具的过度依赖，有时会引入未经验证的安全漏洞。所谓的“直觉”，在安全审计面前往往不堪一击。

---

Vibe Coding 的真正甜区：原型与探索

批判归批判，Vibe Coding 就一无是处吗？当然不是。它有一个绝对的统治领域：原型设计（Prototyping）。

如果你现在的目标是：

• 探索一个模糊的想法
• 验证某个技术方案是否可行
• 搞 Hackathon（黑客松）
• 写一个阅后即焚的一次性脚本

在这些场景下，Vibe Coding 是无敌的。它鼓励你快速迭代，一上午尝试十种不同的写法。这时候，过早的优化（Premature Optimization）才是万恶之源。

把它想象成画家在定稿前的铅笔草图——草图乱一点没关系，重要的是捕捉灵感。

但危险在于，很多人把“草图”直接当成了“工程图纸”去施工。

Vibe Coding 的强项是帮你找路，一旦路找到了，就该切换回严谨的工程模式。

---

为什么“氛围”难以规模化？

“我的混乱是我的捷径，但对你来说就是迷宫。”

Vibe Coding 本质上是一种极其个人化的体验。一个人单兵作战时，你可以容忍自己的烂代码，因为你脑子里有上下文。但一旦团队超过三个人，协作就需要协议、文档和规范。

当大家都在“跟着感觉走”，没有统一的命名规范，没有一致的数据处理逻辑，所谓的“氛围”就会迅速衰退成“熵增”。

其表现包括：

• 沟通成本爆炸：
  “你这一块逻辑为什么要这么写？”
  “当时感觉这样比较顺。”
  ——这种对话是团队协作的杀手。

• Deadline 是氛围粉碎机：
  周日在大脑多巴胺分泌旺盛时写代码是享受；
  周五面临交付压力时，面对一堆缺乏结构的代码，只会让人血压升高。

---

极客的生存之道：混合模式

经过半年的洗礼，最聪明的开发者已经不再追求纯粹的 Vibe Coding，而是进化出了 混合流（Hybrid Workflow）。

1. 分离“探索期”与“交付期”

给自己设定专门的 “Vibe Time”。在这个阶段，随便写、随便试。一旦核心逻辑跑通，立刻进入重构阶段，把“草图”变成正规军代码。

2. 分支策略

一些团队甚至建立了专门的 experimental 分支用于 Vibe Coding。在这个分支里，linter 规则可以放宽，代码审查可以从简。

但如果要合并回 main，必须经过严格的清洗和格式化。

3. 轻量级护栏

即使是“乱写”，也要保留底线。比如：

• 核心的命名约定不能乱
• 模块的边界要清晰

就像在爵士乐即兴演奏中，大家至少要在“大调”和“小调”上达成一致。

---

总结

Vibe Coding 的蜜月期结束了，这其实是件好事。

这意味着我们不再把它视为一种“神学”或“革命”，而是回归到工具的本质。它不是用来替代软件工程的，它是用来加速早期灵感捕获的。

如果你能分清什么时候该 “Vibe”（探索），什么时候该 “Build”（构建），你就掌握了这种新范式的精髓。

少一点 hype（炒作），多一点工程诚实。这才是极客该有的样子。