跳转到内容

05-待决问题

文档性质:当前待决问题总文档
用途:把“现在还没定死的问题”和“明确先留后处理的能力”集中保留
边界:这里不覆盖 01-当前目标与范围.md02-当前系统现实.md07-视觉与页面表达.md 的当前结论 口径提醒

  • source = news / imports 当前只表示进入路径,不表示平台来源,也不等于分发资格
  • visibility 当前只表示可见性,不等于“可分发”或“可首页推荐”
  • 这里讨论的是“还没定死的承载方式”,不是回滚当前系统现实 最后更新:2026-04-16

现在最需要避免两种混乱:

  1. 还没定稿的问题不断污染当前执行规格
  2. 明确重要但暂时不做的能力,在聊天或旧文档里慢慢消失

所以这份文档只做两件事:

  • 集中保留还没定死、但后面一定要决策的问题
  • 集中保留 Phase 2 及之后值得继续规划的能力

进入这里的问题或能力,必须满足

Section titled “进入这里的问题或能力,必须满足”
  • 现在还不能直接写进当前主规格
  • 后面一定会回来
  • 不单独保留会导致团队重复讨论或丢上下文

它只代表:

  • 现在先不做
  • 但以后值得继续判断或规划
  1. README.md
  2. 01-当前目标与范围.md
  3. 02-当前系统现实.md
  4. 06-首页分发与合集字段要求.md
flowchart TD
  A[新问题 / 新能力想法] --> B{当前已经定稿?}
  B -->|是| C[回 01 / 02 / 06 / 07]
  B -->|否| D{Phase 1 现在必须落规格?}
  D -->|是| E[继续讨论并收敛到 active 文档]
  D -->|否| F[进入 05 待决问题]
  F --> G{后续是否重新进入决策}
  G -->|Phase 1 中后段| H[回写 active 文档]
  G -->|Phase 2 以后| I[保留为后续规划]

这张图说明 05 不是杂物堆,而是“暂不落地但必须保留上下文”的过渡层。


3. 当前最重要的未决问题优先级

Section titled “3. 当前最重要的未决问题优先级”
  1. Distribution Eligibility / Homepage Eligibility 最终由什么正式能力承接
  2. scene 体系会不会语义过载
  1. Collection / Series / Topic 的后续建模边界
  2. 推荐最终偏兴趣还是偏目标
  3. Streak / 学习机制何时重新增强
  4. Homepage Tabs 在 Phase 2 之后要不要引入动态化
  1. 搜索最终会不会成为重要入口
  2. Podcast 会不会上升为长期主线
  3. 分享与传播是否独立成增长战线

首页相关讨论默认使用这套冻结表达:

  • 今日新闻速递
  • 热门推荐
  • 轻松入门
  • 播客精选
  • 今天正在更新
  • 还能继续逛
  • 继续探索
  • 更多你可能想看

其中:

  • 更多你可能想看 当前仍是库存充足时才出现的可选层
  • 今日新闻速递 是首页 Hero / 当日内容路由,不是长期 Collection
  • 播客精选今天正在更新 当前都按 Collection + item 外露 讨论
  • 热门推荐轻松入门还能继续逛更多你可能想看 当前都按 Collection 分发层讨论
  • 继续探索还能继续逛 这个底部探索型区块的当前 active 可见标题,不再视为待命名状态

Q1. 首页 今日新闻速递 未来会不会重新回到更强学习入口?

Section titled “Q1. 首页 今日新闻速递 未来会不会重新回到更强学习入口?”
  • 首页第一版仍是内容平台首页
  • 今日新闻速递 优先承担“今天值得看什么”的角色
  • 不由学习任务或打卡主导首页主心智

随着内容池和回访机制成立,首页的“内容平台感”和“学习牵引力”未来可能需要重新平衡。

优点:平台心智更稳
风险:学习目标感偏弱

方案 B:后续逐渐强化“今日学习”角色

Section titled “方案 B:后续逐渐强化“今日学习”角色”

优点:更容易建立习惯
风险:过早强化会把首页拉回任务产品

Phase 1 不调整,等内容平台感成立后再判断。

Phase 2


