任务交接要明确责任和交付要求，关键做法是把口头说明变成一份可核对的交接记录：写清交接前后的责任人、交付物及验收标准、截止时间、依赖与未决事项，由接收方确认、双方与负责人共同确认后生效。本文适用于单项任务在两个人之间转移的场景，给出一套可直接套用的字段、步骤、角色分工和完成检查清单。
要点总览（TL;DR）
- 把交接从口头说明变成可核对的交接记录，写清交出方、接收方、最终责任人、交付物与验收标准、截止时间、依赖与未决事项。
- 交接按发起、准备材料、接收方核对、负责人确认、生效与旧责任人退出、设置确认期六步执行，以接收方确认和负责人审批作为生效标志。
- 执行责任随生效时间切换，信息责任保留到确认期结束；交接记录由接收方维护，负责人保留最终确认权。
- 验收标准要写到可检查、可测试，例如通过某组测试用例或评审无阻断意见，避免“完成开发”“文档齐全”这类无法判断的表述。
- 用完成检查清单逐项核对字段完整性、责任唯一性、交付要求可验证性和确认留痕，阻断项未闭环不进入生效状态。
一份交接记录要写清哪些字段
交接记录的作用是让接手的人知道“要做什么、做到什么程度算完成、出了问题找谁”。字段不必多，但每一项都要能核对。下面这张表可以作为模板直接填写。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 交接对象与任务标识 | 写明任务名称、所属项目、工作项编号或文档链接，确保双方指向同一件事 | “订单导出功能开发”，需求单 REQ-2317 |
| 交出方 | 填写姓名与角色，注明其对交接前工作成果负责 | 张明，后端开发 |
| 接收方 | 填写姓名与角色，注明其确认后承担后续执行责任 | 李华，后端开发 |
| 最终责任人 | 对任务结果负责的人，通常是任务负责人或主管；接收方与最终责任人可以是同一人，也可以不同，但必须写明 | 王强，研发组长 |
| 交付物清单 | 逐项列出需要交付的成果，包括代码、文档、数据、账号权限、外部联系人等 | 功能代码分支、接口文档、测试环境账号 |
| 验收标准 | 每项交付物写清“怎样算合格”，尽量用可观察、可测试的条件描述 | 接口在测试环境返回 200 且字段完整；文档覆盖全部入参与异常码 |
| 截止时间与关键节点 | 写明最终截止时间和中间节点，注明时间口径（自然日或工作日） | 联调完成 3 月 12 日，上线 3 月 20 日 |
| 依赖与风险 | 列出依赖的外部团队、系统、数据，以及已知风险和应对方式 | 依赖支付团队提供回调地址；风险为测试数据不足 |
| 未决事项 | 列出尚未决定或尚未解决的问题，写明当前状态和下一步动作 | 导出字段是否含手机号待产品确认，3 月 10 日前答复 |
| 生效条件与确认方式 | 写明交接在什么条件下生效，由谁以什么方式确认 | 接收方书面确认、负责人审批后生效，记录留存在任务下 |
填写时有两个常见疏漏值得注意。一是把“交出方”和“最终责任人”混为一谈，导致交接后无人对结果负责；二是验收标准写成“完成开发”“文档齐全”这类无法判断的表述，接收方无从核对，分歧往往由此产生。验收标准应尽量落到可检查的动作或结果上，例如“通过某组测试用例”“评审会上无阻断意见”。
交接怎么走：从发起到确认的操作步骤
交接不是一次口头交代，而是一个有起点、有确认、有退出机制的短流程。下面六步可以作为标准动作执行。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 发起交接 | 交接原因（人员变动、任务转派、阶段移交） | 交出方或负责人提出交接，明确交接范围与期望生效时间 | 交接事项与时间要求 | 接收方与负责人知悉并同意接手 |
| 2. 准备交接材料 | 任务当前进展、已有成果、相关文档 | 交出方按字段表整理交接记录，附上交付物位置和访问方式 | 填写完整的交接记录草稿 | 字段无空缺，交付物可访问 |
| 3. 接收方核对与提问 | 交接记录草稿 | 接收方逐项核对交付物和验收标准，对不清楚的地方提出书面问题 | 问题清单与补充说明 | 所有问题得到答复或转为未决事项 |
| 4. 负责人确认 | 修订后的交接记录 | 任务负责人或主管审核责任划分、验收标准和未决事项处理安排 | 确认意见 | 负责人明确同意或提出修改要求并闭环 |
| 5. 交接生效与旧责任人退出 | 已确认的交接记录 | 记录状态更新为生效，任务责任人变更为接收方，交出方退出日常执行 | 生效的交接记录与更新后的任务责任人 | 系统中责任人已变更，交出方不再被默认指派 |
| 6. 设置确认期 | 生效记录 | 约定一段确认期（如 3 至 5 个工作日），期间接收方可就历史信息向交出方提问，交出方有义务答复 | 确认期内的问答记录 | 确认期结束且无未答复问题 |
确认期的意义在于给“信息转移是否真的完成”留出验证窗口。确认期内发现遗漏，按未决事项补充记录，不必推翻整份交接；确认期结束后再出现的问题，原则上由接收方按新任务处理，需要追溯历史信息时另行沟通。确认期长度按任务复杂度设定，简单任务可以缩短，跨系统、跨团队的任务适当延长。
交接双方与负责人各承担什么
责任悬空通常源于角色边界不清：交出方以为交完就没事，接收方以为只是“先看着”，负责人以为双方已经谈妥。用一张对照表把每个角色在交接前后的职责和交付物固定下来，可以避免这类情况。
| 角色 | 交接前职责 | 交接后职责 | 主要交付物 |
|---|---|---|---|
| 交出方 | 对已完成的成果质量负责；整理并如实提供进展、文档、依赖和风险 | 在确认期内答复接收方关于历史信息的提问；对交接时隐瞒或遗漏的关键信息承担责任 | 交接记录中的交付物与说明、确认期内的答复 |
| 接收方 | 核对交接材料，提出疑问，确认自己有能力按验收标准完成 | 对交接生效后的执行结果负责；主动跟进未决事项 | 确认意见、问题清单、后续执行计划 |
| 任务负责人或主管 | 判断交接时机是否合适，指定接收方 | 确认责任划分与验收标准；对双方分歧作出裁定；跟踪未决事项闭环 | 确认意见、裁定结论 |
交接期间出现责任重叠是正常现象，处理原则是“执行责任随生效时间切换，信息责任保留到确认期结束”。也就是说，交接生效后由接收方执行并承担结果，但交出方在确认期内仍需对历史信息的准确性负责。交接记录由接收方维护日常更新，负责人保留最终确认权；记录存放在任务或项目统一位置，避免散落在个人聊天记录中。
当交接涉及多人协作时，可以在任务管理工具中把上述动作固定下来：交接记录作为任务下的一份文档，责任人变更直接体现在工作项上，确认意见和确认期问答留痕在同一处。ONES 的工作项与文档可以承载这类记录和状态变更，让“谁在什么时候确认了什么”可追溯，减少交接后靠回忆对账的情况。
示例：一次需求开发任务的交接
以下为演示情景，用于说明字段和步骤如何落地，不代表真实项目数据。
背景与交接原因：后端开发张明因岗位调整，需将“订单导出功能开发”交给同组李华，任务负责人为研发组长王强。任务处于开发中段，接口已完成一半，前端联调尚未开始。
填写后的交接记录要点：
- 任务标识：需求单 REQ-2317，关联项目“订单中心”。
- 交出方张明，接收方李华，最终责任人王强。
- 交付物：已完成的两个接口代码分支、接口文档初稿、测试环境账号、导出模板文件。
- 验收标准：接口在测试环境对 1 万条订单数据导出成功且字段与模板一致；接口文档覆盖全部入参、出参和异常码；前端联调通过。
- 截止时间：联调完成 3 月 12 日，上线 3 月 20 日，均按工作日计算。
- 依赖与风险：依赖支付团队提供对账字段说明；风险为测试环境数据量不足，需提前准备造数脚本。
- 未决事项：导出是否包含手机号字段，待产品经理 3 月 10 日前确认。
- 生效条件：李华书面确认、王强审批后生效，记录留存在任务下。
交付要求的具体写法：把“接口完成”拆成可检查的条件，例如“导出接口在测试环境对 1 万条数据执行成功，耗时在约定范围内，导出文件字段顺序与模板一致”。这样接收方接手后能自行判断进度，负责人验收时也有据可依。
未决事项与风险的处理：手机号字段问题不阻塞开发，先按不含手机号实现，产品确认后再评估改动量；造数脚本由李华在接手后两天内补齐，作为风险应对动作写入记录。
确认与生效过程：张明提交记录，李华核对后提出“异常码文档缺失”的问题，张明当天补充；王强确认责任划分和验收标准后审批，任务责任人变更为李华，确认期设为 5 个工作日。
交接后出现分歧时的处理：若联调阶段发现某接口行为与文档不符，先查确认期问答记录和代码提交历史，判断属于交接前遗留还是交接后改动；无法判断时由王强裁定，并将结论补入交接记录，避免同类问题重复出现。
交接完成检查清单
交接是否真正生效，可以用下面这份清单逐项核对。任一项不通过，交接应退回补充，不进入生效状态。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 字段完整性 | 字段表中各项均已填写，无空白或“待定”占位 | 交接记录全文 | 交出方 |
| 责任归属唯一性 | 每个交付物和执行动作都有且只有一个责任人，最终责任人明确 | 交接记录中的角色栏与任务责任人字段 | 任务负责人 |
| 交付要求可验证 | 每项验收标准都能通过检查、测试或评审判断是否达成 | 验收标准条目及对应验证方式 | 接收方与负责人 |
| 确认与留痕 | 接收方确认、负责人审批均有记录，时间与人员可查 | 确认意见、审批记录 | 接收方 |
| 未决事项跟进 | 每项未决事项都有负责人、答复时间和当前状态 | 未决事项列表 | 任务负责人 |
| 确认期安排 | 确认期长度已约定，期间问答渠道明确 | 交接记录中的确认期条款 | 交出方与接收方 |
出现以下情况应判定为阻断项并返工：交付物无法访问或缺失关键文档；验收标准存在无法判断的表述；未决事项无人认领；接收方未明确确认。返工后重新走确认流程，确认期从生效日重新计算。把这套字段、步骤和清单固定为团队惯例后，单项任务交接就有了统一口径，责任和交付要求不再依赖个人记忆。
常见问题
交接时接收方已经口头答应接手，还需要书面确认吗？
建议保留书面确认。口头答应能说明接收方愿意接手，但无法固定确认的时间、范围和条件。书面确认至少应包含接收方对交付物清单、验收标准和未决事项的核对意见，以及确认时间。这样在交接后出现分歧时，可以判断问题属于交接前遗留还是交接后新增，负责人裁定也有依据。
交接确认期应该设多长，确认期结束后发现问题怎么办？
确认期按任务复杂度设定：简单、边界清晰的任务可以设 2 至 3 个工作日，跨系统、跨团队或历史信息较多的任务可设 5 个工作日或更长。确认期内发现遗漏，按未决事项补充记录，不必推翻整份交接。确认期结束后再出现的问题，原则上由接收方按新任务处理；需要追溯历史信息时另行沟通，涉及责任判断的由任务负责人裁定并补入记录。
交接期间原责任人和接收方都在参与，出了问题算谁的？
处理原则是执行责任随生效时间切换，信息责任保留到确认期结束。交接生效前，交出方对已完成的成果质量和信息准确性负责；生效后，接收方对执行结果负责，但交出方在确认期内仍需如实答复历史信息相关问题。双方职责重叠期间，负责人应明确当前阶段的主责人，避免同一件事出现两个默认执行人。
任务只完成了一半，很多信息还没定下来，这种情况能交接吗？
可以交接，前提是把不确定的部分写进未决事项，而不是等全部确定后再交。未决事项要写明当前状态、待谁决定、答复时间和不处理的影响。对于不阻塞后续工作的未决事项，可以先按临时方案推进，并注明方案变更后的评估方式。把未决事项留在原责任人记忆里，恰恰是交接后责任悬空的主要来源。
团队规模小、任务简单，也需要走完整的交接流程吗？
流程可以简化，字段不宜省略。小团队可以把交接记录压缩成任务下的一段说明，保留责任人、交付物、验收标准、截止时间和未决事项这几项核心信息，确认方式用一次书面回复即可。确认期可以缩短甚至合并到下一次例行同步中。判断标准是：接手的人能否仅凭记录判断做到什么程度算完成，以及出问题时能否找到对应责任人。
