一条 Guideline 5.6(行为准则)的拒审:8 月 9 日来信,审核暂停,信里写明 8 月 18 日之前不接受重新提交、此前的回复与重交不会被受理;近两个月后解除。值得留下的不是时间线,是三个可迁移的判断。
一、先分类,再动手。5.6 是行为/质量级裁决,不是某个构建的技术缺陷:信里没有可复现的 bug,只有一句“应为用户提供有意义、打磨过、可靠的体验”。对这封信找 diff 是没有靶子的——它审的是整机体验,不是你上一版改了什么。分类错了,后面每一步都在白费力气。
二、消息自己写明了解除日期,就把它当时间表,不要当偶发故障。带日期的拒绝(冷却期、配额重置、维护窗口都是同类)有个共同性质:日期之前发出的任何尝试,对任何版本的工作都不可能成功。窗口期里发回复、抢重交,不是诚意,是把拒收当成了进度;拒收要和真正的工作失败分开记,否则一串一模一样的“被拒”会淹没真实信号。
三、为什么本地全绿还会吃到这封信:本地检查验证的是零件,这封信审的是整机。单测、组件测试、静态质量分,没有一项是真人评审对“打磨与可靠”判断的代理;另一半盲区是熟悉度——天天开发的人,测不出第一次打开时的迟疑。
修复的顺序(顺序本身承重): 1. 分类:是给了可复现问题的逐项技术拒审,还是质量/行为级暂停?后者改代码不是答案的主体。 2. 把信上的日期写进日历;窗口期内零提交、零回复。 3. 窗口期只做一件事:冷启动,像第一次见到它的评审那样,把应用存在的那个核心流程从头走到尾,记下每一处摩擦——空白态、卡死的加载、点了没反应的按钮、付钱一步的犹豫。修这些,不加功能。 4. 日期过后,一次、克制地重新提交,备注里具体写验证过什么;“各种修复”这类话对谁都没有信息量。同批还有受影响的提交时,先小批,不要齐发——大规模重交在平台看来,可能正是触发暂停那件事的重演。
一分钟自检:把当前构建装到干净设备上,冷启动,一口气走完核心流程,数摩擦点——不费力就能数满三个,这封信的前提你已经凑齐。顺手看一眼测试输出末尾的 Executed N tests:N 为 0 的全绿,是对“无”的判定,不是对可靠的判定。