Q2. Collection / Series / Topic 什么时候彻底独立建模?

Section titled “Q2. Collection / Series / Topic 什么时候彻底独立建模?”
  • Collection 在 Phase 1 必须成立
  • 播客精选今天正在更新 当前先通过 Collection + item 外露 表达
  • Series 在 Phase 1 可先作为 Collection 的特化表达
  • Topic 在 Phase 1 可先弱化为时效分发层

当播客体系成熟、系列化内容明显增多、专题运营频次提升后,继续共用一个集合模型是否还合适,需要重新判断。

方案 A:Phase 2 正式独立 Series / Topic

Section titled “方案 A:Phase 2 正式独立 Series / Topic”

优点:模型更清晰
风险:工程改动更大

方案 B:继续共用 Collection 主模型,通过 type 和时效字段表达

Section titled “方案 B:继续共用 Collection 主模型,通过 type 和时效字段表达”

优点:工程简单
风险:后期语义越来越脏

Phase 1 不独立。等内容规模和运营频次达到阈值后,再评估是否拆。

Phase 2 或更晚


Q3. Podcast 在 Yomiya 中到底是补充线,还是未来长期留存主线?

Section titled “Q3. Podcast 在 Yomiya 中到底是补充线,还是未来长期留存主线?”
  • Podcast 目前仍是 Phase 1 的补充线
  • 不作为平台成立前提
  • 不要求播客先成熟后首页才成立

播客和系列化陪伴关系可能会成为长期留存资产,但当前还没有足够内容和验证数据支持它成为平台主轴。

优点:聚焦视频和首页平台感
风险:可能低估长期留存价值

方案 B:在 Phase 2 强化为第二主线

Section titled “方案 B:在 Phase 2 强化为第二主线”

优点:增强陪伴型关系和订阅感
风险:会抢占视频与首页优化资源

继续作为补充线观察,不在 Phase 1 上升为主战场。

Phase 2


Q4. 自动入库后的 Distribution Eligibility / Homepage Eligibility 最终会不会独立成明确字段或状态机?

Section titled “Q4. 自动入库后的 Distribution Eligibility / Homepage Eligibility 最终会不会独立成明确字段或状态机?”

逻辑上已经明确区分:

  • 已入库
  • 已结构化
  • 可分发
  • 可首页推荐
  • source = news 当前只说明它走的是官方供给进入路径,不等于它已经通过分发资格判断
  • visibility 当前只说明用户能不能看见,不等于它应该进入首页、合集或推荐层
  • 当前公开读取默认只取 source = news,这只能说明 imports 默认不进官方内容池,不能替代正式的分发资格定义
flowchart TD
  A[内容已进入 news] --> B[source]
  A --> C[visibility]
  A --> D[distribution eligibility]
  D --> E[homepage eligibility]
  B --> F[只回答进入路径]
  C --> G[只回答用户能否看见]
  D --> H[只回答能否进入分发层]
  E --> I[只回答能否进入首页候选层]

这 4 层是 4 个不同问题,不能再用 sourcevisibility 去顶替后两层。

现在语义已经拆开,但工程承载还没有拆开:一部分信息在 source,一部分信息在 visibility,一部分仍散落在查询条件、处理链路和后续规则里。也就是说,团队已经知道“分发资格”不是 source、也不是 visibility,但还没有冻结:

  • Distribution Eligibility 由什么正式能力承接
  • Homepage Eligibility 是否单独承接,还是从分发资格再往上收口
  • item、collection、homepage slot 三层分别在哪一层做准入判断

优点:语义清晰,便于查询和运营
风险:增加数据迁移与兼容成本

优点:短期工程更轻
风险:后续逻辑越来越分散

Phase 1 先把规则边界写死:

  • source 只回答“从哪条进入路径进来”
  • visibility 只回答“用户能不能看见”
  • Distribution Eligibility 只回答“能不能进入分发层”
  • Homepage Eligibility 只回答“能不能进入首页候选层”

在这个边界稳定后,再决定工程上是独立字段、状态机,还是规则层计算结果。

Phase 1 实施中后段


