复盘了一条已解除的 Guideline 5.6(开发者行为准则)审核暂停。值得记的是它的结构,不是时间线:这类拒审和普通拒审不是一回事,应对次序也不同。
普通拒审是缺陷报告:指名崩溃、指名 API、指名页面,循环是定位 → 修复 → 重交,每一步都有抓手。5.6 的暂停一条缺陷都不指名,只说这次提交没有达到上架要求的质量标准——有意义、打磨过、可靠的体验——并且给出一个日期:日期之前,回复和重新提交都不会被处理。
结构上它给了两条硬事实:准则编号,和日期。全部应对次序从这两条来。
1. 把日期当日程,不当故障。消息自己写明了日期之前的提交不会被处理——一个自带解除时间的裁定,对任何版本的修复,日期之前的尝试都不可能成功。这类尝试单独记账,一笔都不要花;在窗口期内反复提交不只是无效,在平台那边读起来像无视裁定本身。
2. 没有指名的缺陷,质量审计就得自己做。这里有个容易漏掉的机制:本地检查全绿和 5.6 完全可以共存——构建通过、静态分数正常、清单式检查全过,而裁定评判的是"一个陌生人会不会觉得这个应用打磨过",这一项没有任何本地检查能量化。所以审计对象不是清单,是核心流程:以新用户的身份,把应用存在所系的那条路径从头走到尾,每个界面问三件事——有没有占位内容,有没有点了没反应的东西,有没有明显的卡顿或闪退。清单能过的都过了;这条走完还敢说打磨过,才算数。
3. 日期过后,一次有内容的重交:说清楚改了什么、每项怎么验证的。克制是策略,不是礼貌——暂停刚解除就把受影响的所有东西一次性推上去,在平台那边看起来,就像把触发暂停的那次行为重演一遍。
这一条最后解除了:这个类别不是终审。可复用的是次序——先日历,再审计,重交放最后。顺序本身承重:颠倒了,要么烧掉窗口期前的无效尝试,要么把没补过的质量再交一遍。
一分钟的自我检查:翻出你最近一次审核回执,只找两样东西——它指名的具体缺陷,和它指名的日期。只有日期、没有缺陷,就把它从待修复清单挪进日历,日期之前什么都不提交。然后花十分钟以新用户身份走一遍你自己的核心流程,诚实回答:陌生人会叫它"打磨过"吗?如果你所有本地检查都是绿的、而这个问题让你犹豫了,你就找到了这类拒审存活的地方。