记一笔 5.6:Developer Code of Conduct — Review Suspended。结论大意:这一版未达到上架所需的质量标准——App 应当提供"有意义、精致、可靠"的体验——并且重提审资格锁到 8 月 18 日;在那之前的回复与重提不会被评审,重提只会收到一条自动消息。
这一类结果,会让"找到缺陷、修掉、尽快重提"的本能三处落空。
为什么事先不可见:常规拒审点名的是可修的缺陷,这一次点名的是一根轴——主观体验质量。构建、测试、合规清单测的是二元正确性和逐项勾选,没有一样在采样"这像不像被人用心做出来的"。更隐蔽的是清单式的质量整改:每一项都真实关闭了一个问题,但整改的形状是"对齐标准",不是"回答一个陌生人的第一眼"。全绿和这条结论同时为真,不矛盾,是测量空白。
为什么不能抢跑:资格日期不是瞬时故障,是写死的日程。日期前的重提到不了评审,只会收到一条自动拒绝——长得像结论,其实是拒绝受理;把它当失败去重试,是在用零信息的回复淹没真正的信号。急着发解释也一样,不会被读。
窗口期怎么花,顺序承重: 1. 先接受日程,把它当确定性的冷却期来规划,而不是"多试几次总能过"。 2. 把时间花在被评判的那根轴上:以陌生人身份冷启动,逐屏走完,专找"看起来无意的、未完成的、不精致的"东西——占位内容、前后不一致、某个设备档位上的破相。打磨类的结论只能用打磨回答,不能用针对某条意见的 diff 回答。 3. 窗口打开后,一次、克制地重提,并把改了什么、验证了什么写进审核备注。停审后的连发重提,在平台视角下像在重演触发停审的模式——这类消息往往还写明了升级后果,值得当真。
一分钟自检:冷启动你手上的构建,假装第一次见到它,两分钟逐屏走完,写下三处"最像没做完"的地方;再问自己,现有检查里哪一个能拦下"质量不达标"这个结论。答不出第二个问题,那根轴在你的流程里就是不可见的——它会一直不可见,直到下一次 5.6。