Q5. 当前的 scene 体系,长期能否同时承担“标签、聚合、Tab 映射、合集建议”四种职责?

Section titled “Q5. 当前的 scene 体系,长期能否同时承担“标签、聚合、Tab 映射、合集建议”四种职责?”
  • Phase 1 继续优先使用现有 scene 体系
  • 当前不再新建并行主标签体系

scene 当前潜在承载了太多职责:标签、首页 Tab、合集归档依据、推荐与筛选辅助。短期可行,长期是否语义过重仍需观察。

优点:统一、少建模
风险:语义过载

方案 B:后续拆出更轻量的主题层

Section titled “方案 B:后续拆出更轻量的主题层”

优点:前台展示和推荐更灵活
风险:再次引入并行标签体系

Phase 1 不新增大体系,等内容和推荐复杂度提升后再评估是否拆层。

Phase 2


Q6. 首页 Tabs 最终是固定配置,还是会动态增减?

Section titled “Q6. 首页 Tabs 最终是固定配置,还是会动态增减?”
  • Homepage Tabs 在 Phase 1 的行为已经冻结,不再属于当前实现面的待决项
  • 它是 Home 内部的页内状态切换器,不是默认页面跳转器
  • 推荐 必须默认命中,播客 必须固定放在第二位
  • 当前 active 顺序固定为:推荐 / 播客 / 资讯 / 旅行 / 动漫 / JLPT
  • 当前真正待决的,只剩下 Phase 2 之后要不要把这套固定顺序动态化

Phase 1 已经需要先守住稳定入口和用户认知,但更后续仍要判断:首页 Tabs 是否应该随着库存、热点和运营节奏动态增减。

优点:用户认知稳定
风险:内容不足时空心化

方案 B:Phase 2 之后引入动态 Tab 架构

Section titled “方案 B:Phase 2 之后引入动态 Tab 架构”

优点:更贴库存和热点
风险:用户心智不稳定

Phase 1 继续完全按固定顺序执行,不在实现层重新讨论;真正的开放问题只保留到 Phase 2 之后是否值得动态化。

Phase 2


Q7. 搜索在未来到底承担什么角色?

Section titled “Q7. 搜索在未来到底承担什么角色?”
  • Phase 1 不做复杂搜索系统
  • 当前核心问题不是“搜不到”,而是“平台感还没建立”

内容池真的变大以后,搜索的价值一定会上升。

平台主心智始终靠首页与合集完成。

方案 B:搜索逐渐成为重要主入口之一

Section titled “方案 B:搜索逐渐成为重要主入口之一”

当库存变大后,用户会更高频地带着明确目标来找内容。

Phase 1 不展开,等可分发内容池和合集层先成立后再判断搜索权重。

Phase 2 / 3


Q8. 推荐系统最终会偏“兴趣驱动”,还是偏“目标驱动”?

Section titled “Q8. 推荐系统最终会偏“兴趣驱动”,还是偏“目标驱动”?”

Phase 1 当前更偏:

  • 首页人工编排
  • 核心需求入口
  • 合集和主题驱动

从长期看,推荐系统可能会在兴趣驱动和目标驱动之间摆动。

优点:更像内容平台
风险:学习目标感偏弱

优点:更容易形成“学习结果”认知
风险:平台会重新偏工具型

Phase 1 不做算法判断,先用合集和首页结构观察用户行为数据。

Phase 2


Q9. Streak / 学习机制何时重新进入主产品层?

Section titled “Q9. Streak / 学习机制何时重新进入主产品层?”
  • Phase 1 不让学习任务主导首页
  • 当前更重内容发现和连续消费

如果 D1 成立、内容平台感成立,下一阶段自然会回到“如何把偶尔看看转成持续学习习惯”。

方案 A:晚一点再引入更强学习机制

Section titled “方案 A:晚一点再引入更强学习机制”

优点:不打断平台心智
风险:习惯形成较慢

方案 B:在 Phase 2 逐步增强 Streak 和目标进度

Section titled “方案 B:在 Phase 2 逐步增强 Streak 和目标进度”

优点:更有机会形成稳定习惯
风险:重新走回任务产品

