# 写明解禁日期的拒审先等再修才不会白费

> Guideline 5.6(Developer Code of Conduct – Review Suspended)的拒审,教给我的不是这条准则本身,而是"拒审"一个词装着两种不

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

Guideline 5.6(Developer Code of Conduct – Review Suspended)的拒审,教给我的不是这条准则本身,而是"拒审"一个词装着两种不同的东西。

一种拒审给你缺陷清单:哪个功能坏了、哪条元数据违规,修掉重交就行。5.6 这种质量停审是另一种:没有缺陷清单,没有复现步骤,没有任何可以拿来 diff 的东西,只有一句"未达到上架所需的质量标准",加一个明确的日期——那次写的是九天后才解禁,在那之前,回复和重新提交都不会被处理。

面对第二种,顺序错了就全错。我的顺序:

1. 先分类,再动手。把消息读两遍,只找两样东西:它指出可修复的缺陷了吗?它写明日期了吗?写明日期的拒绝是一张日程表,不是一次故障——任何落在日期之前的尝试,对任何版本的工作都不可能成功;这不是"多试几次"能翻过去的,规则在消息里已经写完了。

2. 锁定期内,不交一版,不回一条。这不是不作为,是唯一做得对的动作:窗口期里的每次提交都预先作废,消息自己写明了;而注定没有回音的回复,只会把"我们在努力"的错觉留给自己。

3. 窗口期花在真正的标准上。这条准则衡量的是 meaningful、polished、reliable 的体验——人的判断。本地自动化能测的一切(编译过不过、测试绿不绿、元数据合不合规)和它不在同一根轴上,所以答案不是加更多本地检查,而是换一双新鲜的眼睛把核心流程从头走一遍:第一次打开的人说得出这是干什么的吗?哪里卡、哪里糙?这类问题没有任何 lint 会替你回答。

4. 日期过了,先确认窗口真的开了,再用一个小的、受控的版本恢复提交流程,别把积压一口气倒回去——停审之后的大批量重交,在审核那侧看,可能正像触发停审的行为本身。

一分钟自检:翻出你最近一次被拒的消息,找带日期的那一句;如果存在,把计划里所有落在这个日期之前的动作——提交、回复、申诉——列出来,每一项都是注定作废的尝试,现在划掉。

写明解禁时间的拒绝,不是让你修的,是让你等的。把等的时间花在只有人能做的判断上,把提交留给日期之后。