Vibe Coding 已死。以下是它的替代方案。
Source: Dev.to
请提供您希望翻译的完整文本内容（除代码块和 URL 之外），我将按照要求将其翻译成简体中文并保留原有的格式。谢谢！
Vibe 编码的兴衰
在 2025 年 2 月，Andrej Karpathy 创造了 “vibe coding”——一种仅凭“氛围”来构建软件的艺术，让 AI 完全负责编写代码，而你只负责引导。一年后，他已经转向其他方向，整个行业也是如此。原因如下。
Karpathy——前 OpenAI 创始成员、前特斯拉 AI 主管——在 2025 年 2 月发了一条推文，掀起了一场运动。他描述了一种全新的编码方式：“完全顺从氛围，拥抱指数增长，忘记代码的存在”。他把它称为 vibe coding。网络立刻爱上了它。突然之间，每个人都成了开发者。你不需要懂代码，只要描述你想要的功能，让 AI 来实现即可。
“不要去阅读代码。不要试图理解它。只要接受或拒绝 AI 给你的结果。如果出现错误，把错误信息复制回提示中，让 AI 修复。这并不是真正的编码，我写道。我只是看东西、说东西、运行东西、复制‑粘贴东西。”
采用数据随之而来。
- 根据 Stack Overflow 2024 开发者调查，82 % 的开发者现在至少每周使用一次 AI 编码工具。
- 微软报告称，AI 在其产品中生成的代码约占 30 %。（来源： The New Stack）
- GitHub Copilot 单独就拥有 超过 180 万 付费订阅者。
但采用并不等于验证。人们同样热衷于加密货币日交易和 NFT。问题从来不是开发者是否会 使用 AI 来写代码，而是这些代码是否真的能正常工作。
到 2025 年底，连 Karpathy 也开始退缩。在后续的帖子中，他承认需要 更多的监督和审查，并描述了自己日益结构化的工作流程——使用规范、审查输出，并像对待初级开发者的 Pull Request 那样对待 AI 生成的代码。 “顺从氛围” 的时代在它的第一个生日之前就已经结束。
让 hype 破灭的数据
当科技媒体庆祝 vibe‑coding 革命时，研究人员悄悄测量它实际产生的效果。结果令人震惊。
安全是最大的问题。 一项乔治城大学 CSET 研究发现，45 % 的 AI 生成代码包含安全漏洞——这不是边缘案例，也不是理论风险，而是几乎一半代码中真实、可被利用的缺陷。
情况更糟。CodeRabbit 2025 AI 代码质量报告分析了数百万次 pull request，发现 AI 生成的代码比人工编写的代码多出 1.7 倍的重大问题。这些并非风格挑剔，而是错误、逻辑缺陷以及能够通过初审的安全漏洞。
“86 % 的 AI 生成代码未通过 XSS 防御。88 % 存在日志注入漏洞。47 % 包含 SQL 注入缺陷。”
— 乔治城 CSET，AI 生成代码安全分析
接受率也说明了问题。GitHub Copilot 的建议接受率徘徊在 30 % 左右，这意味着开发者拒绝了 70 % 的 AI 建议。如果你的同事在代码审查中有 70 % 的拒绝率，你肯定会严肃地谈论他的表现。
生产力呢？ 对使用 AI 工具的开源开发者进行的受控研究发现，他们的编码速度实际上比不使用 AI 的人慢 19 %——尽管主观上认为自己更快。AI 制造了一种危险的生产力幻觉。
创业生态也以惨痛代价领悟到了这一点。Lovable，一家 AI 应用构建平台，曾在盛大宣传后推出——随后研究人员发现平台上1,645 个应用中有 170 个存在数据泄露漏洞。这相当于**超过 10 %**的应用在发布时就让用户数据悬而未决。
MIT Technology Review 将生成式编码列为 2025 年的突破性技术，但明确将其与 vibe coding 区分开来。他们的表述是：突破在于能够根据结构化规范构建软件的 AI，而不是根据“氛围”构建软件的 AI。
为什么 Vibe 编码在生产环境中会失败
上面的数字并非随机。它们是根本性缺陷方法的可预见结果。Vibe 编码因三种结构性原因而失败：
- 没有架构就没有连贯性。 按行提示 AI 会产生能够解决每个单独提示的代码，但永远无法形成一个连贯的整体。没有数据模型，没有 API 合约，没有关注点分离。你得到的是一堆在演示中可运行、在真实流量下就会崩溃的代码。
- 没有规范就会产生幻觉依赖。 AI 模型会用看似合理的胡言乱语填补空白。没有明确规定功能应如何工作的规范，AI 会自行“发明”行为——这些发明会产生极难发现的 bug，因为它们乍看之下是正确的。
- 部署速度超过安全审查。 Vibe 编码的核心吸引力在于速度。但当没有人审查输出时，这种速度就成了负担。你发布得更快，但也更快地发布了有漏洞的代码。45 % 的漏洞率并不是因为 AI 写不出安全代码，而是因为 Vibe 编码从未要求它这么做。
核心问题： Vibe 编码优化的是创建速度，而不是输出质量。在生产环境中，质量是唯一重要的因素。没有质量的速度只是一种更快累积技术债务的方式。
AI生成的代码债务
行业在过去一年里一直在努力弥合这一差距——不是放弃 AI（它的生产力潜力太大，无法忽视），而是为 AI 生成代码的方式设定结构。
实际有效的方案：规格优先 AI
答案不是“更少的 AI”。而是 更有针对性的 AI。
MIT Technology Review 做出了正确的区分：突破点不是“AI 根据提示编写代码”。而是 “AI 根据结构化计划构建完整软件”。
这就像让承包商“随便建点好东西”，与直接交给他们建筑蓝图的区别。
这标志着从 建议优先工具（Copilot、ChatGPT、Cursor）向 规格优先平台 的转变。
| 维度 | 建议优先（Vibe 编码） | 规格优先 AI |
|---|---|---|
| 输入 | 自然语言提示 | 结构化规格 |
| 架构 | 自发（或缺失） | 在生成前已定义 |
| 输出 | 代码片段、碎片 | 完整应用程序 |
| 测试 | 手动，事后 | 自动生成 |
| 安全 | 基于希望 | 内置于流水线 |
| 可维护性 | 低（无人能理解代码） | 高（规格文档阐明意图） |
关键洞见： 规格优先并不意味着更慢。前期对 要构建的东西 进行定义的投入会多次收回成本。你可以跳过 “生成 → 测试 → 修复 → 重新生成” 的循环——这些循环消耗了大多数 Vibe 编码者的大量时间——并且首次就能正确完成，因为 AI 拥有足够的上下文来生成连贯、可投入生产的代码。
乔治城大学的研究也支持这一点。当研究人员在 AI 提示中加入面向安全的指令时，安全代码生成率从 56 % 提升至 66 %——仅是一次简单的提示修改。想象一下，如果向 AI 提供一个 完整的规格，其中包含明确的安全要求、数据验证规则以及认证模式，会产生怎样的影响。
Source: …
2026 实战手册
如果你在使用 AI 生成代码——而且你应该这么做——请遵循这个在生产环境中真正有效的框架。
1. 从规格（spec）开始，而不是提示（prompt）
在生成任何代码之前，先定义数据模型、API 合约、业务规则和用户流程。AI 应该是 实现 一个计划，而不是自行发明计划。这能把生产软件和点击错误按钮就会崩溃的演示区分开来。
2. 像审查初级开发者的 PR 那样审查 AI 输出
不要在未经审查的情况下接受 AI 生成的代码。阅读代码，检查逻辑，验证边界情况。AI 是一个不知疲倦的初级开发者，擅长模式匹配却缺乏判断——请相应地对待它。
3. 使用安全优先的提示和模板
乔治城大学的研究表明，明确的安全指令可以显著提升 AI 代码质量。将安全需求写入你的规格中。使用默认包含身份验证、输入验证和输出编码的模板。
4. 在部署前自动化测试
如果你的 AI 生成的应用没有自动化测试，就不允许发布。仅此而已。测试生成是 AI 最强大的能力之一——在 2026 年，部署未经测试的代码没有任何借口。
5. 为任务选择合适的工具
逐行代码建议工具在现有代码库中完成小任务时表现出色。要构建完整的应用程序，你需要一个能够理解全局——架构、数据流、安全、测试——而不仅仅是下一行代码的平台。
结束思考
问题不在于 AI 能否写代码，而在于你是否拥有安全交付的流程。2026 年获胜的团队不会是写代码最多的团队——而是交付 bug 最少的团队。
Vibe 编码曾是一段时光。它向数百万人展示了 AI 在代码方面的能力，并迫使行业认真对待 AI‑辅助开发。那段时光已经过去。取而代之的是更好的方案：从计划出发构建软件的 AI，伴随审查、测试以及从一开始就内置的安全。
我是 Codavyn 的创始人，我们构建以规范为先的 AI 开发工具。如果你想了解生产级 AI 代码生成的样子，请查看 Star Command。