每个季度我都会坐在一个房间里，看团队决定要不要再订一款 SaaS。销售的话术永远一样：买工具、省人力、下周上线。2019 年这套逻辑成立，现在几乎不成立了。
麦肯锡 2026 年 8 月的《AI 现状》报告调研了 97 个市场的 1700 多位高管，其中一个数字点破了这个变化：32% 的组织表示已经决定不再采购某款软件，因为用 agentic coding 工具可以在内部自建。同一份报告说，80% 的组织认为 AI 提升了个人生产力，但把 AI 影响传导到企业 EBIT 层的比例一直停在 37%，真正算得上 AI 高绩效的组织只有 6%。翻译过来就是：自建的算力已经到位，把它变成利润的经营纪律还没有。
故事的另一端在 2026 年春夏变得更响。2026-05-20，Intuit 宣布裁掉约 3000 人，约占 17% 的员工，同时计提 3.0 到 3.4 亿美元重组费用，当天与 Anthropic、OpenAI 签署多年期 AI 合作。2026-05-08，Cloudflare 裁掉 1100 人，约占 20%，同时公布 2026 年 Q1 营收 6.398 亿美元、同比增长 34% 的历史新高，并称三个月内内部 AI 使用量增长了 600%。2026-09-17，Monday.com 宣布裁掉约 630 人，同样约 20%，转向 AI Work Platform。卖你工作流工具的厂商，正在被同一批 AI 工具重新剪裁他们自己的人力结构。
为什么「默认买」不再赚钱
订阅溢价是真实的。你为一套你并不完全使用的工作流买了通用版本，还要额外吸收厂商自身的动荡。涨价、席位蔓延、功能堆砌，全都落到你的月度 opex 上。当一家 SaaS 厂商自己都在因为 AI 缩编，供应商稳定性就从一个不变量变成了一个变量。
Intuit 是最干净的例子。它一边向 AI 原生的交付方式重组，一边在其他产品线继续给自己加席位。如果你的 SaaS 厂商裁了 17% 的人，那么任何超过十二个月的重签周期，都应该被当成一笔押注。
决定「自建」的四个维度
我给每个候选工作流用同一张表。四个维度，各打一到五分。任何一项低于三分就选采购。
需求稳定性
每季度规则都在变的工作流不适合自建。规格不稳，你就是在用工程工时追一个移动的靶。这一项打不到三分以上，就交给厂商的配置器。
数据敏感度
工作流如果碰客户 PII、财务台账或受监管的档案，自建会改变风险结构。审计链、留存策略、事故响应都归你。当厂商会把同一批数据放到黑盒里时，自建值得；当厂商已经拥有你无法低成本复刻的合规认证时，就不值得。
运维能力
大多数自建项目就是在这里悄悄失败的。做一个东西是一场冲刺，长期维护一份东西是一份工作。如果你的团队里没人能在周末响应这个工作流的 on-call，那你不是在自建，你是在把未来的事故外包给未来的自己。
集成依赖
如果工作流要接五六个第三方系统，每个都有自己的 API 漂移风险，那么集成的复杂度会盖过逻辑本身的复杂度。只有接入面不超过两个干净的系统，才考虑自建。
把工作流端到端地算一遍
四个维度打完分，再把账算清楚。取月运行次数，乘以每次运行预估的 token 或 API 调用数，得到月度 AI 支出，再与 SaaS 席位价按同一月度口径对比。最后加上评审、修补、看护自建的这部分人力成本。大多数团队都在这最后一栏低估了预算。
只有当自建在十二个月口径上的单次总成本低于席位价，且运维负担控制在每周两小时以内，自建才算赢。如果你的月运行量很低，任何模型价格都不划算。如果你的月运行量很高、数据又不敏感，几乎任何自建方案都赢。
给 token 支出设一道硬上限
麦肯锡调研中，大约 20% 的组织表示因为运行或 token 成本而限制了 AI 使用。这个数字决定了你的上限怎么定。
先锁定月度支出上限，再上线，而不是等账单来了再设。挑一个仍能通过质量门槛的最便宜模型。默认用这个模型跑工作流，只在特定质量门槛触发时才路由到大模型。这样才能让单次成本随着调用量放大仍然可控。
上线前先写清回退条件
我会要求每个团队在生产环境第一次跑之前，先把回退条件写下来。准确率低于阈值、周运维时间超上限、单次运行成本突破定线，都算触发条件。写在你做决策的那份备忘里。
没有回退条件，失败的自建就变成了永久沉没成本。有了回退条件，它就是一次两个月、下行有界的实验。「自建还是采购」这个问题只有当两个选项都有退出机制时才公平。
什么时候买，什么时候自建，什么时候砍
没有普适答案。下面这张表是我带去评审时用的版本。
| 维度 | 采购 SaaS | 用 AI 自建 |
|---|---|---|
| 前期成本 | 低，第一个月就是订阅费 | 较高：工程工时加提示与评测搭建 |
| 持续成本驱动 | 席位、涨价、附加模块 | 单次运行的 token 或 API 调用，加上一个半职运维角色 |
| 工作流归属 | 归厂商，你依赖他们的路线图 | 你拥有逻辑、数据与变更日志 |
| 失败模式 | 涨价、厂商撤出、功能漂移 | 静默退化、失控的 token 账单、被遗弃的代码 |
| 何时最适用 | 需求不稳、数据敏感、运维能力薄 | 需求稳定、可测量运行量、运维覆盖到位 |
我最后的规则是：当运维能力薄、数据敏感度高，或工作流依赖单一厂商 API 时，就采购。当需求稳定性得到验证、运行量可测、你有真实的工程小时预算加 token 上限时，就自建。当两个方案在十二个月内都收不回成本时，就彻底砍掉。如果你还在保着一份每年席位费高于内部自建总价的订阅，把它砍掉。
真正的瓶颈不是能力，是成本纪律。麦肯锡调研中已经有约 20% 的组织被 token 与运行成本卡住，赢家是那些把自建当成一次有预算、有回退机制的实验的团队，而不是把自建当成希望的团队。挑两三个量最大、最稳定的工作流，跑一遍四维打分，设好月度 token 上限，看着你手上的厂商清单变薄。这才是把 AI 杠杆从个人生产力指标变成利润行的做法。