8.0
热点
AI SCORE
观点评论2026-08-13 19:40
Vibe Coding不是软件工程：AI编程的边界与反思
dev.to · AI#AI编程#工程实践#安全
Editor brief · 编辑速览
区分AI辅助开发与vibe coding两种模式，指出近半数AI生成代码存在安全漏洞。强调AI是工具而非工程判断的替代品，观点客观有据。
Vibe Coding 无处不在，但它到底算不算正经的软件工程？
Vibe Coding——通过给 AI 下指令来写软件，几乎不做人工审查、直接接受 AI 的输出——本身并不能算好的软件工程。它是一种原型构建技术，却被误当成了一种开发方法论。数据也印证了这一点：近一半由 AI 生成的代码样本存在可利用的安全漏洞，工程负责人已经在反映治理危机。如果有意识地结合真正的工程纪律来使用，AI 辅助编程确实具有变革性的力量。但如果把它当作工程判断力的替代品，那它就是一个披着漂亮 UI 外衣的隐患。
这个概念出自 Andrej Karpathy 2025 年 2 月的一篇文章，此后它分化成了两个截然不同的东西，却经常被混为一谈：
AI 辅助开发——专业开发者在正常的工程工作流中使用 Copilot、Cursor 或 Claude Code 这类工具：架构经过规划、输出经过审查、测试有人编写。
真正意义上的 Vibe Coding——描述你想要什么，以最少的审视接受输出，通过重新提问而不是通过阅读和推理代码来迭代。
大多数讨论——无论是炒作还是反攻——实际上针对的都是第二种。而两者之间的混淆，正是为什么每一篇"vibe coding 太厉害了"和每一篇"vibe coding 是一场灾难"的文章都能引用真实案例的原因。
它的吸引力并不神秘。当它起作用时，速度是真的快：
如果你的工作是"做出个能给人看的东西"，这几乎就是魔法。这也正是 dev.to 的热门页面、GitHub 的探索动态和 Hacker News 都偏向于那些看起来已经完成的项目的原因——因为现在生成精美外观的成本很低，平台奖励的是看起来完整的东西，而不是真正做得好东西。
"看起来完成了"和"真正完成了"之间的差距，就是一切问题的核心。
Vibe Coding 诚实地展示了功能的简单 80%，却对困难的 20% 保持沉默。生成一个结账流程、管理后台或 CRUD 面板只需要几分钟。而悄悄崩溃的是这些：
那些在截图里看起来最完成的应用，往往在底层最脆弱——因为 AI 非常擅长生成看起来可以投入生产的东西，而只有经过训练的眼睛才能区分"看起来完成了"和"真正完成了"。
如果你抛开情绪只看 2025-2026 年的研究，会看到一个相当一致的画面：
与此同时，Gartner 预测，如果组织不建立质量控制，到 2028 年，不受管控的"提示词到应用"开发模式可能使软件缺陷率增加 2500%。这不是笔误——这就是采用速度与治理成熟度之间差距的规模。
同一工具在不同人手里效果不同，这就是"vibe coding 很棒"vs"vibe coding 是灾难"往往取决于谁在操控方向盘的原因：
最后一点才是真正的工程风险。AI 辅助编程并没有消除对工程判断力的需求——它只是把这种判断力发生的位置从"写代码"移动到了"审查代码"。如果循环中没有人有判断力来审查，那判断就不会发生。
软件工程作为一个学科，实际上并不是关于代码打得有多快。它是一套实践——架构、测试、审查、安全思维、可维护性——这些使软件在长时间内保持可靠，而不仅仅是在演示中能用。按这个定义：
Vibe Coding 本身不是软件工程。它是一种恰好能产出可运行代码的原型技术。
这不一定是贬低——草图、原型和快速迭代一直都有价值。错误在于把草图当成交付物。63% 的 vibe-coding 工具用户自称是非开发者（PM、创始人、设计师），用这种方式构建内部工具并没有做错什么——风险出现在那段原型代码悄悄变成生产系统，而没有人随后对其进行工程纪律约束的时候。
当把 AI 辅助编程应用于正确的问题时，它确实有用。它特别适合以下场景：
在某些情况下，严重依赖 AI 生成的代码会带来重大风险。当处理以下情况时要谨慎：
关键的区别不在于 AI 是否写了代码，而在于是否有具备适当专业知识的人理解、审查、测试并为之负责。
如果你要依赖 AI 生成——目前这个阶段大多数团队都应该——解决办法不是避开它，而是保持 vibe coding 倾向于跳过的工程纪律：
在选工具之前就定好审查标准。 代码审查深度、测试覆盖率最低要求、部署门槛应该是政策，而不是等东西坏了才事后补上的东西。
把 AI 输出当作一个快速、自信的初级工程师的草稿——而不是一个完成的 PR。 读它，理解它，然后才发版。
永远不要让 AI 生成的代码在没有人追溯逻辑的情况下接触认证、支付或数据访问。 CVEs 持续出现的地方就在这里。
让工具的自主性与审查者的资历相匹配。 提问的人越初级，输出就越需要更多的审查——而不是更少。
架构决策要由人来做。 AI 擅长在你已经决定好的形状里填充内容；但在决定形状本身方面，它差得多。
Q: Vibe coding 和 AI 辅助开发是一样的吗？
不是。AI 辅助开发在正常工程流程中保持了人类对架构、测试和输出的审查。而严格意义上的 vibe coding 意味着以最少的审查接受 AI 输出，并通过重新提问而不是阅读代码来迭代。
Q: Vibe coding 生成的代码安全性更低吗？
数据表明平均来看是这样的——独立测试中约 45% 的 AI 生成代码样本存在可利用的安全漏洞，几起真实的生产级数据泄露已被追踪到缺失基本访问控制的 AI 生成应用。
Q: Vibe coding 可以安全使用吗？
可以，用于原型、内部工具和样板代码——尤其是有高级工程师审查输出的时候。对于生产系统、任何接触敏感数据的部分，或者提问者没有足够经验来发现问题的场景，它是有风险的。
Q: Vibe coding 会取代软件工程师吗？
证据指向另一个方向：它正在把工程工作从写代码转移到审查和架构上。变得越来越有价值的技能不是提问——而是判断生成输出是否真正正确的判断力。
Vibe coding 不是反攻者给它塑造的恶棍，也不是炒作承诺的免费午餐。它是一种快速产出软件形状的方法。那个形状能否变成真正的软件工程，仍然取决于它一直依赖的那些东西——审查、测试、架构判断，以及循环中真正理解所发版内容的负责人。工具变快了。好的工程标准没有变。
AI 正在改变软件的构建方式。受益最多的团队不会是使用最多 AI 工具的那些，而是知道 AI 在哪里增加价值、人类专业知识在哪里重要、以及如何负责任地将两者结合的那些。