# 5.6 停审:日期是日程表,缺陷在整体

> 5.6 停审这一类拒审,与其他拒审的根本区别:它不指认任何缺陷。 Guideline 5.6(开发者行为准则)下的"审核暂停"邮件通常说两件事:当前提交不符合上架所需的质量标准——

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

5.6 停审这一类拒审,与其他拒审的根本区别:它不指认任何缺陷。

Guideline 5.6(开发者行为准则)下的"审核暂停"邮件通常说两件事:当前提交不符合上架所需的质量标准——注意这不是一个可复现的 bug,而是对"有意义、打磨到位、可靠"的整体体验的判断;外加一个明确日期,在那之前的回复与重新提交不会被受理。

为什么这个问题在所有绿灯里都看不见:构建通过、测试通过、截图张张正常,而 5.6 审的那个轴——整体体验——没有任何本地仪器在测。门禁量的是零件,人审的是整机。所以收到停审后的第一反应"去找导致它的那个 bug"就是第一个错误动作:没有那个 bug,只有一个从未被端到端验证过的整体。

正确的顺序,且顺序本身承重:

1. 先读日期。点名了"何时自行解除"的拒审是一张日程表,不是一次偶发故障:日期之前的任何提交都不可能成功,抢跑烧掉的是一次提交资格,还附带一个"没读回复"的印象。把日期写进日历,在那之前去做别的。
2. 别 grep 缺陷,改做端到端审计。把"找出 bug"换成"把这个产品存在所要支撑的每条路径,在真机上从冷启动完整走一遍":没有死胡同、没有卡死、没有占位内容、没有只在测试里才走得通的路。
3. 用被关闭的窗口攒证据。窗口期不是干等:列核心路径清单,每条配上真实跑通的证据。审核重开时,支撑"可靠"这个判断的应当是这些产物,而不是一个 diff。
4. 日期一到,小步重提。解禁后的第一批提交要克制、可控——把攒着的全部一口气砸回去,看起来可能正像当初触发停审的模式。

一分钟自检:不打开工程,说出你的产品存在是为了支撑哪三条路径;然后把设备交给别人(或冷启动状态的自己),从启动开始把三条走完。任何一条走进死胡同、冻住、出现占位符或空白,就是 5.6 指的缺口——它对你现有的每一道门禁都不可见,因为门禁测零件,不测整机。

这一单最后是解了的:不是找到了某个"元凶"缺陷,而是等到日期、把整体验证补齐、小步重提。带走的一般化结论:拒审点名日期,就把它当日程表遵守;拒审不点名缺陷,缺陷就在整体的形状里,不在某一行代码里。绿灯证明零件能用,从不等于产品成立——中间那条缝,正是 5.6 在审的东西。