一次 Guideline 5.6(开发者行为准则)的评审暂停,从外观上和普通技术拒审毫无区别:同样的状态、同样一封信。真正改变事件类别的那句话,藏在人人跳过的段落里——某个日期之前不受理重新提交,提前的回复不会被读取。这一次,那个日期在九天之后。
笔记三条,按重要度排:
1. 带日期的拒绝是日历,不是队列。窗口打开之前,任何版本的提交、任何措辞的回复都不可能成功——不是"改得还不够好",而是此刻根本没有评审在进行,没有任何可以说服的对象。把重试花在日期之前是零收益;而"回复要快"这个在技术拒审里是美德的反射,在这里只会堆出一列不会被读的消息。
2. 它指认的是类别,不是位置。这类信的措辞是"未达到分发所需的质量标准",不指向任何具体缺陷,所以别从措辞里反推 bug。修复的单位不是 diff,而是这个账号提交出去的东西整体上像不像被认真打磨过:按真人评审会走的路径把核心流程完整过一遍(自动化质量分与人对"打磨"的判断不对齐,别拿它当验收),更新说明写明改了什么、验证了什么——"修复了若干问题"这种句子在此背景下最无用。
3. 窗口打开后,先交一个。把受影响的东西一次全部重新涌入,从平台那侧看,可能正像当初触发暂停的行为模式。一次一个,通过再继续;这里的慢是策略,不是拖延。
一分钟自检:重读那封信,定位带日期的那一句;检查是否有任何自动回复或定时重提会在日期前触发——有,现在就关掉;再把"恢复提交"这条待办写成"提交一个",不是"提交全部"。