UX Collective：企业选买还是自建，如今也是 UX 决策

人工智能让自建变得便宜，也让购买变得容易。如今的权衡取决于谁来承担维护、工具之间的衔接、对话界面以及数据。

在我职业生涯的大部分时间里，买还是自建由产品管理负责。产品经理撰写论证，财务核对数字，采购签字。

设计师在决策做出之后才介入，接手任何胜出的方案，然后花数年时间打磨它的粗糙之处。人工智能同时改变了双方的算盘。

自建现在更便宜了，但每年的维护成本从来不会出现在商业论证中。

购买会带来遗留负担，而这种负担如今还包括别人的模型、路线图和发布周期。而且通常还有第三个没人明说的选项：替换你已有的系统。

Menlo Ventures 在 2025：企业生成式 AI 现状 中发现，76% 的企业人工智能用例是购买而非自建的，高于一年前的 53%。与此同时，编码智能体让一个可用的内部工具看起来像是一个下午就能完成的项目。

越来越多的工作发生在 Teams、Slack、Claude 和 ChatGPT 内部，而这两个选项都不拥有这些界面。

不要问哪个选项成本更低，而要问复杂性落在哪里：落在你的代码里、供应商的路线图里，还是落在你的用户身上。

为自建维护编制预算

配备编码代理的设计师，能在供应商销售团队回电之前就搭起一个内部工具。Andrej Karpathy 在 2025 年把这种松散的风格命名为 vibe coding，而 Simon Willison 则在 Not all AI-assisted programming is vibe coding (but vibe coding rocks) 中划清了界限。原型可以松散，但你要保留的代码必须像其他代码一样被阅读。

大多数内部工具最终都会成为你要保留的代码，因此它们就是产品。它需要预算、负责人，以及出问题时能找的人。大多数团队并不这么想，因为没人花钱买过它。

我是吃了苦头才学到这一点的。

在我工作过的一个地方，我们在 AI 出现之前构建了一个内部工作流应用，因为能买到的东西没有一个符合我们团队的工作方式。它上线很快，人们开始依赖它，而恰恰就在那时，它变成了维护的噩梦。

每一个新的审批环节都意味着要改动几乎没人理解的代码，小修小补又会在别处引发问题，而这些都没有人预留过时间。

我的规则就是由此而来的。我每年预留前期构建成本的 30% 用于维护：更新、补丁、模型变更和新需求。

算一算这笔账，很多 vibe coding 出来的应用比它们所替代的订阅服务还要贵。假设两个人花两周时间，按全负荷成本每小时 150 美元计算，前期就是 24,000 美元，之后每年 7,200 美元。25 人每人每席位 20 美元的订阅服务每年是 6,000 美元。三年下来，自建花费 45,600 美元，而订阅是 18,000 美元，而且其中只有一方配有支持团队。

每一行生成的代码，都是某个人必须负责的代码，而最初的负责人通常并不想要这份责任。

开源最早教会了我们这一课。Black Duck 的 2026 Open Source Security and Risk Analysis Report 发现，98% 被审计的代码库中包含开源成分，而 93% 的代码库中含有两年内没有任何开发活动的组件。

2024 年，一个后门程序侵入了被广泛使用的 XZ Utils 库，此前攻击者花费数年时间赢得了该库维护者的信任。生成的代码存在同样的弱点：没人花钱买它，所以没人拨预算去盯着它。谷歌的 2025 DORA 报告发现，采用人工智能仍然会损害交付稳定性。

接受供应商的 Legacy

购买看起来是谨慎的选择，而且通常也确实是。

根据 MIT 的 NANDA 计划的研究，从专业供应商处购买的成功率约为 67%，而内部开发的成功率只有其三分之一左右，该研究收录于 Fortune 的 MIT 报告：95% 的企业生成式 AI 试点项目正在失败。

合理的反对意见在于选择偏差，因为企业往往为理解透彻的问题购买，为混乱的问题自研，这美化了供应商。这个数字不必当真，但其方向与企业预算的实际流向一致。

购买的从来不只是功能集。你还会得到供应商的数据模型、发布节奏，以及它对你用户想做什么的理论。

