Seka 二期产品需求文档（PRD）V4.1

拼团翻译 · 兴趣社区 · H5联动 · 完整商业闭环

V4.1 主要变更说明

1. 拼团并发策略调整：同一文件+语言允许同时开多个拼团，互不影响，用户自行选择加入哪个团
2. 导航架构精简：底部 Tab 由 4 个缩减为 3 个（首页、兴趣、我的），取消独立发现 Tab，拼团发现入口迁入首页和兴趣页
3. 社区内容策略调整：兴趣社区以用户原创内容（UGC）为核心，系统自动生成的拼团状态卡不出现在社区 Feed，仅通过消息通知触达用户

目录

• 0. 产品全局视图与战略定位
• 一、一期基础能力复用边界
• 二、解析页三分流改造
• 三、拼团翻译功能完整设计
• 四、求翻译意向系统
• 五、拼团数据模型完整设计
• 六、兴趣社区功能完整设计
• 七、消息通知中心完整设计
• 八、私信系统设计
• 九、页面与信息架构
• 十、H5落地页与App深度联动
• 十一、内容安全与版权保护
• 十二、用户激励体系
• 十三、数据埋点需求
• 十四、管理后台功能扩展
• 十五、技术约束适配
• 十六、排期建议
• 十七、二期产品总结

0. 产品全局视图与战略定位

0.1 四阶段产品路线图

0.2 二期核心目标与成功指标

商业核心：将"多人支付工具"升级为"需求聚合 + 裂变传播 + 结果共享"的完整交易闭环
增长核心：团长裂变系数 K > 1，每个团长平均带来 ≥1.5 个新用户
留存核心：兴趣社区 D7 留存率从一期基线提升 ≥15%，社区内容以真实 UGC 为主

0.3 三条完整产品飞轮

一、一期基础能力复用边界（重要约束）

⚠️ 设计原则：二期所有新功能必须严格建立在一期已有能力之上，不重复造轮子，不破坏已有用户心智
⚠️ 核心约束：同一用户仅允许1个执行中的翻译任务，多个任务按提交时间排队（一期规则，二期继承）

二、解析页三分流改造（核心入口）

解析页是整个产品最关键的决策节点。一期该页面只有"确认支付"一个出口，导致价格敏感用户大量流失。二期改造目标：把流失流量变为可聚合的需求资产。

2.1 页面结构

2.2 三卡片设计规范

关键设计原则：默认选中独享，不强制引流，避免破坏已有用户的翻译工作流。
高价触发阈值由后台配置（默认：拼团推荐 150P，求翻译推荐 300P）。
视觉处理：满足触发条件时，拼团卡加粉色边框 + "推荐"角标，吸引注意力但不强制。

2.3 模式选择后的操作路径

三、拼团翻译功能完整设计

3.1 拼团参数设计（后台可配置）

并发团策略说明（V4.1变更点）

允许同一 Book_ID + 目标语言同时存在多个进行中的拼团，各团独立运作，互不影响。用户在首页拼团入口或兴趣页帖子中可看到同一书目的所有在招募的团，自行选择加入哪一个。

平台侧影响：同一翻译结果（Book_ID + target_language）只生成一次，多个成团的团共享同一份译文；翻译任务在第一个团成团时触发，后续成团的团直接复用已有结果，无需重复翻译，边际成本接近零。

用户侧体验：加入一个团后，若该书已有译文存在，成团即可阅读，无需等待翻译；若尚无译文，按正常翻译流程排队。

3.2 发起拼团完整流程（8步）

Step 6 设计说明（V4.1变更点）

发团成功后的社区发帖改为用户主动选择，而非系统自动生成。弹窗提示："要把这个拼团发到兴趣广场招募同好吗？" 用户确认后，系统提供预填模板，用户可编辑后发布——这条帖子本质上是用户的 UGC，计入用户发帖数，享有 UGC 激励奖励，排序逻辑与普通 UGC 帖相同。

3.3 拼团详情页（H5 + App 共逻辑）

3.4 加入拼团前置条件与边界

