FDEOps：如何管理客户现场的 AI 交付、验收与移交
很多企业 AI 项目不是技术做不出来，而是交付过程中没有持续记录：客户真正要什么没人说得清，谁能验收没有确认，上线后谁负责也没有写下来。
FDEOps 的定位很明确：AI coding agent 负责客户代码仓库里的开发，FDEOps 负责代码之外的客户交付工作。
它记录的不是普通项目管理信息
普通项目管理往往关注任务、负责人和截止日期。客户现场还需要记录：
- 客户描述的愿望和真实问题是否一致；
- 哪些人拥有决策权和验收权；
- 什么结果才算完成；
- 客户允许访问哪些数据；
- 哪些动作必须经过确认；
- 上线后客户能否自己运行；
- 出现问题时如何回滚和升级。
因此，FDEOps 的记录对象更接近一份持续更新的交付证据链。
六阶段交付模型
FDEOps 将一次客户工作拆成：
Land → Discover → Plan → Ship → Outcome → Close
Land：先确认简报和决策人
项目开始时不要直接进入开发。先确认：
- 客户说要解决什么问题；
- 谁提出了这个问题；
- 谁真正受影响；
- 谁可以批准数据、权限和上线；
- 谁最终签字或接受结果。
如果连验收人都没有找到，后续的“完成”就很可能只是团队内部的自我判断。
Discover：验证简报是否符合真实工作
客户简报通常是压缩后的结论，不是完整事实。需要观察一线人员如何工作：输入从哪里来，使用哪些系统，哪些规则没有写进文档，异常发生时找谁。
访谈中应把“客户说的”和“现场看到的”分开记录，避免未经验证的假设直接变成产品需求。
Plan：从验收结果倒推顺序
计划不只是列开发任务，而是先写出“什么证据能证明这件事做成了”。例如：
目标：客服可以使用资料助手回答常见产品问题
证据：20 条脱敏真实问题中，18 条引用正确版本资料；
2 条无法确认的问题明确转人工；负责人完成验收。
有了证据，团队才能决定先准备哪些资料、设计哪些测试、连接哪些系统。
Ship：先在客户环境里证明，再上线
客户环境中的权限、数据版本和网络条件经常与开发环境不同。交付时要分别记录：
- 测试环境验证结果；
- 生产环境变更范围；
- 上线前检查；
- 回滚方式；
- 谁批准上线；
- 上线后如何观察。
“已经部署”不等于“已经交付”。
Outcome：记录承诺、指标和签收
Outcome 阶段回答三个问题：
- 我们原来承诺改变什么？
- 实际测量到什么？
- 谁接受这个结果？
不要用“客户觉得不错”替代验收。应尽量记录任务完成率、人工修改量、处理时间、错误类型、使用频率以及未覆盖的边界。
Close：让客户离开 FDE 也能运行
交付结束不是把项目归档，而是确认客户拥有：
- 运行手册；
- 权限和账号责任；
- 数据更新流程；
- 监控和故障处理方式；
- 回滚方式；
- 后续联系人；
- 已知限制和未完成事项。
如果系统必须依赖原 FDE 记忆才能运行，项目还没有真正完成移交。
本地记录和权限边界
FDEOps 强调客户记录保存在本地，并且写入前需要确认。这有助于避免未经确认就把客户信息写进系统，但它不自动解决合规问题。
实际使用时仍需明确：
- 哪些材料允许进入本地目录；
- 哪些内容必须脱敏；
- 哪些文件不能交给模型读取；
- 客户资料如何备份和删除；
- 多客户目录如何隔离；
- 团队成员如何获得最小权限。
本地优先是存储策略，不是完整的安全方案。
适合用它解决的场景
- 多个客户同时推进，靠聊天记录容易混乱；
- FDE 需要在客户、销售和研发之间传递上下文；
- POC、上线、验收和交接经常被混在一起；
- 客户更换联系人后，历史判断无法恢复；
- 项目结束后要复盘承诺与实际结果。
不应期待它替代什么
FDEOps 不能替代客户的工单系统、权限系统、生产监控或合同。它解决的是交付上下文和证据记录问题，不是所有企业运营系统的统一入口。
总结
FDEOps 最有价值的不是命令数量，而是它把客户交付从“依赖个人记忆”变成“有阶段、有记录、有验收、有移交”的过程。
项目地址和命令会随版本变化，使用前请以 FDEOps 当前 README 为准。本文是面向企业 AI 交付的结构化解读，不代表 GPT88 对该项目的官方背书。