大语言模型时代，软件“买”与“建”怎么选？River 能否成可行业务待验证

[brandur.org 导航]

[brandur.org]

[文章]

[短文]

[片段]

[时事通讯]

[系列文章]

[近况]

[工具]

[关于]

文章信息

自动

发布时间显示，本文于 2026 年 5 月 31 日发布，地点为柏林。作者在 X/Twitter 上的账号是 [@brandur]

作者计划与质疑

作者上周写了关于 [离开 Stainless] 的文章，并打算将副业项目 [River] 打造成小型可持续业务。发出那封信后，有人质疑在人工智能时代经营软件公司的思路，认为推出的产品可能会被大语言模型（LLM）构建的内部软件包瞬间取代。作者虽成了大语言模型的拥趸，但仍会详细阐述自己的思路，让读者自行判断

领英小故事

作者分享了一个小故事，今天早上在领英浏览时，看到有用户称所在公司每月在 Atlassian 的 Jira 上花费 400 美元，因不满费用让团队用 Claude 构建新的内部任务跟踪器，弃用 Jira 并节省开支，还得到可通过大语言模型不断改进、满足各种需求的定制软件包

软件行业“购买还是构建”问题变化

多年来软件行业一直在讨论“购买还是构建”的问题，去年情况发生变化。过去构建软件成本极高，考虑到工程师薪资和人才稀缺性，人们面临高昂前期成本、进度超期和诸多难题，一般只在核心业务领域开发，公司规模足够大时才考虑周边项目。但大语言模型改变了这一切，让开发大量软件变得可行

便宜 ≠ 免费

大语言模型虽让软件开发成本大幅降低，但未降到零。优秀的大语言模型构建的系统仍需反馈循环，操作人员让模型工作、调整、再处理、优化，经数十次循环才能达到时间投入和质量的最佳平衡。维护仍是持续成本，特别是复杂软件包，有新功能添加和漏洞修复，大语言模型使更改更容易，但并非免费，最昂贵的是人工监督和验证结果的兼职劳动力成本

以每月花 400 美元用 Atlassian 软件为例，考虑初始构建和大语言模型驱动的持续维护后，这样做是否合理值得思考。任务跟踪器是复杂软件，大量使用大语言模型，保守估计初始开发至少需几周时间，之后内部负责人还需进行漏洞修复和功能开发

作者进行了大致计算，假设工程师年薪 20 万美元，每周工作 40 小时，每月工资 16700 美元，每周 3850 美元，每小时 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

为抵消每月 400 美元的 Atlassian 费用，工程师每月用于自制 Jira 克隆版的工作时间（不包括上下文切换开销）不能超过 4 小时（400 / 96），即便乐观假设能减到每月 2 小时，最初两周努力后，仍需 37 个月才能收回成本（收回每月 400 美元的 Atlassian 费用减去每月 2 小时的维护成本所需的月数 = 2 * 3846.15 / (400 - 2 * 96.15)）。所以从成本看，重新构建 Jira 不划算

构建门槛

这是否总是成立呢？换个角度看价格更高的 SaaS 产品。Gemini 报告称，功能齐全的 Salesforce 账号每月约 500 美元，50 个账号就是每月 25000 美元。以这个价格可让 1.5 倍的工程资源（25 / 16.7）全职投入克隆版开发。CRM 是复杂软件，重建不易，但对较小公司来说，更倾向于“构建”选择。（而且，Salesforce 今年以来股价下跌了 30%，市场似乎也认同这一点）

可行区间

作者认为，对于任意复杂度的软件包，存在一个可行区间。在这个区间内，只要定价合理，即使有强大的大语言模型，购买软件也比自己构建更划算：

处于可行区间的软件需满足两个条件：

• 具有足够的新颖性，使得用大语言模型重建并非易事，且需要一定的持续维护工作
• 定价不会过高，以免强烈促使人们使用大语言模型重建

只要软件定价合理，使其保持在可行区间内，那么购买许可证的总费用就会低于使用大语言模型进行初始开发和持续维护的累计费用

在可行区间的某个位置，存在可销售软件的最小可行单元。低于这个单元，重建软件的工作量与购买第三方软件的流程相当甚至更少，从长远来看也不划算

River 作为可行业务

过去几年，Blake 基于 [开源项目 River] 开展了小业务。River 是适用于 Go 和 Postgres 的作业队列，至少接下来几个月作者将全职接手该项目。作者希望尽管进入大语言模型时代，River 仍能超过可销售软件的最小可行单元，成为可行公司

从新颖性看，River 是开源项目，几乎所有作业相关功能（定期作业、定时作业、唯一作业、Web UI 等）可免费使用，但一些高级功能（工作流、顺序作业、并发限制作业等）和计费功能（按发票计费）保留在收费的 [专业版] 中。大语言模型可复制这些高级功能，但作者团队在 API 设计和性能优化方面投入很多精力，重建出类似质量的软件并非易事

从价格方面看，采用基于团队规模而非人数的次线性定价模式，最多 20 名开发者的团队每月只需 125 美元，对于无限站点许可证则按倍数递增。所以对于中小型开发团队来说，每月 125 美元就是所有人的全部费用

作者也不确定自己这样做是否正确，目前把生计押在这上面，未来几个月见分晓

关于文章顶部的照片说明

文章顶部照片是保加利亚索非亚附近维托沙山脉中名为 "Zlatnite Mostove"（"金桥"）的自然景观。作者最近参加 [巴尔干 Ruby 会议] 后去那里徒步旅行。这片岩石区域被称为 "桥"，是因为它覆盖着下面的一条活跃河流。文章部分内容与 River 有关，照片里也有河流，作者觉得这样的关联合理

不过，换用其他产品确实更划算。在这个具体案例中，很简单：用 Linear 代替 Jira

若读者认为作者犯了错误，可考虑 [提交拉取请求]