# 5.6 停审:把解禁日当排期,把窗口当工期

> 收到 Guideline 5.6(Developer Code of Conduct - Review Suspended)和收到一次普通被拒,是两类事件。 普通被拒指向一个可修的

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

收到 Guideline 5.6(Developer Code of Conduct - Review Suspended)和收到一次普通被拒,是两类事件。

普通被拒指向一个可修的缺陷:一次崩溃、一份缺失的声明、一段误导定价的文案。5.6 指向的是标准本身——"有意义、打磨过、可靠的体验"——并附一个日期:在那之前不符合重新提交资格,此前的回复与重交不会被处理。

这类停审最容易做错的一步,是把那个日期当故障而不是排期。日期之前发出的任何尝试,对所有版本的提交都不可能成功;在窗口里反复提交或追问,只是往平台那边的记录上叠东西,而资格一恢复就把积压全部倒出去,恰恰看起来像重演触发原因的动作。顺序应当是:

1. 先读懂消息引用的是什么。没有按钮、没有某行代码,引用的是成品的打磨度与可靠性——这两个量编译门禁和本地评分都测不到。全绿的构建与"体验不够有意义"可以同时为真,这不是矛盾,是度量层的盲区:自动化检查都在组件层,而这类判定发生在整体层。
2. 把窗口当工期,花在被审判的那根轴上:让一个从没见过产品的人冷启动跑通核心路径,补上真正有意义的功能与可靠性工作,清掉占位文案,把"修复了若干问题"式的更新说明换成"改了什么、怎么验证的"。本地分数量化得了覆盖率,量化不了打磨。
3. 日期过后,交一次,交得克制:把改了什么、验证了什么写进消息自己指定的那栏评审备注,而不是在窗口里提前重交,也不是资格一回来就批量倾倒。

一分钟自检:现在冷启动自己的产品,跑它存在的那条主路径,再读一遍商店描述与更新说明。任何一句你在别人 App 里读到会皱眉的话,就是这条标准看到的东西。

停审结束、资格恢复、版本过审,这一类结局不需要任何代码"修复"那个判定本身——需要的只是把解禁日当排期,把窗口里的时间花在消息真正引用的标准上。