当 Andrej Karpathy 在 2025 年初提出「vibe coding」这个词时，他或许没有预料到这个概念会如此迅速地经历一场完整的兴衰周期。从最初被视为编程民主化的利器，到如今被贴上「RIP Low-Code 2014-2025」的墓碑标签，vibe-coding 正在经历一场深刻的存在主义危机。这场危机的本质并非技术本身的失败，而是开发范式从「快速生成」向「长期维护」的根本性转变所带来的系统性冲击。
从 Day 1 到 Day 2：开发范式的根本性转变
vibe-coding 之所以在 2025 年初引发巨大关注，核心原因在于它承诺了一种前所未有的开发速度。开发者不再需要逐行编写代码，只需要用自然语言描述需求，AI 就能在几秒钟内生成可工作的应用程序。这种模式对于原型验证和概念证明来说确实是革命性的 —— 一个原本需要数周才能完成的功能，现在只需要几分钟。
然而，Stack Overflow 的最新调查数据揭示了一个令人不安的现实：尽管有 84% 的开发者已经在工作中使用 AI 辅助工具，但其中只有 3.1% 的人表示对 AI 工具「高度信任」。这个数字背后的含义远比表面看起来更加深刻：开发者们正在大量使用他们并不完全信任的工具，而这种信任缺失的根源正是对长期维护的担忧。
行业的关注焦点已经从「Day 1 问题」—— 即「我能让应用多快生成」—— 全面转向了「Day 2 问题」—— 即「我该如何维护、扩展、调试和迭代这些由 AI 生成的代码」。这个转变标志着 vibe-coding 从一个纯粹的效率工具演变成了一个需要严肃工程治理的复杂系统。Rocket.new 等工具已经开始强调「生产就绪」和「长期可维护性」，而非单纯的生成速度，这本身就是市场转向的明确信号。
灾难预言：挑战者号时刻的警示
Simon Willison，Django Web 框架的共同创建者，给出了一个发人深省的预测：「我们将迎来一个与编码代理安全相关的『挑战者号灾难』。」这个类比源自 1986 年美国挑战者号航天飞机失事事件，那场灾难的根源是一个小小的 O 形环失效，但由于系统性忽视了警告信号，最终导致了七名宇航员的牺牲。
Willison 的担忧并非空穴来风。他指出：「这么多人，包括我自己，几乎都是以 root 权限运行这些编码代理。我们让它做任何事情，每次我的电脑没有被清空，我就觉得『哦，没问题』。」这种麻木感正是灾难的前兆。当 AI 代理被赋予越来越大的权限，而开发者逐渐习惯于不加审核地接受 AI 的输出时，系统性风险就在悄然积累。
David Mytton，开发者安全提供商 Arcjet 的创始人兼首席执行官，给出了更加具体的警告：「2026 年，我将看到大量 vibe-coding 应用以大规模的方式进入生产环境。这对于开发速度来说是件好事，但你仍然需要密切关注。将会有一些大爆炸发生！」他所说的「爆炸」并非比喻，而是指那些未经适当审查的 AI 生成代码在生产环境中可能引发的灾难性故障。
长期维护的技术债务与可持续性危机
vibe-coding 面临的核心可持续性挑战可以从三个维度来理解：代码理解、技术债务和安全漏洞。
首先是代码理解问题。当一个开发团队在数月或数年后需要修改或扩展一个 vibe-coding 生成的应用时，他们面临的将是一堆自己从未写过、甚至从未仔细阅读过的代码。David Mytton 提出了一个直击本质的问题：「你到底有多深入地理解 AI 返回给你的内容？你该如何测试它？它实际上在做什么？」这些问题在快速迭代的初期往往被忽视，但当系统需要长期维护时，它们会变成难以逾越的障碍。
其次是技术债务的累积。Eitan Worcel，Mobb 公司的创始人兼首席执行官，对此有深刻的洞察：「在 vibe-coding 之前的世界里，安全积压是一份你可能在下次审计前才会去处理的已知问题列表。糟糕，但相对可控。现在，那些未解决的漏洞正在积极地塑造你的团队明天要编写的代码。你的积压不再是静态的债务；它是一种活跃的风险，影响着每一行新代码。」这意味着 vibe-coding 不仅没有消除技术债务，反而可能使其变得更加隐蔽和危险。
第三是安全漏洞的放大效应。Worcel 指出：「大多数生产应用已经存在多年 —— 如果不是数十年 —— 携带着或大或大的安全积压。当你提示大语言模型添加一个功能时，它会首先查看应用代码，如果发现一个可以用于实现请求功能的模式，它会将这个模式视为『已批准的模式』，并优先使用它，即使该模式是有漏洞的。」换句话说，AI 有可能将项目中已有的不安全模式复制到新的代码中，从而放大而不是减少安全风险。
工程实践的回归：类型系统、编译器与测试
面对这些挑战，行业正在重新发现传统工程实践的价值。David Mytton 给出了一个看似简单却极具洞察力的建议：「强类型语言在与 AI 编码器配合使用时具有优势，因为编译器会在出现问题时失败。使用 Rust 这样的语言更好，编译器会在某些东西不正确时失败。这一直是该语言的一个优势，但代价是陡峭的学习曲线。也许现在这个代价已经不重要了，因为 AI 可以编写可证明正确的代码？」
这个观察揭示了一个重要的趋势：类型系统和编译器不再仅仅是人类程序员的负担，而是成为了 AI 生成代码的质量门禁。当 AI 生成的代码必须通过类型检查时，许多潜在的错误会在编译阶段被捕获，而不是等到生产环境中才暴露。对于追求系统可靠性的团队来说，这可能是选择编程语言时需要重新考虑的因素。
除了类型系统，全面测试的重要性也被重新强调。Mytton 指出：「否则，你需要一套全面的测试套件来确保代码更改不会破坏功能。这可能意味着端到端测试。」在 vibe-coding 的语境下，测试不再仅仅是质量保证的手段，它实际上成为了理解 AI 生成代码行为的唯一可靠方式。通过测试，开发者可以间接地「理解」那些他们没有亲手编写的代码。
边界划定：AI 辅助与人类工程判断的分水岭
在经过两年的实践和反思之后，业界正在形成一套关于 vibe-coding 适用边界的共识。David Mytton 给出了截至 2026 年 1 月的明确指引：「在经过验证的组件周围进行脚手架搭建：可以。无法验证的新型安全实现：不可以。对现有代码进行小规模、可审查的更改：可以。从头开始生成整个代码库：只有在将其视为可丢弃的情况下才可以。」
这个框架的核心洞见在于：AI 的角色应该是在人类设定的边界内工作，而不是无限制地发挥。当涉及到安全关键代码时，Mytton 的建议非常明确：「如果你不能适当地审查它，你就承担了你可能没有意识到的风险。这就是为什么 AI 应该实现经过验证的组件，而不是从头发明安全机制。」这与密码学领域的经典格言「不要自己编写加密算法」形成了有趣的呼应 —— 在 AI 时代，这个原则可能需要扩展到更广泛的编程领域。
从更宏观的视角来看，vibe-coding 的兴衰周期揭示了一个更广泛的真理：软件开发的核心挑战从来不仅仅是「写代码」，而是在复杂系统中管理不确定性、积累知识和传承实践。AI 可以极大地加速代码生成的速度，但它无法替代人类工程师对系统的深层理解和判断。在某种程度上，两年 vibe-coding 热潮的退去可能不是失败，而是一次必要的校正 —— 它提醒我们，工程的本质不是魔法，而是纪律。
资料来源
本文核心观点来源于以下资源：Simon Willison 关于编码代理安全预测的博客文章（2026 年 1 月）；David Mytton 在 LinkedIn 和 The New Stack 上的分析；以及 Eitan Worcel 关于 vibe-coding 安全积压问题的论述。