外部依赖是"会变的"
AI 功能几乎都依赖外部：模型服务、向量库、爬虫源、云厂商 ✔。
这些依赖会涨价、改接口、限流、下线 ✔ —— 如果没准备，某天早上系统就会大面积挂掉 ✔。
把外部依赖当风险来管 ✔：登记、监控、留退路 ✔。
一、依赖登记表（一张表能省很多事）
依赖名 ｜ 用途 ｜ 关键程度（致命/可降级/可替换 ✔）
｜ 当前版本/接口 ｜ 计费口径 ｜ 变更通知渠道 ｜ 退路方案 ｜ 负责人
要点：关键程度与退路方案最常被省 ✗ ——
没有退路方案的"致命依赖"，就是单点故障 ✔。
二、四类变化的应对
| 变化 | 应对 |
|---|---|
| 涨价 | 成本上限告警；准备替代方案；按档位切换 ✔ |
| 接口变更 | 版本锁定 + 变更前灰度；沙箱先验 ✔ |
| 限流收紧 | 配额与排队；多供应商分流 ✔ |
| 服务下线 | 提前迁移（这是最需要预案的 ✔） |
"多供应商分流"是最实用的退路 ✗→✔：同一能力接两家 ✔，
平时按比例或按档位分流 ✔，一家出问题时能快速切换 ✔。
三、必须提前做的三件事
- 抽象层 ✔：业务代码不直接调某家 SDK ✗ → 中间加一层适配 ✔（换供应商只改适配层 ✔）；
- 契约测试 ✔：用同一批样本测两家供应商，确认行为差异在可接受范围 ✔；
- 切换演练 ✔：真的切一次（见断上游演习那篇 ✔），确认链路能跑 ✔。
四、监控什么
- 各依赖的错误率与延迟（分供应商 ✔）；
- 配额使用率与限流触发次数 ✔；
- 计费口径变化的异常（单位成本突然抬升 ✔）；
- 官方变更公告（订阅渠道，别靠新闻 ✗）。
五、一条务实建议
对每个"致命依赖"问三个问题：
① 它今天挂了，我们能撑多久？（小时/天 ✔）
② 有没有第二家能接？（有 → 演练过吗 ✔）
③ 迁移要多久？（人日量级 ✔ —— 超过一周就要提前立项 ✔）
判据
你的主力模型供应商明天宣布下线 ✔，你能否在两周内完成切换 ✔ 且质量不降 ✔？
答不出，说明外部依赖还只是"用着"，没有被管理 ✗。