国内项目验收为什么总卡住

验收的标准要在开工那天就立起来。标准没写进合同，后面所有的“我觉得还不行”都没法反驳，也没法满足。

验收为什么会变成拉锯

国内 B 端项目常见的场面是这几句：功能都有了但感觉不对；演示时没人提问题，验收时一下列出 40 条；老板说再用用看，一用两个月；尾款拖到第二年，理由是系统不稳定；对接人换了，新来的人不认之前的纪要。

表面看是客户难缠，实际上三件事没做：双方对范围各有一份记忆，什么叫“通过”说不清，演示、反馈、修复都没留痕。验收靠的是证据。

拖延是有成本的，只是账不立刻出现。尾款压着，现金流先紧；原班人马被调去下一个项目，再回来修验收问题，重新熟悉上下文花的时间不比当初做的时候少；拖过三个月，客户内部换人，连“当时为什么这么定”都没人说得清。

所以验收这件事，要当成项目管理的一部分来做。前面每一份纪要、每一次确认、每一张问题清单，都是在给验收那天的自己省事。

八类标准，缺一项就会有人拿它卡你

功能

依据签约时的范围清单（附件 A）逐条勾选——清单逐条编号并标注 Must/Should，验收单的功能列引用附件 A 编号，没编进去的一律不在本次验收范围。每条写清入口、操作步骤、预期结果，写成能复现的句子，比如“商户可以发布商品并成功下单支付，订单在后台可见”，不要写“系统功能正常”。验收环境要用生产或与生产同配置的预发，不要在开发机上演示。

缺陷分级要写成可判定的三句：

级别以双方在验收会上共同确认为准，甲方对级别有异议的，应在验收单签署前书面提出。每条通过的功能留一张截图或一段录屏，后面争论“当时是不是好的”时，这就是证据。

数据

出事故最多的是金额和总量。这一项要由客户的财务或业务负责人签字，只让 IT 点“确定”没有用，数据对不对他负不了责，所以数据核对表要加一列“确认人”，签字区为它单设一行。差异清单不能只写“有差异”，要写清哪几条、差多少、什么原因、谁确认可以接受。金额字段用整数分存是开发期的建表约定，验收时改不了库；验收核的是一件事——对账导出用整数或 DECIMAL 合计，不用浮点，不用单条肉眼核对。

权限

做一张“角色 × 功能 × 数据范围”的矩阵，逐格测。平台管理员能看所有租户，租户管理员只看本租户，门店店长只看本门店，普通员工只看本人，代理商只看自己发展的商户。每个角色至少验三件事：该看的能看到，不该看的看不到，改 URL 或者直接调接口也越不过去。第三件最容易漏，因为前端菜单已经藏好了，看着像没问题。导出、报表、消息通知也要按角色测一遍。很多系统菜单藏好了，导出接口却把全量数据吐出来。测试时拿低权限账号的 token 直接请求接口。页面藏得住，接口藏不住。

性能

“系统要快”不是标准。性能指标要写全四件事：

1. 并发口径：在线用户数和峰值并发分开写，比如在线 50、峰值并发 20。混着写，验收时甲方按 50 并发压，你必挂。
2. 接口枚举：写清登录、下单、报表这些具体接口，别写“主要页面”。
3. 指标红线：比如这几类接口 95% 请求小于 3 秒，关键接口的 TPS 到多少。
4. 基准条件：压测环境几核几 G、什么数据库版本，数据量多少，比如 10 万订单、1 万商品。

小项目不需要完整压测报告，但至少要有一次按真实数据量跑主流程的记录。没有这条，列表页全表扫描会在上线第一天才被发现。压测记录要写清工具、脚本、数据量、机器配置和测试时间，没有这些参数的 P95 不可比，客户也没法判断你说的“3 秒”是在什么条件下跑出来的。

安全

最低限度查这几项：默认密码是否强制修改、是否开了 HTTPS、登录有没有失败次数限制、上传文件是否限制类型和大小、调试接口和 Actuator 是否关掉、数据库是否只对内网开放、有没有一份权限矩阵和越权测试记录。不用把等保全套搬上来，但这几条是底线，也是被客户的安全人员一眼看穿的地方。

再加两项：依赖包有没有已知高危漏洞，日志里有没有打印身份证号、手机号、密码。前者用现成工具扫一遍，后者翻一遍最近的日志文件就能看出来。

