氛围编程如何改变程序员？

让AI来写代码安全吗？这些技术背后是否存在代价和陷阱？

我注意到我身边有不少人对如何使用Vibe Coding（氛围编程）有着不同的看法。
例如，Vibe Coding还过于糟糕，可能无法支持完成一个大型项目。又或者，Vibe Coding已经足够强大，以至于程序员已经不再被 需要。

本文将尝试从多个角度，解读目前Vibe Coding能带来的价值和问题，和我们应该如何使用Vibe Coding。

什么是Vibe Coding

“Vibe Coding” 是 2025 年流行起来的一个术语（由 Andrej Karpathy 等人推动流行化）。核心思想是：使用以自然语言作为指令 的AI-Agent生成代码，开发者把关注点从一行行写代码转为通过“指令-观察-迭代”的方式引导 AI。

简单来讲，传统的AI辅助编程更注重于如何让AI在行内补全代码，而Vibe Coding则是将AI作为能够主动产出完整功能模块的合作者， 开发者不需要深入审核每一行代码，而是直接对应用进行测试来驱动迭代。

这样做的好处显而易见，开发者无需再关心代码实际的运行原理，而是转而通过AI来对应用进行功能开发和调试。收到错误信息时，只 需要抛给AI，问题就会被自动解决。

如今的AI集成IDE只需一句提示词，便能自动生成任意类型的应用。AI可以自动进行编码、调试、撰写文档和代替用户执行其他操作， 例如发布。这一编程方式彻底颠覆了“编程一定要代码”这一传统观念。

效率与质量

Vibe Coding在编写代码方面的效率比人类高上非常多倍。只需要给出提示词、运行、提供反馈和新需求，AI就能将几天的工作量缩到 几个小时甚至是几分钟。测试案例、文档、样例和接口约定等内容AI只需要很短的时间就能完成总结。AI编程使得“造轮子”的部分变得 轻松且迅速。

综合社区中的经验和意见，Vibe Coding在简单 CRUD、脚手架和前端界面等方面收益最大。这些领域通常不需要复杂的业务逻辑，AI 可以帮助节省大量的机械劳动。

但是，这样做也有代价。

2025 年 5 月，据报道，瑞典氛围编码应用程序 Lovable 生成的代码存在安全漏洞，在 Lovable 创建的 1,645 个 Web 应用程 序中，有 170 个存在允许任何人访问个人信息的问题。Vibe Coding - Wikipedia

一方面是生成式AI技术不够成熟，一方面也有用户的提示词工程技术不足的问题，AI在某些条件下依旧会输出脆弱的逻辑，导致程序产 生严重错误或逻辑漏洞。AI生成的代码可能会在某些情况下失效，造成例如边缘案例、并发/竞态问题甚至是SQL注入。

在我个人曾经的使用经历中，AI经常出现违反提示词，编造出虚假的逻辑，缺少对代码的理解等问题。不过，这些问题随着AI的发展逐 渐变得稀少。实际上，目前市面上的推理模型已经有着超过人类的代码理解力和边缘情况处理能力。AI通常可以主动发现代码中的问题 ，提出有关并发/竞态问题的改进建议和更强的错误处理思路。

除了代码本身的质量问题，我认为代码块之间的质量差距才是导致一个项目“卷成一团乱麻”的元凶。由于AI模型之间的编码习惯并不统 一（虽然这在人类编程者中也会出现），导致“代码块有着自己的思想”的情况经常出现。代码块之间的接口、抽象层次和目标方向无法取 得一致，导致AI更倾向于强行耦合接口或在原本的代码块上添加更多不必要且杂乱无章的代码行。

结果是项目快速失去可维护性，陷入过度耦合。而AI对于已经变成一团乱麻的项目会更倾向于用更小的更改来让某个功能“能跑”，也就是 继续堆叠代码，缺少对整个项目的理解力，堪称火上浇油。

一个不重要但很有趣的事情：

在实际的使用中，AI总是会在写完某个代码块后编写大量的测试和文档，文档质量也参差不齐，导致原本清晰的项目结构被破坏。以 及部分模型会喜欢创建相当多的“_simple”和“_enhanced”代码。例如，一份feature.ts，在经过几次改进之后会出现:

• feature-enhanced.ts
• feature-improved.ts
• feature-fixed.ts

而在经过痛苦的“调试-新指令”循环后，feature-simple.ts和feature-using-other-method.ts也会出现。

