一条 4.3(a)(Design – Spam)的拒审信读起来像指控，其实是一份对比结论：审核认为这款应用与商店里已有的应用在二进制、元数据或概念上相似，只有微小差异。一款功能单一的小工具收到过这条，一个多月后解决了。值得记的是这条 guideline 的坐标系。
它量的不是应用好不好，而是应用和全店同类像不像。所有本地质量信号——构建、测试、元数据校验——都在拿应用和它自己比：和规格比，和昨天的构建比。这些全绿对 4.3(a) 没有预测力，因为被对照的那批应用根本不在你的仓库里。单一功能的小工具最暴露：一个概念如果搜索结果前五名彼此可互换，“只有微小差异”就是这个品类的常态，而不是指控。
通用的处理顺序，顺序本身承载信息——先定位因素，再动概念，文案最后：
1. 别先争 "spam" 这个词。它不是说你抄了代码；重读原文，判断三条里你踩的是哪条：二进制、元数据、概念。共用模板或成品源码起家的，二进制相似是可测的；描述和截图一眼模板腔的，先中的是元数据那条。 2. 差异化放在概念层，第一屏、第一张截图就能验证。埋在设置深处的功能，在审核的对照过程里等于不存在。 3. 然后才轮到元数据，它本来就被点名：把“简单易用”“功能强大”这类通用赞美换成只有这款应用能兑现的具体陈述。概念不动、只磨文案，移动不了那把量相似度的尺子。 4. 最后重提。申诉留给确实不同、被看错的情况：它改的是这一次判断，改不了相似度本身。
一分钟自测，提交前做：搜你的核心概念词，打开前五个结果，用一句话说出你的应用做了哪件它们都没做的事，这句话要能从第一张截图验证。说不出来，4.3(a) 就是活的险——在提交前修，不在拒审后修。
这和一条老教训同根：本地的质量分是拿自己和自己的规格比，永远代理不了那个拿你和所有人比的判决。