任务交接单用一张表记录交接全过程，通常包含六类字段：表头标识、任务现状、待办与遗留、风险、附件与权限、三方确认。模板按必填与选填分层，必填项缺失时交接不成立。本文交付一张可直接复制到文档或表格工具中的空白交接单，并说明每个字段写什么、哪些必须填、如何按团队情况裁剪。适用范围是单项任务的责任交接，不涉及组织角色分工与人力调配。
要点总览（TL;DR）
- 任务交接单以一张表覆盖六类字段：表头标识、任务现状、待办与遗留、风险、附件与权限、三方确认。
- 必填字段围绕责任归属与后续执行确定，包括任务名称、任务编号、当前状态、原负责人、新负责人、交接日期、待办事项和接收确认；缺失时先补齐再签署，或由确认人注明例外。
- 待办事项一条一行，写清动作、对象和截止时间；遗留问题写清现状与卡点；风险描述可观察事实、影响范围和应对措施。
- 交接单由交接人、接收人和确认人三方签署，签署完成作为交接成立的时点。
- 模板按任务类型裁剪字段，新增字段以是否影响责任归属或后续执行为判断标准，并做好编号、归档与交接后复查。
可复制的任务交接单空白模板
下表可直接复制到文档或表格工具中，按行填写。左列为区块，中列为字段名，右列留白供填写。区块顺序对应交接的实际动作：先确认交的是什么任务、由谁交给谁，再交代任务当前状态，然后列出未完成事项和风险，最后登记附件并由三方签署。
| 区块 | 字段名 | 填写位置 |
|---|---|---|
| 表头 | 交接单编号 | |
| 任务名称 | ||
| 任务编号 | ||
| 所属项目 | ||
| 交接日期 | ||
| 任务现状 | 当前状态 | |
| 完成进度 | ||
| 原负责人 | ||
| 新负责人 | ||
| 交接原因 | ||
| 待办与遗留 | 待办事项 | |
| 遗留问题 | ||
| 下一步动作 | ||
| 截止时间 | ||
| 风险 | 风险描述 | |
| 影响范围 | ||
| 应对措施 | ||
| 关注人 | ||
| 附件与权限 | 相关文档 | |
| 权限与账号 | ||
| 其他附件 | ||
| 确认 | 交接人签字 | |
| 接收人签字 | ||
| 确认人签字 | ||
| 签署日期 |
待办事项、遗留问题和风险三类内容往往不止一条，填写时在单元格内一条一行，或另附明细表并以交接单编号关联。模板本身只规定字段，不限制行数。
每个字段记录什么：字段说明与填写口径
字段名相同，写法差别很大，交接质量取决于颗粒度。下表逐字段说明含义与填写口径，与上一节模板逐一对应。
| 字段名 | 记录什么 | 填写口径 |
|---|---|---|
| 交接单编号 | 本次交接的唯一标识 | 按团队编号规则生成，全团队不重复，便于检索和归档 |
| 任务名称 | 被交接任务的名称 | 写可检索的完整名称，避免“那个需求”“上次说的功能”这类指代 |
| 任务编号 | 任务在工作项或项目中的编号 | 照抄系统中的编号，保证交接单能对应到具体工作项 |
| 所属项目 | 任务归属的项目或产品线 | 写项目全称；跨项目任务注明主责项目 |
| 交接日期 | 交接生效的日期 | 写实际生效日，与签字日期区分 |
| 当前状态 | 任务在交接时点的状态 | 使用团队统一的状态取值，如未开始、进行中、待评审、阻塞、已完成 |
| 完成进度 | 任务已完成的比例或所处阶段 | 用百分比或阶段描述，二者选一并在团队内统一 |
| 原负责人 | 交接前对任务负责的人 | 写姓名与所在团队，便于接收人追溯 |
| 新负责人 | 交接后对任务负责的人 | 写姓名，并注明责任生效时间 |
| 交接原因 | 为什么发生这次交接 | 写事实，如人员调岗、项目转交、休假代理 |
| 待办事项 | 接收人需要继续完成的事 | 一条一行，每条以动词开头，写清对象和完成标准 |
| 遗留问题 | 交接时尚未解决的问题 | 一条一行，写清问题现状、已尝试的处理和卡点 |
| 下一步动作 | 接收人接手后的第一个动作 | 与待办事项对应，写明先做什么、找谁 |
| 截止时间 | 待办与下一步动作的时间要求 | 写具体日期；无明确期限的写“待确认”并注明确认人 |
| 风险描述 | 可能影响任务完成的事项 | 描述可观察的事实，如依赖方延期、资源未到位，不写“有风险”这类空泛判断 |
| 影响范围 | 风险波及的任务、里程碑或团队 | 写具体对象和影响方式 |
| 应对措施 | 已采取或计划采取的动作 | 写动作、责任人和时间，与风险逐条对应 |
| 关注人 | 需要知悉风险的人 | 写姓名与角色，便于接收人判断向谁同步 |
| 相关文档 | 任务相关的需求、设计、会议记录等 | 登记文档名称与存放位置，确保接收人能打开 |
| 权限与账号 | 接收人需要开通或移交的权限 | 逐项列出系统、权限级别和办理人 |
| 其他附件 | 无法归入上述类别的材料 | 登记名称与位置，避免口头传递 |
| 交接人签字 | 交出方对内容真实完整负责 | 签字即确认所列状态、待办和风险与实际一致 |
| 接收人签字 | 接收方对已理解并接手负责 | 签字前应逐条核对待办与遗留问题 |
| 确认人签字 | 第三方对交接成立负责 | 通常由直属上级或项目负责人签署，处理例外情况 |
| 签署日期 | 三方签署的时间 | 与交接日期不一致时，以签署完成作为交接成立时点 |
填写中最常见的偏差是只写任务名称不写状态，接收人无法判断从哪一步接手。另一个偏差是待办事项写成一句概括，如“继续推进需求”，接收人仍需重新梳理。把每条待办写成可执行的动作，交接单才具备执行价值。
必填与选填怎么划分
划分依据只有一条：缺了这项，责任归属或后续执行是否受影响。受影响列为必填，否则列为选填。按此标准，必填字段覆盖“交的是什么、现在什么状态、由谁交给谁、接下来做什么、谁确认接手”五个问题。
| 类别 | 字段 | 说明 |
|---|---|---|
| 必填 | 任务名称 | 缺失则交接对象不明 |
| 必填 | 任务编号 | 缺失则无法对应到具体工作项 |
| 必填 | 当前状态 | 缺失则接收人无法判断接手起点 |
| 必填 | 原负责人 | 缺失则责任来源不清 |
| 必填 | 新负责人 | 缺失则责任承接不清 |
| 必填 | 交接日期 | 缺失则责任生效时点不清 |
| 必填 | 待办事项 | 缺失则接收人无执行依据 |
| 必填 | 接收确认 | 缺失则交接未成立 |
| 选填 | 所属项目 | 任务编号已能定位时可省略 |
| 选填 | 完成进度 | 状态已能说明阶段时可省略 |
| 选填 | 风险描述 | 无风险时填“无”，不强制展开 |
| 选填 | 相关文档 | 无独立文档时可省略 |
| 选填 | 关注人 | 无特定知悉对象时可省略 |
必填项缺失时有两种处理方式：一是补齐后再签署，这是默认做法；二是由确认人注明例外，写清缺失原因和补交时间，并在交接单上留痕。例外不应成为常态，同一团队反复出现同类例外，说明字段设置或流程需要调整。
选填不等于可以不写。风险描述在无风险时填“无”，比留空更能说明交接人已做过判断；留空容易被理解为未检查。
填写示例：一次完整的任务交接
以下示例为演示情景：一项进行中的接口改造任务由A交接给B，因A调往其他项目组。示例展示各字段的实际写法和颗粒度，字段与前述模板、说明保持一致。
| 区块 | 字段名 | 填写内容 |
|---|---|---|
| 表头 | 交接单编号 | HO-2024-031 |
| 任务名称 | 订单接口改造：支持批量查询 | |
| 任务编号 | ORD-1182 | |
| 所属项目 | 订单中心二期 | |
| 交接日期 | 2024年6月3日 | |
| 任务现状 | 当前状态 | 进行中 |
| 完成进度 | 60%，接口开发完成，联调未开始 | |
| 原负责人 | A（订单组） | |
| 新负责人 | B（订单组），自2024年6月3日起生效 | |
| 交接原因 | 原负责人调往供应链项目组 | |
| 待办与遗留 | 待办事项 | 1. 与支付组完成批量查询联调，6月10日前完成 2. 补充批量场景的性能测试报告，6月14日前提交 3. 更新接口文档中的分页参数说明，6月7日前完成 |
| 遗留问题 | 1. 单次查询超过500条时响应超时，已定位到数据库索引缺失，修复方案待评审 2. 测试环境数据量与生产不一致，压测结果需在生产影子库复核 |
|
| 下一步动作 | 先约支付组确认联调时间，再推动索引修复方案评审 | |
| 截止时间 | 联调6月10日；性能报告6月14日；文档更新6月7日 | |
| 风险 | 风险描述 | 支付组同期有两个版本上线，联调窗口可能推迟 |
| 影响范围 | 影响订单中心二期6月20日的提测节点 | |
| 应对措施 | B于6月4日前与支付组负责人确认联调排期；若推迟超过三天，上报项目负责人调整提测计划 | |
| 关注人 | 项目负责人C、支付组负责人D | |
| 附件与权限 | 相关文档 | 接口设计说明v1.2（项目文档库/订单中心二期/设计）；联调记录（同上/联调） |
| 权限与账号 | 测试环境订单服务部署权限，由运维E办理；生产影子库只读账号，由DBA F办理 | |
| 其他附件 | 6月1日联调问题清单 | |
| 确认 | 交接人签字 | A，2024年6月3日 |
| 接收人签字 | B，2024年6月3日 | |
| 确认人签字 | C，2024年6月4日 | |
| 签署日期 | 2024年6月4日 |
示例中待办事项每条都带动作、对象和日期，遗留问题写清了现状和卡点，风险写的是可观察的排期冲突而非笼统判断。接收人据此可以直接安排第一周的工作，确认人也能判断是否需要提前介入。
若团队使用 ONES，交接单可作为文档存放在项目页面下，通过文档关联项目任务，把任务进度嵌入交接单，使单据中的状态与工作项保持一致；页面版本记录便于回看交接时的原始内容。负责人变更、状态流转和待办跟踪仍在工作项中完成，交接单承担的是责任确认和过程留痕。
模板的调整与维护方法
模板需要在长期使用中裁剪和复查，否则字段会越加越多，填写负担上升而信息价值下降。调整围绕三件事：按任务类型保留字段、控制新增字段、管理版本与归档。
按任务类型裁剪字段
| 任务类型 | 建议保留字段 | 可简化或省略 |
|---|---|---|
| 常规任务 | 表头、当前状态、原/新负责人、待办事项、接收确认 | 风险描述填“无”即可；关注人可省略 |
| 跨团队任务 | 在常规字段基础上保留风险、影响范围、关注人、权限与账号 | 完成进度可用阶段描述替代百分比 |
| 长期任务 | 在跨团队字段基础上保留遗留问题、相关文档、下一步动作与截止时间 | 无 |
裁剪的原则是保留与责任和后续执行直接相关的字段，删减只影响描述完整度的字段。跨团队任务涉及多方依赖，风险和权限字段必须保留；长期任务的遗留问题往往跨越多次交接，需要完整记录。
新增字段的判断标准
新增字段前先问两个问题：缺了这项，是否会导致责任归属不清或后续执行受阻？现有字段能否通过调整填写口径覆盖这一信息？只有第一个问题答案为“是”、第二个答案为“否”时才新增。新增字段同步更新字段说明和必填清单，避免模板与说明脱节。
版本与归档
交接单编号按团队约定生成，建议包含年份和流水号，便于按时间检索。归档位置与任务文档放在一起，接收人和确认人都能访问。保留期限按项目周期和合规要求设定，项目结项后至少保留到复盘完成。模板本身也应记录版本，字段调整时注明变更内容和生效日期，旧单据按原版本理解。
定期复查
交接完成后两到四周，由接收人或确认人回看一次：待办事项是否按截止时间推进，遗留问题是否已闭环，风险是否发生及应对是否有效。复查结果不必另建表单，直接在原交接单上标注状态即可。连续几次复查发现同类待办反复延期，说明交接时的颗粒度或排期需要调整，这比增加字段更能改善交接质量。
常见问题
任务交接单必须三方签字吗？只有交接人和接收人确认可以吗？
三方签署的作用不同：交接人对所列状态、待办和风险的真实完整负责，接收人确认已理解并接手，确认人通常由直属上级或项目负责人担任，负责处理例外情况。两人签署在常规任务中也能完成责任转移，但遇到必填项缺失、交接原因特殊或双方对任务状态理解不一致时，缺少第三方容易留下争议。团队可以按任务重要程度决定是否设置确认人，跨团队任务和长期任务建议保留。
交接单里的待办事项和遗留问题有什么区别，能合并写吗？
待办事项是接收人接手后需要继续完成的事，写法以动词开头，带对象和完成标准；遗留问题是交接时尚未解决的问题，重点写现状、已尝试的处理和卡点。两者合并会让接收人分不清哪些是计划内工作、哪些是尚未解决的障碍。实际操作中可以放在同一区块，但分行分列记录，遗留问题解决后再转为待办或标注闭环。
交接单填完后放在哪里，后续怎么跟踪待办是否完成？
交接单归档位置应与任务文档放在一起，接收人和确认人都能访问，编号包含年份和流水号便于检索。待办跟踪不必依赖交接单本身：若团队使用 ONES，可把交接单作为文档存放在项目页面下，通过文档关联项目任务并嵌入任务进度，使单据中的状态与工作项保持一致，负责人变更和待办推进仍在工作项中完成。交接后两到四周回看一次，在原交接单上标注待办和遗留问题的状态即可。
小团队任务量不大，也需要完整的交接单吗？
可以裁剪。常规任务保留表头、当前状态、原负责人与新负责人、待办事项和接收确认即可，风险描述无风险时填“无”，关注人和权限字段可省略。裁剪的原则是保留与责任归属和后续执行直接相关的字段，删减只影响描述完整度的字段。任务量小、交接双方坐在一起沟通充分的团队，交接单更多起留痕作用，字段可以精简，但任务编号和接收确认建议保留。
交接单模板用久了字段越来越多，怎么控制？
新增字段前先判断两件事：缺了这项是否会导致责任归属不清或后续执行受阻，现有字段能否通过调整填写口径覆盖这一信息。只有前者为“是”、后者为“否”时才新增。同时同步更新字段说明和必填清单，模板记录版本和变更生效日期。定期复查中若发现同类待办反复延期，优先调整交接时的颗粒度和排期，而不是继续加字段。
