自建 vs 采购 vs 混合：当 AI 写 code 时，什么改变了？
▶
自建 vs 采购的争论并不新鲜——但答案可能是新鲜的。我坐下来与 Fanatics 的 Zach Zalowitz 和 Nextuple 的 Laxman Mandayam 一起参加 Order Management Gurus 小组讨论，探讨当 AI 开始写 code 时，真正改变的是什么。
智能体 AI 和 AI 生成的 code 正在重写规则。当一个开发者能在几天内搭起一个可用的微服务——或者一个 AI 智能体能够配置一个过去需要数周的集成——旧的决策框架就崩裂了。如果 AI 能更快地构建它，你还需要购买吗？如果你购买，你是否真的只是在组装和配置，把 AI 当作胶水？而如果你走混合路线，又该如何防止它日后变成一场维护噩梦？
旧算法不再成立
经典的自建 vs 采购决策主要关乎成本与速度：自建需要一个团队和一个季度；采购能让你现在就进入市场。AI 不只是改变了这些数字——它改变了“自建”本身的含义。过去需要六个月的项目，如今一个小团队几天就能搭起来，或者由一个智能体来完成过去要耗尽整个小组的集成工作。这并不代表每一次自建都是好主意。它只是让那些老捷径——“我们总是采购”“我们总是自建”——变得站不住脚。
采购正变得更聪明，而非更容易
当问题不是你的核心竞争力，或者供应商的路线图比你的团队吸收领域知识的速度更快时，采购仍然胜出。但“我们为什么要买这个”的门槛已经提高了。如果答案是“因为我们没有人手”，AI 已经让这个答案变得更无力。如果答案是“因为供应商掌握了这个领域最难的部分”，那仍然是个有力的答案——而且 AI 正在让它变得更有力，因为集成和配置恰恰是 AI 擅长的部分。
混合是一个维护决策，而非架构决策
小组上最坦诚的对话是关于混合的。混合是大多数企业最终的归宿——问题在于它究竟是变成一个经过深思熟虑的系统，还是一个意外形成的系统。如果你要围绕一个供应商平台来构建，你就得拥有那些接缝：自定义集成、数据契约、以及你 AI 生成的 code 与他们的 code 相接之处。那些从第一天就把混合当作维护决策来对待的团队——配齐负责人、测试和文档——能避开噩梦。而那些把它当作“先买，以后再想办法”的团队，最终会得到一个无法升级的平台。
这场讨论汇聚了在现实世界中做出过这些决策的实践者——深入探讨 AI 原生开发究竟对 OMS、ERP 和企业应用的自建 vs 采购算法做了什么。如果你今年要做这个决策，值得一看。