隱私政策與使用者協議產生

應用程式要上架，隱私政策與使用者協議是躲不掉的兩份文件。難的不是抄一份回來，而是抄回來的那份和你的產品根本不匹配：應用商店審核會逐項比對「聲明蒐集的資訊」、「實際申請的權限」、「整合的 SDK」三者是否一致，一處對不上就會被退回，還可能被要求限期改善。這個工具的做法是讓你先把產品事實說清楚：蒐集哪些資訊、用了誰的服務、怎麼收費、能不能註銷，再由這些選項逐條產生正文，改一個勾選，文字立刻重寫。

怎麼用它產生

• 兩套文件共用一組基礎資訊：頂部切換「隱私政策」與「使用者協議／服務條款」，產品名稱、主體、聯絡方式、生效日期不用重填，兩套條款各自展開
• 蒐集範圍逐條成文：勾選裝置資訊、日誌、位置、相機、麥克風、通訊錄、儲存、剪貼簿、感測器、付款資訊等類別後，每一條都會寫成「蒐集什麼、用來做什麼」的形式並附上系統權限說明；未勾選的不會出現，避免過度聲明
• 三種蒐集基調：純本機執行（不蒐集任何個人資訊）、只蒐集必要資訊、蒐集並與第三方分享。選第一項時正文會直接聲明不申請權限、不上傳資料，這類工具型產品最容易被漏掉的正是這句
• 第三方能力清單：推送、統計、廣告、付款、地圖、第三方登入、客服、雲端儲存、分享、當機監控可分別勾選，SDK 名稱以逗號分隔填入就會單列一段，與商店要求的第三方共享清單對齊
• 儲存與 Cookie：區分境內儲存與涉及跨境傳輸兩種表述，跨境一支會寫出安全評估、標準合約備案等法定程序；Cookie 與 localStorage 是否使用也各有對應條款
• 你的權利與註銷管道：查詢、更正、刪除、撤回同意、取得副本、拒絕自動化決策逐項列出，註銷方式依應用程式內自助、電子郵件申請、無需帳號三種分支產生對應流程與答覆時限
• 未成年人條款分級：一般族群與可能涉及 14 歲以下兩種寫法，後者會加入監護人同意與兒童資訊刪除的承諾
• 使用者協議涵蓋收費與免責：完全免費、一次性付費、訂閱自動續費、含廣告四種模式各有一套扣款與關閉續費的表述，退款方式獨立選擇；責任限制載明以近 12 個月實付費用為上限，並保留依法不得排除的責任
• 可勾選的附加條款：帳號實名與安全責任、使用者內容與授權、AI 產生內容聲明、服務限額與合理使用、出口管制、通知與送達，按需增減不會留下空標題
• 缺失項不會默默出錯：必填資訊沒填時，正文以【請填寫：…】佔位並在下方彙總提示，匯出的檔案裡同樣保留，不會被誤認為已填完整

適用情境

• 獨立開發者第一次提交 App Store、各家 Android 商店或鴻蒙應用市場，需要一份結構完整的隱私政策
• 純本機計算的工具型應用，想準確表達「我們不蒐集資料、也不申請權限」
• 小程式上線前補《使用者隱私保護指引》對應的說明文字
• 產品改版接入新的統計或推送 SDK，需要把第三方段落同步進去
• 把既有政策貼進來對照，檢查是否漏掉註銷管道、跨境儲存、未成年人等必備條款
• 需要同時給出純文字（商店後台貼上）、Markdown（放進儲存庫 README）與 HTML（掛在官網頁面）三種格式

常見問題

• 產生的文字能直接提交嗎？結構與常用表述是依現行法規與應用商店的常見審核重點撰寫的，可以直接當作底稿，但必須逐條核對你的真實做法。工具給的是範本，不能替你的產品承諾你做不到的事，也不構成法律意見；涉及敏感個人資訊、跨境傳輸、付費訂閱或醫療、金融、教育等專門領域，建議再經過一次專業審閱
• 「隱私政策」和「使用者協議」要分開嗎？要。前者回答「你怎麼處理我的資料」，後者回答「能不能用、怎麼用、出問題誰負責」，多數商店要求分別提供兩個頁面或兩個連結，本工具的兩套文件正是為此分開
• 為什麼強調 SDK 清單？審核方會把你聲明的 SDK 清單與安裝檔靜態掃描結果比對。列了卻沒整合、或整合了卻沒列，都會被退回，所以這一欄單獨成段並保留自由填寫
• 純本機工具該怎麼寫？把「整體蒐集情況」選成不蒐集任何個人資訊，正文會自動改為不蒐集、不上傳、不申請權限的聲明，同時保留聯絡方式與政策更新段落，這比套用一份蒐集十幾項的範本更經得起核對
• 生效日期與更新日期有什麼用？兩者都會寫進文件開頭與「本政策的更新」條款。政策改動後只改內容不改日期，等於無法向審核方與使用者證明版本先後，這是常見的退回理由
• 填寫的內容會上傳嗎？不會。表單值只存在於目前頁面的記憶體，正文由瀏覽器現場組裝，複製與下載走的都是本機 Blob，頁面不發出任何請求，重新整理即清空
• 還需要準備什麼？應用商店一般還會要求權限用途說明彈窗、第三方共享清單表格與 SDK 目錄，這些需要與本文逐字對齊，先確定這裡的選項再改其他文件，比反過來補要省事