Claude Code 提示词库：让您的 Web 应用为 App Store 和 Google Play 做好准备

审查这个 Web 应用在原生 iOS 和 Android WebView 应用中使用时存在的问题，并修复发现的问题。检查：viewport meta 标签；从 320 px 到 1024 px 没有横向溢出；点按区域至少 44 x 44 px；固定的页眉、页脚和底部导航使用 env(safe-area-inset-top) 和 env(safe-area-inset-bottom) 留出内边距，确保没有内容被刘海或主屏幕指示条挡住；没有只能靠悬停打开的菜单；输入框字号至少 16 px，以免 iOS 自动缩放；没有仅限桌面端的侧边栏；没有依赖鼠标的元素。同时让首次绘制更快：懒加载重量级组件，用骨架屏代替空白页面。列出修改过的每个文件，以及所有无法自动修复的问题。

为这个应用创建 /privacy 和 /terms 页面。先检查代码库，列出我们实际收集或处理的每一类个人数据：身份验证提供商及其存储的内容、包含用户数据的数据库表、分析或错误跟踪 SDK、支付提供商、推送通知服务、会接收用户内容的第三方 API。根据这份清单，用通俗易懂的语言撰写隐私政策，包含以下部分：收集的数据、用途、第三方、保留期限、用户权利、账户删除（链接到 /delete-account）、联系邮箱，并说明 iOS 和 Android 应用加载的是同一项服务。不要编造我们并没有的做法。在页脚和设置页面中链接这两个页面，确保它们在 320 px 宽的屏幕上清晰可读，并把任何不确定的表述标记为 TODO，以便我确认。

Apple 准则 5.1.1 和 Google Play 要求：能够创建账户的用户，也必须能在应用内删除账户。请实现以下内容：设置中的“删除账户”按钮，带确认对话框，说明删除的后果；一个服务器端函数（边缘函数、API 路由或云函数，admin 或 service-role 凭据只在服务器端使用），删除属于当前已认证用户的所有数据行，然后删除该身份验证用户本身；成功后让用户退出登录并显示确认页面；一个公开的 /delete-account 页面，为已经卸载应用的用户说明操作步骤，并提供邮箱联系方式。如果存在订阅，在对话框中说明商店订阅需要在 App Store 或 Google Play 设置中单独取消。如果项目已有测试配置，为这个服务器函数添加测试。

审核人员会拒绝显示空白页面或原始错误信息的应用（Apple 2.1，Google Play 的功能损坏政策）。检查这个应用中的每一次数据获取和每一个路由，确保每一处都具备：加载状态（骨架屏或加载指示器）、带一句有用说明和主要操作的空状态，以及带易懂提示和“重试”按钮的错误状态。添加一个带友好备用界面的全局错误边界。显式处理网络故障：当 fetch 因设备离线而失败时，明确提示设备处于离线状态，而不是显示笼统的错误。清除控制台错误和未处理的 Promise 拒绝。列出改动过的路由。

我们的原生 iOS 和 Android 应用在加载这个 Web 应用时，使用一个包含标记 WebViewGoldApp 的自定义 User-Agent。添加一个小工具函数 isNativeApp()，检查 navigator.userAgent 中是否包含该标记，并在 html 元素上添加一个可供 CSS 选择的 data 属性或 class（例如 data-native-app）。然后，仅在原生应用内运行时：如果 Cookie 横幅对应用用户而言并非法律要求，就隐藏它；隐藏所有“下载我们的应用”或“在应用中打开”之类的推广；隐藏网站顶部页眉以及页脚中指向营销页面的链接；隐藏外部社交媒体链接，或用 target=_blank 打开它们，让封装层把它们交给系统浏览器；显示底部标签导航，代替桌面端菜单。在浏览器中保持网站原有的行为不变。

这个应用提供 Google 登录（可能还有其他第三方登录）。Apple 准则 4.8 要求提供一个同等的、注重隐私的登录选项，Sign in with Apple 就是标准做法。使用我们身份验证库中的 Apple 提供方来添加它（Supabase Auth、Firebase Auth、Auth.js 或 Clerk：先判断我们用的是哪一个，再按照它文档中的 Apple 提供方配置步骤操作）。Apple 按钮的尺寸和醒目程度要与 Google 按钮相同，并遵循 Apple 的按钮设计规范。Apple 只在首次登录时返回用户姓名，因此要在首次登录时把它保存下来。把我必须在 Apple Developer 门户中完成的后台步骤（Services ID、密钥、回调 URL）写成清单，保存在 SETUP-APPLE-LOGIN.md 中。注意：在原生应用内，WebViewGold 封装层会自动识别 appleid.apple.com 并处理弹窗，因此登录流程本身不需要任何应用专属代码。

在 iOS 和 Android 应用内，数字产品和订阅必须通过应用内购买销售（Apple 3.1.1，Google Play 结算），而不能走我们的 Stripe 结账。WebViewGold 封装层集成了 RevenueCat，当页面导航到 revenuecat://purchase?external_id=USER_ID&product=PRODUCT_ID 时就会发起购买（product 是 RevenueCat 控制台中显示的产品 ID；external_id 是我们的用户 ID，以便 RevenueCat 把这笔购买归属到对应用户）。请实现：当 isNativeApp() 为 true 时，“升级”和“购买”按钮把 window.location.href 设为该 scheme，并带上当前用户 ID 和对应的产品；在浏览器中继续使用 Stripe。添加一个服务器端点，接收 RevenueCat webhook，验证 authorization 请求头，并更新数据库中该用户的权益，这样 Web 应用在下次加载时就能解锁相应功能。添加一个“恢复购买”链接和一个“管理订阅”链接，后者说明订阅需要在 App Store 或 Google Play 设置中管理。不要在原生应用内显示 Stripe 价格或外部支付链接。

原生应用通过 WebViewGold 支持推送通知。当页面导航到 registerpush:// 时会触发系统权限弹窗；导航到 checkNativePushPermissions:// 可以读取当前状态，片刻之后它会注入一个 JavaScript 变量 nativePushEnabled（true 或 false）。构建一个授权引导页面，仅当 isNativeApp() 为 true 时，在新手引导或首次登录之后出现一次：用一句话说明我们会发送什么（例如订单更新和回复），提供一个导航到 registerpush:// 的“开启通知”按钮，以及一个“以后再说”链接，把用户的选择在 localStorage 中记住 30 天。在设置中添加一行“通知”，检查 nativePushEnabled；如果通知已关闭，显示一个导航到 settingsapp:// 的链接，用于打开系统设置。绝不要在应用的第一个页面上触发 registerpush://。