当你购买时，你引入了另一家公司的组织架构图。

正如 Melvin Conway 于 1968 年所观察到的，系统反映了设计它们的组织的沟通结构。你的用户最终被困在一个为该公司最大客户调优的产品里，而那些客户可能与你毫无相似之处。

衡量工具 Gaps

用户不会孤立地体验你自研或购买的东西，他们体验到的是其中的 gap。你可以像在可用性测试中统计点击次数那样统计这些 gap：选定一个真实任务，追踪它跨越各个系统的过程，记录下每一次切换和每一个重新输入的值。

这些 gap 累积得很快。

在 2022 年一项针对三家《财富》500 强公司 20 个团队中 137 名员工的研究中，人们每天在应用程序和网站之间切换约 1,200 次。每次切换后重新调整状态每周耗费他们将近四小时，约占其工作时间的 9%，数据来自《哈佛商业评论》和 AAPL Leadership 上的 我们在应用程序之间切换浪费了多少时间和精力？。

自研工具同样会扩大这些 gap。20 世纪 90 年代，各部门自行构建 Microsoft Access 数据库，因为等待中央技术团队需要一个季度。

这些数据库一直可用，直到它们的作者换了工作，之后其中的数据就成了又一个无人能及的地方。今天的版本是漂移：与产品其余部分不再匹配的模式，以及无人设计过的错误状态。

复杂性总会落在某处，唯一的选择是落在哪里。

复杂性是守恒的，唯一真正的选择是谁来吸收它。这就是 Larry Tesler 的定律。

自研会把复杂性转移到你的代码库中，而购买会把它转移到别人的路线图上。草率地混用两者，则会把它转移到你的用户身上，一次复制粘贴而已。在任何人争论许可费之前，先问问在每种方案下复杂性最终会落在哪里。

为宿主 Surface 而设计

在许多组织中，人们遇到你产品的地方已经不再是你的产品本身，而是 Teams、Slack、Claude 或 ChatGPT。

2025 年，随着 OpenAI 的 Introducing apps in ChatGPT and the new Apps SDK，应用进入了 ChatGPT 对话内部。2026 年 1 月，MCP Apps — Bringing UI Capabilities To MCP Clients 让工具能够返回在 Claude 和 ChatGPT 内部渲染的交互式界面。无论是自建还是购买，你使用频率最高的那个界面，最终可能会变成别人窗口里的一张卡片。

我以前就在这种架构下工作过。我曾为 Myspace 设计开发者文档站点，其 2008 年的开发者平台允许第三方应用运行在会员资料页上。宿主决定了盒子的尺寸、权限，以及应用能了解到查看者多少信息。每一个应用都是在这个框架内设计的，而聊天界面正在重新画出这个框架。

宿主画出框架，而你的工作是决定什么内容适合放进其中。

这些规则很具体，而且属于宿主。根据 OpenAI 针对 Apps SDK 的 UI 指南，ChatGPT 中的内联卡片最多只能有两个操作，不允许嵌套滚动，使用系统字体，并且由宿主为你添加一个 logo。

一条 Slack 消息在 Block Kit 下最多可容纳 50 个块。微软的 Types of Cards & their Usage 将 Adaptive Cards 列为新 Teams 开发的推荐卡片类型。

人们期望你的产品用起来像他们度过大部分时间的地方，这就是 Jakob Nielsen 的 Jakob's Law of Internet User Experience。在聊天界面内部，这不再只是建议，因为宿主的模式是唯一可选的模式。因此，要把卡片当作你自己的产品来设计，只承担一项职责、一个主要操作，并在任务超出其范围时引导用户回到你的完整应用。

计算替换成本

这些决定大多不是在空白之地做出的。已有东西存在，真正的问题是要不要替换它。替换所带来的成本，不会出现在任何一栏账目中。

第一项成本是专业知识的流失。任务耗时会随着重复而下降，这就是我在 UX Guidelines 网站（@usabilitycounts）上介绍过的 Power Law of Practice，而你的高级用户在旧工具上已有数年的重复积累。一旦替换，他们就得从曲线起点重新开始，而且通常是在最繁忙的那个季度。

