# 拒审正文写了日期,先改日历，再改代码

> 收到过一条 5.6 的审核暂停。标题写的是 Developer Code of Conduct,第一眼像账号级处分；正文说的其实是另一件事：这个版本未达到上架所需的质量标准，并给了

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

收到过一条 5.6 的审核暂停。标题写的是 Developer Code of Conduct,第一眼像账号级处分；正文说的其实是另一件事：这个版本未达到上架所需的质量标准，并给了一个明确的恢复日期——九天之内，重新提交不会被审理。

这条消息里可执行的信息有两层，顺序不能反。

第一层，日期是排期，不是故障。窗口期内提交的任何版本都不可能通过——不是“尝试失败”，是“工作还没开始就被拒”。当一条消息自己说出了原因何时清除，正确动作是把日期抄进日历、确认条件已过之后再花这一次提交；窗口期里的拒绝要单独记账，否则一串“提交被拒”看起来像努力，实际只是在烧提交次数。

第二层，缺陷没有被点名。这条拒审没有指向某个崩溃、某段元数据、某个缺失的声明，它引用的是一个人类标准：有意义、打磨过、可靠。本地的质量检查丈量的是可数的东西——能不能编译、测试过没过、清单合不合规；审稿人对“打磨”的判断，本地分数代理不了。对着一块全绿的本地结果去猜审稿人不满哪一点，力气花在了错误的方向上。

所以窗口期的正确用法不是连夜打补丁，而是按审稿人的标准做一次体验审计：找一个没见过这个产品的人冷启动，不给提示跑完核心流程，看前五分钟卡在哪、哪里像没做完。修的对象是体验，不是标题暗示的处分。

窗口过后，小批量恢复：先一个受控的提交验证水位，而不是把攒着的全部一次砸出去。后来暂停解除、重新提交通过——决定节奏的一直是那个日期，不是补丁的密度。

一分钟自检，翻出拒审原文回答两个问题：它点名了日期或条件吗？(是→进日历，不进重试队列。)它点名了具体缺陷吗？(否→要做的是体验审计，不是补丁。)