# 审核被暂停不是 bug 报告,别急着改代码

> 遇到过一种审核结果,和普通拒审长得不一样:准则 5.6,审核被搁置,提示「当前提交未达到分发所需的质量标准」,并写明在某个日期之前不具备重新提交资格。 最容易犯的错,是把它当成一份

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

遇到过一种审核结果,和普通拒审长得不一样:准则 5.6,审核被搁置,提示「当前提交未达到分发所需的质量标准」,并写明在某个日期之前不具备重新提交资格。

最容易犯的错,是把它当成一份缺陷清单,立刻开始翻代码找问题。

为什么容易看错:普通拒审会指向具体的页面、流程或元数据缺失,它是针对这一次提交的技术反馈。而这类搁置没有指出任何一个可复现的缺陷,只给了一个笼统的质量判断和一个时间窗口。它针对的是提交者与整体质量的关系,不是某一行代码。往里改再多,也改不掉一个日期。

比较稳的处理顺序:
1. 先读清楚消息里的日期,在窗口结束之前不回复、不重新提交。提前动作只会让情况更糟。
2. 把这一份结论归入「账号级风险」,而不是「本次提交的技术问题」。两类风险的补救方式不一样,混在一起只会把精力花错地方。
3. 窗口期内做的是通读式的质量自查:核心流程是否真的从头走到尾、每个入口是否可靠,而不是针对某条报错修补。
4. 解除后先小批量提交,观察结果,再决定是否扩大。一次性全量重提,从对方角度看很像触发搁置的那种行为重演。

一分钟自测:翻出你手上最近一次拒审的原文,问两个问题。它有没有点出一个可以复现的具体缺陷?它有没有写出一个日期?有日期、没有具体缺陷,就别把它当 bug 修。

这类事件的教训,是先判断风险属于哪一类,再决定动手改什么。