这张卡讲 FDE 交付收尾最容易敷衍的环节：知识转移。
核心拆解：FDE 模式的固有风险是知识单点——系统怎么设计的、为什么这样设计，都在驻场工程师脑子里。KT 的内容要分三层转移：文档（架构与操作手册）、技能（接手方实操一遍）、决策依据（当时的取舍理由），只做第一层等于没转移。最常见的通病是 KT 沦为几场培训会，讲完即散，无考核无回访，等于把成本花在了仪式上。
增量判断：可验收的 KT 标准不是开了几次会，而是接手方能独立完成一次故障演练或日常操作全流程。AI 系统还要多转移一样东西：评测集与基线数据，否则接手方连效果是否退化都判断不了。KT 还应排进项目计划与报价，免费的知识转移不会被双方重视。
行动建议：把你手上项目的 KT 清单按三层重排，缺哪层补哪层，并约定演练日期，演练不过就延迟验收，把这条写进交接协议，客户会感谢你。
—— FDEChina编辑部 · 实战派
定义
知识转移（Knowledge Transfer，KT）指交付团队把系统维护与运营所需的文档、操作技能和决策上下文，系统性地移交给客户团队或接手方的过程，是驻场交付收尾阶段的关键环节。
展开
KT 的内容要分三层看：第一层是文档——架构说明、部署手册、运维手册；第二层是技能——接手方在陪同下实操完成部署、备份、故障处置等关键操作；第三层是决策依据——为什么选这个方案、放弃了哪些替代、哪些约束不能碰。很多项目只做第一层就宣布完成，结果接手方拿着文档不敢动系统。Forward Deployed Engineer（FDE）模式的固有风险加剧了这件事：小团队、强闭环意味着知识高度集中在驻场者个人身上，不主动转移就成了客户的技术单点，也成了供应商的人员风险。
可验收的 KT 标准不是「开了几次培训会」，而是接手方能独立完成一次故障演练或日常操作全流程。AI 系统还要多转移一项：评测集与效果基线，否则接手方连效果是否退化都无法判断，托管与自维的交接都会卡在这里。