我们花了十五年时间看着软件吞噬世界。整个行业被软件吞噬——零售、媒体、金融——你能想到的，过去几十年都经历了令人难以置信的颠覆，伴随着 SaaS 工具的激增。这导致了大量 SaaS 公司的出现——其总估值已达数万亿美元。
在我上一篇关于 AI 编码智能体是否使软件成本下降 90% 的辩论文章中，我主要关注了市场的供应侧。如果这个假设成立，对 SaaS 工具的需求会发生什么变化？我一直在深入思考软件工程变化所带来的这些第二和第三层影响。
关于"自建还是购买"的考量正在开始改变。软件吞噬了世界。而智能体将要吞噬 SaaS。
我观察到的信号
最明显的变化始于需求的蒸发——尤其是对于那些"更简单"的 SaaS 工具。我相信许多软件工程师已经开始意识到这一点——许多我原本想找个免费增值或付费服务来做的事情，现在往往能让一个智能体在几分钟内以我想要的精确方式解决。有趣的是，我甚至没有注意到这个转变。它就自然而然地发生了。
如果我想要一个内部仪表板，我甚至不会去想用 Retool 之类的工具会不会更简单。我直接构建这个仪表板。如果我需要在媒体摄取过程中重新编码视频，我只需让 Claude Code 为 ffmpeg 写一个稳健的封装器——而不是承担将原始文件发送到独立服务的所有成本（和速度影响），还要担心触发使用层级限制，或者强行理解另一个 API 的设计逻辑。
对于不那么纯粹的软件开发任务，这一点更加明显。例如，我曾让 Gemini 3 在几分钟内制作出非常高质量的 UI/UX 线框图和原型图——根本不需要使用独立的服务或找一些模板来开始。同样，当我需要做演示时，我不需要使用某个平台来美化我的幻灯片——我只需让 Claude Code 将我的 Markdown 导出为一个设计精美的 PDF。
我开始看到的另一个可能影响更大的转变是，人们开始真正质疑来自大型"企业"级 SaaS 公司的续费报价。虽然这还处于早期阶段，但我相信这是一个非常重要的新兴行为。我现在已经看到几个例子，当 SaaS 供应商 X 发来他们惯常的年度两位数百分比涨价通知时，团队开始问："我们真的需要支付这笔费用吗，还是可以自己构建我们需要的东西？"。一年前，这最多只是一个假设性问题，并且会很快得出'不行'的结论。现在，这是一个人们真正投入精力去认真思考的实际选项。
最后，大多数 SaaS 产品包含许多客户并不需要或使用的功能。SaaS 产品工程中的很多复杂性就在于管理这些功能——但当你的客户只有一个（你的组织）时，这种复杂性一夜之间就消失了。同样，当客户与决策者是同一个人时，这个客户就完全掌控了产品的路线图。不再需要寄望于 SaaS 供应商将你的请求优先于其他客户。
维护方面的异议
对此的主要反对意见是"谁来维护这些应用？"。这是一个真实且合理的反对理由。软件有需要修复的缺陷、需要解决的扩展性问题、需要修补的安全漏洞，而这些并没有改变。
我认为首先需要指出的是，大量 SaaS 产品维护不善（根据我的经验，往往价格越贵，质量越差）。通常，安全风险恰恰来自于需要连接和访问内部数据的外部第三方本身。如果你能把这一切都移入你现有的 VPN 或访问解决方案之后，你将大幅减少组织的攻击面。
除此之外，智能体本身能显著降低维护成本。一些我经历过最痛苦的维护任务——比如将弃用的库更新到另一个有更好支持的库——在智能体的帮助下变得容易得多，特别是在静态类型的编程生态系统中。此外，公司在构建内部工具时最大的顾虑是只有一个人了解所有细节——如果他们离职，所有的内部知识也随之而去。智能体不会离职。而且，通过一个精心编写的 AGENTS.md 文件，它们可以向未来的任何人解释代码库。
最后，SaaS 自身也存在维护问题。本月我从朋友那里看到的一个突发事件是，一家 SaaS 公司决定弃用其现有的 API 端点，转向另一组 API，而新 API 并不具备所有相同的方法。由于这是一个核心系统，这是一个巨大的问题，需要投入大量资源来更新、测试和推出受影响的集成。
我并不是说没有真正软件知识的中小企业会突然替换掉他们所有的 SaaS 套件。我确实认为正在发生的是，拥有一定技术能力和理解力的组织将更加审慎地思考他们的 SaaS 采购和供应商生命周期。
SaaS 的经济学问题
SaaS 估值建立在两个关键假设之上：快速的客户增长和高 NRR（通常超过 100%）。
我认为我们已经可以看到，某些工具和应用领域的新客户需求已经开始下降。这是一个问题，并将导致这些公司的销售和营销支出增加。
然而，更隐蔽的问题是净收入留存率的下降。NRR 衡量的是现有客户在持续基础上与你的业务往来金额，并已根据客户流失进行调整。如果你的 NRR 是 100%，那么你现有的客户群体花费的金额保持不变。如果低于 100%，那么他们花的钱在减少和/或客户在流失。
许多优秀的 SaaS 公司的 NRR 显著高于 100%。这正是许多 SaaS 商业模式的魅力所在——公司发展壮大，需要为其计划增加更多用户。或者他们需要从较低价格的层级升级到更高的层级以获得额外功能。这些增购通常非常有利可图。你不需要在销售和营销上投入巨资来获得这种增长（你已经与他们建立了关系），而为客户增加 100 个用户许可证的利润率几乎接近无限。
这就是我认为一些 SaaS 公司将受到严重打击的地方。人们将开始将部分解决方案迁移到自建/修改的内部平台上，以避免为了更高的定价层级而支付显著更多的费用。或者，他们将通过 API 从你的平台获取数据，并构建内部仪表板和报告，这意味着他们可以移除 80% 的用户许可证。
这在何处行不通（以及什么仍有护城河）
最明显的是任何需要极高正常运行时间和 SLA 的系统。达到 4 个或 5 个 9（99.99% 或 99.999% 的可用性）真的很难，构建高可用性系统变得非常困难——并且很容易在构建过程中自找麻烦。因此，在我看来，像支付处理和其他核心基础设施这样的东西是相当安全的。你（目前）还不能轻易地用智能体替换 Stripe 及其在核心支付上的所有工程工作。
同样，非常高容量的系统和数据湖也难以替换。为巨大的数据集或交易量启动集群并非易事。这再次需要专业的知识，而你的组织内部很可能缺乏这种知识，如果存在的话。
另一个是具有显著网络效应的软件——尤其是你需要与组织外部人员协作的场景。Slack 就是一个很好的例子——你不会用内部工具来替换它。同样，拥有丰富集成生态系统和插件市场的产品在这方面具有真正的优势。
拥有专有数据集的公司仍然非常有价值。金融数据、销售情报等数据仍然有价值。如果说有什么不同的话，我认为这些公司拥有真正的优势，因为智能体可以用新的方式利用这些数据——它们被更紧密地锁定了。
最后，法规和合规性仍然非常重要。许多行业需要符合监管要求——这不会在一夜之间改变。
这确实需要你的组织具备（内部或外部）管理这些新创建应用程序的技能。我认为涉及 SRE 和 DevOps 的产品和人员需求将真正上升。我推测我们将看到公司内部出现全新的职能和团队，专门致力于管理这些新的应用程序。这当然需要成本，但通常可以通过现有的 SRE 或 DevOps 职能来管理，或者如果需要新增人员和基础设施，其成本可以在数量多得多的应用程序之间分摊。
谁面临最大的风险？
在我看来，面临严重风险的公司是那些后台工具，它们本质上只是 CRUD 逻辑——或者只是在客户自己的数据之上的简单仪表板和分析工具。
这些工具往往会产生很多摩擦——因为它们的工作方式不完全符合客户的期望——而且它们是最容易被智能体替换的工具。记录现有系统并告诉智能体构建一个移除了痛点的新系统非常容易。
SaaS 当然没有消亡。就像任何重大的技术变革一样，总有赢家和输家。我确实认为，对于许多没有明确护城河或专有知识的 SaaS 产品，其门槛将变得高得多。
难以预测的是智能体向价值链上游移动的速度有多快。我假设智能体目前还无法管理复杂的数据库集群——但我不确定这种情况还会持续多久。
而且，我没有看到每家公司都能突然替换掉所有 SaaS 支出的路径。如果说有什么不同的话，我认为我们将会看到市场的（又一次）分化。拥有强大内部技术能力的公司与不具备此能力的公司。这将成为前者又一个竞争优势——而对于后者，随着 SaaS 提供商试图从较无法转换的第二类客户身上挽回在第一类客户那里损失的收入，他们很可能会看到成本急剧增加。
但我的关键结论是：如果你的产品只是一个计费系统上的 SQL 封装器，那么你现在有成千上万的竞争对手：就是你客户那里，拥有一个空闲的周五下午和一个智能体的工程师们。（来源）
