当一个平台让你更快上线，哪些依赖成本必须先写进账本？
依赖不是罪，没定价的依赖才是；账本上要有迁移窗口、备用路径和可接受的降级。
先把问题说清楚
采用时只比较当期账单和开发速度，还是同时为退出、迁移、能力降级和运行时限制预留预算与设计？
- 谁在决定
- 资源有限、需要持续发布或运营产品的独立开发者。
- 眼前情境
- 一个 AI API、托管模型层或云运行时能明显缩短今天的交付时间，但它的版本、价格、配额与专有接口不由你控制。
- 需要选择
- 采用时只比较当期账单和开发速度，还是同时为退出、迁移、能力降级和运行时限制预留预算与设计？
- 要守住什么
- 拿到平台带来的真实速度，同时保住下一次选择的能力：能换、能降级、能撤。
- 现实约束
- 一个人没有平台团队；演练迁移、监测生命周期、维护备用路径，花的都是本来就稀缺的时间。
- 判断失误的代价
- 低估依赖，关键路径可能在涨价、退役或限流时当场断掉；高估依赖，早期项目会被不必要的多云架构拖死。
- 本期不讨论
- 本期不把所有 SaaS 都叫锁定，不比较供应商优劣，也不主张为早期试验预搭多云。
初步回答
当产品的关键路径落在你不能控制的专有接口、模型生命周期或套餐边界上，且没有演练过的退出／降级路径时，依赖就应作为明确成本写进决策。定价的内容是迁移窗口、备用路径、监测与可接受的功能降级——不是「永远不用平台」。
四条信号
每条证据，只检验一个判断。
通用语言不等于可迁移，接缝在平台服务的接口上
NIST 在 PaaS 可移植性章节指出，即使使用标准语言，不同平台的文件、队列等服务接口也可能不兼容；通用接口能降低风险但有成本，还可能牺牲平台特有能力。
检验的判断只要代码用的是通用语言，换云就只是部署工作。
依赖成本的位置在应用与平台服务的接缝，不在编程语言本身；采用专有队列、状态或身份之前，应先知道哪些调用要重写、哪些数据要转换。
编辑判断
查看来源 →采用专有能力可以，但要在采用当天写下「替换它需要重写什么」，而不是等到告别那天再盘点。
模型不是恒定的地基：退役让迁移成为持续成本
文档说明模型或端点弃用后有关闭日期，到期即不可访问；一般可用模型通常至少提前六个月通知，预览模型可能只提前两周，并建议在退役前完成替代评估与迁移。
检验的判断把模型版本固定在代码里，它就成了稳定的长期基础设施。
迁移不只是换一个模型名：提示、测试阈值、降级策略和对用户的行为承诺都要重新评估，这些时间应计入产品成本而不是事后救火。
编辑判断
查看来源 →把「模型退役」当成日历上必然到来的事排进成本，而不是当成发生在别人身上的新闻。
托管平台再加一层生命周期：日期、访问与价格都可能另算
Bedrock 将模型分为 Active、Legacy、EOL 三种状态，平台上的生命周期日期可能与模型厂商公布的不同；EOL 后请求会失败，迁移须由客户自行完成，延长访问可能价格更高。
检验的判断经由聚合平台接入模型，等于稳定拥有这个模型；只要模型厂商还在，访问和价格就不必另算。
同一个模型可能同时受模型厂商与托管平台两层生命周期约束；模型在关键路径上时，两层日历都要监测。
编辑判断
查看来源 →聚合平台买到的是便利，不是所有权。把 lifecycle 页面放进巡检清单，等于给关键路径上保险。
套餐边界是产品行为的一部分，到线时以错误的形式出现
文档列出 Free 计划每天 100,000 请求、每请求 10 ms CPU；Paid 默认 30 秒、可配置至 5 分钟。超过 CPU 限制时，运行时终止执行并向客户端返回错误 1102。
检验的判断运行时的依赖成本等于标价；现在能跑，以后也会以同样的能力和失败模式跑。
当 AI 调用、认证或渲染进入关键路径，套餐边界决定产品是失败、优化还是搬家；降级方案与重构时间都是真实成本。
编辑判断
查看来源 →在到达边界之前决定「到线时砍哪个功能」，比在错误日志里第一次思考这个问题便宜得多。
本期到此
平台依赖该不该定价，不看平台「可不可靠」，看三件事：关键路径是否落在你不能控制的接口、生命周期或套餐边界上；专有状态能否导出替换；给定的迁移窗口够不够完成替换、回归和用户沟通。任何一问答「否」，依赖成本就该进账本。
可以做什么给你正在依赖的一个平台能力做四问检查——关键性、专有性、时间、成本——把答案写进项目文档，而不是记在心里。
仍然不确定各平台的政策、期限与限额会变；本期引用的条款以各家当前文档为准，采用前应复核最新版本。
下一期问题现金 runway 应怎样改变长期原创投入的强度与复核时间？
往期