跨团加入的补充说明：若用户已加入某个团，同一书目另一个团成团更早，该用户仍可阅读（以任一已加入且成团的团为准）。已参与多个团的用户，各团退款独立处理（每个失败团单独退款）。

3.5 拼团完整状态机

[PENDING]  → 团长支付成功  → [GROUPING]
                                  │
                    ┌─────────────┤
                    │             │
               满员 ↓        超时未满员 ↓
           [SUCCESS]           [FAILED]
                │                  │
          返币+创建占位任务      自动退款所有成员
                │
           [QUEUED] → 排队执行 → [TRANSLATING] → [COMPLETED]
                │
           若 Book_ID+语言已有完成的译文 → 直接跳至 [COMPLETED]，无需重新翻译

[GROUPING] → 团长2h内无人加入时取消 → [CANCELLED]

3.6 费用计算与返还机制

全本翻译价格  = Token数 × 每Token单价（服务端配置，$1 = 100P）
单人份额     = ceil（全本翻译价格 / 参团人数）  ← 向上取整，保证平台不亏损
实际收取总额  = 单人份额 × 参团人数            ← 可能略高于全价，差额归平台
团长返还金额  = 单人份额 × 返还比例（后台配置）

译文复用时的计费说明：若成团时已存在同 Book_ID + 目标语言的完成译文，平台无需支付翻译成本，但仍向用户收取正常拼团费用，差价为平台利润。这是内容复用带来的规模效益，不影响用户端价格。

3.7 拼团失败承接流

拼团失败是最大的用户流失节点。失败弹窗设计原则：不只是退款通知，而是下一步行动引导。

四、求翻译意向系统（新增核心模块）

定位：高价拦截的最后防线，将"看了价格就离开"的用户转化为"公开的、可聚合的翻译需求信号"。
与普通内容帖的核心区别：每一条求翻译帖都可以被平台、团长、其他用户看到并响应，最终转化为交易。

4.1 发布求翻译帖流程（6步）

4.2 求翻译帖 → 正式拼团转化规则

4.3 求翻译帖数据模型（新增表 demand_post）

五、拼团数据模型完整设计

5.1 拼团订单表 group_order

5.2 拼团成员表 group_member

5.3 拼团分享记录表 group_share_log

六、兴趣社区功能完整设计

核心定位（V4.1重新明确）：兴趣社区是以用户原创内容（UGC）为绝对主体的内容场，通过真实用户的推荐、片段分享、阅读评价来建立口碑并驱动拼团转化。

与拼团的关系：拼团是独立的交易模块，通过用户自愿发帖、分享链接进入社区；社区不是拼团的广告牌，而是用户自发聚集、讨论作品的地方。系统自动生成的状态卡（翻译完成、成团通知等）仅通过消息通知触达用户，不在 Feed 中展示。

6.1 模块优先级

6.2 UGC内容体系

第一层（核心）：用户主动原创内容

这是社区 Feed 的绝对主体，目标占比 ≥ 70%。

关键原则：拼团招募帖是用户自愿选择发布的，系统不代替用户发帖。团长在发起拼团后，弹窗询问"要发到兴趣广场吗？"，用户确认并编辑后才发布。不存在系统自动发出的拼团状态帖。

第二层（辅助）：用户行为引导内容（半自动，需用户确认）

半自动内容的本质是降低用户发帖成本，提供预填模板，但发布动作由用户主动触发。

第三层（运营内容）

运营内容与 UGC 明确区分，打上"官方"标识，不与用户帖子混排，以独立卡片或置顶方式展示。

6.3 信息流排序算法

社区 Feed 的排序以内容质量和用户偏好为核心，商业转化价值作为辅助加权，而非主导因素。

score = 内容质量 × w1 + 用户偏好匹配 × w2 + 新鲜度 × w3 + 社交关系 × w4

内容质量  = like_count × 1 + comment_count × 2 + share_count × 3 + save_count × 2
用户偏好  ：同语言偏好 +8 / 同题材偏好 +6 / 该作品有翻译历史 +5
新鲜度    ：发布时间指数衰减，半衰期 16h（略长于工具类产品，阅读社区内容保鲜期更长）
社交关系  ：关注用户的帖子 +10

