4.11 我怎样避免被一个模型或工具锁住
云枢科技另一个团队曾经做过知识整理试点。
试点完全围绕某家工具建设：业务规则写在工具内部，测试样本放在供应商账号里，员工修改过的结果也只能在那个系统查看。
半年后价格上涨，公司想比较其他选择，却发现最难迁移的不是模型，而是公司已经不知道自己的规则、资料和正确结果放在哪里。
我先区分公司能力和供应商能力
供应商提供模型、工具和服务。公司必须掌握的是：
- 这项工作为什么做；
- 什么事实可以使用；
- 哪些规则和权限必须遵守；
- 哪些情境算正确或错误；
- 历史结果和人工修正；
- 运行指标、事故和版本记录。
如果这些内容只能在供应商环境里解释，公司购买的不是一种可替换工具，而是把经营记忆一起交了出去。
业务规则不能只藏在提示和配置里
“大额折扣必须由谁批准”“产品没有发布的能力不能对外承诺”，这些是公司规则。
工程师可能把它们实现为不同形式，但规则的经营含义、负责人和版本要留在执行包中，由公司确认。
这样替换工具时，新方案需要重新实现规则，却不需要重新猜公司原来为什么这样做。
我不会要求业务人员理解技术配置，但他们必须能够读懂当前生效的业务边界。
重要资料和结果要能取回
我和工程师检查：
- 原始资料是否仍由公司保存；
- AI 整理结果和人工修正能否导出；
- 权限、动作和事故日志能否取得；
- 供应商停止服务后，哪些工作会立即中断；
- 导出的内容是否还能看懂来源和时间。
“支持导出”不等于真正可迁移。只有一堆没有关系的文件，内部团队仍然无法恢复工作。
我们安排一次小型导出演练，选十笔订单，在公司控制的环境里重新还原它们的来源、确认结果和状态。
用同一组业务情境比较替代方案
模型排行榜不能告诉我哪个方案适合云枢科技。
我使用已经建立的验收情境，让不同选择处理同样的正常、缺失、冲突和高风险订单，再比较质量、等待、成本、权限和恢复。
替代方案可能在语言整理上更好，却不能满足公司数据边界；也可能便宜很多，但复杂合同错误率更高。
同一组业务情境让比较回到真实工作，而不是供应商各自最擅长的演示。
我把供应商变化也当作一种故障
价格上涨、接口变化、服务中断、合规条件改变，都可能让原方案不再适用。
我写清出现这些变化时：
- 谁负责评估影响；
- 哪些价值流和用户受影响；
- 可以暂时降级到什么方式；
- 公司能维持多久；
- 替换前必须重新通过哪些情境。
这样供应商变化不会在发生当天才第一次进入风险讨论。
可替换不等于为了未来设计一切
完全消除依赖既不现实，也可能让第一版过度复杂。
我关注的是那些会让公司失去决定权的依赖：业务规则拿不回、重要资料无法导出、测试无法复现、权限和日志看不见、停止服务后没有人工方式。
供应商特有的便利功能可以使用，但要写清它带来的价值和迁移代价。
可替换是一种经营选择能力，不是要求团队频繁更换工具。
我怎样判断公司仍然掌握主动权
我请内部团队不用打开供应商管理后台，回答五个问题：
- 当前业务规则和权限是什么；
- 哪些验收情境必须通过；
- 最近有哪些人工修正和事故；
- 重要资料和结果怎样取回；
- 如果下周停止服务，公司怎样继续工作。
如果答案只能由供应商顾问提供，公司还没有真正掌握这项能力。
商机到回款项目保留了六类公司资产
| 公司必须掌握 | 保存内容 | 替换时怎样验证 |
|---|---|---|
| 经营问题和目标 | 订单证据、基线、根因竞争解释和范围决定 | 新方案不能把任务改成“自动写方案” |
| 业务规则 | 状态、决定人、来源优先级、禁止动作和版本 | 用同一笔订单复述未来工作 |
| 样本与正确标准 | 十二类脱敏用例、禁止结果和业务判断人 | 让候选方案处理相同输入，不使用供应商演示样本 |
| 人工修正与事故 | 原因、受影响订单、恢复和后续检查 | 确认历史失败仍会被阻止 |
| 权限与行动记录 | AI 身份、读取范围、批准、暂停和撤权 | 演练越权、撤权和影响追踪 |
| 运行与成本 | 等待、AI 使用、人工复核、支持和供应商依赖 | 比较完整成本与降级能力，不只比较调用价格 |
供应商停止服务时，第一阶段可以退回原流程和批准的最小交接表。公司保存来源标识、状态、决定和验收结论，不能只得到一堆失去关系的导出文件。替换后至少重跑主体冲突、特殊折扣、权限拒绝、直接发送、财务中断和重复提交。
可替换性不会要求工程师为了未知未来抽象所有实现。它只保护公司不能失去的经营决定权。下一节把这一项与前面十一项材料一起组装，检查完整执行包是否真能由业务、工程和风险三方复述：我怎样组装一份完整执行包。