作者：软件外包的纠纷，很少吵在“代码写得烂”，多半吵在“这算不算做完”。甲方觉得登录偶尔卡一下不能收，乙方觉得功能都齐了就该付尾款；交付时给了一个压缩包，数据库文档没有，服务器账号在对方手里。这些问题都有同一个根源：开工前没把“什么叫做完”写成纸面标准。
验收标准不是防乙方的，是防双方记忆走样的。需求聊得再热络，三个月后各自记的都是对自己有利的版本。
验收分三层，缺一层就有漏洞
第一层：功能验收。对照需求清单逐项过。每个功能点写清“输入什么、操作什么、看到什么”，验收时按这条路径点一遍就算过。功能清单是报价单的影子——报价单上有它，验收单上也该有它，两边对得上，“偷偷砍功能”的争议就不存在了。
第二层：质量验收。功能对了还不够。测试报告要覆盖主流程、兼容性（约定哪些机型和浏览器）与基础性能（约定并发量或加载时间）。质量标准不用定成行业最高，但要有数字：首屏几秒内、核心接口响应几百毫秒内、崩溃率多少以下。没有数字的标准没法执行，“用起来要流畅”这种要求最后只能靠吵架解决。
第三层：交付物验收。这是最容易漏的一层，也是最致命的一层——漏了它，换开发商时你会发现自己什么都带不走。
一份可以直接套用的交付物清单
源码与工程：完整源码仓库（含提交历史，不是最后一版的压缩包）、工程可在约定环境重新构建。
数据与文档：数据库结构文档、接口文档、部署手册——换一个团队照着文档能把系统跑起来。
账号与资产：域名、服务器、云服务、小程序与支付账号全部落在你名下，乙方只有协作权限；管理员账号密码当面移交。
后台与培训：管理后台操作手册，至少一次使用培训，操作者的问题当场清掉。
测试留痕：测试用例与测试报告，和第二层的质量标准一一对应。
这份清单签合同时作为附件，验收时逐项打勾。有个简单的检验法：让乙方的对接人休假两周，你的团队按文档自己发布一个版本——做得到，交付物才算齐。
里程碑怎么排
验收不该只发生在结尾。常见的排法是三段：原型确认（交互稿签字，需求冻结的起点）、阶段版本（每两到四周一次可运行版本，问题当场提）、终验（三层验收一起过）。每段对应一笔里程碑款，尾款留一到两成在终验后或质保期结束时付。
里程碑验收的好处是把大争议化成小争议。三个月只看两次的项目，问题会攒到终验一起爆发；两周看一次的项目，每处偏差都在下一周被纠正。验收节奏在合同里写死，比事后催进度有用。
争议高发点的处理
需求变更。变更不可怕，可怕的是口头变更。规则很简单：变更走书面评估，影响工时的出增减报价单，确认后排期；文案、样式这类微调不另收费，界限在合同里写明。做了没写、写了没确认的变更，是尾款纠纷的第一大来源。
延期的责任。延期分两种：乙方进度问题，按合同违约条款处理；甲方需求确认或资料提供拖延导致的顺延，工期相应顺延。双方责任要在项目周报里留痕，到时候翻记录，不翻脸。
小问题清单。终验时发现的小瑕疵，分“阻断项”和“保留项”：登录不了、支付失败这类阻断项必须修完再验收；界面细节、体验优化这类保留项列成清单，约定质保期内修完，不阻塞验收付款。全修完再收货和收货后限期修完，两种做法都行，提前说好比到时候扯皮强。
尾款与质保
尾款比例是对乙方最直接的约束，一般留一到两成，质保期一到三个月。质保期内非新需求的缺陷修复免费；质保期后的迭代另签，但必须基于你手里的源码——这也是交付物清单里源码完整性必须验收的原因。
验收标准的详细程度，其实也是筛选开发商的试金石：愿意把验收单写细的服务商，通常对交付质量有底气；含糊其辞的，交付时大概率含糊。选合作模式的对比可以看外包形态怎么选，从零到一的里程碑节奏在APP开发全流程里有拆解，上线前的功能自查可以用小程序UAT清单过一遍。
把“什么叫做完”在开工前写成纸，是定制软件项目里性价比最高的十分钟。我们的交付条款在合作流程页有完整列法，欢迎对照着压价、对照着验收。