项目结束时要回答两个问题：客户内部获得了什么可继续运行的能力，交付方又从现场获得了什么经过验证的产品输入。只有前者，交付方会不断重复定制；只有后者，客户会继续依赖外部团队。系统可访问不等于用户已经激活。FDE 要观察目标用户是否在关键任务中重复使用、是否回到旧方法、哪些人能够帮助项目继续运行，并用 30、60、90 天证据决定扩大、修改或停止。能力转移不以培训签到结束，而以维护者和内部教练在无代操条件下独立更新、评估、发布、处置故障与教练他人。
- 按真实运行责任设计能力移交
- 培养能辅导他人解决问题的内部教练
- 用独立接管与延迟证据评估能力
从概念到可执行判断
用接管而非培训完成定义退出
客户或内部团队能够更新知识、运行评估、处理常见问题、升级故障和发现下一场景，才具备接管条件。退出不是突然离场，而是逐步减少代操作并移交责任、权限和判断。
客户依赖下降不等于合作价值下降。外部 FDE 可以转向更难的场景，而不是长期替客户维护日常工作。
移交包包含场景与价值、流程与责任、上下文与知识、Agent 与 Skill、评估与错误、安全与运行、培训、支持边界和 90 天安排。
代码只是其中一部分。没有业务解释、评估集、版本和维护 SOP，内部人员无法判断改动是否安全。
按真实异常设计接管演练
参加培训不等于能够维护。内部维护者至少独立完成一次知识更新、评估运行、版本发布或故障处理，并知道何时升级。
演练记录保留操作结果、问题、补充培训和最终责任人，作为退出评审证据。
培养内部教练而非内部代操者
内部教练要能通过真实事件追问任务、证据、判断、边界与反例，帮助维护者自己定位和解决问题，不把所有操作重新集中到一个专家。
用 30/60/90 证据观察能力稳定性
前 30 天关注首次激活、入口、主要错误和支持响应；60 天关注重复使用、关键任务深度、绕行与知识维护；90 天再判断业务结果、角色变化、内部接管和扩展条件。
不同场景的周期可以调整，但不能在第一周用短期热情代替持续结果。
试点期间将日志、用户反馈和现场观察汇总，按对真实使用的影响排序。先解决阻止关键任务完成的障碍，再处理外观和低频偏好。
模型问题、知识问题、流程问题和组织问题需要交给不同负责人，不能全部归入产品待办。
将辅导和运行经验回流能力系统
记录维护者和内部教练在独立接管中的求助、绕行、故障与决策，把共性缺口回流到文档、评估、平台和教练材料。
药企跨地区复制：复制的不是一份代码
一个合规场景在首个团队验证后，希望推广到不同地区。
团队沉淀规则来源、评估集、例外处理、维护 SOP 和内部责任，并允许地区团队根据本地要求更新。
能够复制的是一套问题定义、知识治理、评估和运营方法，而不是把同一套程序原封不动安装多次。
双向交付六问
退出评审同时检查客户与产品两端：
业务、知识、技术和风险分别由谁负责？
维护者是否独立完成过更新、评估或故障处理？
问题怎样升级，下一场景由谁发起？
哪些是客户专属，哪些会跨客户重复？
哪些可成为模板、Skill、组件或平台能力？
哪些现场证据证明原有产品判断需要改变？
先回答，再展开答案
01为什么客户接管与产品回流要同时发生？
只有接管会让交付方重复定制，只有产品回流会让客户持续依赖外部团队。
02参加一次培训能证明维护者已经接管吗？
不能，需要独立完成真实更新、评估、发布或故障处理。
03支持者网络除了高层 Sponsor 还需要谁？
业务 Owner、日常维护者、非正式影响者、实际用户和受影响人员。
04为什么要分 30、60、90 天观察？
首次激活、稳定使用和业务结果出现的时间不同，分段可以避免用短期热情替代长期证据。
把方法带回真实工作
企业内部推进（默认）
为企业内部试点组织无代操接管演练，并辅导一名内部教练带领复盘。
外部客户交付（可选）
在客户责任人确认下完成能力移交与内部教练接管。
所需材料
- 项目全部交付物
- 内部维护者
- 权限与责任安排
- 产品或平台评审角色
- 通过质量门的原型
- 试点用户与 Owner
- 日志和反馈渠道
- 支持者与受影响人员
交付物
- 分角色能力移交包
- 内部教练培养与观察记录
- 无代操接管演练与 30/60/90 能力证据板
通过标准
- 维护者能独立完成其责任内的更新、评估、发布和故障处置
- 内部教练能引导复盘并帮助他人解决问题
- 接管能力在 30–60 天延迟评审中仍可见
能力证据
- 维护者独立更新、评估、发布与故障处置的完整记录
- 内部教练独立引导一次真实问题复盘的观察证据
填写模板或完成课程不等于能力达标；通过必须以真实任务、现场行为和可复核证据为依据。