瀑布项目的阶段交接，最容易出问题的地方是“口头说清楚了，事后找不到依据”。一份可核验的阶段交接单，需要把移交基本信息、准入准出核对、交付物与文档清单、遗留问题与待办、签字确认这五块内容固定下来。签字项至少覆盖移交方负责人、接收方负责人和阶段评审人三方，遗留问题必须写明责任人与关闭期限。下面给出一张可直接复制使用的空白模板，再逐项说明填写口径、必填选填划分，并用一份完整示例演示字段之间如何对应。
要点总览（TL;DR）
- 瀑布阶段交接单按五块组织：移交基本信息、准入准出核对、交付物与文档清单、资源权限与遗留问题、签字确认，空白模板可直接复制使用。
- 签字项至少覆盖移交方负责人、接收方负责人和阶段评审人三方，各自确认的内容不同：移交方确认交付齐全，接收方确认核对并承接，评审人确认阶段成果达到准出要求。
- 必填项保证交接可核验：项目与阶段、移交接收双方、实际交接日期、准出条件及核对结论、评审结论、交付物名称版本与存放位置、遗留问题责任人与期限、三方签字；其余字段按项目情况选填。
- 可核验的关键是字段互相对应：准出核对中的“不满足”项，要在遗留问题区有责任人和期限，在签字区有评审人的附加条件说明。
- 模板应按项目规模裁剪并做版本管理，准出条件清单与阶段准入准出检查清单保持同源，定期复盘淘汰长期空白的字段。
可复制空白交接单模板
下表为空白模板，可直接复制到文档工具或表格工具中填写。表格按五个区域排列，填写时按区域顺序推进，前一区域未完成核对不要进入签字区。
| 区域 | 字段 | 填写内容 |
|---|---|---|
| 一、移交基本信息 | 项目名称 | |
| 项目编号 | ||
| 移交阶段 | ||
| 移交方（部门/角色/姓名） | ||
| 接收方（部门/角色/姓名） | ||
| 计划交接日期 / 实际交接日期 | ||
| 交接单编号与版本 | ||
| 二、准入准出核对 | 本阶段准出条件清单 | |
| 逐项核对结论（满足/不满足/不适用） | ||
| 阶段评审结论（通过/有条件通过/不通过） | ||
| 评审记录位置（会议纪要或评审单编号） | ||
| 未满足项的处置说明 | ||
| 下一阶段准入条件确认 | ||
| 三、交付物与文档清单 | 交付物名称 | |
| 交付物类型与版本号 | ||
| 存放位置（文档库路径或链接） | ||
| 完成状态（已完成/部分完成） | ||
| 对应需求或工作项编号 | ||
| 四、资源、权限与遗留问题 | 环境与账号权限移交情况 | |
| 待办事项及承接人 | ||
| 遗留问题描述 | ||
| 遗留问题责任人 | ||
| 遗留问题关闭期限 | ||
| 风险提示与依赖说明 | ||
| 五、签字确认 | 移交方负责人签字 / 日期 | |
| 接收方负责人签字 / 日期 | ||
| 阶段评审人签字 / 日期 | ||
| 项目经理（或交接协调人）签字 / 日期 |
使用时注意两点：交付物清单按“一行一个交付物”展开，不要合并成一句话；遗留问题区按“一行一个问题”展开，每个问题单独带责任人和期限。这样表格在评审和追溯时才具备可核对性。
交接单字段说明与填写口径
字段能否发挥作用，取决于填写人是否知道数据从哪里取、判断标准是什么。下表按区域说明每个字段的含义、取数来源和判定口径。
| 字段 | 含义 | 取数来源 | 填写口径 |
|---|---|---|---|
| 项目名称与编号 | 唯一标识本次交接所属项目 | 项目立项文件或项目管理系统 | 与立项记录保持一致，编号用于跨文档检索 |
| 移交阶段 | 标明交接发生在哪个阶段边界 | 项目计划中的阶段划分 | 写阶段全称，如“需求分析阶段”，避免只写“第一阶段” |
| 移交方与接收方 | 明确交出责任和接收责任的主体 | 项目组织架构与角色任命 | 写到部门和具体责任人，接收方须为实际承接后续工作的人 |
| 交接日期 | 区分计划时间与实际发生时间 | 项目计划与实际执行记录 | 两个日期都填，偏差较大时在备注中说明原因 |
| 准出条件清单 | 本阶段结束应满足的条件 | 阶段准入准出检查清单 | 逐条列出，与检查清单条目一一对应，不临时增删 |
| 核对结论 | 每条准出条件的判定结果 | 评审记录、测试报告、文档状态 | 只填“满足/不满足/不适用”三种值，“不适用”须写明理由 |
| 阶段评审结论 | 评审会议对阶段成果的正式判断 | 评审会议纪要或评审单 | 引用评审结论原文，并注明评审记录编号或存放位置 |
| 交付物名称与版本 | 本阶段产出的可交付成果 | 交付物登记表或文档库 | 粒度要求：一个可独立评审、独立接收的成果为一行，如一份需求规格说明书、一套接口文档 |
| 存放位置 | 交付物的实际归档地址 | 文档库、代码库或配置库 | 填写可访问的路径或编号，避免只写“已发邮件” |
| 遗留问题描述 | 本阶段未关闭、需后续处理的事项 | 问题清单、评审意见、测试缺陷 | 写清现象、影响范围和期望结果，不写“待优化”这类无法验证的表述 |
| 遗留问题责任人与期限 | 明确谁在什么时间前关闭 | 问题跟踪记录 | 责任人写具体姓名，期限写到日期，跨阶段问题须经接收方确认 |
| 移交方签字 | 确认已按清单完成移交 | — | 确认交付物齐全、位置可访问、遗留问题已如实登记 |
| 接收方签字 | 确认接收并承接后续责任 | — | 确认已核对交付物内容、认可遗留问题处置安排 |
| 评审人签字 | 确认阶段成果达到准出要求 | — | 确认评审结论与核对结果一致，有条件通过时注明附加条件 |
交付物清单的粒度是常见分歧点。判断标准可以统一为：接收方能否仅凭清单条目找到对应文件并独立开展下一阶段工作。如果一条记录里塞了三份文档，接收方核对时就无法逐项确认，清单也就失去了核验价值。
遗留问题的填写规则可以概括为“可追踪”：每条问题有唯一编号、有责任人、有期限、有当前状态。状态建议统一为“待处理/处理中/已关闭”，关闭时补充关闭说明，便于下一阶段复盘时统计遗留问题的消化情况。
必填项与选填项的划分
并非所有项目都需要填满整张表。团队可以先确定一个最低可用版本，保证交接可核验，再按项目情况补充。下表给出划分建议。
| 字段 | 属性 | 理由或适用情形 |
|---|---|---|
| 项目名称、移交阶段、移交方、接收方、实际交接日期 | 必填 | 缺少任一项，交接单无法定位到具体项目和责任主体 |
| 准出条件清单及核对结论 | 必填 | 这是判断阶段能否移交的核心依据 |
| 阶段评审结论 | 必填 | 评审是阶段移交的正式授权来源 |
| 交付物名称、版本、存放位置 | 必填 | 接收方据此核对成果，缺失则交接无法验证 |
| 遗留问题描述、责任人、关闭期限 | 必填（无遗留问题时填“无”） | 遗留问题是跨阶段风险的主要来源，必须显性化 |
| 移交方、接收方、评审人签字 | 必填 | 三方签字构成交接的确认链条 |
| 项目编号 | 选填 | 多项目并行、需要跨文档检索时填写 |
| 计划交接日期 | 选填 | 需要考核交接及时性时填写 |
| 交接单编号与版本 | 选填 | 交接单需要多次修订或归档管理时填写 |
| 环境与账号权限移交 | 选填 | 涉及测试环境、生产权限或第三方账号时填写 |
| 待办事项及承接人 | 选填 | 存在未纳入交付物但需继续推进的事项时填写 |
| 风险提示与依赖说明 | 选填 | 下一阶段存在外部依赖或已知风险时填写 |
| 项目经理签字 | 选填 | 组织要求项目经理统一把关时填写 |
缺失必填项时的处理方式应当事先约定，避免临场妥协。常见做法是：必填项缺失时交接单不予签署，由移交方补齐后重新提交；确因客观原因无法补齐的，在“未满足项处置说明”中记录原因、补救措施和完成时间，并经接收方与评审人共同确认后，交接单标记为“有条件交接”。有条件交接的记录应在下一阶段启动会上复核，确认补救措施已落实。
完整填写示例：一个需求阶段的交接
以下为演示情景，用于说明字段之间如何对应，不代表真实项目案例。某信息系统项目完成需求分析阶段，向设计阶段移交。
基本信息：项目名称“客户服务平台升级”，项目编号 PRJ-2024-018，移交阶段“需求分析阶段”，移交方为需求组分析师张某，接收方为设计组负责人李某，计划交接日期 6 月 14 日，实际交接日期 6 月 17 日，交接单编号 HO-018-02。
准入准出核对：准出条件共四项。需求规格说明书通过评审——满足；需求追溯矩阵覆盖全部一级需求——满足；关键需求完成业务方确认——满足；非功能需求完成初稿——不满足，性能指标待运维团队补充。阶段评审结论为“有条件通过”，评审记录编号 RV-018-05。未满足项处置说明：性能指标由运维团队于 6 月 21 日前补充，设计阶段先行开展功能设计。下一阶段准入条件确认：设计阶段可在性能指标补充期间启动。
交付物清单：需求规格说明书 V1.2，存放于项目文档库“需求/正式版”目录，状态已完成，对应需求工作项 REQ-101 至 REQ-138；需求追溯矩阵 V1.0，同目录，已完成；业务流程图集 V1.1，同目录，已完成；非功能需求初稿 V0.9，存放于“需求/草稿”目录，部分完成。
遗留问题与责任人：问题一，性能指标未定稿，责任人运维组王某，关闭期限 6 月 21 日，状态处理中；问题二，报表模块字段口径待业务方确认，责任人需求组张某，关闭期限 6 月 19 日，状态处理中。风险提示：第三方接口文档尚未提供，可能影响设计阶段的接口设计排期。
签字区：移交方张某 6 月 17 日签字，确认交付物齐全、遗留问题已如实登记；接收方李某 6 月 17 日签字，确认已核对交付物内容、认可遗留问题处置安排；评审人王某 6 月 17 日签字，注明“有条件通过，性能指标补充后复核”。
这份示例体现了一个关键对应关系：准出核对中的“不满足”项，在遗留问题区有对应的责任人和期限，在签字区有评审人的附加条件说明。三处信息互相印证，交接单才具备可核验性。如果核对结论写了“不满足”，遗留问题区却空白，接收方就无法判断该问题由谁在何时解决。
当交接单需要多人协作填写、遗留问题需要持续跟踪时，可以把表格承载在项目管理工具中。ONES 支持用项目计划按阶段分解工作并设置里程碑，阶段评审与交付物可以作为工作项记录状态；ONES Wiki 支持文档关联任务，交接单作为文档与对应需求、交付物工作项建立关联后，接收方从文档即可跳转到具体工作项核对进展。遗留问题以工作项形式登记责任人与期限，关闭状态可随时查询，减少在表格与聊天记录之间反复确认的成本。
模板的调整与维护方法
模板的价值在于长期稳定使用，团队需要建立裁剪和维护规则，避免模板越改越臃肿或逐渐被弃用。
按项目规模裁剪字段。小型项目可保留必填字段的最低可用版本，交付物清单控制在关键成果范围内；中大型项目或跨部门交接，补充环境权限、风险依赖、项目经理签字等选填项。裁剪规则建议写入模板说明页，明确哪类项目使用哪个版本，避免每次交接临时讨论。
模板版本与变更记录。模板本身应有版本号，每次调整字段时记录变更内容、变更原因和生效日期。已签署的历史交接单保持原版本不变，新版本只对后续交接生效，这样历史记录在追溯时不会因模板变化而失真。
与准入准出清单联动维护。交接单中的准出条件清单应与阶段准入准出检查清单保持同源。检查清单条目调整时，同步更新交接单对应区域，并在变更记录中注明。两边各自维护、内容不一致，是交接核对流于形式的主要原因之一。
定期复盘与字段淘汰。建议每季度或每完成若干次阶段交接后，抽取已签署的交接单做一次复盘，检查三类情况：长期空白或填写随意的字段，考虑删除或改为选填；反复出现“有条件交接”的环节，考虑前移到阶段执行中管理；接收方反馈核对困难的区域，调整字段粒度或补充说明。字段淘汰同样需要记录，保证模板演进有据可查。
维护工作可以和阶段评审结合进行。每次阶段评审后花几分钟记录交接单的使用问题，积累到一定数量再统一修订模板，比频繁小改更容易保持模板的稳定性。
常见问题
交接单上的签字能不能用邮件确认或系统审批代替手写签字？
可以，前提是确认记录可追溯。签字项的本质是留下“谁在什么时间确认了什么内容”的凭证，手写签字、电子签名、系统审批记录或带明确确认意见的邮件回复都能满足这一要求。需要保证三点：确认人身份可识别、确认时间可查、确认内容与交接单版本对应。如果采用邮件确认，建议在交接单上注明确认邮件的主题或编号，避免日后翻找困难。涉及合同金额、对外交付等责任较重的阶段，按组织规定采用正式签署方式。
阶段评审结论是“不通过”，还能填写交接单吗？
评审不通过意味着本阶段尚未达到准出要求，此时不宜按正常流程签署交接单。可行的处理是：在交接单的核对区如实记录不通过的原因和未满足项，将整改事项登记为遗留问题并明确责任人与期限，交接单标记为“未完成交接”或暂缓签署。待整改完成、重新评审通过后，再补充签署。把不通过的情况记录下来，比直接搁置交接单更有价值，下一阶段启动时能清楚看到前置条件还差什么。
跨部门交接时，接收方对交付物有异议怎么办？
异议应当在签字前解决，而不是签完再提。建议在交接单的核对区增加一栏“接收方核对意见”，接收方逐项核对交付物后填写认可或不认可，不认可的条目转入遗留问题区，写明具体差异、期望结果和关闭期限。移交方与接收方对差异达成一致后，再由评审人确认。如果分歧较大无法当场解决，交接单标记为“有条件交接”，由双方上级或项目经理协调，并把协调结论补记在交接单上。
小型项目字段裁到多少还能保证可核验？
最低可用版本建议保留以下内容：项目名称、移交阶段、移交方与接收方、实际交接日期；准出条件清单及逐项核对结论；阶段评审结论；交付物名称、版本与存放位置；遗留问题（没有则填“无”）及责任人与期限；移交方、接收方、评审人三方签字。这组字段能回答“谁把什么交给了谁、依据是什么、还有什么没完成”。项目编号、计划日期、环境权限、风险提示等字段可以省略，但省略不影响上述核心判断。
交接单和阶段准入准出检查清单是什么关系，需要各维护一份吗？
两者用途不同但内容同源。准入准出检查清单是阶段开始和结束时逐条核对的依据，交接单是移交时记录核对结果和确认签字的凭证。实践中可以让交接单的准出条件区域直接引用检查清单的条目编号，核对结论回填到交接单，检查清单本身作为附件或关联文档保存。这样清单调整时只需同步更新交接单的引用条目，避免两份文件各自维护、内容逐渐不一致。
