我全力支持人工智能，但我们需要谈谈“氛围编码”。
目录
无论在阅读文章之前还是之后，您都可以收听播客，以获取更多关于该主题的见解：
▶️ 在 YouTube 上观看：
🎙️ 在 Spotify 上收听：
介绍
人工智能太棒了
正如标题所示，我非常支持人工智能。我认为它是计算机科学发展的必然趋势。我们一直致力于构建更智能的系统，并尽可能地实现自动化——这源于我们的本性。人类渴望便捷、高效和简单。我们越能轻松地创建和管理复杂的系统，就越好，这完全没有错。
大型语言模型（LLM）已成为这一进步的基石。如今，几乎所有软件工程师都以某种方式依赖它们（或者至少绝大多数如此）。我的职业软件工程生涯始于2017年，当时我被聘为初级软件工程师。那时，情况截然不同。花上一整天时间在互联网上苦苦搜寻解决方案是常有的事，而有时解决方案几乎是不可能找到的。如果当时我能使用ChatGPT，我只需10分钟就能生成一个解决方案，对其进行分析，然后根据我的具体用例进行调整。
故障代码和冷总线
当时，我们能找到的最好的资源就是 Stack Overflow——说实话，它常常感觉像是互联网上最乌烟瘴气的地方之一。我记得当时在一个鲜有人用的平台上工作，文档糟糕透顶，社区支持也几乎为零。走投无路之下，我决定在 Stack Overflow 上发个问题。你知道结果如何吗？什么都没有。没有回复，没有点赞，也没有踩——只有一片寂静。我又发了几个问题（哦，我甚至还因此获得了一个徽章——我可没开玩笑。），最后，不知什么原因，有人踩了我的问题，导致我的账号被锁了。没错，就这么简单。账号被锁，不是因为发垃圾信息或恶意捣乱，而是因为我问了一些没人知道答案的合理问题（这真是开启软件工程师职业生涯的绝佳方式，对吧？）。如果我当时有像现在这样的 AI 工具，我职业生涯的那个阶段就不会那么痛苦了。我不用在晚上十点坐在空荡荡的冷公交车上焦虑地思考职业选择，就能找到那些答案了。
我分享这些是为了澄清一点：我是人工智能、机器学习、深度学习——整个领域的坚定支持者。甚至我的博士研究也专注于数据挖掘和人工智能。我曾与一些对这项技术持怀疑态度的人进行过专业辩论，说实话，我不理解他们的敌意。我为什么要拒绝一个能帮助我更高效地工作、更快地学习、提高效率的工具呢？
然而，接下来是“但是”。
然而，这并不意味着我们应该以最糟糕的方式滥用任何工具的潜力。仅仅因为某样东西功能强大，并不意味着就可以肆意使用。包括人工智能在内的工具，其目的是为了辅助我们，而不是取代我们。而这种区别至关重要。
这就引出了我的核心问题：氛围编码。
我对这种趋势存在根本性的质疑。它让我感觉很不对劲。事实上，它错得离谱，我可能都无法在一篇文章里一一阐述。但我们不妨从最基本的——根本性的问题——入手，逐步探讨更复杂的问题。
名称本身
即使“氛围编码”背后的概念很棒，但它的名字仍然是最糟糕的。我认为这个名字考虑得不够周全。让我们先来定义一下这个术语的两个组成部分：
氛围：指某个地方、情境、人物等的情绪以及它们带给你的感受（dictionary.cambridge.org）
编码：指编写一系列指令（称为程序）的过程，计算机可以按照这些指令执行任务。它涉及设计和实现算法，即用一种或多种编程语言编写代码来逐步规范流程。(wikipedia.org)
既然我们已经定义了这两个术语，那么我还有两个很傻但很真诚的问题：
- 这一切究竟与氛围有何关联？
- 这一切中究竟哪里涉及到编码？
我认为恰恰相反。
实际氛围
对我来说，编程带来的愉悦感源于学习——真正的学习。当你深入学习一门新语言、尝试一个全新的库、探索一种新的设计模式或架构风格时，这种愉悦感就会油然而生。你会尝试理解它、实践它、将它融入到项目中——甚至可能为了看看它如何运作而开启一个全新的项目。
然后，失败是不可避免的。你会遇到瓶颈。因为如果你没有遇到瓶颈，说明你还没有真正努力过。你会花几个小时去弄清楚哪里出了问题。在这个过程中，你会学到更多。最终，你会豁然开朗。你会做对。你甚至可能会与他人分享你的经验——就这样，你成长了。你比刚开始的时候更优秀了。
这就是编程的精髓所在。整个过程——好奇心、失败、坚持、突破、情感交织。正是这些赋予了编程活力和意义。
我花了无数个小时修复那些顽固的bug——而且，这过程并不总是充满乐趣。有时令人沮丧、精疲力竭，甚至几乎让人失去信心。但一旦找到解决方案，一切又会焕然一新。突然间，世界仿佛变得色彩斑斓。我甚至能准确地回忆起当时正在听什么音乐、几点钟、天气如何、喝的是什么咖啡——每一个细小的细节都历历在目。
后来，当我再次听到那段音乐时，一切都回来了。我仿佛又回到了当时的场景，再次体验了那种感觉。那种情感的洗礼，那种成就感，对我来说，才是真正让编程有意义的地方。这才是编程的精髓所在。重要的不仅仅是结果，更是让你不断成长的旅程。
旅程比目的地更重要
刚开始工作的时候，我完全只关注结果——最终的成果、产出、“最终产品”。但我大错特错了。随着时间的推移，我意识到过程才是真正重要的。
没有终点，只有沿途的里程碑。这条路充满挑战、教训，而最重要的是，充满各种感受。
这正是我当初选择成为软件工程师的原因。高中时，我常常幻想自己未来能够深入理解复杂的系统——能够运用精湛的技能，凭借不懈努力积累的专业知识解决问题。这种憧憬激励着我。也正是这份工作如此吸引我的原因。
对我来说，这才是真正的乐趣所在——编程时经历的情绪过山车。起起伏伏，挫折与突破，以及随着你沉浸于问题之中，慢慢地靠自己找到答案，你的情绪也随之变化。我觉得没有比这更棒的乐趣了。
我实在无法理解，明明只是告诉LLM（法学硕士）该做什么，它就自动生成代码，怎么会有人把这个过程称作“感受过程”呢？我不是说它一无是处，以后有机会再详细说说，但我近期内应该不会尝试这种方法。
让我们回到过去
让我们想象一下，在 20 世纪 80 年代，氛围编码会是什么样子——那时，我们今天所拥有的人工智能水平还只是科幻小说里的东西。
你是一名计算机科学专业的学生，正在努力支付大学学费。你翻开当地报纸，发现了一份不同寻常的招聘启事：
HELP WANTED: VIBE CODER
80sCoolVibes, Inc.
Venice Beach, California – Est. 1981
Are you looking for a coding job that doesn't require any actual coding knowledge?
Can you explain something in plain English?
Then congratulations — this job is for you.
... and the rest of the text ...
薪水不算高，但刚好够支付学费。于是你去应聘——出乎意料的是，你竟然得到了这份工作。
今天是你上班的第一天，你兴奋不已。你终于踏入了科技界，而这正值历史上最具标志性的十年之一——20世纪80年代。计算机正在蓬勃发展，未来正在被实时书写，而你渴望成为其中的一份子。
办公室里有个叫马库斯的家伙——他是公司里唯一真正的软件工程师。他很聪明，代码写得也很棒。但问题是：他不做决策，也不设计系统。他只是坐在那里等着别人——也就是你——告诉他该做什么。
你的工作？告诉马库斯你的需求。等他做出来。检查结果。告诉他需要改进的地方。重复这个过程。
你开始意识到有些事情不太对劲。
你正处于科技史上最具活力的时代。你渴望成为一名建设者、一名创新者，一名能够从内到外理解系统的人。但现在，你却在键盘上玩传话游戏。你没有编写代码——你只是审批它、指导它、提示它。
你不是程序员。你只是告诉代码生成器该做什么的人——无论这个生成器是人还是机器。核心概念是一样的。
我不知道你怎么想，但在那一刻，我会开始认真质疑自己的决定和求职能力——或者我会觉得自己成了《黑镜》新一集里的角色，这听起来更可怕。
抽象之上的抽象？
编程语言正变得越来越平易近人。现代语言往往会互相借鉴彼此的优秀理念，力求使语法更简洁、更直观、更易于学习。当然，凡事总有例外，但总的来说，如果你要开发一种面向未来且能被广泛采用的语言，那么拥抱这些进步已不再是可选项，而是必不可少的。
你可能会说，像 PHP 这样的语言仍然被广泛使用，或者几乎整个美国银行系统都运行在 COBOL 上。你说得没错——但这完全是另一回事。我指的不是那些用于构建庞大遗留系统、几乎不可能（或风险极高）重写的语言。
以航空业为例。如果飞机的机载软件是用 C 语言编写的，没人愿意把它迁移到“更优雅”的语言——这也不难理解。谁也不想在万米高空遇到意想不到的 bug。同样，如果银行的核心系统已经用 COBOL 语言运行了几十年，通常最好还是不要改动它。这类系统规模庞大，至关重要，即使是微小的改动也可能造成重大影响。在这些情况下，稳定性永远比优雅更重要。
但对于新项目——那些还在设计阶段或试图获得市场认可的项目——情况就不同了。如果你的语言不易阅读、编写和理解，而且没有其他突破性的优势，那么它就很难被广泛采用。开发者体验如今比以往任何时候都更加重要。
我想强调的是，现代高级编程语言已经变得极其直观。以 Python 为例——它几乎可以像阅读普通英语一样阅读，这是一件好事。任何人只需几分钟学习基础知识，就能用 Python 构建一个简单的计算器应用程序。这就是易于理解的语法的力量——它赋予人们创造的能力，而不仅仅是提示。
你无需让AI模型替你写完所有代码。你可以用自己的语言亲自编写，并且仍然完全掌控一切。你是飞行员——坐在左侧，双手握着操纵杆。当你遇到瓶颈或需要回忆某个语法时，你可以求助于你的副驾驶（AI）。你获取信息，进行提炼，使其符合你的特定需求，然后将其集成到你的代码库中。你并非盲目复制——你仍然在掌控着你的方向盘。
氛围编码的精髓在于，在已有的抽象概念之上，又引入了一层抽象——但这一次，抽象的可预测性大大降低。像 C# 这样的编程语言本身已经是高级语言，并且抽象化了机器代码，但它们依然精确可靠。如果你编写的代码违反了 C# 的语法规则，它就无法编译。就这么简单。如果你精通 C# 编程，你就能掌控一切。你可以记录错误、调试关键代码段、分析性能、编写简洁易维护的代码——换句话说，你是驾驶员。你了解系统底层的运行机制。即使经过抽象，它依然保持一致性和确定性。
但Vibe编码改变了这一切。它引入的抽象与托管代码的抽象不同——它更加模糊。例如，C#编译器总是会为同一段源代码生成相同的中间语言和字节码。而AI工具则可能根据上下文、随机性或提示语，为相同的请求生成完全不同的输出。这使得这一新的抽象层可靠性大大降低——至少目前如此。
那么，如果你过于信任人工智能会发生什么呢？
我不确定人工智能的未来会如何，我也不会妄自预测——但就目前而言，如果你在编写代码时过于信任人工智能，事情可能会很快变得非常糟糕。
需要澄清的是，我说的不是那种你向人工智能寻求帮助，查看输出结果，进行调整，然后认真地将其整合到项目中的工作流程。那种流程没问题，效率很高，这正是优秀人工智能助手的作用所在。我指的是那种完全凭感觉写代码的模式——你给出一些模糊的指令，甚至都不看代码，就直接发布到生产环境。这种做法的糟糕后果已经有很多例子可以说明。
以那个如今臭名昭著的、用 Cursor 构建的 SaaS 项目为例。作者曾自豪地发推文称，该项目“零手写代码”。两天后呢？他又发了一条推文——这次是关于 API 密钥被用完、用户绕过订阅以及数据库中被随机写入垃圾数据。用他自己的话说，“各种莫名其妙的事情发生了”。
那不是软件工程，那是碰运气，然后称之为开发。
我仍然真心同情那个人——当你辛辛苦苦打造出一个了不起的东西，却眼睁睁看着别人滥用它、钻空子、榨干它的所有价值时，那种感觉真的令人无比沮丧。但这是我们都必须接受的现实：通往可持续成功的道路没有捷径。
即使你运气好，不费吹灰之力就取得了一些成就，这些捷径通常也存在漏洞。而这些漏洞很容易被利用。
人们会注意到你为了成功而走的捷径——有些人甚至会故意在这些捷径上设下陷阱，等着有人掉入陷阱。
没错，利用别人的失败是不对的。但世界并不公平——互联网更是如此。总有人在暗中寻找可乘之机。所以，无论你是开发产品、创业还是学习新技能，最好的心态其实很简单：“抱最好的希望，做最坏的打算”。这并非悲观，而是未雨绸缪。
安全风险
现在我们已经了解了基于 vibe 编码的 SaaS 示例，接下来让我们简要讨论一下这种方法带来的安全风险。
为公司开发软件时，安全性并非可有可无，而是重中之重。您肯定不希望自己的 API 密钥出现在 GitHub 代码库中，更不希望它们被公开。您需要确保凭据、令牌和敏感配置能够安全存储、加密并妥善划分权限范围。
但人工智能工具本身并不了解应用程序中哪些内容属于敏感信息。它们不知道哪些变量是机密信息，哪些数据绝对不能记录，也不知道哪些安全最佳实践适用于您的用例。当然，您可能知道这些信息并告知人工智能——因为您是一位经验丰富的开发人员，之前遇到过这些问题。但对于那些没有相关经验的人来说呢？那些将人工智能作为辅助工具，从未从零开始构建过安全系统的人呢？他们可能会在不知不觉中将机密信息提交到版本控制系统中，以明文形式记录用户密码，暴露内部端点，或者打开巨大的攻击面——而这一切仅仅是因为代码“看起来没问题”。
这就是氛围编码的真正危险之处：它可能会忽略你甚至不知道自己应该关心的部分。
除非你开发的是非常简单的应用程序，否则你最终都需要和真正的工程师交流。
软件可能会迅速变得非常复杂——尤其是在企业环境中。如果你的应用完全由 AI 模型构建，而你最终在尝试修改某些非常具体的内容时遇到了瓶颈，那么 AI 很可能也无能为力。有一次，我正在自定义我的个人 .NET 项目模板应用程序。我需要以一种非常特殊的方式调整.NET 项目模板的template.json文件，即使尝试多次，AI 也无法生成有效的解决方案。最终，我在 GitHub 的一个讨论帖深处找到了解决方法。
到了那个时候，你就需要一位真正的软件工程师——一位能够阅读、理解并精准地修改代码的人。甚至是一位能够找到人工智能无法找到的解决方案的人。但问题在于：这个人可能并不擅长处理人工智能生成的代码。事实上，仅仅是添加一个功能、修复一个bug，甚至理解现有的代码结构，都可能需要耗费大量的精力。从头开始重构整个代码库？那简直就是一场噩梦。
Vibe 编码构建速度很快，但它也可能悄无声息、悄无声息、迅速地积累大量的技术债务。
最后但同样重要的是——可持续性
当被问及 OpenAI 因为人们对 ChatGPT 说“请”和“谢谢”之类的话而损失了多少时，Sam Altman 在 X 上发表了著名的回答：
“数千万美元花得值——谁知道呢。”
这仅仅是礼貌性的回应——比如“没问题”或“不客气”。如果这些看似微不足道的互动就要花费数千万美元，那么我们就能大致了解幕后究竟消耗了多少能源。
现在缩小视角，单独看一下 ChatGPT 的全貌：
-
日活跃用户约1.22亿
-
每周活跃用户约4亿
-
每天处理约10亿条消息
-
每天消耗约1吉瓦时电力——大致相当于33000个美国家庭每天的用电量。
仅仅一种产品就消耗了如此惊人的能源。
软件工程的核心原则之一始终是效率——不仅体现在性能和架构上，也体现在资源消耗方式上。然而，Vibe 编码却恰恰相反：它将能源消耗推向了前所未有的高度。偶尔在静态网页上查找信息是一回事，而让 AI 模型全天生成、重新生成和重写整个代码库则是另一回事。
如今全球有数千万软件工程师。而“氛围编程”（vibe coding）——就其本质而言——比真正的工程开发要容易得多。因此，不难想象，未来“氛围编程”从业者的数量将远远超过传统开发人员。
如果这种情况发生，软件开发的能源消耗可能会飙升——随之而来的是碳排放量的大幅增加，以及我们尚未准备好应对的可持续发展危机。
这不再仅仅是一个技术问题，它也是一个环境问题——我们迟早都必须面对这个问题。
临近尾声，让我们转入积极的氛围。
那么，氛围编码究竟在什么情况下才有意义呢？
样板项目/代码
首先，快速生成样板项目是一个很好的应用场景。人工智能工具可以极大地简化这一过程——尤其是在你还没有现成的模板系统的情况下。当然，如果你已经投入时间构建了自己的自定义模板，那么生成样板项目可能就像运行一条命令行命令一样简单。但如果你还没有呢？人工智能可以很好地弥补这一不足。
演示项目
Vibe Code 的另一大优势在于为客户创建演示项目。有时，你并不需要功能齐全的产品，只需要展示一些东西。一个可行的概念，一个初步的想法验证。与其花费数小时拼凑一个可有可无的演示，不如让 AI 来处理。快速构建，展示你的愿景，之后你可以选择丢弃，或者将其保留为原型以便后续完善。
弥合工程师与管理人员之间的差距
这种方法对非技术利益相关者，例如项目经理或产品负责人，也极其有用。借助人工智能工具，他们可以快速构建原型，以可视化和功能化的方式向开发团队传达他们的愿景。他们无需编写冗长的需求文档，即可生成产品雏形，从而更清晰地表达他们的目标。这种快速原型制作方式可以减少误解，并帮助开发人员更快、更准确地交付预期成果。
试水产品创作
它还能在帮助新开发者入门或探索软件工程领域方面发挥重要作用。通过尝试人工智能生成的代码，初学者可以初步了解不同领域的编码方式。他们可以生成网页应用、桌面工具、移动应用和游戏，并发现自己的兴趣所在。虽然它无法替代深度学习和实际经验，但模拟编程可以作为通往真正软件工程的入门途径。
总而言之
氛围编码本身并没有错——但如果使用不当，就可能带来意想不到的后果。就像生活中几乎所有事情一样，它只是一种工具。而任何工具都有利弊，它既可以为你带来益处，也可能成为你的累赘。关键在于你如何以及何时使用它。
我近期会开始使用“氛围编码”吗？大概不会。我仍然想亲自掌控驾驶舱——完全掌控一切，对引擎内部的运行情况了如指掌。现在还不是我和人工智能交换座位，把操纵杆交给人工智能当副驾驶的时候。
但一旦它成为标准，我肯定会改用。——我仍然相信从长远来看，这才是未来发展的方向。
如果有人在这种工作流程中找到了活力和创造力？如果他们热衷于用这种方式构建产品？那么，当然应该让他们去做。任何人都没有权利阻止别人探索新的工作流程或工具。我只要求他们睁大眼睛，充分了解其中的风险和局限性，尤其是在他们还不具备识别潜在问题的技术经验时。
归根结底，我们都是同一个开发者社区的一份子。无论你是传统开发者还是新锐开发者，无论你是喜欢动手实践还是使用语音提示——最重要的是我们尊重彼此的开发路径，并互相帮助成长。
这才是真正的氛围！
