# 拒审信自带解冻日期:先当日程,再谈修复

> 一版提交被 Guideline 5.6 打回:开发者行为准则,审核暂停。这封拒审信与多数不同的地方,是它自己写明了解冻条件——在那之前不具备重新提交资格,此前的回复与重提都不会被受

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

一版提交被 Guideline 5.6 打回:开发者行为准则,审核暂停。这封拒审信与多数不同的地方,是它自己写明了解冻条件——在那之前不具备重新提交资格,此前的回复与重提都不会被受理。从拒审到解冻隔着九天。这件事最终解决了,值得留下的不是时间线,而是一个读法。

为什么直觉会处理错:工程师看到拒审的默认动作是定位问题、改代码、尽快重提。但暂停类的裁定不是对这一版代码的技术反馈,而是准入层面的冻结,自带生效区间。日期之前,任何版本的任何修改都不可能被受理——这属于「工作还没开始就被拒绝」,和「做失败了的工作」是两类失败。把它们混在一起重试,账面上像在努力,实际上每个动作都在窗口外空转,还可能被读成无视冻结。

处理顺序,顺序本身是承重的:
1. 先在拒审信里找写明的日期或条件。找到,就把所有动作——包括回复——排到它之后。在日历上记一笔,比多改十行代码值钱。
2. 冻结期用来抬高自己的质量线。信里引用的标准是「有意义、打磨过、可靠」的体验;对着它做一轮诚实自审——核心路径端到端跑过没有,粗糙的地方清了没有。这些工作无论解冻与否都成立,不会白做,这也正是它和「为过审打补丁」的区别。
3. 解冻后先小批量提交,不要把积压一口气全推上去。大批量重提在平台那侧的形状,和触发暂停的原始行为是同一种。
4. 查一遍自动化。如果存在拒审后自动重提的循环,确认它读得懂「此日期前不受理」;按计时器重试的流水线会在冻结期里替你制造新问题。

一分钟自检:翻出你最近一封拒审信,只找一样东西——写明的日期或前置条件。有,就把它从「待修的 bug」重新归类为「日程」;再确认按下重提键的是人还是脚本。