接上篇# 

在上一篇文章中，我表达了自己对于氛围编程（Vibe Coding）的观察和担忧。

让我很意外的是，这个话题引发了大量关注。我在大家的评论中也看到了不一样的观点，这让我很开心。

后来我想，不如把这个话题当做一场自我辩论，这次让自己站在 “反方” 视角，来说说为什么我们要拥抱氛围编程。

辩论并非推翻自己先前的观点，它的价值在于让你我进行更全面的思考。

关于氛围编程的说法# 

有人觉得 “氛围编程” 这个说法很奇怪，其实我也不喜欢。这里 “氛围” 的含义究竟是什么，似乎没有确切的定义。

我们姑且把氛围编程理解为一种强依赖 AI 的编程方式，人类少参与或不参与 Code Review，让 AI 完成整个产品的开发任务。

我们的目标是什么？# 

我在上一篇文章中表达的核心观点，其实都是围绕 “我要完成一个生产级应用” 这个目标的。

在这个前提下，纯粹的氛围编程的确还没有能力从零完成一个生产级应用。

但是，假设我们的目标只是做一个非常简单的应用、一个 MVP，那么氛围编程大概可以胜任。

比如大家评论中所说的：学生的毕设、一次性代码、预览和示意。

对于一个简单的场景而言，代码写的好不好，讲不讲软件工程的方法论，其实都不重要。

什么人做什么事# 

假设未来有这样一群专门从事氛围编程的人，他们可以不懂技术，但是可以快速生产 MVP，我称之为 MVP 工程师。

当一个 MVP 被验证成功，下一步就是迁移到生产级。

我们完全可以回到可靠的软件工程方法论中，招聘更专业的软件工程师来完成迁移工作，而不是当初那个用氛围编程实现想法的人。

工程难题的解决之道# 

上一篇提到：氛围编程还没有解决软件工程已经解决的种种难题。实际上，现有的基础设施已经可以解决掉很多工程问题。比如低代码平台、各类搭建平台。

在早期，低代码范式很少在非专业开发角色上验证有效，依然需要专业工程师参与。

但如今 AI 的快速进步让非专业选手终于可以放心下场，解决了以前总要请人搭把手的问题。

在成熟稳定的基建上，氛围编程其实不再需要管理软件工程的复杂性，这些复杂性会被第三方解决。

总结一下# 

氛围编程也许并没有想象中那么值得警惕，当我们把目标、人和基础建设都考虑进去，那么氛围编程产生的最大价值是：提供了一种有别于专业软件开发的新方式。

现在，不如各司其职，让氛围编程解决想法落地，让专业编程实现生产变现。

比尔盖茨曾说：“我们总是高估未来两年的变化，低估未来十年的变革”。

对于一种新的编程范式来说，我们既不能盲目乐观，也不能盲目悲观。也许十年之后，软件行业将会是另一番格局。