我为何要放弃 Vibe Coding
我为何要放弃 Vibe Coding
作者：Lucas Fernandes Aguiar 2025年3月20日
我们都经历过：戴上耳机，音乐震耳欲聋，手指在键盘上飞舞，沉浸在使用你最喜欢的 AI agent 的“心流”之中。 朋友们，这就是 vibe coding。 当你进入状态，似乎毫不费力地产生代码时，就是 vibe coding。
它认为，你可以通过沉浸在编码的感觉中，相信你的直觉并顺应灵感的浪潮来创建出色的软件。 但最近，我意识到至少对我而言，这种感觉...不对劲。 这就像我在观看一个 AI agent 为我编写代码，偶尔插话提出建议或更正，但通常只是观察代码展开而没有完全掌握正在发生的事情的复杂性，这可能会导致以后浪费我的时间。
到底什么是 Vibe Coding？
Vibe coding 与其说是一种方法论，不如说是一种心态。 它优先使用 AI agent 而不是通过结构化的计划和严格的测试真正思考代码实现。 它追求取得进展的多巴胺刺激，通常没有明确的路线图。 它的诱人之处在于它让人感觉富有成效。
为什么 Vibe Coding 对我不起作用
在过去的两个月里，我一直在大量依赖 vibe coding，结果并不理想。 原因如下：
首先，我最初被像 Cline、Roo Code 这样的 AI agent 所吸引，然后尝试了 Cursor editor，因为它们承诺可以增强我的编码流程。 我喜欢拥有一个可以预测我的需求并帮助我更快编写代码的 AI 伙伴的想法。 但是，我很快意识到这种方法正在把我引向歧途。
我意识到的是，使用 AI agent 可以很好地创建你想要的东西的模型，但是在那之后，上下文窗口以及所有内容都会随着时间的推移导致越来越多的返工。 发生这种情况是因为在你的沮丧中，首先想到的是再次向模型解释，甚至不知道已经实现了什么。 这是可以理解的，因为在几分钟内，agent 可能已经编写了数千行代码，而且很明显，这有点疯狂。
我在 vibe coding 中看到的最大问题是：
- 这可能是一个巨大的时间黑洞：一开始你似乎正在到达某个地方，但是由于你没有结构，你会被屏幕上出现的内容所引导，并且你会被屏幕上出现的下一个错误或工作功能所消耗。
- 它很昂贵：这是第一个问题的后果。 随着上下文窗口的增长，请求变得越来越昂贵，并且你很快就会看到像发送 50 万个 token 这样的数字，而收到的 token 只是其中的一小部分。
最终，对于许多任务来说，它似乎并不是一个巨大的节省时间的方法，如果你在没有结构的情况下开始一个项目，那就是这样。 你一开始“节省”的时间，你以后必须用它来重写代码以实现你最初的目的。
另一方面：爱好者的观点
但也有很多好处，因为至少随着时间的推移，我可以更多地了解代码。 在开始这段旅程时，我很清楚，我需要时间和金钱才能创建一个有价值的项目。 一些最初看起来遥不可及的事情，在多次阅读代码试图理解错误后，我已经开始理解语言的结构和语法。 就我而言，我正在将精力集中在学习 Python 上，所以我创建的大部分代码都是用 Python 编写的。 随着时间的推移，我可以更好地理解错误是什么，并且可以推动模型朝着解决方案前进。
Vibe Coding vs. AI Chat vs. 网页搜索
- Vibe Coding：非常适合初步探索和了解问题，但不适合结构化开发和复杂项目。
- AI Chat（ChatGPT 等）：可用于生成样板代码和获得快速答案，但可能导致依赖 AI 生成的解决方案而不完全理解它们。 需要仔细验证，并且可能遭受“AI 幻觉”。
- 网页搜索（Google 等）：对于查找特定解决方案和理解概念至关重要，但如果你不知道自己在寻找什么，可能会让人感到不知所措和耗时。
平衡似乎在于在编辑器内使用 tab completion，并使用像 Gemini Code Assist 这样的东西。 我正在使用 Gemini Code Assistant，因为它免费，但我真的很喜欢它。 我在 VS Code 中使用它，并推荐它。 它在创建单元测试方面非常好，并且在运行测试时，它在解决失败方面也相当出色。 因为这是我第一次为我的代码创建单元测试，所以理解正在发生的事情对我来说有点困惑，但是在 Gemini 的帮助下，这似乎是可以实现的。
我尝试过的另一件事是使用像 Roo Code 或 Cline 这样的 agent，但倾向于放弃它。 它们可以持续很长时间并消耗大量 token，但不能保证最终能够正常工作。 因此，问题变成了如何随着时间的推移降低成本。GosuCoder 是我看到测试各种策略以降低成本的人，但主要的瓶颈是 Claude 的使用。 虽然它似乎是唯一一个完全支持所有内容的模型，但它是运行成本最高的模型之一，并且由于它倾向于使用大量的 token，因此对于大多数人来说，成本变得令人望而却步。 如果不是因为这一点，Gemini 2.0 和 DeepSeek V3/Chat 似乎对于大多数编码用途来说真的很好（至少对我而言）。
另一种策略是使用 Open WebUI，我一直很喜欢它。 它有大量的功能和选项，这提供了很大的控制权。 我喜欢为我的不同用例（编码、专利、博士等）使用自定义模型。 它大多很便宜，并且在使用 Gemini 时，它提供了非常好的上下文窗口来编辑大型文件。 它似乎非常好的用例是粘贴文本并重新排列它、删除空格、以表格显示以及诸如此类的事情。 执行自定义提示的能力还可以节省 token 费用。
结论：找到更好的平衡
我并不是说 vibe coding 总是坏的。 让你的创造力流动并探索没有严格约束的想法肯定是有价值的。 但是，我已经了解到，这对我来说不是一种可持续的方法，尤其是在截止日期临近且 API 成本不断增加时。 对我而言，Gemini Code Assist 似乎是一个很好的替代方案，因为它免费并且具有很大的上下文窗口。 此外，Open WebUI 非常棒，因为它具有控制权和可定制性，并且对于日常任务来说，成本相对较低。
对我而言，这似乎是目前最好的平衡，但我倾向于最终为聊天应用程序付费，例如 Perplexity（它具有良好的免费套餐，每月费用为 20 美元），因为在过去的 2 个月中，我每月支付大约 30 美元的 API 使用费。 在将来，也许在本地运行一个模型是有意义的，但我认为随着更多高效模型的推出，API 使用的成本将会降低。
你可以通过我的电子邮件 lucas.fernandes.df@gmail.com 或填写下面的表格与我联系，讨论这个和其他主题。