验收是软件外包项目里最关键的关口：过了这一关，尾款就要付，责任就要转移。但很多企业验收时只做了"能打开、能点"的粗检。本文把验收拆成 8 个必查项，逐条打钩即可。
一、需求一致性
- □ 需求规格说明书与最终交付版本一致
- □ 差异项有书面变更记录
需求与交付不一致，是后期纠纷的最大来源。核对时以最后确认的版本为准，而不是最初那份。
二、源码可用性
- □ 源码可在干净环境按文档完成构建与部署
- □ 依赖清单完整，与仓库实际一致
"能构建"是关键动作：不是拿到代码就算交付，而是在没有任何开发环境的情况下，按文档能跑起来。
三、交付物完整性
- □ 交付物清单逐项签收，无缺项
对照清单一项一项签，别嫌麻烦。缺的文档、缺的设计源文件，事后补往往遥遥无期。
四、质量与缺陷
- □ 测试用例全部执行
- □ P0/P1 缺陷清零，P2/P3 有修复计划
缺陷等级要提前定义好，"清零"才有意义。
五、账号与权限
- □ 域名、服务器、数据库、第三方账号均以甲方实名
- □ 权限已交接，子账号已停用
这一项最容易被跳过，后果也最严重。账号交接必须在验收时完成，不能留到"以后"。
六、数据可导出
- □ 数据可完整导出
- □ 导出文件已验证可打开
"支持导出"不算，实际导出一次并打开验证才算。
七、授权文件
- □ 第三方组件清单与授权文件齐备
开源组件、商业字体、图库、插件，授权文件要一份不少。
八、文档与交接
- □ 运维手册、部署文档、接口文档已交付
- □ 做过一次交接讲解
交接讲解的价值在于验证：甲方团队能独立完成一次部署或一次内容更新，才说明文档真的能用。
验收通过之后
验收不是终点。建议保留一份验收报告，记录验收日期、参与人、通过项与遗留项，作为缺陷责任期的起点依据。
验收报告怎么写
验收结束后，建议出具一份简短的验收报告，内容包括：
- 验收日期、参与人员
- 验收依据（合同、需求规格、验收标准）
- 通过项与未通过项清单
- 遗留项的处理计划与责任人
- 缺陷责任期的起算时间
这份报告不只是"走流程"，它是缺陷责任期的起点依据：哪天验收通过，保障期就从哪天开始算。没有报告，日后连"保障期还剩多久"都说不清。
打钩之前，先确认一件事
清单里的每一项，都建议现场验证而不是听说明：让开发方当场演示一次构建、一次导出、一次账号登录。演示通过才算通过，说明通过不算通过。这一步花不了一小时，却能挡掉后期几个月的问题。
验收不通过的五个常见原因
复盘验收失败的案例，原因高度集中：
- 需求与交付不一致：中途改过需求，但没有变更记录；
- 源码跑不起来：依赖缺失、环境未文档化；
- 账号没交接：域名与服务器仍在开发方名下；
- 数据导不出：导出格式打不开，或数据不完整；
- 文档对不上：文档写的是旧版本，与实际系统不符。
这五条都能在验收前自查。 建议在正式验收前先做一轮内部预检，把明显的问题提前暴露，避免验收会上才发现、当场僵住。
验收清单是你在项目里最后、也是最有力的一次把关。8 项逐条打钩，未完成的项不付尾款——这一条写进合同，比任何承诺都管用。