很多團隊把 2.3 / 4.3 當作「文案沒寫好」。真實情況更接近：審核在判斷你是否用中繼資料「講一個應用內無法驗證的故事」，以及你是否用高相似度應用批量覆蓋關鍵詞。本文把這類拒審拆成三件事：哪些信號會觸發懷疑、整改優先級怎麼排、以及如何用證據包把「我確實改好了」說清楚。
Apple 會把「中繼資料說得很精彩、但應用內驗證不到」視為高風險信號。要過審，你需要做的是讓商店頁承諾、截圖展示、實際功能入口三者一致，並且把差異化與真實性做成可驗證的證據。
審核員並不靠直覺判斷「你在操縱」，而是靠一組可復現的矛盾：中繼資料暗示的價值、用戶在應用裡看到的內容、以及你提供的驗證路徑，三者對不上。
標題、關鍵詞暗示「某類能力」，但應用內沒有可驗證入口，或必須跳到外部 Web 才能完成關鍵動作。
截圖展示的 UI、功能閉環或權益，在審核路徑裡找不到；或屬於「典型營銷圖」，與真實介面差距過大。
一堆高熱詞把應用描述「拉向別的品類」，但應用內並無對應內容，容易同時觸發 2.3（誤導）與 4.3（操縱覆蓋）。
同一帳號或關聯帳號在短時間內提交多個高度相似的包：UI骨架、核心流程、素材風格相近，容易被判為重複或批量操縱。
你寫了很多解釋，但缺少可登入帳號、可復現路徑、預期結果與截圖證據。審核員無法驗證，就會傾向拒審。
訂閱價格、試用條款、取消方式在中繼資料裡寫得很好看，但應用內入口模糊或描述不一致，會被當作誤導性設計。
把這張圖當作團隊內部的「排查地圖」：先定位觸發點，再決定你該改中繼資料、改應用內路徑，還是改矩陣策略。
如果你只想要一個能落地的優先級：先讓審核員能驗證，再讓系統看到差異化。很多團隊反過來，先做 UI 改皮，結果依舊被判「重複/操縱」，因為故事仍舊講不通。
我不建議把審核備註寫成辯論，更有效的是把它寫成一份短腳本：審核員照著做就能驗證。結構固定為四段：
如果你同時在提交多個包或頻繁改中繼資料，建議控制節奏：先讓一個版本穩定通過並留存通過記錄，再進行下一輪改動。短期內大量相似提交，會讓你更容易進入「放大審查」模式。