部署

在干净环境按文档部署成功；配置项外置，不写死在代码里；有健康检查接口；有备份脚本并且实际恢复过一次；有升级和回滚步骤；日志、数据、上传文件的目录路径写清楚。“在我电脑上能跑”不算部署验收通过。部署过程录屏，回滚要实际演练一次，不是把步骤写在文档里。演练时记下从发现问题到恢复服务用了多少分钟，这个数字比“支持回滚”四个字有用。

文档

至少四份：部署文档（环境、依赖、端口、账号、启动顺序），操作手册（按角色写，不要一份文档发给所有人），接口文档（客户要对接时才需要），验收单与问题清单（含修复记录）。不用写成书，标准只有一个：没参与过这个项目的技术人员，能照着步骤把它跑起来。文档放在客户能长期访问的地方，不要只发微信文件。版本号和系统版本对应，改一次部署步骤就更新一次，否则第三个月就没人敢照着做。

培训与售后

至少一次录屏培训并留存视频；售后窗口写清是 30 天还是 90 天；范围内 bug 免费、新需求收费；响应时间给具体数字，比如工作时间 4 小时内回复；联系方式和服务时间段也写上。售后边界不清，是尾款拖尾的第二高发点，第一是范围。录屏要包含一次完整业务闭环，从建单到结算，不要只逐个菜单讲功能。新人入职时看的是闭环，不是菜单。

一份可以直接抄走的验收单

抬头和结论区直接抄，中间八张表把字段名换成你项目的叫法：

项目名称：
验收依据：合同编号____、附件 A《验收标准》版本____
验收日期：
验收版本：
参与人：甲方（业务 / 技术 / 负责人）、乙方（交付 / 技术）
材料送达：__月__日，邮件收件人____ / 群内确认截图编号____

一、功能清单

二、数据核对

三、权限矩阵

四、性能记录

五、部署

六、安全（按安全清单逐行）

七、培训与售后

八、遗留问题

结论和签字区：

九、结论
[ ] 通过    [ ] 有条件通过（遗留问题见上表）    [ ] 不通过
P0 遗留：____ 条（必须为 0）    P1 遗留：____ 条（修复时间表见上表）

甲方签字：            乙方签字：
数据核对确认（甲方财务 / 业务负责人）：
日期：                日期：

“有条件通过”这一栏很实用。别为两个 P2 问题把整个项目卡死，也别用“先上线再说”把 P0 放过去，分级处理、写清修复时间和负责人就行。

验收标准要变成合同条款

清单是工程文件，尾款靠的是合同。验收标准要写进合同，配四条：

1. 付款节点：签约 30%、上线款 40%（部署完成即付）、终验 20%、质保金 10%；
2. 乙方书面提交验收申请（邮件送达甲方指定邮箱和负责人）后 10 个工作日内，甲方应组织验收并出具书面结论，逾期既未组织也未书面提出异议的，视为验收通过；
3. 有条件通过时，遗留问题按表推进，不影响验收通过的效力；
4. 遗留问题逾期未修复的，按合同扣减或顺延质保期，同样不影响验收效力——这条是防甲方反过来用“条件未达成”主张验收无效、继续压尾款。

没有这一节，八类标准做得再齐，尾款照样能被“系统不稳定”拖住。

验收会怎么开

验收会开成什么样，基本决定了要签几次字。提前三天把验收单、问题清单、演示账号和会议议程发给对方，写明这次只验已确认的范围；材料送达记一笔——日期、收件人、群内确认截图编号。临时到场的需求，一律记进变更单，不在会上讨论实现。

会议控制在两小时，议程三段：

• 前 30 分钟按功能清单走主流程，由甲方业务人员操作，乙方不抢鼠标；
• 中间 60 分钟按角色验权限和数据，甲方 IT 可以直接调接口；
• 最后 30 分钟逐条确认遗留问题的级别、修复时间和负责人。

必须到场的是三种人：能判断“这样算不算过”的业务负责人，能看部署和安全的 IT，能签字的决策人。少一个，会就白开。结束时当场出纪要，写清通过项、不通过项、遗留问题和下次验收时间，双方在群里回确认。不要等回去再整理，回去之后每个人的记忆都会往自己有利的方向长。

验收流程五步，顺序别换

