先这样答
先说绑定在哪。真正锁死你的通常不是 API 格式，这层好换；是三处隐性依赖：提示词是针对某家模型的行为调出来的，换模型效果掉一大截；工具调用用了厂商私有协议或专有参数；深度用上了对方的独有功能，比如某种缓存或文件解析。做架构时就要意识到，每多接一个专有能力，迁移成本就多一分。
防法和迁移步骤分开讲。防：把模型调用收敛到一个适配层，业务代码只面对生成、嵌入、工具调用几个抽象接口，不直接拼厂商的开发包；提示词按通用能力写，少依赖某家特有的指令风格；每个专有功能都先评估「收益换绑定」划不划算。迁：第一步用固定评测集分别跑新旧模型，量化差距集中在哪类任务；第二步针对掉分的地方改提示词和参数，把基线对齐；第三步灰度切流量，新旧并行跑一段时间，按任务类型逐步放量，出问题随时切回。
总结：不被绑死不等于完全不用厂商特性，而是每次使用都清楚记下迁移成本。适配层和评测集是两件要先备好的事：前者让切换可行，后者让切换敢做。
面试官会怎么追问
- 「提示词换模型就要重写吗？」 不一定全重写，但要重新调。任务描述、输出格式约束大多通用；对模型行为敏感的部分（示例的选择、引导方式）常要按新模型调整，评测集会告诉你哪里需要调。
- 「成本和迁移自由怎么权衡？」 分层处理：核心链路保持可迁移，接受为通用性付一点性能折扣；确定长期不换的场景可以用专有功能换收益，但要把「换模型等于重做这部分」写进技术决策记录，别让后续维护者踩坑。
- 「多模型路由是不是必须的？」 不是。路由本身有维护成本：多套提示词、多套评测基线。大部分团队一个适配层加随时可切的能力就够，真正按任务特性在多模型间路由的是少数重度场景。
回答的坑
- 以为用了通用兼容格式就不算绑定。接口格式只是最浅一层，提示词适配和专有功能才是主要工作量，换格式不换提示词照样掉效果。
- 迁移只对比几个例子就全量切。没有固定评测集量化差距，切换后效果回退很难定位，先有基线再动手。
—— 本题完 ——