编码智能体让从零构建变得前所未有地简单，而从零构建的平台团队缺乏清晰战略的可能性要高出3.5倍。
构建还是购买，通常被看作一种工程层面的权衡：开发者时间与集成、迁移成本相互较量，掌控力则要对比定制开发带来的维护负担。我们在编写《2026年平台工程未来报告》时，并非要去解决这个权衡问题，而是想弄清楚平台功能来源的决策，是否能揭示出平台团队本身的某些特质。结果证明确实如此。在379名平台专业人士的调研回复中，我们发现，主要依靠从零构建的团队，更可能缺乏明确的战略，也更难达成平台目标。
AI 的出现让这个问题变得复杂起来。智能体让构建变得前所未有地容易：过去需要数月才能完成的内部工具，现在一天就能搭建出来。但 AI 消除的只是编写代码的工作量，而不是拥有和维护这些代码所带来的责任。定制功能所伴随的维护、升级与治理工作依然存在，而流经管线的变更量却在不断增加。这使得构建与购买的决策，比以往任何时候都更具战略意义。
我们询问了平台团队如何支持其所拥有的每一项功能：是从零构建，基于现有模板构建，还是购买底层工具。主要采用从零构建方式的团队，更容易表示自己的平台缺乏明确战略。这种关联性很强，但并不像"从零构建就意味着没有计划"这样简单。
大多数团队有意识地选择购买
在平台团队所拥有的各项功能中，我们发现使用底层工具是最常见的方式：51.3%的受访者表示这是他们的主要方式，领先于基于现有模板构建（31.2%）和从零构建（17.5%）。高绩效团队更倾向于使用工具（58.8%），而非基于模板构建（47.8%）或从零构建（33.3%）。这可能反映出一种更广泛的成熟度模式：随着平台工程中架构选择趋于稳定，团队日益倾向于在工具上实现标准化，而不是自行维护。David Tuite 将另一种做法描述为"构建还是购买的陷阱"：团队陷入维护定制界面的泥潭，耗费6到18个月在升级和运维开销上，而无法真正交付价值。
真正有意思的是那些例外情况。本地开发环境、一键式项目和临时环境更倾向于使用模板而非工具，因为它们与特定的技术栈和"黄金路径"绑定，而现成工具很少能提供这些。临时环境值得特别关注，因为它也标志着 AI 发挥积极作用的地方。拥有临时环境的团队，更可能表示 AI 对软件交付的速度和稳定性产生了积极影响；在代码覆盖率和成本控制方面也是如此。在报告 AI 产生极其积极影响的团队中，超过四分之三拥有临时环境。
这种关联性很可能反映的是平台本身，而非某项具体功能。拥有临时环境的团队往往运行在功能广泛的平台上，周围配备了一系列自动化交付能力，而这种广度本身就与 AI 对交付的积极影响相关联。因此，临时环境或许标志着一个平台已足够成熟，能够吸纳 AI 生成的大量变更，而不会失去稳定性。这与 DORA 的研究发现一致：组织从 AI 中获得的收益取决于平台质量，强大的平台会放大效果，而薄弱的平台则会削弱效果。
那些打破这种模式的功能，反映的是适配性问题，而非对购买的抵触，这些决策背后的理由也印证了这一点。当被要求解释其构建或购买的逻辑时，最常见的回答是成本效益分析（29.6%），其次是对开源的偏好（28.6%）、适配性与需求评估（22.4%）、对商业工具的偏好（22.4%），以及为核心差异化而构建（16.3%）。正如一位受访者总结道："构建那些让我们独特的部分，购买或采用那些标准化的部分，并始终考虑长期成本和锁定风险。"这与领域驱动设计中提出的核心理念相同：该理念区分了核心领域（定制开发在此能创造竞争优势）与支持及通用领域（在这些领域，定制开发大多只会增加复杂性和维护成本，而这些问题本可以通过购买解决）。
从零构建的模式
鉴于大多数团队在选择时都经过深思熟虑，关于战略的发现就更值得关注了。按主要构建方式分类后，从零构建的团队报告"缺乏明确战略"作为障碍的可能性，约为基于模板构建团队（15.6%）或使用底层工具团队（16.7%）的3.5倍（57.9%）。
AI 的使用也呈现出类似的聚集现象：主要从零构建的团队更可能中度或大量使用 AI 来进行遗留系统现代化改造和语言迁移。这里存在一个明显的模式：构建最多的团队，恰恰最依赖 AI 来进行维护。这并非因为这些团队总体上更多地使用 AI——它们报告的采用率、影响力和预期效果与其他团队相当。差异只体现在定制功能之后所需的维护工作上。
先构建，后决策
一种解读是，战略先行，构建或购买的决策随后而来：一个没有明确方向的团队，没有依据来决定该购买什么，于是默认选择了构建。另一种解读则是，构建本身就是战略，而不是战略缺失的表现。构建有助于在团队确定平台用途之前，先识别问题并展示进展。
这是一个有趣的观点，但数据本身无法告诉我们哪种解读才是正确的。Simon Wardley 关于映射方法的研究描述了类似的模式：看不到已有工具存在的团队，往往会为那些在别处早已得到更好解决的问题，重新构建自己的解决方案。
有了 AI，从产生想法到拥有可用工具之间的差距已几近消失。一个智能体现在可以在任何人询问是否需要之前，就先构建出一个定制化的事件管理工具。构建变得更容易了，但维护构建出来的东西却没有变得更容易。DORA 的研究揭示了这一点为何重要：好的平台既提供能力，也为这些能力的使用设定边界，而在 AI 辅助开发的背景下，这些边界可能变得更加重要。成熟的工具自带这些边界；而一块一块拼凑起来的平台，只拥有那些有人想到要添加的边界。
无论哪种解读成立，这种关联性都是存在的。从零构建本身并不是问题。默认情况下、毫无理由地从零构建，才是战略缺口出现的地方。
一个比构建或购买更好的问题
这并不是在为"什么都要买"辩护，因为我们发现有些功能确实需要围绕组织自身的具体情况来构建。这是在为"有意识地购买"辩护。当一个团队选择从零构建时，应该有明确的理由。而当团队购买工具时，理由通常已经显而易见：几乎每个团队都会为平台中定义明确的部分购买工具，随着智能体编写的代码越来越多，能够解决这些问题的工具的价值只会不断增长。
