本轮资料里没有找到 Rushi 被拒审的原信；相反，发布复盘把它作为 DrowseBook 的对照案例：Rushi 选 Lifestyle，通过工具定位和来源说明降低了 China mainland 内容风险。
Rushi 这类产品在 App Store 上架时，需要让审核员快速理解：它提供什么内容、来源是什么、是否收集数据、是否有付费和社区功能。
类目风险通常来自表达不清。越像一个安静阅读工具，越要在说明里避免夸张效果承诺；越可能被误解成宗教服务，越要把它写成离线、买断、无广告、无账号的个人工具。
开发细节补充：这篇记录放在 Rushi 如是 的产品日记里，不是为了把一个功能包装成故事，而是把“05 · 审核策略：内容产品如何降低类目风险”放回真实项目推进中看。它要同时回答三件事：用户为什么需要这个点，开发时哪些边界必须先定住，以及这个选择会怎样影响上架、推广和后续课程复盘。平台口径是 iOS / 网页 / 公共领域，当前公开状态是 落地页 / 开放内容 / CC0，所以文案不能脱离真实发布进度。
对应的 docs 线索主要来自 金刚经产品策略、公共文本资源记录、音频与资源策略、多语言和上架文案。公开页面不会照搬内部工作记录，而是把可公开、可学习、不会泄露私密路径和账号信息的事实整理出来。Rushi 相关 docs 覆盖开发哲学、痛点功能清单、UI 结构、语言覆盖、定价下载、音频资源和开发里程碑。 文本资源记录把金刚经、心经、多语言版本和公共领域来源分开处理，重点不是收集越多越好，而是降低误读。 佛珠系统、音频资源和静心 UI 的记录说明产品体验要服务阅读仪式，不应制造复杂负担。 公开文章需要避免把内容产品写成权威解释，而是讲来源、版本、语言边界和用户阅读辅助。
从产品功能看，Rushi 如是 关联的能力包括：金刚经与心经、13 种语言、CC0 公共领域文本、安静阅读落地页。写这类日记时，不能只说“做了什么”，还要说明为什么先做这些、为什么暂时不做另一些。比如一个按钮、一个导入流程、一个本地模型开关或一段截图文案，放在代码里只是小改动，放在产品里却会影响用户理解、审核员复现和后续推广素材。
从工程推进看，这篇日记对应的检查点是：公共领域内容产品和多语言页面。真实开发最容易失真的是中间过程，因为最后页面看起来只有一个结果，但实际会经历方案取舍、权限确认、素材准备、测试设备、审核备注和发布节奏。把这些过程写下来，后面做同类产品时才不会重新踩同一个坑。
从隐私和合规看，当前约束是：公开文本内容为主，正式 App 隐私政策以后以实际功能为准。这类信息必须前置到开发日记里，因为独立产品的可信度不是靠口号建立的，而是靠数据在哪里处理、用户能不能退出、功能是否离线可用、商店页怎么承诺、隐私政策是否与实现一致这些小事实积累出来的。
从课程和复用看，这篇内容可以沉淀到 内容产品、多语言、静心 App。它的价值不只是给访问者看一个产品，而是展示一个独立开发者怎样把想法转成可验证的产品：先收窄场景，再选技术路径，再做体验最小闭环，最后把审核、推广、运营数据和失败教训都纳入下一次迭代。
公共领域内容产品要先讲清来源和边界，再谈 UI、语言和商业化。 这也是为什么每篇产品日记都要写到足够长：不是为了凑字数，而是为了把“证据、决策、实现、边界、复盘”都放在同一页，让读者看到一个判断是怎样被逐步验证出来的。最难的是尊重宗教文本语境，同时把阅读、音频和仪式感做成轻量 App。
所以这篇日记的结论不是“功能已经写完”，而是把一个阶段的判断公开化：哪些证据足够支撑继续推进，哪些资料还需要回到源码、商店材料、公开文案或运营观察里补齐。这样的记录会比单纯的发布公告更慢，但也更真实，能让产品页、发布记录和课程内容保持同一条事实线。
验收时我会把它拆成四个层次：第一层是用户路径能不能走通，第二层是异常状态有没有被诚实处理，第三层是页面上的按钮、状态、截图和文案是否对应真实发布渠道，第四层是公开证据能否支撑这个判断。只要其中一层对不上，产品看起来再完整，也不能算真正进入下一个阶段。
交接时也要保留边界：源码、构建、测试、商店元数据、公开文案、平台反馈和运营观察分别保存原始资料。产品日记只把这些事实翻译成读者能理解的过程，不替任何私有记录保存原始材料。
把这些内容公开出来，还有一个很现实的原因：AI 教程如果只展示成功结果，很容易让人误以为产品是一次生成出来的。真实情况恰好相反，真正可学习的是一次次收窄、验证、失败、补证据和重新提交。日记越具体，后续读者越能看到判断的脉络，而不是只看到一个漂亮的截图。
先把它写成工具，而不是服务
Rushi 的 Review Notes 明确说明它是 Buddhist practice utility，不是 religious service。它不售卖功德、祝福、救赎或任何精神结果，也不募捐。
这句话很关键：审核员不只看 App 里有什么，还看你如何解释它。Rushi 把阅读、佛珠计数和抄经写成离线个人工具，而不是承诺效果的服务。
来源和版权要落到 Guideline 5.2
审核备注把经文来源放到 Guideline 5.2 下解释：金刚经、心经和多语言版本来自公有领域或可核验来源，声音素材来自 CC0 或自录，并在 App 内 About 页列出。
这不是为了写得漂亮，而是为了让审核员能快速判断：产品没有在分发不明版权内容，也没有靠模糊来源规避内容审核。
隐私简单也要写得具体
Rushi 的审核备注写清楚：无网络请求、无分析 SDK、无崩溃上报、无追踪；书签、计数和抄写内容只保存在本地。iOS 隐私清单也只声明必要的 UserDefaults 原因。
这类内容产品最怕一句笼统的“不收集数据”。越简单，越要把简单具体化，让隐私政策、App Privacy 问卷和代码行为互相对得上。
不要把通过当成判例
Rushi 的通过经验可以复用的是方法：Lifestyle 类目、工具定位、来源透明、无 IAP / 订阅 / 广告、无账号、iPhone-only 和审核备注解释。不能复用的是侥幸感。
同样是内容型产品，DrowseBook 因 Books 类、内置样书和 China mainland 可售性被 Guideline 2.1 卡住。两个案例放在一起，才是之后立项和上架时真正有用的判断框架。