内容类型权重（辅助参数，不替代质量评分）：

排序策略说明：V4.1 调整了排序权重的设计思路——不再给"即将成团"的帖子额外大权重，避免社区 Feed 变成拼团广告栏。用户看到的是真正有质量、有共鸣的内容；拼团信息通过用户自愿分享自然流通。

6.4 帖子卡片结构（按类型差异化）

6.5 发帖流程

Step 1：点击发帖入口（兴趣页右上角 ✏️ 按钮）
Step 2：选择内容类型（5选1：推荐这本 / 分享片段 / 说两句 / 发布需求 / 我开了个团）
Step 3：填写内容（有预填模板时用模板，无模板则空白编辑器）
Step 4：关联作品（可选，搜索或从最近记录选取）
Step 5：系统自动推荐标签（可修改，最多5个）
Step 6：预览 → 发布

七、消息通知中心完整设计

V4.1 重申：拼团状态变化（成团、失败、翻译完成等）仅通过消息通知触达，不在社区 Feed 中展示系统生成的状态卡。这是社区 UGC 优先策略的重要保障。

7.1 通知中心结构

入口：底部导航"我的"Tab 右上角铃铛图标（带红点未读数）。

7.2 拼团类通知完整清单

7.3 推送技术方案

八、私信系统设计

8.1 功能范围（轻量化原则）

支持： 纯文字消息 / 图片（最多3张/条）/ 发送拼团卡片 / 发送作品卡片 / 消息已读状态

不支持： 语音/视频消息 / 文件传输 / 群聊 / 消息撤回（二期不实现）

8.2 私信发起场景与快捷话术

8.3 隐私与安全

8.4 私信数据模型

九、页面与信息架构

9.1 底部导航（Tab Bar）——3 Tab 结构

V4.1 调整：取消独立的"发现"Tab，精简为 3 个 Tab。发现拼团的入口迁入首页（模块化插片）和兴趣页（独立Tab分类）。

取消发现 Tab 的原因：拼团发现的核心需求（找到可加入的团）可以通过首页模块和兴趣页的"拼团"子Tab满足，无需独立 Tab 占据导航位置。精简导航减少认知负担，让用户更聚焦在"翻译工作台"和"兴趣内容"两个核心场景。

9.2 首页（最小改动 + 拼团发现模块）

设计原则：首页保持一期"上传 + 任务中心"主心智，在任务中心下方新增拼团发现模块，以折叠区域渗透二期能力，不改变主流程。

拼团发现模块卡片字段：书名缩略 + 语言方向 + 进度条（X/Y人）+ 每人价格 + 倒计时 + 加入按钮

9.3 兴趣页（全新，UGC 内容场 + 拼团入口）

兴趣页是二期最核心的新增页面，定位是真实用户内容的聚集地，同时通过子 Tab 提供拼团发现能力。

顶部 Tab 结构：

"拼团" Tab 详细布局：

┌─────────────────────────────────────────┐
│  🔍 搜索书名/语种                         │
├─────────────────────────────────────────┤
│  📌 即将成团（横向滚动卡片，剩余1~2人）    │
├─────────────────────────────────────────┤
│  用户发的拼团帖 & 求翻译帖（Feed流）       │
│  ┌──────────────────────────────────┐   │
│  │ 🧑 用户A  「我开了个团」  2h前      │   │
│  │ 《Overlord Vol.14》日→中          │   │
│  │ ██████░░ 4/5人  35P/人  剩6h     │   │
│  │ [加入拼团]  [分享]  ❤23  💬5      │   │
│  └──────────────────────────────────┘   │
│  ┌──────────────────────────────────┐   │
│  │ 🧑 用户B  「求翻译」  5h前          │   │
│  │ 《转生史莱姆 第15卷》日→中         │   │
│  │ 独享约180P，已有8人感兴趣           │   │
│  │ [我也想翻]  [发起拼团]  ❤15  💬3  │   │
│  └──────────────────────────────────┘   │
└─────────────────────────────────────────┘

