# 5.6 拒审:信里的日期是排期,不是故障

> 一次 5.6(开发者行为准则)的审核暂停,后来解除了。值得记的不是暂停本身,而是这一类拒审的读法——它长得像普通技术拒审,正确的处理方式却几乎相反。 先说清信里到底写了什么:审核暂

- Canonical page: https://obelisk.club/blog/build-log-3023
- Author: Peter Zhang
- Published: 2026-10-11
- Tags: build-log

一次 5.6(开发者行为准则)的审核暂停,后来解除了。值得记的不是暂停本身,而是这一类拒审的读法——它长得像普通技术拒审,正确的处理方式却几乎相反。

先说清信里到底写了什么:审核暂停,理由是"未达到上架所需的质量标准",并且写明了一个日期——那之前不具备重新提交资格,提前发的回复与重提都不会被受理。信是 8 月 9 日来的,日期是 8 月 18 日。也就是说,恢复条件在拒审当天就已经写进了错误信息里。

这类信容易被处理错,恰恰因为它伪装成了普通拒审:有编号、有消息中心的来信,于是默认动作变成"改点什么、重新提交"。可编号指向的不是某个 build 的缺陷清单,而是资格层面的暂停;窗口期内任何一次重提都花在不可能成功的地方,而把"被挡在门外"记成"提交失败",会让你误判质量状况比实际更糟——那是两类不同的失败。

顺序要紧的处理模式:

1. 先读日期。"某日之前不接受重提"那句才是信的正文。把日历上所有早于它的提交与回复清零——不是推迟,是删除,它们在那个日期前不可能有价值。
2. 用窗口期做真正的质量工作。信里的标准写得明白:有意义、打磨到位、可靠。别猜审核员的心思,把已知的粗糙、崩溃和边角问题修掉,让下一次提交配得上这个标准。
3. 日期过后,重提一次,小批量优先。如果不止一个提交受影响,先提一个受控的小批次,再提其余——从平台视角看,全量重提像极了触发暂停的那类行为。
4. 分开计数。日期前的拒之门外与日期后的审核结果,记进不同的类;这次暂停最终靠时间加质量解除,不是靠重试次数。

一分钟自查:打开你最近一条拒审,搜任何一句写明日期的话——"before 某日"、恢复时间、冷静期。如果存在,把队列里所有早于该日期的动作划掉,再看剩下什么。剩下的才是今天真正该做的事。