襷の系譜 选手关系 V0.1 PRD

日期：2026-06-30

关联文档：

• 2026-06-28-襷の系譜-v0.2-PRD.md
• 2026-06-30-襷の系譜-v0.2-数据模型与功能改造技术方案.md

1. 版本目标

选手关系 V0.1 的目标是，在选手页内上线一个已经可用、可解释、可持续扩展的关系模块。

这一版不追求完整关系系统，不做图谱，不做复杂算法，不做独立关系入口。它只完成一件事：

让用户打开一个选手页时，能够立刻看到“这个人和谁关系最深，以及为什么”。

2. 产品定位

本版本定位为 选手关系的第一版汇总能力。

它是整个多角度关系体系的起点，但前台形态保持克制。

本版本确定如下原则：

1. 前台采用 汇总展示，不拆分独立关系入口。
2. 关系体系长期仍然是 多角度关系测算。
3. 第一版以 直接对抗 为第一优先关系。
4. 第一版采用 分数隐性、理由显性。
5. 第一版基于现有数据推导，不新增核心关系业务表。
6. 第一版通过 缓存预计算 + 懒计算 落地。

3. 使用场景

用户进入任意一个选手页时，应当能快速完成以下动作：

1. 看到与该选手关系最深的一批人。
2. 直观理解这些关系是由哪些事实构成的。
3. 顺着感兴趣的关系继续点进其他选手页。

本版本的关系模块承担的不是“做分析工具”，而是“增强浏览吸引力”和“建立关系浏览路径”。

4. 页面范围

本版本只在选手页内上线关系模块。

页面位置：

• /{locale}/players/[slug]

本版本不新增：

• 独立关系页
• 双人对抗页
• 图谱页
• 关系筛选页

这些方向全部留给后续版本。

5. 模块定义

选手页新增一个固定模块：

• 模块名称：与他关系最深的选手

模块是一个 汇总列表，不是分 Tab，不是图谱，不是大段说明文。

每个相关选手卡片必须包含：

1. 选手姓名
2. 1 到 3 条关系理由
3. 可点击进入该选手详情页

如果理由不足，则不进入列表。

6. 第一版关系类型

第一版固定采用以下 3 类关系来源，并按统一汇总结果展示。

6.1 直接对抗

这是第一版的主关系，排序权重最高。

定义固定为：

两名选手在同场竞技、同一赛事、同一项目、同一组中出现，记为一次直接对抗。

这个定义对驿传和非驿传赛事完全一致。

在驿传场景下：

• 同一届
• 同一区

即视为一次直接对抗。

直接对抗用于表达：

• 谁和他最常正面对位
• 这些对抗持续了多久
• 是否跨越了高中、大学、实业团等不同阶段

前台文案必须使用事实表达，不给出胜负判断。

允许使用的表达：

• 驿传中 3 次同区直接对抗
• 高中到大学共 5 次同场直接对位
• 在箱根与出云中多次正面相遇

禁止使用的表达：

• 经常赢过
• 压制
• 克星
• 宿敌

6.2 并肩作战

这是第一版的第二关系来源，负责补足故事性和普适覆盖。

定义固定为：

两名选手在同一组织体系内，具有明确时间重叠或共同出场经历，记为并肩作战关系。

第一版只纳入以下场景：

1. 同校且时间重叠
2. 同校且共同参加过同一届驿传或同一阶段重要赛事
3. 同队多年并存且共同承担主力出场

这一类关系用于表达：

• 同一时期的队友
• 共同构成某一阶段队伍面貌的人
• 即使不是明星，也能成立的共同经历关系

允许使用的表达：

• 大学时期 4 年同队
• 101 回、102 回连续共同出场
• 同一时期共同承担队伍主力区间

6.3 同阶段高频相遇

这是第一版的第三关系来源，权重低于前两者。

定义固定为：

两名选手在同一阶段、同一类重要赛事中多次出现，但不满足严格直接对抗条件，记为高频相遇关系。

这一类关系的作用只有一个：补足那些确实长期处于同一舞台、但没有大量直接对抗的选手关系。

允许使用的表达：

• 大学时期多次在全国大赛相遇
• 同年代长期出现在同一舞台

如果当前数据不足，本关系可以返回空，但产品定义保留。

7. 汇总规则

前台虽然展示为一个汇总模块，但内部关系来源固定分层。

本版本的统一排序规则固定为：

1. 直接对抗
2. 并肩作战
3. 同阶段高频相遇

汇总原则如下：

