"界面美观、运行稳定、体验流畅"——这三句话是软件外包合同里最常见的验收标准，也是最没用的一句话。形容词无法验证，也就无法追责。本文给出一个可复用的改写方法：把形容词换成"可执行的动作 + 可观察的结果"。
为什么形容词式验收一定会扯皮
形容词的问题是主观：甲方觉得"不美观"，乙方觉得"已经很好"。没有客观标准，争议就只能靠协商，而协商往往靠谁更急。验收标准的本质，是把主观感受翻译成客观事实。
改写公式：动作 + 结果
把"运行稳定"改写成：
把"界面美观"改写成：
把"性能良好"改写成：
规律很清楚：谁在什么条件下、执行什么动作、观察到什么结果。三要素齐全，标准才可执行。
五类交付物的验收动作
| 交付物 | 验收动作 | 通过标准 |
|---|---|---|
| 源码 | 在干净环境按文档构建 | 构建成功，无缺依赖 |
| 功能 | 执行全部测试用例 | 用例通过率 100% |
| 缺陷 | 统计缺陷清单 | P0/P1 为 0，P2/P3 有修复计划 |
| 文档 | 抽查三份核心文档 | 与实际系统一致 |
| 账号 | 登录各账号核对实名 | 均为甲方实名，权限正确 |
验收流程本身也要写进合同
除了标准，还要约定流程：
- 乙方提交验收申请与交付物清单；
- 甲方在约定期限内组织验收，逐项打勾；
- 未通过项写明原因与整改期限；
- 整改完成后复验，通过才进入下一付款节点。
同时约定"验收期限"：甲方逾期未提出异议的处理方式，避免无限期搁置。
验收自查清单
- 需求规格与最终版本一致，差异项有书面变更记录
- 测试用例全部执行，P0/P1 缺陷清零
- 源码可在干净环境按文档构建成功
- 交付物逐项签收，无缺项
- 域名、服务器、数据库、第三方账号已按甲方实名并交接
验收不通过，接下来怎么办
验收标准写得再好，也需要配套的处理机制。建议在合同里约定三步：
- 列整改清单：未通过项逐条写明问题描述、期望结果、整改期限；
- 限期复验：开发方整改后提交复验，复验只针对未通过项，避免"改一处、动全盘"；
- 与付款挂钩：未通过项对应扣留部分款项，复验通过后再释放。
同时要防止两种极端：一是甲方无限期拖延验收，二是开发方对整改敷衍了事。约定"验收期限"与"复验次数上限"，能让双方都有明确的预期。
验收标准的两个常见漏洞
- 只定义"通过"，不定义"不通过"：边界情形（例如偶发的非核心报错）该算通过还是整改，提前说清；
- 只写功能，不写数据：数据迁移是否准确、历史数据是否完整，同样需要可验证的标准。
验收标准要覆盖的四个维度
只写功能验收，往往会漏掉真正影响使用的问题。建议四个维度都覆盖：
| 维度 | 验收什么 | 示例表述 |
|---|---|---|
| 功能 | 是否实现需求 | 用例全部执行通过 |
| 性能 | 快不快、稳不稳 | 首屏时间不超过约定值 |
| 兼容 | 主流浏览器与设备 | 抽查若干设备无错位 |
| 安全 | 权限、传输、备份 | 越权访问被拦截 |
功能是"能不能用"，性能、兼容、安全是"敢不敢长期用"。 只验收前者，上线后往往在后者上出问题。
把形容词换成可执行动作，验收才有依据。建议在合同里同时写清"验收标准 + 验收流程 + 验收期限"三件事，缺一项都会在后期留下争议空间。