先观察 D1、连续消费率和回流行为,再决定 Phase 2 的增强程度。

Phase 2


Q10. 分享与传播体系在未来要不要成为独立工程战线?

Section titled “Q10. 分享与传播体系在未来要不要成为独立工程战线?”
  • 传播很重要
  • 但 Phase 1 不把复杂分享系统做成独立大工程

旅行、动漫、文化冷知识这些内容天然适合传播。如果后续传播数据明显强,就可能需要把分享卡片、金句素材和渠道适配抬成独立增长战线。

方案 A:长期只作为内容附属能力

Section titled “方案 A:长期只作为内容附属能力”

优点:聚焦产品本体
风险:错过自然增长机会

方案 B:在 Phase 2 / 3 独立为增长能力

Section titled “方案 B:在 Phase 2 / 3 独立为增长能力”

优点:提升传播效率
风险:会拉高运营与工程复杂度

Phase 1 先不独立扩张,等真实分享数据出来再决策。

Phase 2 / 3


目标:先做出内容平台感,建立可分发、可组织、可连续消费的内容池。

目标:在内容平台成立基础上,开始增强用户留存、结构化内容体验与基础推荐能力。

目标:让 Yomiya 从“有内容的平台”进化成“有持续关系和个性化体验的平台”。

目标:建立更成熟的增长、商业化、内容运营自动化和长期学习体系。

flowchart LR
  A[Phase 1<br/>内容平台成立] --> B[Phase 2<br/>留存 / 结构化体验 / 轻推荐]
  B --> C[Phase 3<br/>持续关系 / 个性化体验]
  C --> D[Phase 4<br/>增长 / 商业化 / 自动化 / 长期学习]

这张图只回答一件事:哪些能力是后续阶段再进场,不要偷跑回 Phase 1。


  • 更明确的今日学习入口
  • 更轻量的学习目标进度
  • Streak 的更强展示和恢复机制
  • 内容消费与学习进度的连接层

原则:学习机制是增强层,不重新夺走内容平台主心智。

6.2 Collection / Series / Topic 进一步独立建模

Section titled “6.2 Collection / Series / Topic 进一步独立建模”
  • 独立 Series 模型
  • 独立 Topic 模型
  • 更明确的容器间引用规则
  • 更清晰的后台操作对象边界

原则:只有当系列化内容、播客和专题运营频率都上来后,才值得纯化模型。

  • 基于兴趣偏好的基础推荐
  • 合集推荐逻辑优化
  • 首页分发位更细的排序策略
  • 内容类型与用户目标之间的轻量匹配

原则:先做轻量增强,不直接进入重算法阶段。

  • 标题关键词搜索
  • 按内容类型过滤
  • 按难度等级过滤
  • 按合集 / 栏目 / 标签筛选

原则:搜索先作为辅助入口,不抢首页和合集层的主导地位。

  • 更明确的系列页
  • 用户订阅某个系列
  • 新一期更新提醒
  • 系列连续播放体验增强

原则:是否升级为主线,要看真实留存和订阅数据。


  • 个性化推荐系统
  • 搜索升级为重要入口
  • 成就 / 游戏化体系
  • 分享与传播体系独立化

原则:只有当内容池、用户分层、首页基础分发都已稳定,这一层才值得启动。


  • 内容运营自动化增强
  • 更成熟的商业化体系
  • 更完整的长期学习体系

原则:只有当平台已从“证明自己存在”进入“效率优化阶段”,这些能力才适合启动。


  • 平台内容丰富感已经成立
  • 首页内容消费率稳定
  • 连续消费率成立
  • D1 回访开始有意义
  • 可分发内容池与首页推荐之间已有明确分层
  • 用户分层足够明显
  • 首页基础分发已稳定
  • Collection 层和内容池结构稳定
  • 平台已具备足够大的可分发内容库存
  • 平台已经不是“证明自己存在”,而是进入效率优化阶段
  • 数据基础足够支撑自动化和商业化增强
  • 用户关系和产品心智已经相对稳定

这份文档的价值,不是把未来能力提前塞回当前执行面,而是把“现在先不做、以后一定会回来”的问题和方向完整保留下来。