一次 Guideline 5.6(开发者行为准则·审核暂停)拒审的复盘。值得记,因为这类消息和普通拒审的应对模式完全不同——用普通拒审的肌肉记忆去处理它,每一步都会走错。
先说它为什么让人无从下手:消息里没有任何技术性发现——没有指向某个页面、某次崩溃、某段文案,只有一句"未达到上架所需的质量标准",加一个明确的日期:在那之前不具备重新提交资格,此前发出的回复与重交不会被处理。普通拒审命中的是"可修改的缺陷",这一类命中的是"排程"。而质量标准恰恰是本地检查最难测的轴:自己的清单全绿,并不能替真人评审回答 polished / reliable 与否——拿本地分数去推断"不可能因为质量被拦",正是这类暂停看起来永远"无缘无故"的机制。
应对顺序,顺序本身是承重的:
1. 先归类、先读日期。带日期的暂停是一张时间表,不是缺陷清单;日期之前,任何版本的工作都不可能通过。提前重试不但烧掉提交记录,还会在平台侧累积"重复触发"的观感。 2. 不要试图用代码修复它。这一类暂停属于评审层面的判定,和单次技术拒审是两种风险类别;把力气花在猜"到底哪个 bug 引发的"基本是误用。 3. 把窗口期花在消息唯一给出的可操作标准上(meaningful / polished / reliable):核心流程有没有像真人那样端到端跑过、每个本地化是否完整、空状态与边界输入是否可靠——当成一次真正的质量自查,而不是写申诉。 4. 日期过后,第一次重交要小而克制。刚解除就批量重交,在平台视角下可能像暂停诱因的重演。
一分钟自检:收到任何拒审,先看准则编号,再看信有多长。如果落在行为准则/审核暂停一类、且消息里带着具体日期——你的队列是被时间挡住的,不是被缺陷挡住的。核对日期,再决定要不要花任何一次尝试。