项目交接的检验方法，是让接手人员能够独立完成一个约定任务：找到应用、检查一次失败、更新一份资料，或者按步骤恢复服务。文档数量不是唯一标准，关键是材料与实际运行环境一致。
按资产类别确认交付范围
| 资产 | 应说明什么 |
|---|---|
| 定制应用 | 代码或部署包范围、版本、配置说明和依赖 |
| 产品与外部服务 | 授权范围、到期条件、支持联系人和费用承担 |
| 数据与知识资料 | 来源、维护人、版本规则和导出方式 |
| 提示与流程配置 | 当前使用版本、修改方法和复测要求 |
| 评测资产 | 样本、评分规则、历史结果和已知限制 |
| 运行材料 | 发布、暂停、备份恢复和问题排查步骤 |
已有产品组件与项目新开发内容应分开列示。密钥通过企业批准的凭据管理方式交接，清单记录管理位置和责任人，不直接写入明文密钥。
用一次演练检验交接效果
可以安排接手人员在测试环境更新一份政策文件，运行相关问题样本，查看引用是否指向新版本，然后恢复原配置。演练会暴露权限缺失、路径不明、资料更新步骤遗漏等问题。
若项目包含业务写入，再安排一次失败任务排查：根据任务编号查询执行结果，确认是否需要补偿或人工处理。演练记录应写明操作者、环境、结论和未完成事项。
明确哪些工作进入维护
缺陷修复、资料更新、第三方接口变化和新增功能并不相同。项目结束前约定各类问题如何提交、响应时段、负责人及处理范围。新增部门、新任务和新系统接入通常需要重新确认样本与权限，不能仅按已有功能的简单复制估算。
如果有日常定时任务，记录调度位置、运行账号和失败提醒接收人。对于依赖桌面环境的任务，还应明确执行设备和可用条件。
形成可复查的结项记录
结项记录包含本期范围、验收证据、已知问题、遗留项责任人及后续安排。仍有问题时，应明确它是否影响本次放行，以及预期处理时间；不要以空白的“后续优化”代替具体事项。
案例复盘可以使用“背景—限制—实施—验证—下一步”的结构。涉及真实客户时，公开内容应使用已获授权的信息；本知识库中的演算和场景示例不能转成客户成果。
可直接使用的模板
两份模板均为可编辑的 Markdown 文本，可复制到团队文档中填写。具体指标和范围由项目双方确认。需要讨论实施方式时，可查看小火堆 FDE 服务，或带一份脱敏样本进行项目沟通。