← 返回概念解读

Concept Fable精修版

退出计划

Exit Plan · Procurement/Risk

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

盐场签约那天就画好了散伙路,后来才没有停产

海边盐场请来一家公司管理晒盐车、仓库和出货账。新系统让每日产量清楚许多,场主很快把大半流程都交了过去。

账房提醒他,签约时还该问一件扫兴的事:如果三年后不用这家公司,盐、账、人和车怎么退出来?场主觉得太早,庆功酒还没凉,不必先谈散场。

一年后,对方被并购,服务价格上涨,支持也变慢。盐场想换供应商,却发现历史账只能在旧系统里看,车队排班格式导不出,工人也只会按那套界面操作。

有人建议硬切。试了一天,仓库发错两批盐,财务少了一段对账记录,客户投诉没人追。停用系统比继续付钱更危险,盐场像被自己的流程绑在旧码头上。

场主只好补做退出计划:列出所有资料、接口、账号、流程、培训材料、合同义务和未完成订单,按风险分成必须先迁、可以并行、最后归档三类。

新供应商进场前,旧供应商必须提供导出包、字段说明、过渡支持和删除证明。盐场安排双跑两周,每天核对产量、库存和客户回执,错一处就先停下修。

迁移仍然麻烦,但没有停产。最关键的是,盐场把退出条款写进下一份合同:资料归属、导出频率、过渡期价格、协助义务和服务终止后的销毁。

场主后来告诉别人,退出计划不是悲观,而是采购成熟。能离开,才说明今天的合作不是被迫留下;敢把退路写清楚,合作反而更稳。账房后来把这件事写进采购清单:进场越深,退场越要早问。那些看似尴尬的问题,正好能暴露供应商是否把客户锁死。能提前演练一次离开,盐场才敢放心把更多流程交出去。后来盐场每年还演练一次小规模搬离。不是急着分手,而是确认钥匙仍在自己手里,真到变化那天不会被迫停产。后来复盘时,众人把这条经验写进日常规矩:先看现场哪里真正改变了结果,再决定该保留什么、修补什么、限制什么。

揭示

这个故事讲的是:退出计划

Exit Plan 是安全终止或替换供应商的计划,目标是在保留数据访问、服务连续性、合规证明和运营控制的前提下完成迁移。企业 Agent 进入关键流程后,退出计划尤其重要,因为它可能掌握知识库、提示词、工具集成、审计日志、客户数据和操作习惯。采购阶段应明确数据导出、格式说明、过渡支持、删除证明、知识转移、双跑验证和终止费用。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 盐场系统:嵌入业务流程的 AI / Agent 供应商
  • 并购和涨价:供应商变化、商业条款变化或服务下降
  • 导不出的排班和账:数据与流程可携带性不足
  • 硬切导致发错盐:没有退出计划的业务连续性风险
  • 导出包、字段说明、双跑:迁移、验证和过渡期安排
  • 删除证明:终止后的数据清理和合规证据
  • 能离开:采购谈判中的控制权和议价权

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

vendor lock-indata exportoffboardingbusiness continuitytransition plan

相关辨析

这个概念容易和相邻概念混用,建议继续看对比页。