企业AI产品买与建的UX决策框架：复杂度归属与维护成本评估

人工智能让构建变得廉价，也让采购变得容易。如今的取舍取决于谁负责维护、工具之间的衔接缝隙、聊天界面以及数据。

在我职业生涯的大部分时间里，产品管理主导着“买还是建”的决策。产品经理撰写方案，财务核算数字，采购部门签字确认。

设计师在决策做出后才介入，接手胜出的方案，并花数年时间打磨其粗糙的边缘。人工智能同时改变了双方的数学逻辑。

现在构建更便宜了，但每年的维护成本从未出现在商业案例中。

采购伴随着遗留问题，而这些遗留问题现在包括他人的模型、路线图和发布日历。而且通常还有第三个没人提及的选项：替换你已有的系统。

Menlo Ventures 在 2025: The State of Generative AI in the Enterprise 中发现，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) 中划清了界限。原型可以松散，但你保留的代码必须像其他代码一样被阅读。

大多数内部工具最终成为你要保留的代码，这使它们变成了产品。它需要预算、负责人，以及在它出问题时有人可以呼叫。大多数团队不这么想，因为没有人购买任何东西。

我通过惨痛的经历学到了这一点。

我在以前工作的地方建立了一个内部工作流程应用程序，那是在人工智能出现之前，因为我们能买到的东西都不符合我们团队的工作方式。它快速上线，人们开始依赖它，而那正是它变成维护噩梦的时候。

每一个新的审批步骤都意味着修改少数人理解的代码，小的修复会在其他地方引发故障，而且没有人为此预留时间预算。

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

算一下这笔账，许多 vibe-coded 应用比它们取代的订阅服务花费更多。假设两个人花两周时间，按每小时 150 美元的全额成本计算，即前期 24,000 美元，之后每年 7,200 美元。每席位 20 美元的订阅费供 25 人使用，每年运行 6,000 美元。三年下来，构建成本为 45,600 美元，对比 18,000 美元，且只有后者附带支持团队。

每一行生成的代码都是某个人必须拥有的代码行，而最初的拥有者通常不希望承担这一责任。

开源首先吸取了这一教训。Black Duck 的 2026 Open Source Security and Risk Analysis Report 发现，98% 的受审计代码库中包含开源组件，且 93% 的代码库包含两年内无开发活动的组件。

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

接受供应商的 遗留问题

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

根据 MIT 的 NANDA initiative 的研究（被 Fortune 的 MIT report: 95% of generative AI pilots at companies are failing 报道），从专业供应商处购买的成功率约为 67%，而内部构建的成功率仅为其三分之一左右。

合理的反对意见在于选择偏差，因为公司倾向于为理解透彻的问题购买解决方案，而为混乱的问题进行内部构建，这有利于供应商。请宽松地看待这个数字，但趋势与企业预算流向相符。

购买绝不仅仅是获取一组功能。你还会得到供应商的数据模型、发布节奏以及关于你的用户试图做什么的理论。

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

正如 Melvin Conway 在 1968 年所观察到的，系统反映了设计它们的组织的沟通结构。你的用户最终身处一款针对该公司最大客户调优的产品中，而这些客户可能与你的用户 截然不同。

衡量工具 缺口

用户不会单独体验你的内部构建或外部购买。他们体验的是缺口。你可以像统计可用性测试中的点击次数那样统计这些缺口：选择一个真实任务，跟踪其在各个系统中的流程，并记录每一次切换和每一个重新输入的值。

缺口迅速累积。

在一项针对三家财富 500 强公司中 20 个团队的 137 名员工进行的 2022 年研究中，人们每天在应用程序和网站之间切换约 1,200 次。根据 Harvard Business Review 和 AAPL Leadership 发表的 How Much Time and Energy Do We Waste Toggling Between Applications?，每次切换后的重新定位让他们每周花费近四个小时，约占其工作时间的 9%。

自研工具也会扩大缺口。在 1990 年代，各部门构建了各自的 Microsoft Access 数据库，因为等待中央技术团队需要花费一个 季度。

这些数据库在其作者离职前一直有效，随后其中的数据变成了又一个无人能触及的地方。今天的版本表现为漂移：那些不再与产品其余部分匹配的模式以及无人设计的错误状态。

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

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

内部构建将复杂性移入你的代码库，而购买则将其移入他人的路线图。两者的粗心混合会将复杂性转移到你的用户身上，一次复制粘贴接一次。在任何人争论许可费用之前，先问问每种选项下复杂性最终会落在 哪里。

为宿主界面设计

在许多组织中，人们接触你产品的场所已不再是你的产品本身。而是 Teams、Slack、Claude 或 ChatGPT。

2025 年，OpenAI 通过 在 ChatGPT 中引入应用及全新 Apps SDK 将应用移入 ChatGPT 对话中。2026 年 1 月，MCP Apps——为 MCP 客户端带来 UI 能力 让工具能够返回可在 Claude 和 ChatGPT 内渲染的交互式界面。无论是自建还是购买，你最常用的屏幕最终可能变成别人窗口中的一张卡片。

我曾在这种架构下工作过。我为 Myspace 设计了开发者文档网站，其 2008 年的开发者平台允许第三方应用在用户个人主页上运行。宿主平台设定了容器大小、权限以及应用可以了解查看者的哪些信息。每个应用都在这个框架内进行设计，而聊天界面正在重新绘制这一框架。

宿主绘制框架，你的任务是决定什么能装进去。

规则是具体的，且属于宿主平台。根据 OpenAI 针对 Apps SDK 的 UI 指南，ChatGPT 中的内联卡片最多包含两个操作，禁止嵌套滚动，使用系统字体，并由宿主平台为你添加 Logo。

