4. 交付物与验收标准条款
交付物与验收标准条款，是软件开发合同里最容易“看起来没问题、执行起来全是问题”的部分。它同时承担三个功能：界定卖方要交什么、买方按什么规则确认合格、以及双方在多长时间内完成确认。三者缺一，条款就会留下可被利用的缝隙。本节按“交付物清单—验收流程—验收标准—验收期限—视为验收”的顺序展开，重点讲清每一项应当怎么写、常见陷阱在哪里、以及如何用可执行的表述堵住漏洞。
一、交付物清单：不能只写“软件一套”
交付物清单是验收的起点。如果清单本身模糊，后续所有验收标准都失去锚点。常见的模糊写法包括“交付可运行的软件系统”“提供全部源代码及文档”“交付相关技术资料”。这些表述在争议中几乎无法执行：什么叫“可运行”？源代码是全部还是核心模块？文档是用户手册还是设计文档？
可执行的交付物清单应当按“类别—名称—形式—数量—载体”五个维度描述。以一套企业级管理系统为例，清单可以写成：
- 可执行程序：服务端部署包 1 套（Docker 镜像，含 docker-compose 编排文件），管理后台前端构建产物 1 套（静态资源目录）。
- 源代码：服务端源码、前端源码、数据库建表与初始化脚本，以 Git 仓库形式交付，含完整提交历史，交付时打 tag 为 v1.0.0。
- 数据库：建表 DDL 脚本、基础数据初始化脚本、数据字典文档（字段名、类型、含义、是否必填）。
- 文档：需求规格说明书、概要设计说明书、接口文档（OpenAPI 3.0 格式）、部署手册、用户操作手册，均为 PDF 加可编辑源文件。
- 第三方依赖清单：依赖名称、版本号、许可证类型，用于合规审查。
清单越具体，验收时越不容易扯皮。特别要注意“源代码”是否包含构建脚本、配置文件、数据库脚本和第三方依赖锁定文件；缺少这些，买方即使拿到源码也无法独立构建。
二、验收流程：谁在什么时间做什么
验收流程要回答四个问题：谁发起、谁执行、按什么顺序、每一步的产出是什么。一个可执行的流程通常包含：卖方提交验收申请及交付物 → 买方在约定期限内组织验收 → 验收测试执行 → 出具验收报告 → 不合格则进入整改与复验。流程中每个节点的责任人和时限都必须写明，否则“买方迟迟不验收”或“卖方反复整改”都会成为僵局。
建议在条款中明确：卖方提交验收申请时，应同时提交交付物清单、自测报告和已知问题清单；买方应在收到申请后 5 个工作日内组织验收，逾期未组织且无书面异议的，视为进入验收程序。验收测试应基于双方确认的测试用例集执行，测试环境由买方提供或双方约定。
三、验收标准：必须可测量、可复现
验收标准是判断“合格/不合格”的尺子。常见问题是标准写成“系统运行稳定、界面友好、满足业务需求”，这类表述无法测量，也无法复现。可执行的验收标准应当分维度量化：
- 功能维度：以双方确认的测试用例集为准，用例总数、通过数、通过率阈值（例如通过率不低于 95%，且致命与严重缺陷为 0）。
- 性能维度：明确并发用户数、响应时间分位值（如 P95 ≤ 500ms）、吞吐量、资源占用上限，并约定测试工具与测试数据规模。
- 缺陷维度：按致命、严重、一般、轻微分级，约定各级别允许残留数量。例如致命 0、严重 0、一般 ≤ 5 且不影响主流程。
- 文档维度：文档齐全、版本与交付系统一致、接口文档可导入并生成可调用示例。
- 安全维度：无高危漏洞，敏感数据加密存储，权限控制符合约定。
标准一旦量化，验收就从“主观感受”变成“客观判定”。同时要约定测试环境、测试数据、测试工具由谁提供，避免因环境差异导致结果不可比。
四、验收期限：起算点与中止情形
验收期限的争议往往不在“多少天”，而在“从哪天开始算”。常见写法“买方应在收到交付物后 10 日内完成验收”看似清楚，但“收到”是指物流签收、邮件送达还是系统上线？建议明确：以卖方通过约定邮箱发送验收申请及交付物链接之日为起算日，买方应于 10 个工作日内完成验收并出具书面结论。
同时要约定中止情形：因买方原因导致测试环境未就绪、测试数据未提供、关键人员未到场，验收期限相应顺延，且顺延期间不计入卖方违约。没有这一条，买方拖延验收反而可能被用来主张卖方逾期交付。
五、“视为验收”的陷阱与防御
“视为验收”条款本身并非无效，它是为了防止买方无限期拖延。但若表述过宽，就会变成买方被动接受不合格交付物的陷阱。三类高风险写法值得警惕：
- 沉默即通过：约定“买方在收到验收申请后 7 日内未提出书面异议的，视为验收合格”。如果买方内部审批流程长、或验收申请发送对象错误，买方可能在不知情的情况下“被验收”。防御方式是要求卖方同时向合同约定的两个指定联系人发送，并保留送达凭证；买方内部应设置验收提醒机制。
- 使用即通过：约定“买方将系统用于生产环境即视为验收合格”。但试运行、灰度发布、内部演示都可能被解释为“使用”。防御方式是把“试运行”单独定义，明确试运行不等于验收，试运行期间发现的问题仍可要求整改。
- 部分通过即整体通过：约定“任一模块验收合格视为整体验收合格”。这会让未交付或未测试的模块失去追责依据。防御方式是验收按交付物清单逐项确认，整体验收以全部清单项通过为前提。
六、可直接参考的条款要点清单
| 条款要素 | 应写清的内容 | 常见漏洞 |
|---|---|---|
| 交付物清单 | 类别、名称、形式、数量、载体、版本标识 | 只写“软件一套”“相关文档” |
| 验收流程 | 申请、组织、测试、报告、整改、复验各节点责任人与时限 | 只写“双方共同验收” |
| 验收标准 | 功能通过率、性能指标、缺陷分级、文档与安全要求 | “稳定、友好、满足需求” |
| 验收期限 | 起算日、工作日/自然日、中止与顺延情形 | “收到后 10 日内”未定义“收到” |
| 视为验收 | 仅限无正当理由拖延，需书面催告，试运行不替代验收 | 沉默即通过、使用即通过、部分通过即整体通过 |
把上述五项写实，交付物与验收条款就从“形式条款”变成“可执行机制”。审查时的核心判断标准只有一条：当双方对“是否合格”产生分歧时，能否仅凭合同条款和留存的验收记录得出唯一结论。如果能，条款就是合格的；如果不能，就需要在签署前补齐清单、量化标准、锁定起算点，并收紧“视为验收”的适用条件。