任务交接清单要解决的是“交什么、交给谁、何时交、怎么确认”四个问题。一份可用的清单通常包含任务基本信息、交接双方与时间、当前进度与已完成成果、待办事项与下一步动作、文件与权限移交、风险与依赖、接收确认七个信息块。本文提供可直接复制的空白表格，并说明每个字段的填写口径、必填与选填的取舍，以及如何按团队情况调整维护。
要点总览（TL;DR）
- 任务交接清单围绕“交什么、交给谁、何时交、怎么确认”组织，包含任务基本信息、交接双方与时间、进度与成果、待办与下一步、文件与权限移交、风险与依赖、接收确认七个信息块。
- 必填字段的判断标准是：缺少后接收人无法独立推进任务，或事后无法界定责任；任务标识、交接双方、交接时间、进度成果、待办事项、文件入口和接收确认属于必填。
- 填写时写事实、写位置、写责任人，避免“进展顺利”“基本完成”这类无法核验的描述；进度与成果要能互相印证，待办事项与未完成部分要一一对应。
- 清单可按任务类型裁剪选填项，必填项只增不减；用版本号和生效日期管理调整，交接完成后原记录不再修改，补充内容以附页追加。
- 交接记录需要与任务长期关联时，可放入支持文档关联项目任务、页面版本记录与角色权限配置的文档工具中留存。
可复制空白任务交接清单模板
下表按七个信息块组织，可直接复制到文档或表格工具中逐行填写。每一行对应一个字段，填写时保留字段名，在“填写内容”列写入具体信息；不适用的字段写明“不适用”及原因，避免留空造成歧义。
| 信息块 | 字段 | 填写内容 |
|---|---|---|
| 任务基本信息 | 任务名称 | |
| 任务编号 / 工作项链接 | ||
| 所属项目 / 所属模块 | ||
| 任务目标与验收标准 | ||
| 计划完成时间 | ||
| 交接双方与时间 | 原负责人 | |
| 接收人 | ||
| 交接原因 | ||
| 交接生效时间 | ||
| 进度与成果 | 当前进度 | |
| 已完成成果及存放位置 | ||
| 未完成部分说明 | ||
| 待办与下一步 | 待办事项清单 | |
| 下一步动作与建议顺序 | ||
| 关键时间节点 | ||
| 文件与权限移交 | 相关文件与链接 | |
| 账号与系统权限 | ||
| 对接人与外部联系人 | ||
| 风险与依赖 | 已知风险 | |
| 外部依赖 | ||
| 待决问题 | ||
| 接收确认 | 接收人确认意见 | |
| 异议与补充说明 | ||
| 原负责人签字 / 确认时间 | ||
| 接收人签字 / 确认时间 |
表格填写完成后，交接双方各保留一份，并在项目文档中归档一份。归档位置应写进“相关文件与链接”字段，方便后续追溯时直接定位。
每个字段填什么：清单字段说明
字段说明解决的是“填到什么程度算合格”。同一字段在不同任务类型下详略可以不同，但口径要一致：写事实、写位置、写责任人，避免写“进展顺利”“基本完成”这类无法核验的描述。
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 任务名称 | 被交接任务的简短标识 | 一句话说清做什么，与工作项标题保持一致 |
| 任务编号 / 工作项链接 | 任务在系统中的唯一位置 | 填编号或可点击链接，确保接收人能直接打开 |
| 任务目标与验收标准 | 任务完成的判定依据 | 写可检查的结果，如“输出评审通过的方案文档” |
| 交接原因 | 为什么发生这次交接 | 写客观原因，如人员调整、休假、职责变更 |
| 交接生效时间 | 责任转移的时点 | 精确到日期，跨时区协作时注明时区 |
| 当前进度 | 任务此刻处于哪个阶段 | 用阶段或百分比描述状态，如“开发完成，待测试” |
| 已完成成果及存放位置 | 已经产出的可交付物 | 逐项列出成果名称和所在目录或链接 |
| 未完成部分说明 | 剩余工作的范围 | 说明缺什么、缺多少，与待办事项对应 |
| 待办事项清单 | 接收人需要执行的具体动作 | 每条以动词开头，标注责任人与截止时间 |
| 下一步动作与建议顺序 | 先做什么后做什么 | 给出优先级理由，如“先确认需求再开发” |
| 相关文件与链接 | 完成任务所需的资料入口 | 按用途分组，标注文档用途和最后更新时间 |
| 账号与系统权限 | 接收人需要开通的访问权限 | 写明系统名称、权限类型、申请方式 |
| 已知风险 | 可能影响任务完成的问题 | 写风险描述、影响范围和当前应对措施 |
| 外部依赖 | 任务依赖的其他团队或外部方 | 写依赖对象、依赖内容和约定时间 |
| 待决问题 | 尚未有结论、需要决策的事项 | 写问题、待决策人和期望决策时间 |
| 接收确认意见 | 接收人对交接内容的表态 | 明确写“已了解”或列出需要补充的内容 |
容易混淆的是“当前进度”和“已完成成果”。前者描述状态，回答任务走到哪一步；后者描述产出，回答已经交付了什么。两者要能互相印证：进度写“开发完成”，成果就应列出对应的代码分支或构建产物。同样，“待办事项”与“未完成部分”是一组对应关系，未完成部分说明缺口范围，待办事项把缺口拆成可执行的动作。
字段之间还存在引用关系：待办事项的责任人应与接收人一致或明确转交他人；风险与依赖中提到的外部联系人应出现在“对接人与外部联系人”字段；验收标准决定待办事项写到什么程度算完成。填写时先写任务基本信息和进度成果，再据此推导待办与风险，最后完成确认区，顺序上更不容易遗漏。
必填与选填：哪些信息不能省
必填的判断依据是：缺少该字段会导致接收人无法独立推进任务，或事后无法界定责任。按这个标准，任务标识、交接双方、交接时间、进度成果、待办事项、文件入口和接收确认属于必填；描述性、辅助性的信息可以按任务复杂度选填。
| 类别 | 字段 | 说明 |
|---|---|---|
| 必填 | 任务名称、任务编号或链接 | 没有标识就无法定位任务 |
| 必填 | 原负责人、接收人、交接生效时间 | 责任转移的主体和时点 |
| 必填 | 当前进度、已完成成果及存放位置 | 接收人判断起点的依据 |
| 必填 | 待办事项清单 | 交接后的行动依据 |
| 必填 | 相关文件与链接 | 没有入口则任务无法继续 |
| 必填 | 接收确认意见、双方确认时间 | 责任交接完成的凭证 |
| 选填 | 任务目标与验收标准 | 任务简单或标准已在工作项中写明时可引用链接 |
| 选填 | 交接原因 | 例行轮岗等无争议场景可简写 |
| 选填 | 下一步动作与建议顺序 | 待办事项已含优先级时可省略 |
| 选填 | 账号与系统权限 | 接收人已有同等权限时写“已有权限” |
| 选填 | 已知风险、外部依赖、待决问题 | 无风险时写“无”，有则必须填写 |
| 选填 | 对接人与外部联系人 | 纯内部独立任务可不填 |
缺项时的处理方式分三种：确实不适用的字段写“不适用”并注明原因；暂时无法获取的信息写“待补充”，同时指定补充责任人和补充时间；必填项缺失时，交接不应视为完成，接收人可在确认意见中列为异议，待补齐后再签字。风险类字段即使选填，只要存在已知风险就必须填写，这是选填中的例外。
填写示例：一次完整的任务交接
以下为演示情景，用于说明填写方式，不代表真实项目。背景：某产品团队的原负责人因岗位调整，将“客户反馈后台改版”任务移交给同事，任务处于开发完成、待测试阶段。
| 字段 | 填写内容 |
|---|---|
| 任务名称 | 客户反馈后台列表页改版 |
| 任务编号 / 工作项链接 | PRD-2317（附工作项链接） |
| 所属项目 / 所属模块 | 客户反馈系统 / 后台管理端 |
| 任务目标与验收标准 | 列表页支持按状态筛选与批量处理，通过测试用例评审并上线灰度 |
| 计划完成时间 | 本季度末 |
| 原负责人 | 甲（产品经理） |
| 接收人 | 乙（产品经理） |
| 交接原因 | 原负责人岗位调整 |
| 交接生效时间 | 下周一 |
| 当前进度 | 开发完成，待测试 |
| 已完成成果及存放位置 | 需求文档 v2（项目文档库）、交互稿（设计目录）、开发分支 feature/list-revamp |
| 未完成部分说明 | 测试未开始，灰度方案未定，上线公告未写 |
| 待办事项清单 | 1. 组织测试用例评审（乙，本周内）；2. 确认灰度范围（乙+运维，下周）；3. 撰写上线公告（乙，上线前三天） |
| 下一步动作与建议顺序 | 先评审测试用例，再定灰度方案，最后准备公告，避免公告内容与灰度范围不一致 |
| 关键时间节点 | 测试评审本周五，灰度下周，上线本季度末 |
| 相关文件与链接 | 需求文档、交互稿、测试计划草稿、历史评审记录（均附链接） |
| 账号与系统权限 | 测试环境后台账号需申请，申请方式见运维流程文档 |
| 对接人与外部联系人 | 测试负责人丙，运维负责人丁 |
| 已知风险 | 测试资源紧张，可能推迟一周；影响范围为上线时间 |
| 外部依赖 | 依赖运维提供灰度环境，约定下周初交付 |
| 待决问题 | 灰度比例是否包含全部客户，待产品负责人决策 |
| 接收确认意见 | 已了解，需补充测试计划草稿的最新版本 |
| 异议与补充说明 | 测试计划草稿版本待原负责人确认后补充 |
| 原负责人签字 / 确认时间 | 甲 / 交接当日 |
| 接收人签字 / 确认时间 | 乙 / 补充材料收到后确认 |
这份示例的填写理由在于：进度写状态、成果写位置，两者互相印证；待办事项逐条带责任人和时间，接收人不需要再追问；风险与依赖写明了影响范围和约定时间，便于判断是否需要升级处理；确认区保留了异议，说明交接在材料补齐后才真正完成。字段与空白模板一一对应，没有新增或省略信息块。
当交接记录需要长期留存并和任务本身保持关联时，可以把清单作为项目文档管理。ONES Wiki 支持文档关联项目任务，文档实时同步并记录页面版本，可随时查看与回滚；同时支持为不同角色配置读写权限。这样交接清单的修改过程有版本可查，接收人和相关角色按权限访问，责任确认的记录也能随任务一起保留。
调整与维护：让清单适配团队并持续可用
清单要在团队里长期使用，需要解决三个问题：字段是否贴合任务类型、版本是否可追溯、内容是否定期复核。调整原则是“必填项只增不减，选填项按需裁剪”：任何调整都不能删掉任务标识、交接双方、进度成果、待办事项和接收确认这几类信息，否则清单失去责任界定作用。
不同任务类型的裁剪方式可以参照下表：
| 任务类型 | 建议保留 | 可简化 |
|---|---|---|
| 日常运营类任务 | 基本信息、进度成果、待办、确认 | 风险与依赖可写“无”，权限字段可省略 |
| 跨团队协作任务 | 全部信息块，重点写对接人与外部依赖 | 无 |
| 长期项目中的子任务 | 基本信息、进度成果、待办、风险 | 验收标准可引用项目级文档链接 |
| 紧急临时交接 | 任务标识、双方、进度、待办、确认 | 原因、建议顺序可口头补充后补录 |
版本管理上，建议在清单文件名或文档标题中标注版本号和生效日期，例如“任务交接清单 v1.2（2025-06 生效）”。每次调整字段后保留变更说明，写清增删了哪个字段、原因是什么。归档时按任务或项目存放，交接完成后不再修改原记录，后续补充以附页形式追加，保证原始确认内容不被覆盖。使用 ONES Wiki 的模板库可以一键创建清单文档，页面版本记录让每次调整都有据可查。
定期复核建议按季度或按项目阶段进行：收集团队填写中反复留空或反复追问的字段，判断是字段设计问题还是填写习惯问题；检查归档的清单是否能在需要时快速找到；对照实际发生的责任争议，看清单是否遗漏了关键信息。复核结论落到下一版清单中，形成“使用—反馈—修订—再使用”的循环，清单才能持续可用。
常见问题
交接时任务还没到可交付状态，清单还要填“已完成成果”吗？
要填。已完成成果指当前已经产出的可交付物，不要求任务整体完成。开发中的任务可以列出已确认的需求文档、已合并的代码分支、已完成的测试用例等，并注明各自所在位置。如果确实还没有任何产出，写“暂无”并说明当前处于哪个阶段，同时把即将产出的第一项成果写进待办事项。
接收人签字后发现清单漏了关键信息，怎么处理？
交接完成后原记录不再修改，补充内容以附页形式追加，并注明补充日期和补充人。如果遗漏的信息影响任务推进，由接收人在附页中列出缺口，原负责人在约定时间内补齐；涉及责任界定的重大遗漏，可由双方在附页上再次确认。这样既保留了原始确认记录，也让补充过程可追溯。
紧急交接来不及填完整清单，哪些字段可以先口头交代？
紧急场景下优先保证任务标识、交接双方、当前进度、待办事项和接收确认五项，其余字段可以口头补充后补录。口头交代的内容应在当天或次日写入清单，尤其是风险、外部依赖和待决问题，避免时间一长无人记得。补录时在清单中注明“口头交接后补录”，便于区分信息形成的时间。
同一项任务多人协作，交接清单要每人一份吗？
按任务出一份清单即可，在“原负责人”和“接收人”字段中写清主责人，其他协作者在待办事项或对接人字段中体现。如果任务被拆给多个接收人，建议按子任务分别出清单，每份清单对应一个明确的责任主体，避免一份清单上出现多个接收人却无人对整体结果负责。
清单归档在哪里，后续追溯时才能快速找到？
归档位置应写进“相关文件与链接”字段，与任务本身放在一起，按任务或项目存放，文件名包含任务名称和交接日期。使用支持文档关联项目任务的工具时，清单可以直接挂在对应工作项下，页面版本记录保留每次修改，接收人和相关角色按权限访问。这样追溯时从任务就能定位到交接记录，不需要在多个目录中查找。
