你并没有盯着看，工具栈却长出来了
我每年一月都数一遍所管团队在付的 SaaS 账单行数。去年数是 47 行，前年是 38 行，再往前是 22 行。团队里没人有意识地把 47 个订阅都注册了。每来一位新同事就带来自家的项目追踪器，每位客户加上自己偏好的视频工具，每次 AI 试点都新增一条供应商行和一个管理后台，发票叠得越来越厚，而团队越来越说不清哪个地方才算真正的答案。
麦肯锡《2026 AI 现状》用 97 个市场 1700+ 名高管的访谈为这种痛给出了数字。40% 的 IT 高管表示 AI 工具泛滥已经在损害协作和效率。另有 32% 表示他们已经决定不再买软件，因为可以用 agent 编码工具在内部自建。第二个数字才是有意思的：一半高管已经在把软件采购当成一个可以推迟再解决的问题，另一半正在为已经买下的工具付账。
我做远程栈的搭建和运维已经八年。泛滥不是采购问题，而是合并问题。再买一款工具永远不会解决它，因为解法是买动作的反面：挑出三样要留下的，为其余写出迁移方案，给每一个都定一个日期。
整合的三根轴
整合只有当有轴存在时才成立。没有轴，每次清理都只是重新洗牌。我用三根。
第一根轴：单一身份提供方
所有 SaaS 登录都走同一层身份。一个 SSO，一个用于预配账号的 SCIM，一个目录。有人离职，一处停用即清空所有系统。新人入职，一套流程打开所有账号。光这一条就能去掉分布式团队背着的最大安全面，因为我见过的事故复盘里，最常见的一种入侵路径都是残留账号。
任何需要单独密码、单独分组或单独管理流程的工具，都进入退役队列候选。它可能最终被留下，但必须有一个非常硬的理由。
第二根轴：单一领域事实源
每个领域只有一个标准位置。文档、任务、数据、决策、消息。两个工具写同一个领域，其中一个就是背着许可费在跑的重复品。留下的那个通常是团队真的会去搜索真实答案时用的那个，而不是 demo 里听起来更漂亮的那个。
第三根轴：单一管理面板
看续费、看支出、看访问、看停用的地方只能有一个。如果你的管理工作要在十二个后台之间穿梭，跨四张卡，那你没有管理面板，你只有十二个等待发生的意外续费。沿这根轴整合，才是让下面这一节的续费谈判杠杆得以成立的前提。
Keep 与 Kill 的打分
每个供应商都拿四个问题打分。
这个工具是否拥有某个团队在意的领域事实源？ 这个工具是否通过你的安全评审？ 这个工具是否能干净地接入另外两根轴？ 团队是否仍然每天在用？
任一问是明确的是，就留下。四问全为明确否，就砍。介于两者之间的先留下，但写下原因，下次评审时重新看。
下表把六个决策区压成一张可直接在评审会上用的留砍参考：
| 决策区 | 保留该工具 | 砍掉该工具 |
|---|---|---|
| 数据所有权 | 拥有其领域的标准事实源 | 只是存储别处已有数据的副本 |
| 安全姿态 | 通过安全评审，支持 SSO 与 SCIM | 无 SSO，评审薄弱，安全姿态陈旧 |
| 集成度 | 能接入身份提供方与管理面板 | 孤立，需要手工重录，被另外两根轴阻断 |
| 实际使用 | 团队日常活跃度足够 | 活跃席位不到 20%，或 60 天无人登录 |
| 供应商健康度 | 母公司仍在投入，产品持续发布，路线图清晰 | 裁员、分部拆分、路线图转冷 |
| 续费杠杆 | 价格在一个管理面板里可见 | 续费分散在多个后台 |
我最近两次评审有两个有用的反直觉样本。我保留了一个只有不到二十人在用的文档 wiki，因为它拥有事实源、也过了安全评审。我砍掉了一个两百人在用的通用 CRM，因为它没通过安全评审，也没法和身份提供方集成。留 wiki、砍 CRM 是对的，因为 CRM 只差一步就要失去最后一点立足点。
90 天迁移方案
每一个被砍的工具都要有书面的迁移计划和硬性的日落日期。没有日期的工具不会离开。
第 1-30 天：准备
写出迁移方案。画出哪些工作流迁去哪里。用 JSON、CSV 或 API 导出所需数据。确认目标工具能接得住。立刻冻结被砍工具的席位新增，因为新席位只会把迁移窗口拖得更长。
第 31-60 天：双跑
两个工具并行。分块把线上工作流迁过去。这个窗口内才做目标工具的培训，而不是提前做，因为迁移前培训只会长出两种习惯而不是一种。第一次真正的失败一定会出现，趁还有回退通道时修掉它。
第 61-90 天：日落
注销卡。确认导出完成之后删数据。把账号从身份提供方中移除。关闭工单。删掉云盘里的文件夹。此后每一步都只是清理，本应该很轻松，因为你只是在移除东西。
供应商风险信号
整合也是一次供应商风险判断。2026 年的 SaaS 裁员潮是最直白的证据：为一款产品付钱，并不等于母公司还在投入它。
Intuit 于 2026-05-20 宣布裁员约 3000 人，约占 17%；随后在 2026-08-25 发布的 2026 财年业绩中宣布，由于已缩减对 Mailchimp 的投入，自 2027 财年起将 Mailchimp 作为独立分部披露。 Cloudflare 裁 1100 人，约占 20%。 Monday.com 于 2026-09-17 裁约 630 人，约 20%。 Atlassian 裁约 1600 人，约 10%。Wix 裁约 1000 人，约 20%。ClickUp 裁约 22%。全部以 AI 为理由。
当一整批供应商在同一月报告相近比例的裁员、且理由相同，这不是巧合。这是行业在为自己重新定价利润率，而这次重定价正通过续费通知进入你的账本。
每次续费前对每家供应商跟踪四个信号：
- 母公司战略位移。 母公司是否已明确优先其他产品线？两条产品线的路线图是否正在分叉？
- 分部拆分。 供应商一旦被拆成独立分部或独立单位，请预期功能冻结与更慢的支持响应。
- 裁员比例。 单季超过 10% 就是领先指标，因为下一到两个季度的产品路线图通常会跟着收紧。
- 路线图冷场。 三个月内没有 changelog 不是 bug，是信号。
把这四项加进供应商评分表。供应商风险低分的工具只有在事实源和集成度上同时高分时才值得保留。三项目都低的，就是带优先级的砍。
续费杠杆
在续费窗口之前做整合，不只为了省下砍掉的那些工具。更是为了让留下来的那些工具上的定价压力，一次性全部显现。
合并之后，你只有一个管理面板、一个账期、一个采购入口。你可以谈打包续费，而不是十二笔零散续费。你可以回击去年默默接受了的人均提价。你可以亮出真正的替代方案，因为你已经知道拆掉它会有哪些断点和哪些不会。
你也终于能诚实回答每个团队都会问的问题：我们到底在软件上花了多少钱？数字通常比你以为的少，也比你愿意承认的少，但当供应商带着 22% 的续费涨幅打电话来时，这是唯一真正有意义的数字。
合并本身就是重点
常见的诱惑是觉得整合意味着功能变少。不是。重点是停止为同一能力重复付费，也停止让两个工具为同一事实源互相争抢。
挑三样要留下的，用四个标准给其余打分，为被砍的写一份 90 天迁移方案，每次续费前先读一遍供应商风险信号。这就是全部手册。它不性感，不需要新工具，也不需要委员会。它只需要一个人负责，以及一个会按时执行日落日期的日历。