App 上架送審排程流

🎯 這條流程解決什麼

App 上架送審是整個發版週期裡最瑣碎、卻最容易卡關的一段。一個版本真正能送出去，背後要對齊的東西遠比想像中多：版本更新說明要寫中英兩版、商店截圖要不要跟著新功能換、隱私揭露（App Store 的 Privacy Nutrition Label、Play Console 的 Data Safety 表單）要不要更新、新加的權限有沒有寫清楚用途、有沒有觸發出口管制或第三方 SDK 揭露。任何一項漏掉或填錯，輕則被退件重送、整個檔期往後拖三到七天，重則被平台標記政策疑慮，影響後續審查信任度。

實務上這段工作多半落在發版負責人一個人身上，而且常常是發版當天臨時趕。寫版本說明要翻這個 Sprint 合併了哪些 PR、對照工單確認哪些是對使用者有感的功能、再憑記憶補上去年某次被退件學到的眉角。一次完整跑下來，從蒐集資訊、撰稿、截圖、填隱私表單到實際提交，大概要耗掉發版負責人 1.5 到 3 個小時，而且全靠人腦記憶，越接近上線越容易出錯。對一個月發兩到四次版的團隊來說，這是每月固定燒掉的半天到一天工時，還不算被退件重來的隱形成本。

導入後的改變

導入前：每次送審都是一場記憶力測驗。發版負責人臨時翻 commit、手寫更新說明、逐項回想審查要件，平均耗時 1.5～3 小時，退件率高，被退一次就再賠 3～7 天檔期。資訊散落在 Git、工單、上次送審記錄各處，新接手的人完全沒有 SOP 可循。

導入後：版本一進發布分支，系統就先把這版的 PR、工單、提交記錄整理好，AI 草擬中英文更新說明初稿，並比對出一份送審檢核清單告訴你「截圖該不該換、隱私揭露有沒有新增項、權限說明補了沒」。發版負責人從「從零生產」變成「對著清單做確認與微調」，前置作業時間可壓到 20～30 分鐘，省下約 7 成工時。更關鍵的是檢核清單把容易漏的項目顯性化，因疏漏導致的退件大幅減少，檔期更可預測。版本說明可串接 內容改寫 潤飾成更貼近使用者語氣的版本；整條送審節奏也建議納入團隊的 自動化 發版管線統一管理。

流程怎麼運作

對應 frontmatter 的五個節點，逐步說明：

1. 觸發：發布分支（📥）— 當版本合併或打 tag 進入 release 分支，GitHub / GitLab 的 webhook 觸發 n8n / Make 工作流。這裡用「進發布分支」當訊號，而不是用每日排程，是因為送審本來就該綁在版本凍結這個明確事件上。

2. 彙整版本說明（📝）— 系統抓取本次 release 相對上一個 tag 的 PR 標題、commit 訊息與關聯工單，餵給 AI 撰稿節點，產出對使用者有感的中英文更新說明初稿。重點是把工程語言（修了哪個 bug、refactor 哪段）翻成使用者語言（哪個功能更快、更穩）。

3. 送審檢核清單（✅）— 比對這版是否新增權限、是否動到資料蒐集行為、截圖是否需要隨新功能更新，逐項列出 App Store Connect / Play Console 的審查必備項，標出「需更新」與「沿用上次」。

4. 排程送審待辦（📅）— 在 Google Calendar 建立送審任務，並依平台審查時間（iOS 通常 1～3 天、Android 數小時到數天）預留緩衝期，回推可上線日，避免壓線。

5. 負責人確認送審（🔔）— Slack 推送完整檢核結果與初稿給發版負責人，由人工逐項確認隱私揭露與權限說明屬實後，才實際提交。AI 只做前置彙整，按下送出鍵的永遠是人。

需要的工具與串接重點

• GitHub / GitLab：以 release 分支或 tag 為觸發源，建議用 protected branch 確保只有真正凍結的版本會觸發送審流程，避免測試 tag 誤觸。
• AI 撰稿節點：負責把技術提交轉成使用者語言的更新說明，建議在 prompt 裡固定品牌語氣與字數限制（App Store 更新說明有長度上限）。
• App Store Connect / Play Console：可透過官方 API 預填 metadata 與更新說明，但「實際提交審查」這一步刻意保留人工，不做全自動送出。
• Google Calendar：負責排程與緩衝期回推，讓上線日可預測。
• Slack：作為確認關卡的通知與簽核入口。

串接注意點：iOS 與 Android 的隱私揭露機制不同（Privacy Nutrition Label vs Data Safety），檢核清單要分平台維護；商店 API 的權杖要妥善保管，避免外洩造成未授權送審。

常見錯誤與注意事項

• 隱私揭露與個資屬高敏感環節：AI 產出的隱私清單僅為草稿，無法保證符合最新審查政策。每一項資料蒐集揭露、權限用途說明，務必由發版負責人與產品經理人工確認屬實，填錯隱私表單可能涉及對使用者不實揭露，後果遠比退件嚴重。
• 絕不全自動送審：提交審查是不可逆的對外動作，必須保留人工按下送出的關卡，AI 不取代對平台規範與法遵的專業判斷。
• 截圖與實際畫面一致：截圖若與當前版本不符，是常見退件原因，清單要明確標出需更新的截圖。
• 第三方 SDK 與出口管制：新增 SDK 可能帶來新的資料蒐集行為或加密揭露義務，這類需要法遵判斷的項目，系統只提醒、不替你勾選。

台灣中小企業情境案例

台中一家做親子記帳 App 的六人團隊，過去每次送審都由技術 leader 一個人扛，常在發版當天加班趕版本說明與隱私表單，半年內被 App Store 退件三次，兩次是隱私揭露沒跟上新功能、一次是截圖沒換，每次都賠掉約一週上線檔期。導入這條流程後，版本一進 release 分支就自動產出更新說明初稿與檢核清單，leader 確認時間從每次兩個多小時降到約 25 分鐘；接下來兩季發了七個版本零退件，原本壓線的上線日也能準時對外宣布，行銷檔期不再被審查不確定性綁架。

延伸應用

這條流程可以再擴充：送審通過後自動觸發上線公告與更新日誌發佈，串接 內容改寫 同步產出社群與電子報文案；也可加上「灰度發布百分比排程」，讓 Android 分階段放量並監看當機率，異常自動暫停放量。若團隊同時維護多個 App，可把檢核清單模板化，依不同 App 的權限與隱私基準各自套用。把送審納入整體 自動化 發版管線後，需求、開發、測試到上架就能形成一條可追溯的完整鏈路，相關環節可延伸參考 更多工作流。

流程圖

用到的工具

更多「專業服務」工作流

瀏覽全部工作流藍圖 → 自動化工作流中心 → AI Skills 食譜庫 →