我对Vibe编程有点兴趣，但如果你不懂常规编程，我不知道该如何进行Vibe编程。
我最喜欢 Claude 的代码。我觉得 Codex 的代码往往过于复杂，而且不太遵循具体的指令。
最难的部分在于模型会编写大量代码，其中很多都是冗余且粗糙的（传统意义上的粗糙）。但好处是，你可以轻松编写一百万个单元测试。（实际上，我从 gpt-3.5 开始就一直使用 LLM 来进行单元测试。）
这算是一种很有意思的模式。例如，在我一直在做的这个小玩具应用中，有大约 15 个地方会触发应用滚动到某个元素。每个地方都编写了完全相同的 7 行代码来执行此操作。而我的做法是……
我写了一个名为 scrollToElement 的函数，然后在需要滚动到某个元素时调用该函数。但它无论滚动到哪里，都只会重复执行相同的 7 行代码。它似乎没有想到要重构这段代码。这显然很糟糕。然而，
它似乎能够毫无问题地根据需要修改这 15 段相同的代码，而且其行为经过了充分的测试覆盖，即使漏掉了一段，测试也会失败，它会找到错误并进行修复。这在美学上很糟糕，但功能足够好。
直到我开始认真阅读代码，才注意到这个问题。通常来说，你会尽量避免像这样重复代码（DRY 原则），因为它会引入脆弱性和 bug，但这里似乎并没有出现这种情况。虽然这仍然很糟糕，但它也引出了一些有趣的问题……
比如说，如果你遇到一个精力无限、能写出无数代码的人，是不是稍微详细一点的写法更好呢？我自己的很多做法都是出于一种审美偏好，即用尽可能少的代码实现尽可能多的功能，但这可能并不适用于LLM代码。
当然，这种模型不可能拥有无限的续航能力。它需要花钱，而且实际上可能比我付的钱还要多。