# 带日期的拒审是日程表,不是 bug 清单

> 收到过一封 Guideline 5.6 的拒审:Developer Code of Conduct,审核暂停,并写明"8 月 18 日前不具备重新提交资格"。通篇没有点名任何缺陷—

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

收到过一封 Guideline 5.6 的拒审:Developer Code of Conduct,审核暂停,并写明"8 月 18 日前不具备重新提交资格"。通篇没有点名任何缺陷——没有崩溃日志,没有缺失的元数据,没有哪个按钮该改。能提取出来的信息只有一个日期。

这类消息的陷阱在于:它和每封技术性拒审长得一模一样,于是"定位、修复、尽快重提"的反射照常触发。但这封信里没有可修的东西,它携带的不是缺陷清单,是时间表。日期之前的回复和重提不会被受理——那些尝试不构成任何反馈,只是白白消耗提交机会。对一个"在给定时刻之前不可能成功"的窗口硬重试,和普通的偶发失败是两类事,不该用同一套反射去应对。如果你的提交由自动化驱动,这里要多设一道闸:把"被拒"当重提触发器的系统,会在窗口期内一发接一发地把机会打出去。

事后总结的顺序:

1. 先分类再动手。看消息点名的是什么:能指到构建里某处的缺陷,还是只有一个日期。行为准则类的暂停不属于"改代码能解决"的风险类别,指望用一个修复去打动它,力气投错了地方。
2. 有日期,就把日期写进日历,并让每条提交路径都过这道闸——包括自动化的那条。
3. 窗口期拿来做本来就欠着的质量活。这类消息点名的标准是"有意义、打磨过、可靠",这些活无论有没有暂停令都该做,做了也不是谈判筹码。
4. 日期过后,先确认暂停确实解除——看版本在 App Store Connect 里的状态,而不是只看日历——再花第一次重提。
5. 恢复提交先来一次小而可控的,不要把积压一口气全推上去。

一分钟自检:翻开你最近一封拒审,问三个问题——它点名的缺陷,我能指到构建里的具体位置吗?它给了日期吗?我有没有哪条自动化把"被拒"当成"重提"的触发器?如果答案是"没有缺陷、有日期、有自动重提",你手里拿的不是 bug 清单,是日程表:先改日历和闸门,再谈代码。

这一单最后在约两个月后走通。回头看,起作用的不是任何一次抢跑或争辩,而是把那个日期当真。