第二项成本是隐藏的规则。在拆掉一道栅栏之前，你应该先弄清它当初为什么立起来，正如 G. K. Chesterton 在 1929 年所论证的那样。老旧的企业软件里到处都是栅栏，而每一道栅栏都曾是某个人需要的规则。

在演示中，新东西总是能赢过人们已经熟悉的工具。

第三项成本是我们自身的偏见。根据 Michael Norton 及其合著者在 The IKEA Effect: When Labor Leads to Love 中的研究，人们对自己业余水平的成果评价，几乎与专家的成果一样高。Melissa Perri 在 The Build Trap 中描述了这种偏见在组织层面的表现：构建是容易的部分，团队因为发布产品而获得奖励，而不是因为弄清了客户真正需要什么。

非我发明（Not invented here）的心态让情况变得更糟。Not invented here 指的是因为解决方案是别人做的就拒绝接受的条件反射。Ralph Katz 和 Thomas Allen 追踪了 50 个研发项目组，写成了 An empirical test of the Not Invented Here (NIH) Syndrome，这是一篇 1980 年的 MIT 工作论文。

合作五年以上的团队表现明显更差，而且他们与团队之外的专业人士交流更少。编码代理降低了依这种本能行事的成本，因为如今重建供应商的一个功能只需一个周末，而不是一个预算周期。

编码代理还会扭曲估算。在 METR 的随机试验 Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity 中，有经验的开发者使用这些工具完成真实任务耗时多出 19%，但事后却估算自己快了 20%。

这只是一项针对 16 名开发者的研究，METR 现已将其标记为过时。即便如此，给自己的原型定价时，也要像给陌生人的项目定价那样。

购买通用件，构建差异化

我所知最清晰的检验来自 Simon Wardley（@swardley）。在 Finding a path 中，他把组件从起源、定制构建、产品一路归类到通用件。

他用来指代自行构建通用件的简写是 Thomas Thwaites，那位花了九个月试图用原材料造一台烤面包机的设计师。编码代理把九个月缩短到一个周末，但这没看上去那么重要，因为产品发布之后的每一次维修仍然归你。

编码代理改变的是烤面包机的算式，而不是烤面包机本身。

对于基于人工智能构建的产品，这张地图有清晰的分界。模型正在滑向通用件，按 token 租用。围绕它的体验仍然是定制的：一条建议如何自我解释，用户如何纠正它，以及人们是否信任它。竞争对手签署同样的合同是无法复制这些的。

在少数几个地方，自建仍然胜出。当你的数据本身就是优势，而供应商必须持有这些数据才能使用它时，就自建。

当监管排除了市场上所有现成产品时，就自建；并且构建那些你赖以竞争的关键时刻。不过，如果一个功能在每个竞争对手的产品里看起来都一样，那它多半是个通用件。

这些情况还假定你有相应的人才，而大多数组织并没有。凭感觉编程（Vibe coding）能给你一个演示，却给不了生产级人工智能应用所需的技能：在杂乱记录上做检索、评估、权限和监控。

IBM 为 Data Suggests Growth in Enterprise Adoption of AI is Due to Widespread Deployment by Early Adopters 调查了 8,584 名技术专业人士，该报告于 2024 年 1 月发布。技能与专业知识有限以 33% 位居障碍之首，数据复杂性以 25% 紧随其后。一个应用接触的数据越多，这个差距就越大。

绘制数据的分布图

模型只能根据它能看到的内容作答，因此体验取决于你的数据在哪里。买一个工具，你的记录就存放在供应商的 schema 里，按供应商的条件访问。

自建一个，数据就仍然归你，随之而来的还有治理它的职责。Anthropic 在 2024 年发布 Model Context Protocol 时，描述的正是被隔绝在数据孤岛和遗留系统之后的模型。

所以，把落地检验再跑一遍，这次针对数据。Teams 里的一张卡片，其价值取决于背后的权限；一个无法访问合同的助手，也无法总结它。

谁掌握记录，谁就决定了任何界面能展示什么。