根据 Block Kit，Slack 消息最多容纳 50 个区块。微软的 卡片类型及其用法 将自适应卡片（Adaptive Cards）列为 Teams 新开发的推荐卡片类型。

人们期望你的产品像他们花费大部分时间的地方那样运作，这就是 Jakob Nielsen 提出的 互联网用户体验雅各布定律。在聊天界面内部，这不再仅仅是建议，因为宿主平台的模式是唯一可用的选项。因此，请将卡片设计为一个独立的产品，具备单一职责、一个主要操作，并在任务超出卡片承载能力时提供跳转至完整应用的入口。

计算替换成本

大多数此类决策并非在一片空白的基础上做出。某些东西已经存在，真正的问题在于是否要替换它。替换所带来的成本在两个选项中均未体现。

第一项成本是专业知识的流失。随着重复练习，任务耗时下降，这正是我在 UX Guidelines 网站（@usabilitycounts）上介绍的 练习幂律，而你的高级用户在旧工具中已积累了多年的重复经验。一旦替换，他们将重新开始这条曲线，通常是在最繁忙的季度。

第二项成本是隐藏的规则。正如 G. K. Chesterton 在 1929 年所论证的那样，在弄清楚围栏为何竖立之前，不应将其拆除。旧的企业软件充满了这样的围栏，每一道都是某人曾经需要的规则。

新事物总是在演示中胜过人们已经熟悉的工具。

第三项成本是我们自身的偏见。根据 Michael Norton 及其合著者在 宜家效应：当劳动导致喜爱 中的研究，人们对自己业余作品的评价与专家作品相当。Melissa Perri 在 构建陷阱 中描述了组织层面的版本：构建是容易的部分，团队因交付成果而非学习客户需求而获得奖励。

“非此处发明”（Not invented here）使情况更糟。非此处发明 是一种因为解决方案由他人制作而拒绝它的本能反应。Ralph Katz 和 Thomas Allen 跟踪了 50 个研发项目组，以进行 对“非此处发明”（NIH）综合征的实证测试，这是一篇 1980 年的 MIT 工作论文。

合作五年或更久的团队表现明显更差，而且他们与团队外部专业人士的交流也更少。编码智能体降低了顺应这种本能行动的成本，因为重建一个供应商的功能现在只需要一个周末，而不是一个预算周期。

编码智能体还会扭曲估算。在 METR 的随机试验中，经验丰富的开发者使用这些工具处理真实任务时耗时增加了 19%，但事后估计自己快了 20% 衡量 2025 年初 AI 对资深开源开发者生产力的影响。

这是一项仅涉及 16 名开发者的研究，且 METR 目前将其标记为过时。尽管如此，请像评估陌生人的原型那样评估你自己的原型。

购买通用商品，构建差异化要素

我所知道的最清晰的测试来自 Simon Wardley (@swardley)。在 寻找路径 一书中，他将组件从初创阶段、定制构建、产品化到通用商品进行分类排序。

他用来形容自行构建通用商品的代名词是 Thomas Thwaites，这位设计师花了九个月时间试图用原材料制造一个烤面包机。编码智能体将九个月缩短为一个周末，但这并不像看起来那么重要，因为在交付后你仍然要负责所有的维修工作。

编码智能体改变的是烤面包机的数学计算，而不是烤面包机本身。

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

在某些情况下，自建仍然胜出。当你的自有数据是优势，而供应商必须持有这些数据才能使用时，就选择自建。

当监管排除了市场上的所有产品时，或者当你竞争的焦点时刻需要自建时，就选择自建。不过，如果一个功能在每个竞争对手的产品中看起来都一样，那它很可能就是通用商品。

这些情况还假设你拥有相应的人才，而大多数组织并没有。Vibe coding（凭感觉编程）能让你做出一个演示，却无法提供生产级人工智能应用所需的技能：针对杂乱记录的检索、评估、权限管理和监控。

IBM 调查了 8,584 名技术专业人士，发布了 数据显示企业 AI 采用的增长源于早期采用者的广泛部署，发表于 2024 年 1 月。技能和专业知识有限以 33% 的比例位居障碍之首，其次是数据复杂性，占 25%。应用程序触及的数据越多，这一差距就越大。

绘制数据分布图

模型只能根据其可见的内容进行回答，因此体验取决于你的数据位于何处。购买一个工具，你的记录就会存储在供应商的模式中，并受供应商条款的限制。

自行构建一个，数据就归你所有，同时也承担了治理数据的责任。当 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提出的基于场景的方法，通过真实任务进行实操比拼。将您现有的系统和一个快速的内部原型与供应商的产品一同纳入测试，并询问现有系统的最重度用户每个异常步骤存在的原因。
• 列出所有涉及的系统。选择一个真实任务，从头到尾跟踪它。记录它经过的每个系统、每个值存储的位置以及谁可以导出它，然后将该列表放在商业论证中与许可费用并列。
• 预算 30% 用于维护。在构建交付前，指定负责维护的人员，并每年预留其构建成本的 30%。将该条目视为固定支出，就像订阅费一样，这样修复和库更新就不会等待空闲时间。
• 模型变更后重新测试。保留 20 到 30 个具有已知正确答案的真实任务，包括常见请求和高代价错误。每当模型或供应商发布改变了底层内容时运行这些任务，并像可用性研究一样审查结果。

购买与自建现在也是一个 UX 决策，尤其是在企业环境中最初发表在 Medium 上的 UX Collective，人们在那里通过突出显示和回复这个故事来继续对话。