有一种项目，工程师在场时特别好用
FDE 能快速理解需求、改代码、补接口，现场遇到问题几小时就能处理。客户很满意，直到项目进入常态运行：负责的工程师转去下一个项目，知识库更新没人审核，模型调整没人评测，接口报错只能在群里等回复。系统没有坏，却慢慢没人敢用。
这说明项目交付了功能，没有交付运行能力。FDE 的价值是把复杂问题快速带到生产，但成熟交付不能把客户变成长期依赖某个个人。未来越复杂的企业 AI 项目，越需要在开发过程中同步设计谁来接、接什么、怎样判断系统仍然正常。
交接清单不应只有代码仓库和账号
客户需要知道系统用了哪些数据、知识由谁维护、权限如何申请、模型和提示在哪里配置、关键指标怎样看。还要有评测样本、常见故障、人工兜底和升级联系人。只交一份技术架构图，业务团队仍然不知道日常该做什么。
更重要的是决策记录。为什么选择这个流程，哪些方案试过但失败，哪些场景故意没有自动化，什么情况下必须人工确认。这些判断如果只在 FDE 头脑里，下一位维护者很容易重复踩坑，或者为了追求新功能破坏原有边界。
- 交付系统结构、数据来源、权限和配置说明。
- 交付评测集、失败样本、故障处理和人工兜底。
- 记录关键取舍、未解决问题和后续变更规则。
最好的培训，是让客户亲手处理一次变化
很多交接培训停留在看演示。更有效的方法，是让客户团队亲手更新一份知识、运行一次评测、处理一个模拟故障并完成版本发布。FDE 在旁边观察哪里卡住，再补工具和说明。真正做过一次，比听两小时讲解更能暴露能力缺口。
交接对象也不能只有 IT。业务负责人要会判断内容和指标，技术人员要会处理接口与运行，管理者要知道风险和资源边界。企业 AI 是跨部门系统，任何一方缺席，都可能在 FDE 离开后形成新的单点依赖。
未来 FDE 的成绩，要看项目离开他之后怎样运行
OpenAI 的 FDE 岗位强调把成功模式沉淀成工具、playbook 和可复用组件，管理岗位还关注交付模式是否持久。这意味着 FDE 不只是现场救火，还要降低下一次解决同类问题的成本，让团队和客户都从项目中获得能力。
企业验收时，可以增加一个朴素问题：如果主要工程师下周不在线，我们能否更新知识、发现异常、回退版本并找到责任人？答案如果是否定的，项目仍处于个人支撑阶段。真正完成的交付，不是 FDE 永远不可替代，而是他把关键判断变成了团队能延续的方法。
要点总结
- 应包含代码与配置、数据和权限、评测集、运行手册、故障流程、人工兜底和决策记录。
- 可以按角色分工，业务负责知识和标准，技术负责运行与接口，复杂问题再升级支持。
- 让客户独立完成一次知识更新、评测、故障处理或版本回退，并记录卡点。
参考来源说明
本文围绕“FDE 做完项目不能只留下代码：未来交付还要让客户接得住”展开，结合 9 份公开资料及一路凯歌在“FDE 能力趋势”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。