监管正在开始将这一因素纳入考量。根据欧盟委员会的《数据法》解读，该法律自2025年9月12日起生效，而数据处理提供方之间的切换费用（包括数据传出费用）将于2027年1月12日彻底取消。

从纸面上看，更换供应商的成本正在降低。但在实践中，迁移主要是一项数据工程，只是附带了一笔用户体验的账单：字段被重命名、历史记录丢失，以及报表不再匹配。

在签订任何合同之前，先问清楚：数据将存放在哪里、谁可以导出它以及以何种格式导出，以及你的团队已经在使用的界面能否访问到它。

这些答案对体验的影响，远比功能清单更大。

为模型退役做好准备

无论如何，你的产品如今都运行在某些你无法控制的东西之上。基于某个模型构建，那个模型终将退役。Anthropic 承诺在退役一个公开发布的模型之前，至少提前60天通知。

其模型弃用页面显示，2025年9月的 Claude Sonnet 4.5 快照将于2026年9月30日被标记为弃用，退役日期定于2026年11月30日。

购买一个基于模型构建的产品，同样的事情也会发生，只是隔了一层，并且按照供应商的时间表进行。语调会变，拒绝的方式会变，摘要会变长或变短，而过去能通过的边缘案例开始失败。供应商的发行说明可能根本不会提及模型变更，因此要在合同中约定你会得到多少提前通知。

模型更换是一次没人安排过的重新设计，而且现在频繁发生。维护已成为一项实时活动。

退出计划属于设计范畴，而不仅仅是采购。保留一组已知良好结果的真实用户任务，用它们测试每一个新模型或供应商版本，并像评审可用性研究那样评审结果。二三十个任务就足以起步，只要它们涵盖常见请求、代价高昂的错误，以及正确回应是拒绝的场景。

决定复杂性落在何处

买还是建，过去要么在签字时结束，要么在上线时结束。如今这两种选择都不会结束，因为各个部分在决策之后仍在不断变动。自建的成本降低了，但拥有成本依然高昂。采购变得更容易了，但到货时背负的历史包袱比演示中透露的要多得多。

因此，这个决策不能只留在产品管理和财务部门手中。那张电子表格里的数字足够真实，只是遗漏了用户感受最深的成本：无人维护的工具产生的漂移、旧系统消亡时流失的专业知识、卡在新工具无法触及之处的数据，以及布局规则不由你掌控的聊天界面。

设计师、产品经理和研究人员是最早看到这些成本的人。他们也能衡量这些成本——体现在任务耗时上，体现在有人放弃的那些时刻。要在决策做出之前、产品上线之前，把这些证据带入决策。

落地测试不会告诉你该买还是该建。它会告诉你复杂性将落在何处，好让有人能有意地站在那里。多数情况下，这意味着采购通用部分、自建差异化部分。无论如何，两者之间的接缝都属于你，所以要设计好它们。

行动项

• 用原型测试供应商。用真实任务进行一次实操比拼，采用 Tony Byrne 与 Jarrod Gingras 所著《The Right Way to Select Technology》中的场景化方法。把你现有的系统和一个快速内部原型与供应商放在一起测试，并询问现有系统的重度用户：为什么每个奇怪的步骤 会存在。
• 列出所有被触及的系统。挑选一个真实任务，从头到尾跟踪它。记下它经过的每个系统、每个值存储在哪里、谁可以导出它，然后把这份清单放在商业论证中，紧挨着许可 费用。
• 为维护预留 30% 的预算。在构建交付之前，指定负责维护的人员，并每年预留其构建成本的 30%。把这一项当作固定支出，就像对待订阅费一样，这样修复和库更新就不用等到有空时间了。
• 模型变更后重新测试。保留 20 到 30 个已知正确答案的真实任务，包括常见请求和代价高昂的错误。每当模型或供应商发布变更了底层内容时就运行这些任务，并像评估可用性研究一样评估结果。

Buy vs. build is now also a UX decision, especially in enterprise 最初发表于 Medium 上的 UX Collective，人们正在那里通过突出显示和回应这篇文章继续相关讨论。