一次 Guideline 5.6 的复盘。它挂在 Developer Code of Conduct 名下,读起来像处分,但正文给的理由其实是质量:整体未达到上架所需的标准——有意义、打磨过、可靠——并写明了一个具体日期,在那之前不接受重新提交。
这类拒审最难的地方:它不点名任何一行代码。这也正是它能活过所有本地检查的原因——本地检查测的是零件(能编译、测试通过、截图都在),而 5.6 判的是整个产品。一个功能齐全、组件级全绿的应用,照样可以在“打磨”这一层不及格,且没有任何日志会告诉你。本地质量分在这里也救不了你:打磨与可靠是评审对整体体验的判断,不是静态分能代理的东西。
通用的解法,顺序本身就是载荷:
1. 先把日期当日程表。带明确日期的暂停不是偶发故障:日期之前,任何版本的重提都不可能通过,提前的回复也不会被当作申诉。窗口期是用来干活的,不是用来重试的——和配额重置、冷却期是同一类东西,先确认条件已过,再花掉那一次提交名额。
2. 把模糊的标准翻译成可执行的清单。意见不点名,就自己点名:全新安装、真实网络,像评审那样手动把“应用存在的理由”那条主流程从头走到尾;专挑评审真正看得见的类别——空白页、无响应的按钮、卡顿、占位文案、付费路径上任何一次失败。“每个零件都对”不等于“产品及格”,这一条是“绿 CI 掩盖核心路径零覆盖”的商店版。
3. 窗口打开后,带着具体改动与证据回复,而不是反驳。5.6 的解法是证明质量线现在够了,不是论证它一直都够。顺带把更新说明写诚实:改了什么、验证了什么,一句是一句;“各种修复与稳定性提升”这种套话,在已经怀疑质量的评审眼里不是解释,是佐证。
一分钟自查:把当前构建装到干净设备上,交给没写过这份代码的人,不给提示,让他走完那条主流程。他犹豫、卡住、或看见任何没做完的地方,就是质量评审会找到的缺口——没有任何本地指标能预测它。
那次拒审最后是过了。回头看最值钱的一条:日期之前,重试只会消耗提交记录,工作才可能改变结果。