The Minimum Viable Unit of Saleable Software：AI 时代的软件商业最小可行性单元

背景

上周，作者写了一篇关于离开 Stainless 并计划将其个人项目 River 打造为一家小而可持续的企业的文章。在那封信发出后，许多读者提出了一个尖锐的问题：在 AI 时代，你为何还要试图经营一家软件公司？“你疯了吗？你发布的任何产品都能被 LLM（大语言模型）瞬间构建的内部包所取代！”

作为一名坚定的 LLM 信徒，作者承认这是一个非常合理的问题。尽管这可能意味着他确实有些“疯狂”，但他希望通过梳理自己的思考过程，让读者自行判断。

文章以一个真实的轶事开篇：作者在 LinkedIn 上看到有人分享，其公司每月花费 400 美元使用 Atlassian 的 Jira。由于觉得这笔账单过于离谱，该用户让团队使用 Claude 构建了一个新的内部任务追踪器。Jira 被取代，每月 400 美元的支出消失，取而代之的是一个可以通过 LLM 持续优化来定制任何需求的自定义包。

这一现象反映了软件行业长期存在的“购买 vs. 构建”（buy vs. build）辩论。过去，构建软件极其昂贵，尤其是考虑到工程师薪资高昂且优秀人才稀缺。通常的建议是：只在核心领域构建，避免在边缘项目上分心。只有当公司规模大到足以消化这些分散注意力的成本时，自建才变得划算。

然而，LLM 的出现彻底改变了这一计算逻辑。现在，通过让模型执行工作，产生大量软件片段变得完全可行。

核心内容

便宜不等于零成本

虽然 LLM 显著降低了软件构建的成本，但并未将其降至零。由 LLM 构建的良好系统仍然涉及一个反馈循环：操作员让模型工作一段时间，根据结果进行调整，要求再次迭代，进一步细化，如此反复数十次，才能在时间投入和质量之间达到一个令人满意的折中结果。

此外，维护始终是一项持续的成本。对于更复杂的包，总有需要添加的功能或需要修复的 bug。LLM 会让这些更改更容易实施，但并不会使其免费。其中最具成本效益的部分是参与其中的半职人类劳动，他们负责监督和验证结果。

回到上述 Jira 的轶事：在考虑了初始构建努力（包括迭代优化）以及持续的 LLM 驱动维护后，这笔账真的划算吗？任务追踪器仍然是一个复杂的软件组件，即使 gratuitously（慷慨地/过度地）使用 LLM，预计至少需要几周时间进行初始推动。此后，内部所有者将转向 bug 修复和功能开发。

量化分析：构建的门槛

为了量化这一情况，作者尝试进行粗略的数字估算。假设一名工程师年薪 20 万美元，每周工作 40 小时（假设从未存在过 9/9/6 工作制）：

• 月薪：$16,666.67
• 周薪：$3,846.15
• 时薪：$96.15

为了抵消原本支付给 Atlassian 的每月 400 美元，该工程师每月用于提示功能/修复、维护数据库等工作的时间不能超过 4 小时（400 / 96.15）。这还不包括上下文切换的开销。即使有 LLM 的帮助，这已经完全不现实。但为了宽容起见，假设他们能将时间压缩到每月 2 小时。

即便如此，在初始的 2 周努力之后，需要 37 个月才能收回成本（盈亏平衡点计算：2 * 3846.15 / (400 - 2 * 96.15)）。作者坦言，虽然他也讨厌 Jira 并渴望重建它，但这里的数学账目并不成立。

高价软件的构建可行性

但这是否总是成立？让我们从另一个角度来看待一个价格更高的 SaaS 产品。Gemini 报告称，一个完全配置的 Salesforce 席位价格约为 500 美元/月。如果需要 50 个席位，那就是每月 25,000 美元！

以这个价格，你可以雇佣 1.5 倍的工程资源（25,000 / 16,666.67）全职工作在你的克隆版 CRM 上。同样，CRM 是一个相当复杂的软件，重建并非易事，但无论如何解读，这对于一家较小的公司来说，更接近于一个“构建”决策。（随着 Salesforce 年初至今股价下跌 30%，市场似乎也认同这一点。）

可行域与最小可售软件单元

作者主张（并希望）对于任意复杂度的软件包，存在一个“可行域”（zone of viability）。在这个区域内，只要定价合理，购买比构建更明智，即使我们拥有强大的 LLM 作为日常伴侣。

软件在可行域内需满足两个条件：

1. 新颖性：重建工作由 LLM 执行并非微不足道，且存在一定的持续维护负担。
2. 定价：价格并非高得离谱，以至于强烈鼓励通过 LLM 重建。

只要持续的合理定价使软件保持在可行域内，支付的许可总费用将低于提示其初始推动和维持其持续存在的累计费用。

在可行域的某处，存在**“最小可售软件单元”（Minimum Viable Unit of Saleable Software）**。低于这一单元，重建所付出的努力与通过购买第三方软件相比，要么相同，要么更少，且从长远来看不具备成本效益。

River 作为可行的商业模式

过去几年，Blake 基于开源项目 River（一个用于 Go 和 Postgres 的作业队列）经营一家小企业。在接下来的几个月里，作者将全职接管。这篇博客文章旨在说明，尽管世界已经跨越了 LLM 的视界，River 仍然处于“最小可售软件单元”之上，是一家在现代时代可行的公司。

• 新颖性方面：River 是一个开源项目，免费提供几乎所有与作业相关的功能（定期作业、计划作业、唯一作业、Web UI 等），但将一些高级功能（工作流、顺序作业、并发限制作业等）和计费能力（按发票计费）保留在 Pro 版本中。LLM 可以复制这些功能，但由于我们在 API 设计和性能属性上投入了大量思考，要恢复到类似的保真度需要一定的工作量。
• 价格方面：我们采用基于团队规模而非人头数的次线性扩展定价模型。最多 20 名开发人员每月 125 美元起，并根据无限站点许可扩展。因此，对于中小型开发团队，125 美元/月是所有人的全包成本。

回到最初的问题：我这样做对吗？谁知道呢。目前，我将生计押在了这上面，接下来的几个月将给出答案。

(注：文章顶部的照片是保加利亚索非亚附近维托沙山脉的一个自然特征“Zlatnite Mostove”（金桥），作者最近在参加 Balkan Ruby 后去那里徒步旅行。岩石场被称为“桥”，因为它覆盖了下方的活跃河流。这篇文章部分关于 River，而这是一条河流，所以我赌这个联系足够合理。)

关键要点

• LLM 降低了构建门槛，但未消除成本：LLM 使得软件构建更便宜，但并未使其免费。构建过程涉及大量的反馈循环、迭代优化以及持续的人工监督和维护成本。
• 小金额 SaaS 的自建通常不划算：以每月 400 美元的 Jira 为例，即使有 LLM 辅助，工程师的时间成本（基于年薪 20 万美元估算）使得自建在数学上无法在合理时间内收回成本（需 37 个月以上）。
• 高价值 SaaS 的自建可能更合理：对于高单价、多席位的软件（如 Salesforce，月费可达 25,000 美元），自建在资源分配上更具可行性，市场反应也印证了这一点。
• 定义“最小可售软件单元”：存在一个临界点，低于该点的软件功能或模块，其自建成本低于或等于购买成本，且缺乏长期商业价值。高于该单元的软件，购买仍是更优解。
• River 的生存策略：River 通过提供核心功能的开源版本和高级功能/计费的付费 Pro 版本，结合基于团队规模的次线性定价，确保其处于“最小可售软件单元”之上，从而在 AI 时代保持商业可行性。

意义与影响