研发交付验收清单以“验收项”为基本行，至少需要八类字段：验收项编号、验收内容与判定标准、交付物名称与存放位置、验收证据类型与证据链接、验收方式、验收人、验收结论、遗留问题与整改期限。本文给出一套可直接复制填写的空白表格，配套字段说明、必填取舍和一份完整填写示例，适用于某次研发交付的完成确认；清单和证据也可以放到协作工具中承载和流转。
要点总览（TL;DR）
- 验收清单以“验收项”为基本行，至少包含八类字段：验收项编号、验收内容与判定标准、交付物名称与存放位置、验收证据类型与证据链接、验收方式、验收人、验收结论、遗留问题与整改期限。
- 交付物按“名称—版本—存放位置—责任人”记录，四个要素齐全才能锁定被验收的唯一版本；验收证据按“证据类型—对应验收项—存放位置—采集时间—确认人”记录，每条证据挂到具体验收项。
- 验收结论只取通过、有条件通过、不通过三种；遗留问题必须带描述、等级、责任人和关闭期限，未关闭项在验收报告中单独列出。
- 模板可先保留最小必填集，再按软件版本、文档、硬件或接口等交付类型补充字段；字段为空统一填“无”或“不适用”并说明原因。
- 模板本身需要版本号和变更记录，新启动的验收使用新版本，进行中的验收沿用启动时的版本，避免同一份清单中途换口径。
可复制空白模板：验收清单与验收报告
下面五张表构成一套完整模板。验收清单是主表，交付物登记、验收证据登记、遗留问题登记是支撑表，验收报告汇总表用于对外签署。表格按纯文本格式给出，复制到文档或表格软件后按行增删即可。
表1 验收清单（主表）
| 验收项编号 | 验收内容 | 判定标准 | 交付物名称 | 交付物版本 | 存放位置 | 证据编号 | 验收方式 | 验收人 | 验收结论 | 遗留问题编号 |
|---|---|---|---|---|---|---|---|---|---|---|
表2 交付物登记
| 交付物编号 | 交付物名称 | 版本 | 类型 | 存放位置 | 责任人 | 提交日期 | 关联验收项 |
|---|---|---|---|---|---|---|---|
表3 验收证据登记
| 证据编号 | 证据类型 | 对应验收项 | 存放位置 | 采集时间 | 采集人 | 确认人 |
|---|---|---|---|---|---|---|
表4 遗留问题登记
| 问题编号 | 问题描述 | 等级 | 关联验收项 | 责任人 | 关闭期限 | 关闭状态 | 验证人 |
|---|---|---|---|---|---|---|---|
表5 验收报告汇总
| 项目 | 填写内容 |
|---|---|
| 交付名称与版本 | |
| 验收范围 | |
| 验收时间与地点 | |
| 参与角色与人员 | |
| 验收项总数 / 通过数 / 有条件通过数 / 不通过数 | |
| 总体结论 | |
| 遗留问题汇总（编号清单） | |
| 附件清单（交付物、证据） | |
| 提交方签署 / 日期 | |
| 验收方签署 / 日期 |
字段说明：每个字段记录什么、怎么填
字段设计的核心目标是让每个验收项可判定、可追溯、可关闭。判定标准决定这一项能不能判，交付物和证据决定结论有没有依据，遗留问题字段决定未完成事项有没有人跟到底。下表逐列说明填写口径，并给出常见填错方式。
| 字段 | 记录什么 | 填写口径 | 常见填错 |
|---|---|---|---|
| 验收项编号 | 唯一标识一个验收项 | 按模块或类型加序号，如“功能-01”“性能-03”，全表不重复 | 用行号代替编号，插入行后编号错乱 |
| 验收内容 | 本次要确认的具体事项 | 写成一个可观察的对象加动作，如“订单导出支持按日期区间筛选” | 写成“系统功能正常”这类无法判定的表述 |
| 判定标准 | 判定通过的依据 | 给出可核对的阈值、范围或对照文档条款，如“导出结果与筛选条件一致，1万条以内3分钟内完成” | 只写“符合需求”，未指明对照哪份需求或哪个指标 |
| 交付物名称 | 承载该验收项的产物 | 使用正式名称，与交付物登记表一致 | 同一交付物在不同行写成不同叫法 |
| 交付物版本 | 被验收的具体版本 | 写版本号或构建号，不用“最新版” | 验收后交付物又更新，清单仍指向旧版本 |
| 存放位置 | 交付物在哪里取到 | 写仓库路径、制品库坐标或文档目录，精确到可定位 | 只写“见共享盘”，无法定位到具体文件 |
| 证据编号 | 支撑该验收项的验收证据 | 引用证据登记表中的编号，一行可对应多条证据 | 直接粘贴截图，证据与验收项的对应关系丢失 |
| 验收方式 | 用什么方法确认 | 从演示、测试执行、文档评审、现场检查等方式中选择 | 所有验收项统一写“评审”，与实际确认过程不符 |
| 验收人 | 对该项结论负责的人 | 写具体姓名或角色，不用部门名称 | 写“测试组”，出问题时找不到确认人 |
| 验收结论 | 该项的判定结果 | 只取通过、有条件通过、不通过三种 | 出现“基本通过”“待观察”等无法归类的写法 |
| 遗留问题编号 | 该项未关闭的事项 | 引用遗留问题登记表编号，无遗留则留空并标注“无” | 在结论里写“有小问题”，问题没有进入登记表 |
交付物按“名称—版本—位置—责任人”记录，四个要素齐全才能保证验收时定位到唯一版本。验收证据按“证据类型—对应验收项—存放位置—采集时间—确认人”记录，证据类型可分为测试报告、截图、日志、评审记录、演示录像等，每条证据必须挂到具体验收项上，避免出现有结论却找不到依据的情况。
遗留问题字段需要五项信息：问题描述写清现象和影响范围；等级按对交付使用的影响划分，如阻断、严重、一般；责任人写具体承接人；关闭期限写日期；关闭状态取未开始、处理中、已关闭、已验证。遗留问题未关闭时，验收结论不能随主结论一起默认关闭，需要在验收报告中单独列出。
必填与选填：哪些字段不能空
模板过重会导致填写中断，最小可用清单只保留判定和追溯必需的字段。以下为必填与选填的划分，团队可在此基础上按交付类型调整。
| 字段 | 必填/选填 | 理由或适用场景 |
|---|---|---|
| 验收项编号 | 必填 | 支撑引用、统计和追溯 |
| 验收内容 | 必填 | 没有内容无法开展验收 |
| 判定标准 | 必填 | 决定结论是否可判定 |
| 交付物名称与版本 | 必填 | 锁定被验收对象 |
| 存放位置 | 必填 | 保证验收人能找到实物 |
| 证据编号 | 必填 | 结论的依据来源 |
| 验收人 | 必填 | 结论的责任归属 |
| 验收结论 | 必填 | 清单的核心输出 |
| 验收方式 | 选填 | 验收过程需要复核或审计时填写 |
| 交付物责任人 | 选填 | 交付物需要整改或补充时填写 |
| 证据采集时间与确认人 | 选填 | 证据时效性影响结论时填写 |
| 遗留问题等级 | 选填 | 遗留问题需要排优先级时填写 |
按交付类型调整时，软件版本交付应保留版本号、构建号和测试证据字段；文档交付应保留文档版本、评审记录和存放目录；硬件或设备交付应增加序列号、批次和现场检查记录；接口交付应保留接口版本、联调记录和调用方确认人。字段为空时统一填“无”或“不适用”，并在备注中说明原因，避免空白被误读为遗漏。
填写示例：一次版本交付的完整记录
以下为演示情景，用于说明字段之间的对应关系，不代表真实项目。某内部管理系统发布 V2.3.0 版本，验收范围包括订单导出、权限校验和接口联调三项。
| 验收项编号 | 验收内容 | 判定标准 | 交付物名称 | 版本 | 存放位置 | 证据编号 | 验收方式 | 验收人 | 验收结论 | 遗留问题编号 |
|---|---|---|---|---|---|---|---|---|---|---|
| 功能-01 | 订单导出支持按日期区间筛选 | 导出结果与筛选条件一致，1万条以内3分钟内完成 | 订单服务 | V2.3.0 | 制品库 order-service/2.3.0 | E-01 | 测试执行 | 李工 | 通过 | 无 |
| 功能-02 | 角色权限变更后即时生效 | 变更后重新登录即按新权限展示菜单 | 权限模块 | V2.3.0 | 制品库 auth/2.3.0 | E-02 | 演示 | 王工 | 有条件通过 | P-01 |
| 接口-01 | 与结算系统联调订单状态回传 | 状态回传成功率100%，异常有重试记录 | 接口文档与联调记录 | V1.4 | 文档库/接口/结算回传 | E-03 | 文档评审 | 赵工 | 通过 | 无 |
对应的交付物登记记录为：订单服务 V2.3.0，类型为软件包，责任人张工，提交日期为验收前一日，关联验收项功能-01；权限模块 V2.3.0，责任人张工，关联功能-02；接口文档 V1.4，责任人陈工，关联接口-01。证据登记记录为：E-01 测试报告，对应功能-01，存放于测试报告目录，采集时间为验收当日，确认人李工；E-02 演示录像，对应功能-02，确认人王工；E-03 联调记录，对应接口-01，确认人赵工。
遗留问题 P-01 描述为“权限变更后部分缓存菜单需刷新页面才更新”，等级为一般，责任人为张工，关闭期限为验收后五个工作日，状态为处理中。由于该项为有条件通过，验收报告总体结论记为“有条件通过”，并在遗留问题汇总中列出 P-01，待验证关闭后再更新报告状态。示例中三张表的编号互相引用，验收项、交付物、证据和遗留问题形成一条完整链路。
调整与维护：模板怎么随团队变化更新
模板本身也需要版本管理，否则不同项目使用的字段口径会逐渐分叉。建议在模板首页记录版本号、生效日期、变更内容和变更人，每次修改保留历史版本。
- 版本号与变更记录：采用主版本加次版本，字段增删记主版本，措辞或选项调整记次版本，变更记录写明原因和生效范围。
- 新增字段的触发条件：出现结论无法判定、证据找不到、遗留问题无法关闭三类情况时，评估是否补充字段，而不是在备注里临时记录。
- 删除字段的触发条件：连续多个项目该字段为空或只填“无”，且不影响追溯时，可合并或删除。
- 证据归档与保留期限：验收报告、交付物清单和证据按项目归档，保留期限按团队质量管理和审计要求约定，到期前不清理。
- 评审与责任人：指定模板责任人，每季度或每完成若干次验收后收集填写问题，集中评审一次，评审结论记入变更记录。
变更记录表头可设为：版本号、生效日期、变更类型、变更内容、变更原因、提出人、批准人。模板更新后，新启动的验收使用新版本，进行中的验收沿用启动时的版本，避免同一份清单中途换口径。
用协作工具承载清单、证据与遗留问题
表格适合起草和评审，真正执行时，验收项的状态、证据链接和遗留问题需要有人跟进。把清单字段落到协作工具中，可以让验收人、交付物责任人和问题承接人在同一处看到进度。ONES 的方案覆盖需求、基线、版本、变更、测试与发布，并通过关联关系保留过程追踪和审计依据，适合承载这类记录。
一种可行的承载方式是：每个验收项建为一个工作项，验收内容、判定标准、验收方式和验收人放入字段；交付物以附件或制品库链接挂到工作项上，版本号写在字段中；验收证据以附件或文档链接挂接，并在证据登记中保留编号；验收结论用状态字段表达，取值与清单保持一致；遗留问题单独建工作项，关联原验收项，带上责任人和关闭期限，关闭前原验收项保持有条件通过状态。验收人与责任人的确认动作留在工作项的操作记录中，形成交接依据。
标准流程、评审节点和交付物模板可以沉淀为可复用资产，把模板从文档要求转化为项目中的执行流程。对于需求明确、交付周期固定的版本交付，采用项目制管理并严控里程碑和交付物，与验收清单的使用场景较为契合。测试报告、缺陷记录等证据也可以借助用例库、测试计划和缺陷管理形成闭环，减少验收时临时补材料的情况。
常见问题
验收项判定标准写不出来，说明需求本身有问题吗？
判定标准写不出来，通常说明验收内容还停留在笼统描述，而不是需求本身一定有问题。可以先把验收内容改写成“可观察对象加动作”，例如“订单导出支持按日期区间筛选”，再补上可核对的阈值、范围或对照文档条款。若对照文档本身缺失或条款含糊，应先把该文档补齐或明确引用版本，再进入验收。判定标准缺失的验收项不建议直接判定通过。
验收过程中交付物又更新了，清单怎么处理？
清单锁定的是被验收的具体版本，交付物在验收后更新，应视为新的交付批次。处理方式有两种：若更新只涉及已通过项且不影响判定，可在交付物登记中新增一条记录并注明与原验收项的关系；若更新改变了验收内容或判定标准，应新开验收项重新验收，原清单保留历史记录。无论哪种方式，都不要直接修改原验收项指向的版本号，否则结论与证据的对应关系会断掉。
有条件通过的验收项，什么时候可以改成通过？
有条件通过表示该项主体可用，但存在未关闭的遗留问题。改成通过的前提是关联的遗留问题已完成整改并通过验证，验证人确认关闭后，再更新验收项结论。更新时应同时记录关闭日期和验证人，验收报告中的统计数字和总体结论也要同步调整。遗留问题未关闭前，不建议把该项结论直接改为通过，否则报告与问题登记表会不一致。
小团队验收项很少，还需要五张表吗？
验收项很少时，可以只保留验收清单主表和遗留问题登记两张表，交付物与证据信息直接写在主表对应列中。判断是否需要拆表的依据是记录量：同一交付物被多个验收项引用、同一验收项对应多条证据时，拆表更利于追溯；只有三五个验收项且一一对应时，合并填写更省事。后续验收项增多再拆表，历史记录按原结构归档即可。
验收证据需要保留多久，到期可以清理吗？
保留期限取决于团队的 quality 管理和审计要求，模板中应约定一个明确期限并写入维护规则。常见做法是按项目归档，验收报告、交付物清单和证据一并保存，到期前不清理。涉及对外交付、合同约定或行业审计的项目，保留期限应按相应要求执行。清理前建议先确认没有未关闭的遗留问题仍引用该证据。
