正在加载，请稍候
页面能点、接口有返回、用例全绿，上线第三天业务却卡在第一步。问题不在测试覆盖率，而在验收表量错了对象——它数页面，不数行为。
验收会上所有人都说测过了：页面点得动、接口有返回、用例全绿。上线第三天，门店在「待收货」状态下发起退货，流程卡在第一步。清单一项没漏——它只是量错了东西。
小程序定制项目的验收表通常是这么长出来的：产品经理列页面，前端按页面排期，测试按页面写用例，最后按页面数量乘以工时报价。整条链路里，「用户在异常状态下能不能完成他想做的事」这件事，没有出现在任何一张表上。
页面是界面的切片，行为是业务的终点。两者之间隔着一堆状态：未登录、库存为负、优惠券已失效、重复提交、弱网重试。清单覆盖不到它们，因为它们不是页面。
这不是某一类项目特有的毛病，而是所有按「可数的东西」验收的定制交付共有的结构性缺陷。区别在于小程序入口重、生命周期短、状态恢复弱，异常路径暴露得更快，所以问题往往在上线后一周内集中爆发。
同一类错位在移动端项目里也出现过，只是暴露的位置换成了端侧能力边界，可参考移动端定制交付边界的复盘。
技术栈本身也在动。2026 年 9 月 htmx 4.0 改用 Fetch API 重写并内置了 DOM Morphing Swap，前端渲染层的换代节奏依然很快。如果验收契约绑的是「某个组件库的某个版本渲染正常」，一次依赖升级就会让整份契约失效；绑在行为上则不会。
2026 年 9 月的一篇 QCon 上海演讲预告里，支付宝数字民生的研发工程师复盘了生活缴费系统的跨语言重构：约 60 万行 Java 代码、600 多个接口。他做的第一个决定是把目标从「迁移代码」改成「迁移行为」。
理由写在演讲提纲里：代码评审通过、生成用例 PASS、覆盖率上升，都只能说明部分实现被检查过，不能证明目标业务分支真的执行了。为此他们建了两个互相校验的循环——一个回到老系统提取「需要迁移什么行为」，另一个在新系统回放相同场景，判定新旧行为的差异。
第二个决定更值得定制开发团队抄：场景的生成与验真必须分离。一个环节不能既负责生成目标、又负责修改数据、还负责证明目标已经完成。放在外包交付场景里，这等于说「乙方自己写用例、自己跑通过、自己宣布验收」这种流程，从结构上就不成立。
他们踩过的坑也很具体：生成的用例描述合理、断言最终通过，但实际执行在前置分支就提前结束，目标调用压根没发生。他们把这种状态叫假覆盖。换成小程序现场，这就是「测试全绿但门店退不了货」的同一件事。支付宝 60 万行跨语言重构的双循环交付实践值得逐段读完，尤其是路径压缩那一节。
改法不复杂，就是把验收表的行头换掉。下面这张对照表可以直接拿去改自己项目里那份 Excel。
| 维度 | 页面清单式验收 | 行为契约式验收 |
|---|---|---|
| 计量单位 | 页面数 / 接口数 | 业务终点数 |
| 通过标准 | 点得动、有返回 | 可见终态 + 副作用一致 |
| 异常态 | 抽查，通常不覆盖 | 每个终点点名边界条件 |
| 证据形态 | 测试截图 | 可回放场景 + 实际执行路径 |
| 付款节点 | 按页面开发进度 | 按业务终点通过率 |
| 差异处理 | 口头描述「跟原来不一样」 | 差异结论 + 回退方案 |
表里最容易被忽略的是「付款节点」那一行。只要钱还挂在页面进度上，团队的行为就不会真的改变——契约写得再漂亮，也只是附件。
平台差异本身也是行为差异的一个来源。把差异收进适配层是另一条常见解法，跨平台团队的能力建设那篇把分层拆得比较细。
小程序在调用涉及用户信息的能力之前，必须按微信开放文档的要求填写并生效《用户隐私保护指引》，未配置会直接拦截相关接口调用。这类事项不属于任何一个页面的功能点，却能让整个上线卡住。它恰好说明为什么验收基准要落在「行为能否发生」，而不是「页面是否画完」。微信开放文档关于用户隐私保护指引的填写说明里写得很直白。
一、验收标准是商务条款，不是测试团队的文档。如果合同里只写页面数量，验收阶段就没有任何抓手要求对方证明行为等价。把业务终点通过率写进付款节点，验收才有牙。这个结论不限于外包场景——AI 试点项目卡在验收环节的比例同样高得反常，只是卡点换了个名字。
二、用例全绿可能是最危险的信号之一。假覆盖说明绿色只代表断言被满足，不代表目标路径被执行过。要求交付方提供实际执行路径证据，比要求增加用例数量有用得多。
三、报价单位应该换掉。页面数量鼓励拆页面，业务终点数量鼓励想清楚边界。而机械的代码改动成本正在快速塌陷——2026 年 9 月出现的模型侧能力已能单日处理 68 万行级别的迁移，单个任务的成本差异可以达到八成。这意味着定制开发里真正稀缺的，不再是敲代码的速度，而是把行为定义清楚的那个人。同样的落差在贡献率与交付速度之间也能看到，根源都不在写代码这一环。
按页面数估工期会系统性偏乐观，因为返工几乎都发生在边界条件上。更稳的估法是先数业务终点，再按「首次通过」与「边界补齐」两段分别估算，最后乘一个异常态系数。
页面是可数的一维量，行为是多维的。报价按一维量走，做的是多维的活，多出来的那部分没有价格，自然会在项目后期变成争议或者偷工。
要三样东西：可回放的场景脚本、关键路径的服务端日志、每个终点的差异结论。三样里如果只能拿出截图，就说明证据链在最后一步断了。
先回答一个问题：要迁移的是代码还是行为。如果业务分支分散在配置和外部依赖里，逐行对齐结构通常是伪目标，验证行为等价才是真目标。
算，优先级还高于功能。隐私保护指引未生效时相关接口会被拦截，功能再完整也跑不起来。
如果你手上正有一份按页面数量写的验收清单，先做一件事：把它翻译成业务终点列表，然后数一数有几个终点在原文里根本找不到。剩下的部分，可以翻我们的小程序与系统定制案例看别人怎么拆，或者直接把清单发给我们做一轮验收结构评审。