AI让软件开发更便宜之后,企业应该自建还是采购?

↑↑↑🎧听全文，预计阅读时间5分钟

作者 | 陈智

来源 | 薄云咨询

生成式AI正在改变软件开发的成本结构。过去需要数周完成的原型，现在可能几天就能搭出来；过去必须依赖专业开发团队的小工具，业务人员也开始借助AI编码快速实现。

这带来一个越来越常见的问题：既然开发变得更便宜，企业是不是应该少买SaaS，多做自建？

答案并不简单。AI确实降低了“做出一个系统”的门槛，却没有同步消除长期维护、数据治理、安全合规和业务责任。真正需要判断的，不是代码能不能生成，而是这个能力是否值得企业长期掌握。

自建和采购，不再是简单的二选一

01

传统的软件决策通常围绕成本展开：采购需要支付许可费和席位费，自建需要承担开发成本。AI编码出现后，前期开发成本下降，自建看起来更有吸引力。

但一个业务应用的全生命周期远不止开发。上线后还要面对需求变化、模型升级、接口调整、权限管理、异常处理、数据质量和用户支持。很多AI原型在演示时效果很好，一进入生产环境，就暴露出维护责任无人承担的问题。

因此，企业更应该把应用拆成不同层次来看：通用能力可以采购，差异化逻辑可以自建；稳定底座可以采购，关键业务规则必须掌握；界面和工具可以替换，数据、流程和评价标准不能失控。

五个维度决定“买、做还是组合”

02

第一，看战略差异性。如果某项能力直接决定企业的竞争优势，例如独特的定价逻辑、供应链调度方法或客户经营模型，企业应保留更高控制权。若只是通用报销、考勤或会议管理，采购成熟产品通常更经济。

第二，看业务特异性。标准化程度高、流程相对统一的场景，更适合采购；流程高度独特、规则频繁变化、需要沉淀专有知识的场景，更适合定制或自建。

第三，看系统复杂度。一个面向单一部门的轻量工具，与一个涉及多系统交易、权限和审计的核心平台，不属于同一类决策。越接近核心业务记录和控制系统，越需要重视稳定性与成熟度。

第四，看合规与可靠性。涉及财务、人事、客户隐私和关键生产的数据，不能只看功能是否可用，还要评估权限、留痕、可回退和责任边界。高风险场景往往更适合采用成熟底座，再在其上建设企业自己的智能层。

第五，看维护能力。企业是否有长期产品负责人、技术团队和业务专家共同维护？如果没有，自建系统很容易在最初负责人离开后失去更新。

“自建”也不等于完全自主

03

很多企业把代码归属理解为自主可控，但AI时代的依赖关系更加复杂。即使代码完全由企业持有，系统仍可能依赖外部大模型、云平台、开发框架、数据库和第三方接口。

所以，真正要管理的是依赖结构：哪些供应商可以替换，哪些数据能够迁移，哪些规则掌握在企业内部，哪些关键能力一旦停服就无法运行。

企业可以采用“核心自有、外围采购”的组合方式。把业务规则、领域知识、数据结构和评价标准留在企业内部；把通用模型、基础设施和标准化工具作为可替换的外部能力。这样既能利用成熟生态，又能避免把全部智能资产锁在单一供应商中。

先做决策矩阵，再谈技术方案

04

很多项目一开始就进入产品比较和技术讨论，结果是不同部门各说各话。业务部门关心是否好用，IT关心安全与集成，管理层关心投入产出，供应商则强调功能完整。

更有效的方法，是先形成一张统一的自建—采购决策矩阵。对每个场景，从战略差异、业务特异性、复杂度、风险和维护能力五个维度评分，再决定采用采购、定制、自建或暂缓。

对于战略差异低、标准化程度高的场景，优先采购；对于差异高但复杂度可控的场景，可以自建或深度定制；对于差异高、风险也高的核心场景，应采用成熟底座加企业自有规则层；对于价值不明确、数据基础不足的场景，暂缓往往比仓促开发更理性。

AI让开发更便宜，真正改变的不是企业必须自己做更多软件，而是企业第一次有机会更细致地决定：什么能力值得拥有，什么能力适合租用，什么依赖必须保持可替换。

不要只比较首年成本

05

采购方案看似持续付费，自建方案看似一次投入，但真正应该比较的是三到五年的总拥有成本。除了开发和许可费用，还要计算数据接入、模型调用、版本升级、安全审计、业务培训、异常处理和人员更替。很多“便宜自建”并不是开发失败，而是后续没有预算和责任人继续维护。

参考资料

David Klotz, “The Buy-or-Build Decision, Revisited: How Agentic AI Changes the Economics of Enterprise Software,” arXiv preprint arXiv:2604.26482, April 29, 2026.