平台能力能让一个人更快上线。问题不是要不要依赖，而是采用时有没有同时知道：哪一段关键路径交给了谁，状态怎样取回，通知窗口够不够迁移，失败时产品怎样降级。
如果这些问题要等到涨价、退役或限流后才回答，依赖成本只是被推迟，不是不存在。
本文不主张早期项目预搭多云，也不比较供应商优劣。目标是让必要依赖可见，而不是把所有平台能力都视为锁定。
一页依赖账
每项关键依赖只需要先登记一行：
| 依赖 | 当前价值 | 专有接缝与状态 | 退出要做什么 | 通知与复核 |
|---|---|---|---|---|
| 模型 API | 缩短开发或推理时间 | 提示、评测阈值、模型行为 | 替代评测、回归、用户沟通 | 厂商退役通知与复核日期 |
| 托管运行时 | 省去部署和运维 | 队列、文件、身份、配置 | 数据导出、接口改写、重新部署 | 平台生命周期与套餐边界 |
| 第三方服务 | 快速补齐产品能力 | 账号、历史记录、回调 | 导出、替代流程、功能降级 | 条款、价格和配额变化 |
“退出要做什么”不能只写“更换供应商”。要拆到需要改写的调用、需要转换的数据、需要重跑的测试，以及必须通知的用户。
接缝
NIST 关于公有云的技术指南指出，即使应用使用标准语言，不同 PaaS 的文件、队列等服务接口仍可能不兼容。通用接口可以降低可移植风险，但也有实现成本，并可能放弃平台特有能力。
因此，依赖盘点应从应用与平台服务的接缝开始，而不是问“代码使用的语言是否通用”。专有能力可以采用，但采用当天要记录替换范围；如果专有状态无法导出，产品降级路径也应在账本里写明。
生命周期不是一张日历
模型厂商和托管平台可能分别维护生命周期。OpenAI 的弃用文档说明，弃用模型或端点会有关闭日期；一般可用模型通常至少提前 6 个月通知，预览模型可能只提前 2 周。AWS Bedrock 又把模型分为 Active、Legacy 和 EOL，平台日期可能与原厂不同，EOL 后请求会失败，迁移由客户完成。
关键路径上的模型因此至少有两张日历：原厂模型和托管入口。迁移也不只是换模型名；提示、测试阈值、延迟、成本、降级策略和对用户的行为承诺都要重新评估。
套餐限制是第三张日历。Cloudflare Workers 当前文档列出不同计划的请求与 CPU 限制，并说明超过 CPU 限制会终止执行。限额不是账单附注；当认证、AI 调用或渲染位于关键路径时，它直接决定到线后的产品行为。
退出演练留下什么
不需要为了证明“可迁移”立即建设第二套生产系统。更小的演练是选 1 条关键路径，在隔离环境完成以下记录：
- 导出必要配置和非敏感状态；
- 列出必须替换的接口与专有格式；
- 用候选替代方案跑同一组回归任务；
- 记录迁移、验证和沟通分别需要的时间；
- 模拟替代方案不可用时，产品保留哪些最低功能。
演练结果与厂商通知窗口比较。所需时间接近或超过可用窗口时，应缩小专有接缝、提前准备降级，或接受这项依赖并把风险明确写进产品决定。早期项目如果迁移演练的维护成本高于失败后果，也可以只保留数据出口和停机说明，不为“理论可移植”建设多余架构。