1. 内部预验收：自己按清单跑一遍，明显问题修掉再约甲方。
2. 演示验收：让甲方业务按真实角色走主流程，问题当场记下来。
3. 问题分级：确认 P0/P1/P2、修复时间和是否影响上线；第二、三步通常循环一到两轮，P0 清零才往下走。
4. 上线验收：收到上线款之后执行，由甲方技术看部署、权限、备份、日志、安全，主流程在生产环境冒烟一遍。
5. 签字与交接：验收单、文档、账号、录屏、尾款节点一起交付。

每一步都要留记录。微信群里一句“可以了”不如一张签字的验收单，但在还没有流程意识的早期项目里，至少把群里的确认截图归档，后面就有得说。

验收之后的 30 天

签字那天交付的是系统和文档，接下来一个月交付的是稳定性。交接清单要逐项过：服务器和数据库账号、第三方后台、备份任务、日志和告警、监控面板、域名和证书、支付和短信的余额提醒。每一项写接收人，不要只发一个压缩包。第一周每天同步一次，第二周隔天，第三周开始走工单。这个节奏在合同里不用写得太细，但内部要排出来。上线初期客户的问题密度最高，以我的体感，回应速度对评价的影响比功能多少更大。30 天结束做一次复盘，问三个问题：哪些问题重复出现，哪些功能没人用，哪份文档没人看懂。答案写进下一单的范围模板和验收单。这一单的验收，就是下一单的输入。

三个坑

无限试用。客户说先用一个月，好用再付——那等于免费劳动。演示环境可以随便试，生产环境必须按合同付款之后再上线。

口头变更。“顺便加个功能”，加着加着原定范围被挤掉了，验收时双方都不满意。所有变更走变更单——编号、日期、提出人、内容描述、影响（几天、多少钱）、对应附件 A 的编号、双方签字——哪怕只加一天也要写下来。

只验功能不验运维。系统能点，但没有备份、没有日志、不能回滚，上线第一周出问题，客户就会认定你交付的是个半成品。运维能力也是交付物，这八类标准里部署和安全那两项就是在管这件事。

甲方不签字，先别急着翻脸

不签字通常有四种原因，处理方式完全不同。P0 或 P1 没修完，那就修，别谈条件。新增需求没被满足，把变更单拿出来，确认是加钱还是换范围。对接人换了或者预算卡住，找当初拍板的人，不要在新对接人身上反复消耗。最多见的是第四种：经办人怕担责不敢签，要走内部审批——帮他把向上汇报的材料准备好（验收单按附件 A 逐项打勾，只留结论空格），把决策人拉进验收会当场拍板。不管哪一种，都先发一份书面说明：哪些项已通过、哪些项未通过、证据是什么、计划怎么修、什么时候再验。口头沟通完补一封邮件，抄送双方负责人——图的是让事情有落点。

可以提“有条件通过”：P0 清零、P1 有修复时间表，先签验收，遗留问题按表推进。我经手的项目里多数客户能接受，因为他要的是系统能用，不是把你耗死；前提是遗留问题表有“逾期处理”一列——逾期未修按合同扣减或顺延质保期、不影响验收效力，不然对方反过来能主张“条件未达成、验收无效”。

不要扣数据、锁系统、停掉生产环境。合同纠纷归合同，扣数据会把有理变成没理，也会让其他客户不敢再找你。

签字之后，责任不会消失

验收单固定的是范围和标准，不是质量责任的终点。签字之后发现系统泄露数据、算错钱、丢了订单，该修的还是要修，该赔的还是要赔。它的作用是把“做什么、做到什么程度、什么时候算完”说清楚，减少事后扯皮。把它当成免责书，下一次合作就没有了。

清单管不到的那部分

这份清单适用于中小型 B 端定制和白牌交付，不覆盖等保测评、行业强制认证、政府项目的验收程序。政企项目的差异就三条：第五步拆成初验（对应上线）和终验（试运行 N 天后），签字改盖章，验收单按甲方招标文件的附件格式重排——映射过来就行，不必整套重学。涉及资金、医疗、个人信息处理的系统，要按对应监管要求补专项验收。模板里那几张表可以直接改字段名就用，但“通过标准”那一列必须换成你和客户谈定的数字。

系列：上一篇 两周交付一个行业系统：范围冻结、里程碑与验收 ｜ 相关 主流程演示得再顺，客户还是要先导一个 Excel、为什么国内 B 端买家要源码买断，而不是 SaaS 订阅