我尝试用 Vibe Coding 开发 C++ 音频流系统：以下是结果

Source: Dev.to

让节奏驱动

先说明一下，我并不是完全盲目地进行。因为我了解音频流、环形缓冲区以及它们如何与渲染器集成，我对大模型（LLM）做了一点点引导。即便如此，结果正是我所预料的——

• 它能运行。
• 没有崩溃。
• 没有明显错误。

但仔细观察，你会发现它并没有真正工作。

我得到的只是概率上的平均实现——即某人可能会怎样实现音频流的平均方案。没有新意，也没有意识到这个流是在渲染器内部运行的。只是最符合统计概率的解法。

说实话，平庸本身并不是最糟的，最糟的是：

2.1 k 行代码。

顺便说一下，这与 AMP 没有任何关系——它是个很棒的工具。它们从免费到付费的转变实际上相当令人印象深刻。这些不过是让 LLM 做它们擅长的事的前端而已。

作参考：如果你熟悉 raylib（本例即使用它），干净的 C++ 实现音频流通常不到 100 行。

那么这 2 k+ 行代码到底是什么？仔细看看结尾的 TODO。

乍一看，你可能没有发现问题。问题在于：

我现在拥有一个平均的解决方案，却必须阅读并调试它。

• 我的仓库被成千上万行自动生成的 Markdown “文档”污染。
• 我花了很长时间等待生成，这段时间本可以直接用来编写代码。

真正的代价：阅读代码

如果你曾经接手过一个代码库，你一定深有体会。如果没有，来做个练习：fork 任意一个你依赖的项目，然后尝试阅读它。

阅读不是自己写的代码很困难。它与你的思维模型不相连，也不在你的脑中。

现在再尝试阅读大体可用，但并不完美的代码。低层次圈子里有句老话：“我喜欢段错误，因为它们能准确告诉我哪里出错。”这话不假。没有什么比看起来合理、能运行却悄悄做错事的代码更让人恐惧的了。

这正是 Vibe 编码给我的感受。最终，我花在处理这些问题的时间比自己动手写代码、动脑思考、并在真正有帮助的地方使用 LLM 的时间还要多。

想象一下一个没有任何编程背景的人。他们会重复多少次提示？他们甚至会说什么是“错误”？

我最终的落脚点

写到这里，我真的感到沮丧。对那些改动毫无兴趣。所以我决定以我真正推荐的方式使用 LLM：把它当作工具。

“Claude，帮我梳理一下这段代码，给出一个简明的工作原理概述，并附上链接。”

就这么简单。

最后思考

反 Vibe 编码者并不是反对 LLM。我们反对的是没有脑子的营销幻想以及它对初学者造成的真实伤害。这就是我们从一开始就一直在说的。

不过，人生是自己的。随你怎么使用它，随你觉得合适。