网站会员订阅制方案

> 📅 2026-08-11 建立 > 状态：方案讨论稿 v1，待确认

---

一、背景与痛点

当前网站（quant.aohan.net）的访问控制非常原始：

• 邀请码是固定写死的：在 .quant_auth.json 里存一个固定的 invite_code，首次初始化随机生成后永久不变，无法作废、无法换发、无法设置有效期。
• 注册即全部可见：目前全站几乎没有内容分级，只要注册成功，策略研究、选股逻辑、持仓推送等核心内容一律可见。
• 因子拥挤度失控风险：量化因子存在拥挤度——越多人看到并跟单同一因子，因子收益衰减越快、越容易失效。一旦网站推广，任何人拿到固定邀请码都能注册，核心策略等于被白嫖，因子价值被稀释。

核心诉求：把"固定邀请码"升级为"管理员动态签发、可设有效期、可作废的邀请码"，并建立分层会员体系，从准入和内容分级两个层面控制因子暴露。

---

二、方案总览

采用邀请 + 付费混合模式，内容采用分层订阅，兼顾当前个人使用与未来商业化扩展：

游客 ── 只能看公开页（首页/文档库公开内容）
  │
  ├─ 凭邀请码注册（免费试用期）──→ 基础会员（试用档）
  │                                  │
  │                            试用到期后付费升级
  │                                  ▼
  │                             标准会员（月/季/年订阅）
  │                                  │
  │                             可选升级（更高档位）
  │                                  ▼
  │                             尊享会员（核心策略、限量）
  └──────────────────────────────────┘

三层控制因子暴露

---

三、邀请码系统设计

3.1 核心能力

3.2 数据模型

邀请码表（SQLite，存入 quant.db）：

3.3 注册校验流程

用户提交邀请码
    │
    ▼
查邀请码 → 不存在？→ 拒绝"邀请码无效"
    │
存在且有效？→ 已作废？→ 拒绝"邀请码已作废"
    │
    ├─ 已过期？→ 拒绝"邀请码已过期"
    ├─ 达到使用上限？→ 拒绝"邀请码已被使用完"
    │
    ▼
通过 → 注册成功 → used_count +1
    │
    ▼
新用户默认进入「试用会员」档，记录 source_code

> 关键点：邀请码必须绑定使用记录，这样一旦某个邀请码被泄露或滥用，管理员可以精准作废并追溯是谁通过它注册的。

3.4 管理员管理界面

• 管理后台新增「邀请码管理」页：

- 生成新邀请码（设置有效期 / 次数 / 备注） - 列表展示：未用 / 已用 / 已过期 / 已作废 状态 - 一键复制、一键作废

• 邀请码签发方式推荐：微信 / 邮件人工转发，不提供公开申请入口，天然限流。

---

四、会员分层体系

4.1 档位设计（四层）

4.2 因子拥挤度防护（重点）

4.3 付费模型

> 说明：当前网站尚未推广、以个人使用为主，付费金额可后置；此处给出可扩展的定价骨架。

4.4 支付方式（中国场景）

> 建议起步期先做「人工收款 + 手动开通」，代码层面预留支付回调接口，后续接入支付渠道无需改动权限体系。

---

五、用户与权限体系改造

5.1 用户数据模型扩展

当前 .quant_auth.json 的 users 结构：

"users": {
  "aohan": {
    "password_hash": "...",
    "salt": "...",
    "is_admin": true
  }
}

扩展为：

"users": {
  "aohan": {
    "password_hash": "...",
    "salt": "...",
    "is_admin": true,
    "tier": "admin",
    "member_expire_at": null,
    "source_code": null
  },
  "zhang3": {
    "password_hash": "...",
    "salt": "...",
    "is_admin": false,
    "tier": "trial",
    "member_expire_at": 1754899200,
    "source_code": "A3F9-K2X7"
  }
}

> 迁移建议：把邀请码表和用户表迁入 quant.db（SQLite），.quant_auth.json 只保留 secret 与 users 的密码信息。这样邀请码、会员状态、订阅记录都能用 SQL 查询和统计。

5.2 权限判断逻辑

_request 进入时:
    └─ 解析 session → 得到 user + tier
    └─ tier 为空 / 过期 → 视为游客
    └─ 根据路由的 required_tier 判断是否有权访问

• 路由表增加 required_tier 字段：/cross-section 需标准会员，/push 需尊享会员，/~docs 按文档目录配置。
• 文档库已支持目录级可见性（/api/doc/visibility），正好与会员档位映射：公开 Tab / 需登录 Tab / 需付费 Tab。
• 会员到期后自动降级：session 有效期内每次请求实时校验 member_expire_at，过期即视为游客档，无感知续费则下次访问变回游客权限。

5.3 页面改造点

---

六、实施路径（分阶段）

Phase 0：当前阶段（个人使用）

• 邀请码动态签发 + 有效期 + 作废（管理员界面）
• 用户表扩展 tier 字段，暂时全部设为 admin
• 不影响现有任何功能

Phase 1：内容分级

• 现有内容模块盘点，标注档位
• 文档库目录级可见性与会员档位打通
• 策略页面脱敏渲染
• 试用期机制（7 天）

Phase 2：付费订阅

• 定价 + 人工收款流程（管理后台手动开通/续费）
• 会员到期自动降级
• 尊享档限量（先手工控制，满员后不再签发）

Phase 3：规模化（未来扩展）

• 接入微信/支付宝自动支付
• 自动续费、订单系统
• 登录设备绑定、防共享检测
• 数据分析：会员留存、内容点击、因子使用追踪

---

七、待确认问题

• 试用期时长：7 天是否合适？还是取消试用，注册即需付费？
• 付费定价：标准/尊享两档定价是否有初步意向？（当前可先不定价，只搭体系）
• 尊享档限额：首批名额想定多少？（建议 20-50 人，控制拥挤度）
• 信号延迟：标准档延迟披露的天数（T+2 / T+5 / T+10）？
• 是否禁外传条款 + 设备绑定：初期是否只做协议勾选，设备绑定后置？
• 文档库公开范围：哪些 Tab 保持公开（吸引访客），哪些收进付费档？

---

八、风险与对策

---

附：与现有代码的对应关系