9.4 我的页（扩展一期）

十、H5落地页与App深度联动

10.1 设计原则

核心目标：让外部分享链接能在H5完成完整的"查看详情 → 注册 → 支付 → 加入"流程，不强制下载App。
转化策略：优先让用户完成"加入拼团"行为，App下载作为次要引导，而非拦截。
技术依赖：Universal Links（iOS）/ App Links（Android），已安装App的用户自动跳转App内。

10.2 H5页面清单（P0）

10.3 H5通用规范

十一、内容安全与版权保护

11.1 三层审核机制

11.2 前台限制规则

11.3 违规处罚阶梯

十二、用户激励体系（二期新增）

原则：奖励真实的 UGC 贡献和交易转化行为，不奖励刷量行为。
社区激励以内容质量为导向，避免为了薅积分发水帖。

十三、数据埋点需求（V2，完整版）

在一期埋点体系（event_catalog/common_params/event_params标准）基础上，新增以下二期事件：

13.1 解析页新增事件

13.2 拼团核心事件

13.3 社区核心事件

13.4 核心看板指标

十四、管理后台功能扩展

14.1 拼团管理模块

14.2 社区管理模块

十五、技术约束适配

15.1 与一期任务系统兼容

15.2 拼团并发安全

15.3 拼团超时处理

15.4 翻译结果共享与复用机制

拼团成功后，翻译引擎完全复用独享翻译流程（切片/并发/保底/格式还原），不新建翻译逻辑。
翻译结果以 Book_ID + target_language 为键存储，供多个成团共享。
成团后系统首先检查是否已有该键的完成译文：若有，直接关联，成员立即可阅读；若无，触发翻译任务排队。
阅读权限：通过 group_member 表校验，所有成员均有阅读和下载权限。

十六、排期建议（优化版）

总工期估算：P0约13周（含设计1周、开发9周、联调测试2周、灰度1周），取消发现Tab后客户端工作量有所减少
P1在P0上线后4~6周内跟进；拼团功能与社区功能并行开发（后端分别开工）

P0（首发必须，约13周）

P1（首发后4~6周跟进）

十七、二期产品总结

17.1 三条飞轮闭环（必须全部跑通）

17.2 三个关键设计决策说明

决策一：拼团不设并发限制

允许同一文件+语言同时开多个拼团，本质是相信市场竞争机制——用户会自然流向更快满员的团，团长有动力主动宣传。限制并发的副作用更大：会让有意开团的用户因"已有团在招"而放弃，反而压制了发团积极性。配套机制是在拼团详情页展示同书其他在招的团，让用户有充分信息做选择。

决策二：导航精简为3 Tab

"发现"Tab 的功能可以被首页拼团模块 + 兴趣页拼团子Tab完全覆盖，独立 Tab 的边际价值不足以占据一个导航位置。3 Tab 结构让用户心智更清晰：首页是我的翻译工作台，兴趣是内容社区，我的是个人空间。

决策三：社区以UGC为核心

系统自动生成的拼团状态卡、翻译完成卡不进 Feed，根本原因是：如果社区里全是"XX拼团招募中""XX翻译完成"的系统卡片，用户感知到的是一个广告平台，不会产生归属感和留存动力。真正让社区活起来的是用户说"这本书翻得真好"、"第三章那段对话笑死我了"——这些才是让用户每天回来的理由。

17.3 上线后重点监控（前4周）

• 第1周：关注成团率和成团时长。若成团率<30%，优先排查H5链路是否顺畅
• 第2周：关注UGC帖子占比。若<50%，说明系统内容或运营内容过多，需减少曝光
• 第3周：关注失败挽回率和并发团数据。若同书多团同时失败率高，考虑运营干预聚焦
• 第4周：关注整体K值和社区D7留存，评估两个核心目标的达成情况

17.4 下一步行动建议

© 2026 Seka Product Team · 文档版本 V4.1 · 机密文档，仅供内部使用