Guideline 5.6(开发者行为准则)的拒审,和普通技术拒审长得不一样:没有修复清单,只有两样东西——一句“当前提交达不到上架的质量标准”(要有意义、打磨过、可靠),和一个明确的日期,在那之前重新提交和回复都不会被受理。没有修复项不是消息写得含糊,而是判词本身:它判的不是某个缺陷,是这一类提交值不值得上架。
这类消息最容易引来分类错误——当成“改完就能过”的拒审去抢修。三步,顺序重要:
1. 把日期读成日程表,不是挑战。消息自己说了原因何时解除,和配额重置、冷却期是同一形状:日期之前,任何版本的提交都不可能成功,更好的构建也绕不开这扇门。抢跑被拒的提交不是“失败的尝试”,是没被受理的尝试——别让它混进失败记录,那会污染你对工作本身的判断。日期过后,一次高质量的重提交胜过三次抢跑。
2. 暂停期修的是质量下限,不是提交节奏。5.6 的标尺是人眼:有意义、打磨过、可靠。本地能自动验证的——编译、测试、清单——对这三个词都没有采样点,所以“全绿”和“被暂停”完全兼容;不可见不是谁的失职,是采样位置不同。用这段时间做一次诚实自审:这个产品对谁有意义?比用户已有的选择好在哪?会装在自己手机上用一周吗?答案含糊,问题就不在构建流程里,在选题和完成度上——那是代码之外的工作。
3. 日期过了,小批量恢复。受影响的不止一个提交时,一口气全部重提,在平台那边看来像触发暂停的行为重演。先提最小、最有把握的一个,过审了再放量。
一分钟自检:把商店页给项目外的人看十秒,问两个问题——给谁用的?比什么好?答不上来的提交,再绿的构建也不受这把尺子的保护。