很多專案不是卡在「不會提審」，而是卡在資料不齊、資料和應用行為不一致，或者審核員拿到資料後根本跑不通驗證路徑。這篇按客戶實際提交順序，把上架前需要準備的資料和最常見的缺口一次講清楚。
如果你只想知道最少要交什麼，通常至少要有這幾類：安裝包、應用名稱和描述、圖示和截圖、隱私政策連結、聯絡人信箱、測試帳號。如果涉及訂閱、登入、權限、刪除帳號、地區限制或特殊功能，還要補相應說明和最短驗證路徑。
至少要確認目前提交的是哪個版本、對應哪個環境、是否需要登入、是否依賴某個地區或白名單。很多專案表面「包給了」，實際上給的是測試包或舊包，審核員打開後和商店說明完全對不上。
包括應用名稱、短描述、長描述、圖示、截圖、宣傳文案。這裡最常見的問題不是沒寫，而是承諾過度、截圖和現網功能不一致、文案裡寫了應用裡沒有的功能。
無論是 Google Play 還是 App Store，隱私政策連結都要真實可訪問，而且要和應用裡的實際行為對齊。如果應用採集手機號、位置、裝置資訊、支付資訊，這些在商店聲明和隱私政策裡都要講清楚。
凡是需要登入、訂閱、會員、驗證碼、邀請制或企業白名單的應用，都不要只給一個帳號就結束。審核員需要的是「能進核心功能的最短路徑」，不是讓他自己猜入口。
如果會請求相機、相簿、麥克風、定位、通知等權限，最好提前寫清楚在哪個頁面觸發、為什麼需要、觸發後能完成什麼功能。權限用途和實際觸發頁面不一致，是最常見的審核往返點之一。
有訂閱的應用要準備訂閱項說明、價格邏輯、恢復購買方式；有帳號系統的應用要準備刪除帳號入口和流程說明。這兩塊現在經常不是「可選項」，而是審核時會重點看的地方。
如果你的應用有特殊入口、需要切換地區、需要先完成某一步才能看到核心功能，最好直接寫進審核備註。經驗上，備註越具體，審核員越容易按你的路徑完成驗證。
例如隱私政策說不採集資料，應用裡卻有登入和裝置識別；或者商店截圖展示的是舊版本頁面。
帳號不可用、驗證碼收不到、訂閱入口太深、地區限制沒說明，這些都會讓審核員直接卡住。
開發團隊知道功能怎麼進，不代表審核員知道。審核說明應該按「打開應用後第一步做什麼、第二步點哪裡」的方式寫。
比如金融、社交、UGC、AI 生成、定位、VPN、外部支付跳轉等場景，如果沒有提前把合規邊界和驗證路徑講清楚，審核節奏一定會變慢。
先明確這次是上 Google Play、App Store，還是雙平台；再確認實際提交的是哪個可審核版本。
名稱、描述、截圖、隱私政策、聯絡人資訊先收齊，不要等到提審當天再臨時拼。
用測試帳號從頭走一遍，把登入、訂閱、權限、刪除帳號、核心功能入口和關鍵頁面都按最短路徑跑通。