收到过一条 Guideline 5.6(开发者行为准则)的审核暂停:没有点名任何具体缺陷,理由是未达到上架所需的质量标准,审核挂起,并且信里写着一个日期——那个日期之前不接受重新提交,更早的回复也不会被读。这条暂停后来解除了,把当时想清楚的三件事记下来。
一、先读条款,再动手。拒绝信自带日期,就等于自带了一半答案:窗口之内的任何尝试——回复、重提、申诉——在机制上不可能成功。它和配额重置、冷却期是同一个形状:错误自己声明了解除时间,就当排期处理,写进日历,窗口内计零尝试。往注定失败的窗口里投尝试不只是浪费,还会在对面留下一条"没有读懂规则"的记录。
二、分清题型:这是判断题,不是检查题。5.6 点名的标准是体验要有意义、打磨过、可靠——没有任何一项本地检查能测这几样。构建全绿、测试全过,和体验低于门槛,完全可以同时成立。所以暂停期不该对着猜出来的缺陷改代码:那是把整个窗口花在没人判定过的问题上;该花的是被点名的那条标准本身——冷启动一次,以陌生用户的身份把核心流程从头走到尾:第一次打开能不能看懂,慢设备上卡不卡,出错之后能不能自己恢复。评审在测的就是这些。
三、窗口开了,先验证,再克制地动。日期过没过是可以查证的事实,不是感觉。确认之后,交一次重新提交就好,不要一批——暂停刚解除就倾倒一批,在平台眼里可能正是触发暂停的那类行为的重演。
这个顺序是承重的:先认排期,再分题型,最后才谈提交。顺序一反,后面的每一步都在为错误的下一步积累理由。
一分钟自检:翻出你手头最近的一条拒审信,找两个东西。第一,它命名的是缺陷还是判断?缺陷,去修代码;判断,去用产品。第二,它带没带日期?带了,先在日历上把窗口划掉——窗口内的所有尝试,从一开始就计为零。