价格调整影响评估报告
审阅状态：已完成三轮内部审阅，重点检查覆盖范围、一致性和表达清晰度。
1. 目的
本文旨在评估 2026 年 4 月 5 日生效的价格调整需求对当前 MysticX 造成的影响，并梳理支持全新会员与积分体系所需的各项系统调整。
本文基于以下资料：
z-2-reqirements/20260405 会员和积分 价格调整 包含IOS第一版本.docx- 当前仓库中的运行时配置与产品代码
docs/mobile-app-development-plan.md中已有的移动端规划内容
本文档仅作为技术调研与前期规划指南，未包含具体的代码库逻辑修改。
2. 需求摘要
2.1 需求文档中的目标商业模型
Web 端
保持当前四档积分包，继续原价销售。
目标会员结构如下：
| 方案 | 目标价格 | 目标积分 | 说明 |
|---|---|---|---|
| Gold 月付 | $19.99 | 6,000 | 循环订阅 |
| Diamond 月付 | $69.99 | 30,000 | 循环订阅 |
| Gold 年付 | $89.99 | 100,000 | 一次性即时发放全部积分 |
| Diamond 年付 | $299.99 | 1,000,000 | 一次性即时发放全部积分 |
移动端 v1 (iOS & Android)
移动端不提供积分包。
移动端不提供 Diamond 等级。
移动端仅提供 Gold 等级的订阅方案：
| 方案 | 目标价格 | 目标积分 | 说明 |
|---|---|---|---|
| Gold 周付 | $7.99 | 1,500 | 含 3 天免费试用 |
| Gold 月付 | $19.99 | 6,000 | 订阅 |
| Gold 年付 | $89.99 | 100,000 | 一次性即时发放全部积分 |
2.2 需求隐含的产品方向
- Web 端将继续充当灵活、多元的售卖渠道。
- 移动端将直接转型为侧重订阅模式的精简商店。
- 年付方案将成为业务转化策略中的核心主推项。
- 赠送积分将成为比以往更为关键的转化杠杆。
- 系统默认推荐位应明显向 Gold 年付方案倾斜。
3. 需求中的关键歧义
原始需求资料的方向大体明确，但在细节上存在几处规则冲突或决策缺失，必须在开发阶段前解决并确认。
3.1 周会员范围存在冲突
在主价格模型中，已明确 Gold 周付方案为 移动端专属。
但技术备忘部分又提到 Web 端会员页可能要支持周、月、年切换，且 Gold 和 Diamond 都要有。这与前面的平台拆分方案不一致。
3.2 年付积分回收逻辑不明确
原文要求年付方案的积分将一次性全额发放，同时又隐含提到如果取消计划可能需要做积分回收。
目前未定义的问题包括：
- 是用户主动取消订阅即可触发回收，还是仅在产生退款/拒付行为时才启动回收程序
- 若用户已消费部分获赠积分，剩余积分及账户余额的具体回收逻辑将如何界定
- 系统是否允许出现借额或负值的积分余额状态
3.3 每日奖励是否调整并不清楚
当前系统仍有按会员等级区分的每日 Card of the Day 积分奖励。
本次需求的核心调整点集中在订阅方案所附属的赠送积分上，但原始资料里又出现了类似 80 / 100 这种旧日奖励数字，和当前代码及主方案都不一致。
3.4 跨平台权益规则缺失
需求明确说明 移动端不支持购买 Diamond 会员，但并未说明在 Web 端已购买 Diamond 权益的用户，在登录 移动端时其身份与权益是否应继续被识别和生效。
合理默认假设应该是：
- 移动端不售卖 Diamond
- 移动端仍然承认用户从 Web 获得的 Diamond 权益
但这条需要明确确认。
4. 当前系统基线
4.1 已确认的当前线上价格与积分基线
当前 Web 运行时仍使用旧价格结构：
| 项目 | 当前线上状态 |
|---|---|
| Web Gold 月付 | $19.99 |
| Web Diamond 月付 | $69.99 |
| Web Gold 年付 | $167.92 |
| Web Diamond 年付 | $587.92 |
| Gold 月赠送积分 | 4,000 |
| Diamond 月赠送积分 | 24,000 |
| 积分包 | 2,000 / 5,000 / 12,000 / 30,000 |
| 每日 Card of the Day 积分 | Free 300 / Gold 500 / Diamond 1,000 |
4.2 已确认的运行时架构
当前会员系统是典型的 Web 优先、Stripe 优先架构。
已确认特点：
- Web 订阅由 Better Auth + Stripe 驱动。
- 月度订阅积分通过 Stripe 相关订阅事件发放。
- 一次性积分包通过 Stripe Checkout 购买。
- 当前会员页围绕 Free、Gold、Diamond 三档和月付 / 年付切换构建。
- 当前数据库只定义了三档会员：
FREE、GOLD、DIAMOND。
4.3 已确认的 移动端状态
当前仓库中并没有真正上线的 移动端商业化集成。
已确认结论：
- 没有 RevenueCat 运行时集成。
- 没有 StoreKit、App Store Server 或 Google Play Billing 集成。
- 没有 移动端商品目录的运行时代码。
- 没有 移动端专用订阅回调链路。
- 现有 移动端内容主要停留在规划文档，不是已上线代码。
这明确表明，兼容移动端 (iOS 和 Android) 并不仅是一项简单的配置修改任务，而应被视为全新开发主线。
4.4 已确认受影响的系统面
以下仓库区域已确认会直接受到本次价格调整影响。
| 系统面 | 当前职责 | 为什么会受影响 |
|---|---|---|
config/stripe.ts | 订阅展示价格、价格 ID、积分包定义、方案映射 | Web 价格主来源和方案映射都要调整 |
lib/credits.ts | 每日奖励和订阅赠送积分 | 赠送数值和赠送时机假设都要调整 |
lib/auth.tsx | Stripe 订阅生命周期与 Webhook 发积分逻辑 | 年付一次性发放、周 Gold、未来移动端来源订阅都会影响这一层 |
app/[locale]/(main)/membership/_components/PricingSection.tsx | 对外会员价格卡片 | 价格、赠送积分、推荐逻辑和文案都要更新 |
app/[locale]/(main)/membership/_components/ComparePlansSection.tsx | 会员对比矩阵 | 赠送积分和方案定位都要更新 |
app/[locale]/(main)/membership/_components/FAQSection.tsx | 会员 FAQ 文案 | 方案解释和计费说明都要更新 |
components/CreditPurchaseModal.tsx | Web 积分包购买体验 | 价值说明需要重算，移动端不应照搬这一套购买体验 |
app/api/v1/credits/purchase/route.ts | 一次性积分包 Stripe 购买接口 | Web 积分包继续有效，但平台策略必须表达清楚 |
app/api/v1/credits/route.ts 与 app/api/v1/card-of-day/route.ts | 积分余额与每日积分展示 / 发放 | 每日积分值可能需要确认或同步调整 |
app/api/v1/membership/route.ts | 会员状态接口 | 跨平台统一权益后可能需要扩展 |
prisma/schema.prisma | 会员等级与积分流水模型 | 如果要更精细区分发放来源，可能需要扩展 |
docs/credit-system*.md、docs/stripe-integration*.md、README.md | 对外与对内文档 | 所有旧价格引用都要更新 |
docs/mobile-app-development-plan*.md | 移动端路线图与 IAP 策略 | 必须与真实的移动端 v1 (iOS & Android) 商业方案保持一致 |
5. 按系统区域拆解影响
5.1 计费与订阅配置
计费影响
高。
当前订阅层默认假设是：
- Web 端卖两档付费会员：Gold 和 Diamond
- 只存在月付和年付两种周期
- 赠送积分是跟随订阅周期发放的
新的商业模型引入了：
- 大幅降低的 Web 年付价格
- 大幅提高的赠送积分数值
- 年付方案改成一次性整笔发放积分
- 移动端专属周 Gold 方案和试用
- 移动端商品结构与 Web 商品结构不一致
计费调整
- 更新 Web 价格常量和展示价格。
- 重构赠送逻辑，让年付支持一次性发放。
- 为不同方案增加更明确的元数据，区分：
- 月度循环赠送
- 年付一次性发放
- 移动端周付发放
- 平台专属售卖性
- 引入平台感知的商品模型，不能再假设一套目录通吃所有平台。
计费风险
若仅更新前端展示价格而未同步修改后端的积分赠送逻辑，系统将出现“价格已更新，但权益积分仍遵循旧规则”的严重业务错配。
5.2 积分台账与发放逻辑
台账影响
关键。
这次变化不仅是价格调整，而是订阅积分语义本身发生变化。
当前行为：
- 月订阅按计费周期发积分。
- 一次性购买在支付完成后发积分。
目标行为：
- Web Gold 年付一次发 100,000。
- Web Diamond 年付一次发 1,000,000。
- 移动端 Gold 年付一次发 100,000。
- 移动端 Gold 周付按周发 1,500。
台账调整
- 将月赠送逻辑和一次性年付赠送逻辑彻底分开。
- 为积分流水增加更清晰的标识，用来区分：
- Web 年付一次性赠送
- 移动端周付赠送
- 移动端年付一次性赠送
- 初次购买与续费
- 在开发前就先定义退款和积分回收规则。
- 为大额一次性赠送增加风控与幂等保护。
台账风险
- Webhook 重试导致重复发放整笔积分。
- 用户在退款前已消耗大量一次性积分。
- 升降级路径造成重复或错误补发。
台账建议方案
- 按支付来源维护幂等键。
- 在实现层面把“年付一次性赠送”视为独立逻辑，而不是沿用月赠送逻辑。
- 上线前确认是否允许负积分，以及如何处理回收失败。
- 给财务和客服准备可审计的回滚记录。
5.3 Web 会员页与价格展示
Web 价格页影响
高。
当前会员页基于 Free、Gold、Diamond 三栏加月付 / 年付切换。新的价值表达会明显变化。
Web 价格页调整
- 更新展示价格和赠送积分数量。
- 更新对比表文案，明确说明年付积分是一次性到账。
- 加强对年付方案的视觉推荐。
- 更新推荐位和默认选中逻辑。
- 更新最低单价、最佳价值等文案。
- 让积分包和会员价值关系重新对齐。
来自需求的 Web UX 指向
原文明确倾向：
- 默认聚焦 Gold
- 默认推荐 Gold 年付
- Diamond 侧重高效率或高折扣表达
- 年付必须清楚提示“一次性发满积分”
Web 价格页风险
如果 Web UI 只改一部分，用户会看到价格、赠送积分、对比说明彼此不一致，转化和信任都会受损。
5.4 积分包与积分包定位
积分包定位影响
Web 中等，定位层面偏高。
积分包在 Web 仍保留且价格不变，但它和会员方案之间的关系会被重新定义。
积分包定位调整
- 重新计算所有“最佳价值”“单价最低”文案。
- 重新检查积分包与会员的价格对比逻辑。
- 更新 FAQ 和说明文案，让用户理解：
- 积分包仍适合灵活补充
- 会员现在提供更强的综合积分价值
积分包定位风险
如果这部分文案没有同步重算，最初触发本次项目的“价格倒挂感知”问题会再次出现。
5.5 移动端 v1 (iOS & Android) 兼容性
移动端兼容影响
关键。
当前仓库没有真正上线的 移动端商业化链路。要支持 移动端 v1 (iOS & Android) 定价，需要新建或补齐完整移动端计费架构。
移动端兼容调整
- 实现符合 Apple 和 Google Play 规范的应用内订阅购买。
- 增加以下 移动端商品支持：
- Gold 周付，带 3 天试用
- Gold 月付
- Gold 年付
- 从移动端购买界面排除积分包。
- 从移动端购买界面排除 Diamond。
- 支持恢复购买。
- 支持试用态识别。
- 支持 App Store 与 Google Play 续费、取消、宽限期、退款等生命周期事件。
移动端兼容建议方向
现有移动端规划文档已经倾向 RevenueCat。除非业务明确决定自己直连 Apple 购买体系，否则 RevenueCat 仍是最合适的方案。
移动端兼容风险
- 购买流程不完整或表达不清，导致 Apple 审核被拒。
- Web 与移动端订阅状态不一致。
- 试用状态处理错误。
- 没有恢复购买入口。
App Store 与 Google Play 应用内付款政策约束
这是一条平台政策的硬性边界，不是设计偏好问题。它对支付墙的构建方式以及如何处理已在 Web 端付费的用户，有直接且不可妥协的影响。
Apple App Store 指引 3.1.1 规定：iOS 应用内销售的所有数字商品和订阅，必须通过 Apple 的应用内购买（IAP）完成。应用内不得：
- 添加任何按钮、链接或文字，引导用户前往外部网站（包括自家官网）完成付款。
- 告知用户在其他渠道订阅更便宜或有其他付款方式可选。
- 以任何形式暗示用户"去 mysticx.com 订阅"或"前往 Web 端管理付款"，即便措辞委婉，只要被 Apple 审核认定为绕过 IAP 的引导，均属违规。
Google Play 结算政策 对通过 Play 商店分发的 Android 应用，强制执行相同要求。
对 MysticX 的实际影响：
| 用户状态 | App 可以展示的内容 | App 绝对不能展示的内容 |
|---|---|---|
| 免费用户（从未在任何平台付款） | Gold 周付 / 月付 / 年付 的 IAP 购买按钮 | 任何 Web 订阅入口、Stripe 字样或外部结账链接 |
| 通过 IAP 订阅的 Gold 用户 | 当前 Gold 会员状态；通过系统订阅设置取消 | 任何"前往 Web 端管理付款"的链接 |
| 通过 Web/Stripe 订阅的 Gold 用户 | 识别并显示 Gold 会员状态（需接受其权益） | Gold IAP 购买按钮（否则会造成重复收费）；任何外部付款链接 |
| 通过 Web/Stripe 订阅的 Diamond 用户 | 识别并显示 Diamond 会员状态（需接受其权益） | Gold IAP 促销入口；任何外部升级链接 |
"Reader App" 豁免条款在此不适用。 Apple 指引 3.1.3a 允许以消费已购内容为主要功能的 App（例如 Netflix）省略应用内购买流程，也不必提供外部购买链接。但 MysticX 是一款交互式 AI 服务，应用本身即时生成核心价值，很可能无法通过该豁免条款的认定。
"前往 Web 端管理订阅"这句话，什么时候合规，什么时候违规：
- 合规用法：向已付费用户（Gold 或 Diamond）说明可在官网查看账单历史或取消订阅。这属于账户管理，而非新购引导。
- 违规用法：对免费用户展示此文字，暗示其可以翻墙绕过 Apple 进行付款。
RevenueCat 能正确处理 IAP 端的逻辑——它统一抽象了 StoreKit 和 Google Play Billing，并提供一套统一的权益层。但 RevenueCat 仅能识别通过自身完成的订阅。通过 Web 端 Stripe 购买的订阅，必须同步到 RevenueCat 或后端权益接口，否则 App 会向已付费用户展示购买界面，造成体验混乱甚至重复扣款风险。
5.6 Web 与移动端的统一权益
统一权益影响
高。
一旦移动端上线，商品目录就变成非对称结构：
- Web 卖 Gold、Diamond、积分包
- 移动端只卖 Gold 订阅，不卖积分包
统一权益调整
- 定义跨平台权益优先级。
- 允许 Web 购买的 Diamond 在移动端生效。
- 决定 移动端 Gold 用户是否只能去 Web 购买额外积分。
- 确保后端会员接口不管购买来源如何，都能返回正确的有效等级。
钻石会员在移动端的体验场景
这个场景需要明确设计，原因在于：移动端 App 本身不销售 Diamond，普通新用户无从得知 Diamond 是什么。然而在 Web 端付费的用户中，有相当一部分是 Diamond 会员，他们同样会登录移动端 App。
Diamond 用户登录移动端后应该看到什么：
- 后端会员接口必须根据服务端数据库记录正确识别其账户等级为 Diamond，不受购买来源影响。
- 所有依赖 Diamond 等级的积分奖励、每日福利和功能权限，均应按 Diamond 标准生效，与 Web 端一致。
- 会员升级页或订阅管理页不应出现空白状态或报错。由于移动端不销售 Diamond，对于已持有 Diamond 的活跃用户，该界面应当：要么完全隐藏升级入口，要么展示一张只读状态卡，说明"您是 Diamond 会员，如需管理订阅请前往 Web 端"。
- 不应向 Diamond 用户展示任何引导其订阅 Gold 的促销内容——Gold 是降级操作，对 Diamond 用户推送此类内容会造成困惑并损害信任。
绝对不能发生的情况：
- Diamond 用户不得因移动端权益层未能识别 Web 端订阅，而被错误地显示为 Free 或 Gold 等级。
- Diamond 用户不得被推送 Gold 购买流程，暗示其现有订阅无效或已过期。
- App 不得仅因移动端 IAP 商品目录只定义了 Gold SKU，就静默地将 Diamond 用户的每日积分奖励截断至 Gold 标准。
后端要求：
会员状态接口（app/api/v1/membership/route.ts）必须以服务端数据库中的会员状态作为唯一事实来源返回等级，而不能由移动端 App 自行从 IAP 本地收据中推断等级。移动端必须消费该接口的返回数据，而非依赖本地收据验证结果来决定用户功能权限。
统一权益风险
如果没有统一权益层，用户可能在一个平台是 Gold，在另一个平台却显示 Free 或只享受部分功能。
5.7 通知、CRM 与分析
分析与通知影响
中高。
原始资料明确提到会员升级通知和每日积分提醒。
分析与通知调整
- 增加会员权益升级通知。
- 如果每日领取仍是重要卖点，则为移动端增加 Push 提醒方案。
- 跟踪试用开始、试用转正、周付转化、年付转化、退款、拒付等指标。
- 如果当前已有埋点或看板，需要同步调整事件命名和统计口径。
分析与通知风险
如果分析体系还停留在旧商品模型，业务将无法判断新价格策略是否真的有效。
5.8 法务、客服与文档
法务与客服影响
高。
本次变化直接影响用户对计费、权益发放和退款规则的预期。
法务与客服调整
- 更新价格文档。
- 更新客服 FAQ。
- 复核服务条款和退款表述。
- 为年付一次性发积分增加明确说明。
- 在需要的地方增加移动端平台差异说明。
法务与客服风险
如果产品一次性发放 100,000 或 1,000,000 积分，但法务与客服文案模糊，售后压力和退款争议会显著增加。
6. 必要调整项汇总
6.1 产品与业务决策
- 最终确认周会员是否只在移动端上线。
- 最终确认年付退款与积分回收规则。
- 最终确认每日奖励是否需要同步调整。
- 最终确认 移动端是否承认 Web 购买的 Diamond。
- 最终确认 Web 价格页的推荐位与默认展示逻辑。
6.2 Web 运行时调整
- 更新价格常量。
- 更新赠送积分数量。
- 更新年付一次性发积分逻辑。
- 更新对比逻辑和方案标签。
- 重新计算所有单价类文案。
6.3 移动端运行时调整
- 实现真实的移动端计费集成。
- 增加试用支持。
- 增加周 Gold 商品处理。
- 增加恢复购买支持。
- 增加后端统一权益同步。
6.4 UX 与内容调整
- 更新会员页定位和表达。
- 更新 FAQ 与客服话术。
- 更新年付方案营销文案。
- 增加一次性发放提示。
- 更新移动端规划文档和上线说明。
6.5 运营与监控调整
- 增加退款处理规则和流程。
- 为客服补充年付争议处理手册。
- 增加新商品类型的分析事件。
- 为上线周添加订阅与积分异常监控。
7. 建议实施路径
Phase 0：先锁业务规则
- 解决第 10 节全部开放问题。
- 在编码前冻结最终商品矩阵。
- 明确退款和积分回收规则。
Phase 1：Web 价格与赠送逻辑重构
- 把价格与赠送配置收敛成一个可靠的单一事实来源。
- 实现年付一次性发积分。
- 更新 Web 会员页与积分包文案。
- 验证升级、降级、取消、续费路径。
Phase 2：移动端商业化底座
- 实现 RevenueCat 或等价的 IAP 层，统一接入 Apple App Store 与 Google Play Billing。
- 增加移动端 Gold 周付、月付、年付商品。
- 增加 3 天试用支持。
- 增加恢复购买和生命周期处理。
Phase 3：跨平台权益统一
- 统一 Web 与移动端的订阅状态。
- 测试跨平台登录与权益同步。
- 确认移动端对 Diamond 的识别行为。
Phase 4：文档、客服与监控
- 更新所有价格与计费文档。
- 更新客服 FAQ 与答复模板。
- 增加上线看板与异常告警。
8. 潜在挑战与解决建议
| 挑战 | 为什么重要 | 建议方案 |
|---|---|---|
| 年付一次性发大量积分会放大退款风险 | 用户可能先花掉大量积分再发起退款 | 上线前先定义回收规则，并明确是否允许负积分 |
| Web 与 移动端商品目录不同 | 容易造成用户理解混乱和权益漂移 | 建立平台感知商品目录和统一权益服务 |
| 周付 Gold 引入新计费周期 | 当前运行时默认主要围绕月付 / 年付逻辑 | 把周付视为独立方案类型，不要强行塞进月付逻辑 |
| 当前没有试用支持 | 试用态 bug 会直接造成客服和计费事故 | 在沙盒环境完成试用、续费、取消全链路测试后再上线 |
| 价格相关文案分散在多个位置 | 部分漏改就会出现前后不一致 | 上线前做一次完整价格文案扫表 |
| 已有老年付用户可能仍在旧价格 | 迁移规则不清会引发争议 | 提前定义是否保留旧价或迁移到新价 |
| 年付价值提升非常激进 | 利润结构和滥用风险都会变化 | 上线后重点监控转化率、退款率、拒付率、消耗速度 |
| 移动端不卖积分包 | 用户可能仍希望在手机内补充积分 | 在 App 文案和客服文档中明确平台策略 |
9. 建议 Todo 清单
- 锁定 Web 与移动端的最终商品矩阵。
- 确认周会员是否只在移动端上线。
- 确认年付退款与积分回收规则。
- 将价格与赠送配置收敛为单一事实来源。
- 实现年付一次性发积分逻辑。
- 重新验证 Stripe 订阅生命周期行为。
- 更新 Web 会员、积分包、FAQ、计费相关文案。
- 实现移动端 IAP 基础设施。
- 实现移动端 Gold 周付和 3 天试用。
- 实现恢复购买与跨平台权益同步。
- 增加周付、年付、试用、退款、平台来源等分析事件。
- 为上线周准备客服和监控方案。
10. 开发前必须确认的问题
- 周会员是否只在移动端上线，还是 Web 也要卖周 Gold 甚至周 Diamond？
- 年付方案取消、退款、拒付时，未使用的一次性积分是否要回收？
- 如果需要回收，但用户已花掉部分或全部积分，应该如何处理？
- 当前每日 Card of the Day 积分是否保持不变，还是也要一起调整？
- 移动端虽然不卖 Diamond，但是否要承认用户在 Web 购买的 Diamond？
- 移动端用户是否完全不能在 App 内购买额外积分，还是允许通过 Web 间接补充？
- 年付一次性积分是只在首次购买发放，还是每次年付续费都重新发满？
- 已有旧价格年付用户的迁移策略是什么？
- Web 会员页是否始终默认 Gold 年付，还是只对未登录和 Free 用户默认推荐？
- Diamond 年付在文案上应该强调“75% off”“最佳价值”还是其他表达？
- 移动端的 3 天免费试用是否只给周 Gold，还是月 Gold 也需要？
- 移动端订阅生命周期最终由哪个系统承接：RevenueCat、直接 App Store 处理，还是其他服务？
- 分销、邀请、佣金体系对移动端购买是否有特殊处理要求？
- 法务与客服是否需要单独增加“年付一次性发积分”的专项政策说明？
11. 最终评估
这次价格调整是一次较大的产品模型变化，但 Web 端仍然可控，前提是把它当作“价格与权益模型重构”，而不是简单改几个数字。
Web 端的核心工作主要是：
- 价格重构
- 赠送逻辑重构
- UX 与文案更新
- 退款与政策澄清
移动端的工作量明显更大，因为底层计费基础设施尚未真正落地。要支持 移动端 v1 (iOS & Android) 的周 Gold、试用、无积分包、无 Diamond，需要建设真实的移动端计费系统以及跨平台统一权益层。
建议的上线姿势：
- 先锁清业务规则。
- 再重构 Web 价格与积分发放逻辑。
- 把移动端计费作为独立主线，不要当成 Web Stripe 流程的小延伸。
- 只有在退款规则、权益同步和客服文案都明确后，才进入正式上线。