1. 同一个人可以同时命中多种关系。
2. 多种关系命中时，前台应合并展示为一个人，而不是重复出现。
3. 每个人最多展示 3 条理由。
4. 理由优先展示最硬的事实，优先级与排序规则一致。

这意味着第一版虽然没有显性分数，但内部已经有明确的稳定排序。

8. 分数策略

第一版不在前台展示任何总分、权重分或关系指数。

内部允许存在排序分值，但只用于排序，不用于用户展示。

本版本固定采用：

• 分数隐性
• 理由显性

原因如下：

1. 当前数据仍在补全
2. 权重会持续迭代
3. 显性分数会让用户误以为算法已稳定

因此，前台只展示人和理由，不展示数字分。

9. 展示规则

本版本前台展示规则固定如下：

1. 模块展示一个汇总列表。
2. 默认展示最相关的 6 人。
3. 每人展示 1 到 3 条理由。
4. 理由文案必须是短句，不写长说明。
5. 理由优先体现事实，不体现评价。

展示示例：

• A 选手

  • 驿传中 3 次同区直接对抗
  • 高中到大学共 5 次同场直接对位

• B 选手

  • 大学时期 4 年同队
  • 101 回、102 回连续共同出场

如果某个选手只有很弱、很模糊的关系，不进入前 6。

10. 胜负关系边界

第一版明确不做主动胜负判断。

即使系统已经可以从事实数据中判断部分比赛结果，也不能在选手页关系模块中使用以下表达：

• 经常赢谁
• 对谁胜率更高
• 谁压过谁

原因不是不能算，而是产品阶段不适合主动给出这类高争议结论。

胜负关系 在后续版本中可以作为独立功能存在，例如：

• 用户主动选择两个选手，查看两人历史对抗记录

但这不属于本版本范围。

11. 数据与实现原则

本版本不新增核心业务主表，也不改变主数据模型设计。

关系是派生结果，不是主事实。

主事实仍然来自：

• 比赛
• 项目
• 组别
• 成绩
• 选手参赛记录
• 所属经历

本版本的实现原则固定如下：

1. 基于现有事实数据计算关系
2. 将关系结果写入缓存
3. 不为第一版关系功能单独设计新的核心关系表

12. 缓存策略

本版本缓存方案固定如下：

12.1 基本原则

1. 核心选手采用预计算
2. 非核心选手采用首次访问懒计算
3. 缓存结果服务于选手页汇总模块
4. 缓存结构必须支持未来继续增加关系类型

12.2 核心选手

第一版定义 核心选手 为：

1. 当前站内已收录信息较完整的重点选手
2. 箱根、出云、全日本等关键赛事中高关注度选手
3. 首页、列表页、搜索结果中更容易被访问到的选手

这些人通过任务预计算关系缓存。

12.3 非核心选手

非核心选手不做全量预热。

其关系缓存由用户首次打开页面时触发生成，生成后写入缓存，后续复用。

12.4 缓存组织

缓存组织必须按 关系类型可扩展 的思路设计。

原因是：

• 当前第一版虽然主打直接对抗
• 但整个方向仍然是多角度关系体系

因此，缓存不能只为单一关系写死。

12.5 缓存内容

缓存结果必须至少包含：

1. 相关选手列表
2. 汇总排序结果
3. 每个相关选手对应的理由摘要
4. 生成时间

第一版缓存的是 结果与摘要，不是前台展示时再做全量计算。

13. 非目标

本版本明确不做以下事项：

1. 图谱可视化
2. 独立关系入口
3. 用户发现式推荐
4. 用户登录相关能力
5. 显性分数
6. 胜负标签
7. 宿敌标签
8. 全量赛事穷尽覆盖
9. 复杂算法研究

这些内容都属于后续版本迭代范围。

14. 成功标准

本版本成功标准固定如下：

1. 选手页关系模块稳定展示，不依赖临时手工整理
2. 大部分核心选手页能出现有吸引力的关系结果
3. 用户可以一眼理解“为什么是这些人”
4. 关系结果既能覆盖明星选手，也不会让普通选手页完全空掉
5. 当前结构可以随着数据增加自然变强，而不需要推翻重做

15. 后续迭代方向

本版本上线后，后续迭代方向按以下顺序推进：

1. 扩大直接对抗覆盖赛事范围
2. 提升并肩作战的故事性表达
3. 补强同阶段高频相遇的数据基础
4. 增加独立胜负关系查询
5. 评估是否开放独立关系入口
6. 在数据足够后再研究显性算法表达或关系图谱

本 PRD 作为 选手关系 V0.1 的已定版需求，后续只做迭代，不再回退到重新定义方向。