验收条款写「满足需求」，尾款能拖半年

一个做了四个月的系统，需求清单 47 条全部上线，甲方在验收会上说"还差点意思"，尾款拖了五个月。翻合同，验收条款只有一句话：功能完整，运行稳定，满足甲方需求。

这句话不是没有意义，但它没法拿来判定任何东西。什么叫完整、什么叫稳定、谁说了算，一条都没写。下面四处是最常写成摆设的地方。

一、验收标准要写到字段和角色

"满足需求"的问题在于它是主观判断。可执行的写法是把每条需求拆成三个要素：谁用（角色）、看到什么（字段和列表）、能做什么（操作）。

举个具体的：不要写"支持订单管理"，写"门店店长可查看本店近 30 天订单列表，字段包含单号、金额、支付方式、状态，可按状态筛选，可导出 Excel，单次上限 5000 条"。

这样写看着啰嗦，但好处很直接：签收时双方看的是同一张纸，不需要再解释一遍。我们做原型阶段就把这类条目列成表，客户逐条打勾，后面开发按表做，验收按表核。

二、上线不等于验收，试运行期单独约定

很多合同写"系统上线后 7 日内验收"，等于把风险全压在一方身上。系统刚上线那几天，数据是新的、人是生的，问题一定会有。这时候逼着签字，要么签了后面再吵，要么一直不签。

合理写法是分两段：上线后进入 2 周试运行期，期间发现的问题由乙方免费修复；试运行期结束、致命和严重缺陷清零，再进入正式验收，验收期 5 个工作日。

试运行期还有个作用：把"没做完"和"不好用"分开。没做完是缺陷，要修；不好用是需求变更，要谈。这两件事混在一起，验收会就开不完。

三、缺陷分三级，每级给时限

不分级的后果是：一个错别字和一笔金额算错，在同一个清单里排队。

写进合同的通常是这三档：

• 致命：数据丢失、金额错误、核心流程走不通，24 小时内响应，3 个工作日内修复
• 严重：主流程可用但存在明显阻碍，5 个工作日内修复
• 一般：样式、文案、体验问题，随下个版本发布

还要补一句：缺陷判定以双方共同确认的复现步骤为准。没有这句，就会陷入"我这边是好的"这种拉锯。

四、源码、数据库、部署文档进验收清单

功能验完，很多人就不管了。等到第二年要换服务商，或者想自己加个功能，才发现源码在对方服务器上，数据库账号不知道，部署文档没有。

验收清单里应该固定四项：完整源码（含依赖说明）、数据库结构与初始化脚本、部署与配置文档、第三方账号（短信、支付、地图）的管理权限。

这几条谈的时候不费劲，做的时候也不费劲，难的是事后补。

五、把变更单当流程，不当意外

做到一半改需求是常态，问题在于改的方式。微信里一句"这里能不能再加个字段"，做完没人记得，验收时也算不清。

流程很简单：任何超出已确认清单的改动，走一张变更单，写清改什么、加多少工作量、影响哪个上线节点，双方确认后再动手。金额小的可以直接吸收，但单子要留。一年下来，这张单子就是最完整的项目记录。

怎么判断一份验收条款能不能用

拿合同里那段话问自己三个问题：能不能让两个没参与项目的人得出同一个结论；缺陷修不完时，能不能据此拒付；系统交接给别人时，手上有没有全部材料。

三个都能答"是"，这份条款就能用。答不上来就在签字前改，改条款比改系统便宜得多。

我们交付时把原型、需求清单、验收清单做成同一份东西，原型费在签约开发时全额抵扣，验收不过不结尾款，源码随交付一并给。这些不是宣传语，是写在合同里的条款。