我认为这是一个关于如何高效地进行 vibe 编程的讨论。

我看到了一款游戏叫做 Whispers From The Star，他们在游戏中谈到建造自己的模型来回应用户。 这让我想起了：“酷，但为什么？”

>建造自己的模型花了多少时间从而剥夺了游戏其他方面的开发？ 我们的模型为什么比当前的 LLMs 更好？ 是否有长期的成本效益？

然后我发布了这个帖子，连同一个出版商的回应，人们开始讨论为什么不再支付工具费用的问题，所有东西都可以自建。

我们正在进入一个新的时代：“是的，你可以用 vibe 编程任何东西，但你应该吗？”

vibe 编程就像是一种让我们有无限自信力的药物，我们还没有完全学习如何正确地调节自己。因此，我想讨论一下 build vs. buy 的一些规则。

当我写这篇文章时，我想建造一个，如果它不存在的话，一个 vibe 编程时间和成本计算器。

我已经想到了一些参数来开始：

  1. 这个工具的成本是多少，计划使用多长时间？
  2. 如果你自己建造它，是否需要你可能不具备的知识？
  3. 如果你使用一个 vibe 编程订阅，带有一个限制，完成建造工具本身需要多少次会话或周数？
  4. 如果你使用一个 API 计划，你支付的 token 没有限制，建造工具本身需要多少 token？
  5. 如果它有其他成本，如托管，其他 API 等等，建造工具本身需要多少钱？

所有这些问题都可以形成一个决策矩阵，形式如下：

  1. 如果工具使用的时间成本低于建造它本身的成本，支付工具费；否则，vibe 编程。
  2. 如果工具自我回收的期限超过几年，支付工具费；否则，如果工具自我回收的期限为几月，vibe 编程。
  3. 如果工具需要深入的专业知识，需要花费几个月才能学习，并且会分散你的核心目标，购买工具；否则，vibe 编程。

我仍在思考一个购买还是编程的决策矩阵，但是我想得到其他人的想法。