不过，这个问题可以通过让AI维护一个中心项目规范或文档解决。统一Review或周期性重构措施也可以缓解这一情况。

此外，学术界最新基准也提示了模型的隐藏弱点。例如，EffiBench-X 评测发现，虽然主流模型能生成功能正确的代码，但在执行效 率（包括运行速度、资源使用、多语言）方面平均仅达人类水准的 ~62%。

如何使用

就目前来讲，AI可以被用于小型项目、可行性验证和Demo等方面的生成。相比于人类编程者，AI已经可以相对独立地完成一整个模块的 构建、文档编写和自动化测试等操作。但在大型项目中，AI依旧不够可靠，无法完全代替人类编写的代码。因此，仅使用AI生成代码后 立即投入生产的想法是危险的。

任何AI编写的代码都应该经过完整的审计和测试。对于Vibe Coder，一个建议的行为是强制AI编写的代码通过单元测试、集成测试和 安全扫描。Vibe Coder同样可以手动审阅代码来获得更高的安全性和代码掌控力。

而很多大型公司也在通过推出AI驱动的“Bugbot”服务来充当一定场景下的代码审查的解决方案。这些服务都是通过CI管道集成或主动 扫描来分析和捕捉代码中由AI引入的漏洞。

我们失去了什么

AI编码正在走向完美，它越来越强的编程能力也在代替人类。

短期内，AI会改变IT厂商的岗位入门标准。相比于招聘低阶编码工作者，使用AI进行代码生成的成本要小很多。公司可能会更倾向于重 视系统思维、架构和审查人才。业界讨论 认为AI不会完全消灭岗位，但会改变所需技能。

除了AI带来的职业危机，其责任归属则更令人困惑。当 AI 写出有缺陷的代码导致损失时，责任在谁？产品经理、AI 服务商还是“vibe coder”？目前法律政策仍然在摸索和调整中。

同样，AI存在的缺陷可能会允许更多还不具备编程能力或还没有安全意识的人发布有安全或隐私风险的应用，甚至是极大降低了恶意软件 的制造成本。

我身边的朋友更关心的问题是，AI是否在夺走属于程序员的尊严？

Vibe Coding挑战了程序员所定义的创作与工匠精神，动摇了以“创作”作为自我核心认可的程序员的身份认同，使得过去令人骄傲的工作 在AI面前显得低效和可替代。当创作过程被浮点数计算所取代，它还算作作品吗？还应该被授予荣誉吗？多年的积累与努力不如AI几分钟 的工作。AI正在如挑战绘画领域一样挑战编程领域的成就感和掌控感。

模型选择

当前Vibe Coding主要分为两类：

• IDE 集成式（例如 Cursor、Windsurf、Cline）：提供完整环境感知、自动测试与修复回路，适合快速原型与团队协作。
• Agent Sandbox 式（例如 Lovable、GitHub Copilot Workspace）：允许 AI 主动执行构建、部署、调试等指令，风险与自由度都更高。

而在模型选择上，我可以根据我的个人使用经历来简单划分模型：

• GPT系列的模型更适合跨大型项目进行问题溯源和复杂漏洞解析
• Claude系列的模型有着出色的代码编写表现，更适合日常使用和创建大型模块
• Gemini系列更强调综合性能和长上下文窗口，更适合对大型代码文件进行重构
• DeepSeek R1在对成本控制要求高的情况下是个值得考虑的选择

一些民间研究和实验可以为模型选择提供参考：

• 2025年10月 Code Supernova Evaluation
• 2025年7月 CrossPL: Evaluating Large Language Models on Cross Programming Language Code Generation

这些研究涵盖了上文提到的几种常见模型。

总结

总的来说，AI还不足以独立完成大型项目，必须要有人监督和审查AI生成的代码。而对于小型项目，AI的效率优势已经非常明显。

已经完全适合使用Vibe Coding的环境包括：

• 快速原型 / 个人化小工具：单人工具、可丢弃的“周末项目”和可行性验证
• 增强型工程师工作流：将AI作为单元测试、文档生成工具将重构工具，也可以用于编写初稿、建立框架和补全轮子

但不建议或不应该使用Vibe Coding的环境：

• 高安全/关键系统：应该遵循企业规定的AI辅助流程，并且配备专业审计和强验证流程

把 Vibe Coding 当作编码助手来用，而不是 “替代人类审查的黑箱”。设定规则、自动检测、模型治理与审查约定后，它能把你的 创造力放大；没有这些，你更可能把技术债务和安全漏洞放大。