项目移交清单需要覆盖六类信息：移交范围与边界、交付物与资产、责任与权限交接、知识与文档、未完成事项与风险、确认与签收。本文提供一份可直接复制填写的空白表格，并逐列说明填写口径、必填与选填的划分规则，以及一份完整填写示例。模板适用于项目整体结束、团队更替或阶段负责人转换时的移交；单次软件交付的验收标准判定不在本文范围内。清单条目与签认状态也可以放到 ONES 的项目和文档场景中承载，便于后续查阅。
要点总览（TL;DR）
- 项目移交清单覆盖六类信息：移交范围与边界、交付物与资产、责任与权限交接、知识与文档、未完成事项与风险、确认与签收。
- 最小必填集合为表头的项目名称、移交方、接收方、计划移交日期，以及每行的信息项、内容要求、责任人、接收人、状态；备注列可空。
- “信息项”写交什么，“内容要求”写交到什么程度，两列配合才能让接收方判断能否签收；责任人与接收人分离，避免自交自收。
- 状态统一用未开始、进行中、待确认、已完成四个取值，签认区独立于信息行，由移交方与接收方共同签字并注明日期。
- 清单复用时先按项目类型裁剪条目，再维护版本与变更记录，签认完成后冻结终版并归档到项目知识库。
可复制的项目移交清单空白模板
下表按六大信息类别分组，每组预留若干空白行。使用时先填写表头，再按类别逐行补充信息项。行数不够时在对应类别下插入新行，保持类别分组不变。
| 项目移交清单 | |||||
|---|---|---|---|---|---|
| 项目名称 | 项目编号 | ||||
| 移交方 | 接收方 | ||||
| 计划移交日期 | 实际移交日期 | ||||
| 类别 | 信息项 | 内容要求 | 责任人 | 接收人 | 状态 | 备注 |
|---|---|---|---|---|---|---|
| 一、移交范围与边界 | ||||||
| 二、交付物与资产 | ||||||
| 三、责任与权限交接 | ||||||
| 四、知识与文档 | ||||||
| 五、未完成事项与风险 | ||||||
| 六、确认与签收 | ||||||
表格末尾另设签认区：移交方签字与日期、接收方签字与日期、监交人（如有）签字与日期。签认区不并入信息行，避免与条目状态混淆。
清单字段说明：每一列填什么
模板共七列，各列承担不同职责。填写时容易混淆的是“信息项”与“内容要求”，以及“责任人”与“接收人”。下表给出统一口径。
| 字段 | 填写什么 | 填写口径 |
|---|---|---|
| 信息项 | 本条要移交的具体对象或事项名称 | 用名词短语，指向单一对象，例如“生产环境部署权限”“客户联系人清单”。一个信息项占一行，不把多个对象合并成一行。 |
| 内容要求 | 该信息项应达到的完整程度或交付形态 | 写清“交到什么程度算完成”，例如“含账号、角色、有效期”“覆盖全部在服客户，含联系方式与对接历史”。它是验收该行的依据。 |
| 责任人 | 负责准备、整理并交出该项内容的人 | 填具体姓名，不填部门。责任人对该行内容的完整性和准确性负责。 |
| 接收人 | 接收并确认该项内容的人 | 填具体姓名，通常为接手后续工作的角色。接收人确认后该行才可标记完成。 |
| 状态 | 该行的处理进度 | 统一使用四个取值：未开始、进行中、待确认、已完成。“待确认”表示移交方已交付、接收方尚未确认。 |
| 备注 | 补充说明 | 用于记录存放位置、特殊约定、遗留问题链接或延期原因。无补充内容时留空，不写“无”以外的冗余说明。 |
“信息项”回答交什么，“内容要求”回答交到什么程度，两列配合才能让接收方判断是否可以签收。责任人与接收人分离，是为了让交付与确认由不同角色完成，避免自交自收。
必填项与选填项如何区分
必填项的最小集合是：表头中的项目名称、移交方、接收方、计划移交日期，以及每一行的信息项、内容要求、责任人、接收人、状态。这九项缺任何一项，清单都无法支撑交接和签认。备注列默认可空。
选填与否取决于该信息项是否影响接收方独立开展工作。判断方法有两个：接收方缺少这条信息是否无法启动工作；该信息是否只对特定项目类型有意义。前者为是则应列为必填，后者为是则可设为选填。
| 信息项 | 常规项目 | 判断依据 |
|---|---|---|
| 移交范围与边界说明 | 必填 | 接收方需知道哪些工作归自己、哪些不归自己 |
| 核心交付物清单及存放位置 | 必填 | 缺少则无法找到成果物 |
| 系统账号与权限 | 必填（涉及系统时） | 无权限则无法操作，纯线下项目可略 |
| 关键文档与知识说明 | 必填 | 影响后续判断与排障 |
| 未完成事项与风险 | 必填 | 无此信息会形成隐性负债 |
| 签认记录 | 必填 | 移交生效的凭据 |
| 供应商与合同信息 | 选填 | 仅当接收方需继续对接供应商时必填 |
| 历史决策背景 | 选填 | 对延续性要求高的项目建议填写 |
| 设备与实物资产明细 | 选填 | 涉及实物交接时转为必填 |
按项目类型调整时，遵循一条原则：必填集合只增不减，选填项按项目特征升级为必填。运维接手类项目应把账号权限、监控告警配置升为必填；研究类项目应把历史决策背景、数据来源说明升为必填。裁剪时优先删减与接收方工作无关的选填行，保留六大类别的基本骨架。
填写示例：一个完整填好的移交清单
示例背景：某企业内部数据平台项目由甲团队移交给乙团队继续运营，计划移交日期为 6 月 30 日。以下为已填写内容，字段与空白模板一一对应。
| 类别 | 信息项 | 内容要求 | 责任人 | 接收人 | 状态 | 备注 |
|---|---|---|---|---|---|---|
| 一、移交范围与边界 | 运营职责范围 | 明确日常运维、需求受理、故障响应三类职责的归属，列出不在移交范围内的系统 | 张明 | 李华 | 已完成 | 范围说明见知识库“平台运营边界”页 |
| 二、交付物与资产 | 平台代码仓库与部署包 | 主分支代码、最近一次生产部署包及版本号，附部署说明 | 王强 | 李华 | 已完成 | 仓库权限已转移，部署包存于制品库 |
| 三、责任与权限交接 | 生产环境账号与权限 | 含数据库、服务器、监控平台账号，注明角色与有效期，移交后原账号停用 | 王强 | 赵敏 | 待确认 | 监控平台账号待乙方确认后停用原账号 |
| 四、知识与文档 | 运维手册与故障处理记录 | 覆盖常见故障场景、处理步骤与联系人，含近半年故障复盘 | 陈静 | 赵敏 | 进行中 | 复盘记录整理中，预计 6 月 25 日补齐 |
| 五、未完成事项与风险 | 待上线报表需求 | 列出 3 项已受理未上线的报表需求，含需求描述、当前进度与预计完成时间 | 张明 | 李华 | 未开始 | 需求单已关联至移交清单 |
| 六、确认与签收 | 移交签认 | 移交方与接收方共同确认上述条目，签字并注明日期 | 张明 | 李华 | 未开始 | 计划 6 月 30 日完成签认 |
示例中状态列体现了实际进度差异：已完成的条目可直接进入签认，待确认的条目需要接收方回复，进行中的条目附预计完成时间。备注列只写对接收方有用的信息，例如存放位置、后续动作和时间点。
当移交条目较多、参与人分散时，清单本身需要一个稳定的承载位置。ONES Wiki 支持文档关联项目任务，页面树可以按项目组织移交文档；文档实时同步并记录页面版本，移交过程中的条目调整可以随时查看与回滚；附件存档和预览让部署包说明、运维手册等材料无需下载即可在线查看。对于需要控制查阅范围的项目，还可以为移交方、接收方等角色配置不同的读写权限。清单的签认状态是否形成流转记录，需按组织实际使用的工具能力确认。
清单的调整与维护方法
清单在项目间复用时，先按项目类型裁剪条目，再固定版本，最后归档。三步分别对应填写前、填写中、移交后三个阶段。
按项目类型裁剪。保留六大类别骨架，删除与接收方工作无关的选填行，把项目特征相关的选填项升级为必填。裁剪结果记录在清单开头的“适用说明”中，写明本项目删除了哪些条目、原因是什么，便于后续项目参考。
版本与变更记录。清单在移交过程中会多次修改，建议在表格下方维护一张变更记录表，字段为版本号、修改日期、修改人、修改内容。版本号从 V1.0 起，条目增删或内容要求变化时升小版本，签认完成后冻结为终版。使用文档工具承载时，页面版本记录可以作为变更记录的补充，但变更原因仍应写在清单内。
归档与后续查阅。签认完成后，将终版清单、附件材料与签认记录一并归档到项目知识库，按项目名称和移交日期命名。归档位置应在项目结项说明中注明，方便后续接手人、审计或复盘时检索。若项目在移交后仍有遗留事项，在归档清单中标注跟踪链接，待遗留事项关闭后再补充关闭记录。
维护清单模板本身时，建议每完成若干次移交后回顾一次：哪些条目反复留空、哪些内容要求表述不清、哪些必填项实际未被使用。把回顾结论写回模板，模板才能逐步贴合组织的移交习惯。
常见问题
项目移交清单和单次软件交付验收单有什么区别？
两者关注的对象不同。移交清单面向项目整体生命周期结束或负责人转换，处理的是范围、资产、权限、文档、遗留事项和签认，接收方接手的是后续运营或延续工作。交付验收单面向一次具体的软件交付，核心是验收标准是否达成、缺陷是否关闭、追溯记录是否完整。
如果项目以一次软件交付作为结束节点，两份文件可以同时存在：验收单确认交付物合格，移交清单确认后续责任和资料完成交接。把验收标准逐条塞进移交清单，会让清单变得臃肿，也不便于签认。
移交过程中条目状态一直停在“待确认”，应该怎么处理？
“待确认”表示移交方已交付、接收方尚未回复。处理时先看该行的内容要求是否写清了完成标准：标准模糊时，接收方无法判断是否可以确认，需要补充具体形态，例如账号要含角色与有效期、文档要覆盖哪些故障场景。
标准清楚但仍未确认的，在备注列写明待确认的具体问题和约定回复时间，并在移交例会上逐条过。签认前应确保没有条目停留在“待确认”，否则签认记录与实际交接状态不一致。
小型项目或短期项目也要用完整六类清单吗？
六类骨架建议保留，行数可以压缩。小型项目通常每类一到两行即可，重点是范围边界、交付物位置、遗留事项和签认四项。涉及系统账号的，权限交接不能省；纯线下、无系统依赖的项目，账号权限类条目可以删除。
裁剪的原则是必填集合只增不减，选填项按项目特征升级为必填。裁剪结果写在清单开头的适用说明里，注明删了哪些条目和原因，后续同类项目可以直接参考。
移交清单放在文档工具里维护，签认还有效吗？
文档工具可以承载清单条目、附件材料和版本记录，签认是否有效取决于组织对签认形式的规定。常见做法是清单在文档中协作填写，签认环节打印签字、使用电子签章，或在审批流程中留痕。
使用 ONES Wiki 时，页面版本记录可以作为变更过程的补充，附件存档和预览便于接收方在线查看部署说明与运维手册，读写权限可以按移交方、接收方区分。签认状态能否形成可流转的确认记录，需要按组织实际使用的工具能力确认。
移交完成后发现清单漏了条目，还能补吗？
可以补，但要留下记录。做法是在原清单上新增条目，在变更记录表中登记版本号、修改日期、修改人和修改内容，并注明该条目属于移交后补充。涉及责任或权限的补充条目，仍需原移交方与接收方确认。
如果项目已归档，补充条目应关联到归档清单并标注跟踪链接，待事项关闭后补充关闭记录。这样后续接手人、审计或复盘时能看到完整的交接轨迹，而不是一份被悄悄改过的清单。
