可销售软件的最小可行单元

# 可销售软件的最小可行单元 来源：https://brandur.org/minimum-viable-unit 上周我写了一篇关于离开 Stainless（https://brandur.org/nanoglyphs/051-that-was-fast）以及我打算将我的副业项目 River（https://riverqueue.com/）打造成一个小型可持续业务的想法。发出那封信后，有几个人问我在人工智能时代经营一家软件公司的想法：“你疯了吗？你发布的任何东西都可以被 LLM 构建的内部包瞬间取代！”作为现在和任何人一样成为 LLM 皈依者的人，我承认这是一个非常合理的问题。我可能确实疯了，但我会解释我的想法，由你来判断。 先讲一个故事。今天早上我在浏览互联网上最糟糕的互动农场和虚假信息、虚构轶事的专业索取者聚集地——领英。一个用户发帖说，他的公司每个月在 Atlassian 的 Jira 上花费 400 美元。他对这笔离谱的账单感到个人不满，于是让他的团队用 Claude 构建了一个新的内部任务跟踪器。Jira 和每月 400 美元的开支消失了，取而代之的是一个自定义包，可以通过 LLM 的持续改进以他们需要的任何方式进行定制。 多年来我们一直在软件圈讨论“买 vs 建”，但去年情况发生了变化。过去，“建”是一个非常昂贵的提议，尤其是考虑到工程薪资水平和优秀人才的稀缺。人们可以预期巨大的前期成本、进度超支，以及一个深不见底的兔子洞要钻。普遍的智慧一直是只在核心领域内构建，避免被外围项目分散注意力。一旦你的公司规模巨大，那些干扰的成本轻松消失在利润边际中，那么也许它们才值得去做。 但 LLM 改变了这一切。突然间，通过让模型来做工作，产生大量的软件变得非常可行。 --- ## 廉价 ≠ 零成本（https://brandur.org/minimum-viable-unit#cheap-ne-zero） 虽然 LLM 让软件构建成本大幅降低，但并没有降到零。良好的 LLM 构建系统仍然涉及一个反馈循环：操作员让模型工作一段时间，根据结果进行调整，要求再迭代一次，进一步优化，如此反复。需要几十个循环才能得到一个令人满意的结果，这是时间花费和质量之间的最佳折中。 和以前一样，维护将是一个持续的成本。尤其是对于更复杂的包，总会有要添加的功能或要修复的 bug。LLM 会使这些更改更容易进行，但不会让它们免费，其中最昂贵的部分是人类在其中的兼职劳动，负责监督和验证结果。 回到上面每月 400 美元的 Atlassian 故事：考虑到初始构建工作（包括优化迭代）和持续的 LLM 驱动维护，它到底合不合理？任务跟踪器仍然是一个复杂的软件，即使大量使用 LLM，你也会预期初始推送至少花费几周时间（客气地说）。之后，其内部负责人会转向错误修复和功能开发。 让我们尝试用一些粗略的数字来量化这种情况。假设我们有一个年薪 200,000 美元的工程师，每周工作 40 小时（暂时假设 996 从未被想到）。那就是每月 16.7k 美元，每周 3,850 美元，或每小时 96 美元： ``` salary = 200_000.0 { month: salary / 12, week: salary / 52, hour: salary / 52 / 40, }.each { |k, v| puts "%-6s $%0.2f" % ["#{k}:", v] } ``` ``` month: $16666.67 week: $3846.15 hour: $96.15 ``` 为了抵消本应支付给 Atlassian 的每月 400 美元，工程师花在提示/修复他们自己做的 Jira 克隆版的功能、或者照看它的数据库等事情上的时间不能超过每月 4 小时（400 / 96），不包括上下文切换的开销。即使有 LLM 的帮助，这已经完全不现实了，但让我们客气地说，他们可以将其降到每月 2 小时。即便如此，在最初两周的努力之后，仍需要 37 个月才能实现收支平衡（收回 Atlassian 每月 400 美元所需月份数减去每月 2 小时的维护努力 = 2 * 3846.15 / (400 - 2 * 96.15)）。 别误会，我和任何用过 Jira 的人一样讨厌它，而且也有几乎无法控制的想要重建它的冲动，但这里的数学算不过来¹（https://brandur.org/minimum-viable-unit#footnote-1）。 ### 构建阈值（https://brandur.org/minimum-viable-unit#build-threshold） 但这总是成立吗？让我们换个角度，看看一个价格高得多的 SaaS 产品。Gemini 报告称，一个满载的 Salesforce 席位价格约为每月 500 美元。假设你需要 50 个席位，那就是每月 25k 美元！ 用这个价格，你可以有 1.5 倍的工程资源（25 / 16.7）全职从事你的克隆版工作。同样，CRM 是一个相当复杂的软件，重建并非易事，但无论如何，对于一个较小的公司来说，这更接近“构建”决策。（而且随着 Salesforce 今年迄今下跌 30%，市场似乎也相信这一点。） --- ## 生存区间（https://brandur.org/minimum-viable-unit#zone-of-viability） 我的观点（和/或希望）是，对于一个任意复杂度的软件包，存在一个**生存区间**，在这个区间内，当定价合理时，购买比构建更有意义，即使存在已成为我们日常伙伴的强大 LLM： 生存区间在成本与复杂度的最佳点 处于生存区间的软件满足两个条件： - 具有足够的创新性，使得通过 LLM 重建变得不简单，并且会产生持续的维护负担。 - 定价没有高到强烈鼓励通过 LLM 重建。 只要合理的定价使软件保持在生存区间内，所支付的许可总费用就低于提示初始推送和维持其持续存在的累计花费。 在生存区间的某处是**可销售软件的最小可行单元**，在此之下，重建与采购第三方软件所花费的精力相同或更少，且长期来看不具备成本效益。 | | 持续价格 | 持续花费 | 工程师等效小时/月 | 等效工程资源 | 买 | 建 | |---|---|---|---|---|---|---| | **Jira** | $400/月 | $400/月 | 4.2 小时 | 0.02 工程师 | ✔ | | | **Salesforce** | $500/席位/月 | $25k/月 | 260 小时 | 1.5 工程师 | | ✔ | --- ## River 作为一种可行的业务（https://brandur.org/minimum-viable-unit#river） 过去几年里，Blake 一直在基于我们的开源项目 River（https://riverqueue.com/）做一个小生意，这是一个用于 Go 和 Postgres 的工作队列。在至少未来几个月内，我将全职接手。这篇自我服务的博客文章绕了一大圈，就是想表达：我希望，尽管世界已经跨过了 LLM 的门槛，River 仍然处于可销售软件的最小可行单元之上，并且在现代仍然是一个可行的公司。 在创新性方面，River 是一个开源项目，几乎所有与工作相关的功能（定期任务、定时任务、唯一任务、Web UI……）都免费提供，但保留了一些高级功能（工作流、顺序任务、并发限制任务……）和计费能力（按发票计费）用于一个 Pro 版本（https://riverqueue.com/pro），我们对此收费。LLM 可以重现后者的功能，但我们在其 API 设计和性能特性上投入了足够多的思考，以至于要重新达到类似的质量需要一番功夫。 在价格方面，我们使用了基于团队规模的次线性定价模型，而不是按人头计费。起步价为每月 125 美元，最多支持 20 名开发者，然后上升到该价格的数倍以获得无限站点许可。所以对于一个中小型开发团队来说，每月 125 美元是所有人员的全包费用。 那么回到开头的问题：我做得对吗？谁知道呢。目前我正在拿自己的生计下注，未来几个月会给出答案。 --- *关于顶部的照片：* 这是一个名为“Zlatnite Mostove”（“金色桥梁”）的自然地貌，位于保加利亚索非亚附近的维托沙山脉中。我最近在参加 Balkan Ruby（https://balkanruby.com/）之后在那里徒步。这片岩石区域被称为“桥梁”，因为它覆盖了一条活跃的河流。这篇帖子部分是关于 River 的，而那里有一条河，所以我希望这种联系足以合理。