一条 4.3(a) 拒审(设计-垃圾应用)，一个多月后翻案。值得记下的不是这次的事，而是这类拒审的通用解法——它和崩溃、缺元数据那类拒审不是一种东西。
4.3(a) 说的不是 app 有 bug,而是它和其它开发者提交的应用在二进制、元数据或概念上相似、只有微小差异。这是对“差异性”的裁决，不是对“质量”的裁决。
为什么它本地不可见：构建、测试、元数据检查可以全绿，因为它们度量的是“这个 app 自身做得对不对”，而 4.3 度量的是“它长得像谁”。相似度这个信号只存在于审核那一侧的视野里，任何本地检查都量不到它——绿 CI 和 4.3 拒审从来不矛盾。
解法，以及为什么这个顺序重要：
1. 把拒审信读成差异化缺口清单，不是缺陷清单。二进制、元数据、概念三个维度，至少一个要真的变。 2. 先改产品，再改文案。能翻转裁决的是别人没有的工作流或内容，不是把同一件事描述得听起来不同。 3. 让差异化长在审核最先看的地方：首屏截图、描述第一段。藏在三级页面里的独特功能，对这道裁决等于不存在。 4. 重提时在 Resolution Center 里具体写清什么能力是新的、给谁用、解决什么。重提一个没变的二进制，每次都会得到同样的裁决——前提没变，结论不会变。
一分钟自测：把你的商店页和品类里头部三款竞品并排打开。如果一个陌生人说不出你的 app 做了什么而它们没做，审核也说不出来——这就是 4.3 的风险敞口。更狠的一步：你的截图换到竞品页面上会不会显得违和？不会的话，差异化就没长在审核看的地方。
最后一条更通用的：验收标准永远在别人手里。本地能跑的门，和真正给这件事打分的门，量的从来不是同一个东西。