当一个平台让你更快上线，哪些依赖成本必须先写进账本

资源有限、需要持续发布或运营产品的独立开发者。一个 AI API、托管模型层或云运行时能明显缩短今天的交付时间，但它的版本、价格、配额与专有接口不由你控制。要决定的是：采用时只比较当期账单和开发速度，还是同时为退出、迁移、能力降级和运行时限制预留预算与设计？

想守住的是：拿到平台带来的真实速度，同时保住下一次选择的能力：能换、能降级、能撤。现实约束：一个人没有平台团队；演练迁移、监测生命周期、维护备用路径，花的都是本来就稀缺的时间。判断错了的代价：低估依赖，关键路径可能在涨价、退役或限流时当场断掉；高估依赖，早期项目会被不必要的多云架构拖死。

（本期不讨论：本期不把所有 SaaS 都叫锁定，不比较供应商优劣，也不主张为早期试验预搭多云。）

通用语言不等于可迁移，接缝在平台服务的接口上

NIST 在 PaaS 可移植性章节指出，即使使用标准语言，不同平台的文件、队列等服务接口也可能不兼容；通用接口能降低风险但有成本，还可能牺牲平台特有能力。 来源：NIST · SP 800-146。

依赖成本的位置在应用与平台服务的接缝，不在编程语言本身；采用专有队列、状态或身份之前，应先知道哪些调用要重写、哪些数据要转换。

我的判断：采用专有能力可以，但要在采用当天写下「替换它需要重写什么」，而不是等到告别那天再盘点。

模型不是恒定的地基：退役让迁移成为持续成本

文档说明模型或端点弃用后有关闭日期，到期即不可访问；一般可用模型通常至少提前六个月通知，预览模型可能只提前两周，并建议在退役前完成替代评估与迁移。 来源：OpenAI · API Deprecations。

迁移不只是换一个模型名：提示、测试阈值、降级策略和对用户的行为承诺都要重新评估，这些时间应计入产品成本而不是事后救火。

我的判断：把「模型退役」当成日历上必然到来的事排进成本，而不是当成发生在别人身上的新闻。

托管平台再加一层生命周期：日期、访问与价格都可能另算

Bedrock 将模型分为 Active、Legacy、EOL 三种状态，平台上的生命周期日期可能与模型厂商公布的不同；EOL 后请求会失败，迁移须由客户自行完成，延长访问可能价格更高。 来源：AWS · Bedrock model lifecycle。

同一个模型可能同时受模型厂商与托管平台两层生命周期约束；模型在关键路径上时，两层日历都要监测。

我的判断：聚合平台买到的是便利，不是所有权。把 lifecycle 页面放进巡检清单，等于给关键路径上保险。

套餐边界是产品行为的一部分，到线时以错误的形式出现

文档列出 Free 计划每天 100,000 请求、每请求 10 ms CPU；Paid 默认 30 秒、可配置至 5 分钟。超过 CPU 限制时，运行时终止执行并向客户端返回错误 1102。 来源：Cloudflare · Workers Limits。

当 AI 调用、认证或渲染进入关键路径，套餐边界决定产品是失败、优化还是搬家；降级方案与重构时间都是真实成本。

我的判断：在到达边界之前决定「到线时砍哪个功能」，比在错误日志里第一次思考这个问题便宜得多。

平台依赖该不该定价，不看平台「可不可靠」，看三件事：关键路径是否落在你不能控制的接口、生命周期或套餐边界上；专有状态能否导出替换；给定的迁移窗口够不够完成替换、回归和用户沟通。任何一问答「否」，依赖成本就该进账本。

可以先做的一件事：给你正在依赖的一个平台能力做四问检查——关键性、专有性、时间、成本——把答案写进项目文档，而不是记在心里。

还不确定的：各平台的政策、期限与限额会变；本期引用的条款以各家当前文档为准，采用前应复核最新版本。

下一期想追的问题：现金 runway 应怎样改变长期原创投入的强度与复核时间？