一条 4.3（Spam）+ 4.2.6（App Generation Services）的拒审，对象是一个 1.0 版本的单功能工具，所在的类别早已被近似竞品挤满。记下来，是因为它踩中的盲区从开发侧完全看不见。
审核判断的永远是商店表面——图标、截图、名称、描述——而不是开发过程。构建、测试、代码审查，这些门回答的都是"它能不能用"，没有一项回答"它出现在搜索结果里时，和邻居能不能区分开"。4.3(b) 说的就是这件事：重复与不可区分，是表面属性。4.2.6 更进一步：它判断的是提交物长得像不像生成服务的产物，而"代码是一行行手写的"这个事实没有任何通道能到达审核。本地质量分从来不是人类判断的代理；在 spam 这个类目上，连质量都不是变量，可区分性才是。
4.3 不是对开发方式或诚意的指控，是对表面的判定——所以修法是让表面可区分，而不是自证清白。
通用的修复顺序，顺序本身承重：
1. 先审计类别，再动任何文案。用应用最直观的两个关键词在商店里搜，把自己的首屏截图和排在前面的结果并排放。如果截图换进对方的页面毫不违和，你看到的就是审核看到的。对着商店自己的搜索结果验证，而不是对着自己的意图；这一步的结论决定后面做的是文案工作还是产品工作。 2. 差异点必须住在表面上：第一张截图、描述里点名的一条功能、名称里的独特词。放在第三次点击之后的功能，对审核不存在。 3. 回应审核时按 guideline 条目逐条列出可核对的差异——事实性的、不带情绪、不叙述项目时间线。审核要的是能核对的区分点，不是诚意。 4. 如果审计的诚实结论是"指不出一个只有这个应用展示的东西"，那要修的是产品，不是文案——省下一次注定重演的提交。
一分钟自检，任何提交前都值得跑一遍：搜索你的应用最直观的两个关键词，把第一张截图和排最前面的几个结果放在一起。如果指不出一样只有你的截图里出现的东西，4.3(b) 的风险就在场，而且和代码质量无关。