在大型语言模型（LLM）普及的时代，关于软件是自行开发还是直接采购的传统决策标准正在改变。虽然 LLM 显著降低了开发成本，但并未将其降至零。因此，对于像 Jira 这样价格合理但功能复杂的工具，购买通常仍是更优选择。相比之下，像 Salesforce 这样的高价软件则可能更值得企业投入资源自行重建。由此，存在一个“可行性区间”：只要软件定价合理且具备一定的复杂性，它就能在 AI 时代保持商业价值。
自建还是采购：旧问题，新答案
长期以来，软件行业都在讨论“自建 vs 采购”的问题。过去的共识很明确：由于工程成本高昂，只有在公司的核心业务领域才值得投入资源自建，否则都应该直接采购。
然而，LLM 的出现改变了这一切。现在，借助模型的力量，开发重要软件的门槛和成本都已大幅降低。一个典型的例子是：有人分享其公司用 Claude 构建了一个内部任务追踪器，成功替代了每月花费 400 美元的 Jira 服务。这引发了一个关键问题：在 AI 时代，商业软件还有生存空间吗？
开发成本：便宜不等于零成本
尽管 LLM 让软件开发变得便宜，但成本远未降到零。
- 开发投入： 一个好的 LLM 构建系统仍然需要人工操作员进行多轮的反馈、调整和优化，才能达到满意的效果。
- 持续维护： 软件发布后，修复 bug 和添加新功能会带来持续的维护成本。LLM 能简化这些工作，但无法完全自动化，仍然需要人来监督和验证。
回到那个用 400 美元替代 Jira 的例子，我们来算一笔账：
假设一位年薪 20 万美元的工程师，时薪约为 96 美元。为了抵消每月 400 美元的 Jira 费用，这位工程师每月花在维护自建工具上的时间不能超过 4 小时。考虑到初期的开发投入和持续的维护精力，这个数字在现实中完全不切实际。即使有 LLM 的帮助，为了省下 400 美元而去重建一个复杂的任务管理工具，从经济上看是得不偿失的。
可行性区间：购买的价值所在
但这是否意味着所有软件都应该购买？答案是否定的。让我们看看另一个极端——Salesforce。一个全功能席位的价格约为每月 500 美元，一个 50 人的团队每月就要花费 2.5 万美元。
用这笔预算，公司可以雇佣 1.5 名全职工程师来开发自己的 CRM 系统。在这种情况下，自建（build）决策显然更合理。
对于任何复杂度的软件，都存在一个“可行性区间”。只要定价合理，即使有强大的 LLM，购买通常也比自建更明智。
一个软件产品如果想在这个区间内生存，需要满足两个条件：
- 产品足够复杂： 其功能和设计具有一定的独特性，用 LLM 重建并非易事，且存在持续的维护负担。
- 定价足够合理： 价格没有高到“逼迫”用户去自建的程度。
只要产品的定价能让用户觉得“付费比自己动手更划算”，它就拥有了商业上的生存空间。这也定义了最低可行销售单位——如果产品的价值低于这个门槛，客户重建它的成本就低于购买，那它就无法成为一个可持续的商业产品。
案例分析：我的产品 River 能否存活？
我即将全职投入的项目 River，是一个面向 Go 语言和 Postgres 的任务队列。我希望它能成为一个符合“可行性区间”理论的商业产品。
- 在复杂性方面： River 的开源版本提供了大部分核心功能，而 Pro 收费版本则提供工作流、顺序作业等高级功能。这些功能经过了深入的 API 设计和性能优化，用 LLM 从零开始复刻需要付出巨大努力。
- 在定价方面： 我们采用基于团队规模的定价模型，小型团队的起步价为每月 125 美元。对于一个开发团队来说，这是一个极具吸引力的成本，远低于他们投入工程师资源自行开发和维护的开销。
我正在将我的生计押注于此，赌的是 River 的价值远高于那个“最低可行销售单位”，能够在 AI 时代继续作为一个可行的商业公司存在。未来的几个月将会给出答案。