外包项目验收时，很多企业只盯着"系统能不能跑"，结果上线后才发现文档没给、账号没交接、源码没拿到。交付物不是"附赠品"，而是合同义务的一部分。本文给出一份可直接写进合同的交付物清单，分 5 类，逐项对照签收。
第一类：文档
- 需求规格说明书（与最终交付版本一致）
- 原型文件
- 数据库设计文档
- 接口文档
- 部署与运维手册
文档的价值在于"交接"：人员会流动，开发方会更换，只有文档能让接手的人快速理解系统。没有文档的系统，等于只有原班人马才能维护。
第二类：代码
- 源码仓库（含提交历史）
- 依赖清单
- 构建脚本
- 环境配置说明
这四项缺一不可。尤其是环境配置——很多项目在开发方机器上能跑，换一台机器就报错，根源就是配置没有文档化。
第三类：设计
- UI 设计源文件（分层可编辑，不是导出的图片）
- 设计规范（颜色、字号、间距、组件规则）
只交付切图或导出的图片，后续改一个按钮都要找原设计师。源文件在手，日常微调就能自己完成。
第四类：测试
- 测试用例
- 测试报告
- 缺陷清单与修复记录
测试报告是验收的直接依据。没有它，验收就退化成"凭感觉"，争议时双方都拿不出证据。
第五类：资产与账号
- 账号清单（服务器、数据库、第三方服务）
- 域名与证书信息
- 相关第三方服务的授权与续费责任人
这一类的坑最深：账号如果注册在开发方名下，等于把业务连续性交给了对方。账号必须以甲方实名注册，项目结束全部移交。
把清单写进合同，才有约束力
建议把以上清单作为合同附件，并约定两条：一是验收时逐项打勾，未完成项不付尾款；二是交付时做一次交接讲解，让甲方团队能独立完成一次部署或一次内容更新。
为什么清单必须写进合同附件
"到时候都会给"是最常见的口头承诺，也是最靠不住的承诺。清单只有写进合同附件，才具备两重效力：
- 验收效力：逐项签收，缺项就是未完成，直接对应付款节点；
- 追责效力：事后补交付时，有明确的依据说明"应交付什么、什么时候交付"。
写清单时建议再补两条约定：一是交付时间（例如"上线前 3 个工作日"），二是交付形式（例如"源码以仓库形式、文档以可编辑格式"）。只写"交付文档"不写格式，可能收到一堆无法编辑的截图或 PDF，后续修改依旧要依赖对方。
交付后建议做一次"接管演练"
清单签收之后，建议让甲方团队做一次独立操作：自己部署一次、自己更新一篇内容、自己导出一次数据。能独立跑通，才算真的接管了系统。这一步不做，很可能在半年后才发现"文档写得对，但没人会照着做"。
一份可直接抄的清单表
| 类别 | 交付物 | 验收动作 |
|---|---|---|
| 文档 | 需求规格、原型、数据库设计、接口文档、运维手册 | 抽查三份，核对与系统一致 |
| 代码 | 源码仓库、依赖清单、构建脚本、环境配置 | 干净环境构建成功 |
| 设计 | UI 源文件、设计规范 | 打开源文件，确认可编辑分层 |
| 测试 | 测试用例、测试报告、缺陷清单 | 核对用例执行与缺陷状态 |
| 资产 | 账号清单、域名证书、授权与续费责任人 | 登录核对实名与权限 |
这张表可以直接作为合同附件。 建议在每一行后面加一列"交付时间"，把"什么时候给"也固定下来。
交付物清单是验收的尺子。没有这把尺子，"验收通过"就成了一句无法追责的话。签合同前把这张表贴进去，上线前照着签收，能省掉绝大多数扯皮。