襷の系譜 V0.2 PRD

日期：2026-06-28

关联文档：

• 2026-06-27-襷の系譜-v0.1-PRD.md
• 2026-06-27-襷の系譜-v0.1-技术方案.md

1. 版本定位

V0.1 已经验证了“以选手档案为核心”的资料站方向。V0.2 的目标不是立刻做完整成绩库，而是让站点开始具备三条稳定浏览路径：

1. 选手：从个人档案理解一个选手。
2. 赛事：从一场比赛理解出场选手和结果。
3. 关系：从一个选手跳到与他有关的人、组织和比赛。

V0.2 仍然是粉丝向资料站，不是新闻站，不是实时比分站，也不是完整统计平台。

核心判断：

关系图组件不是当前重点。当前重点是定义“什么关系值得展示、如何计算、如何解释可信度”。

2. V0.2 目标

V0.2 要解决三个问题：

• 用户不只能从选手进入数据，也能从赛事进入数据。
• 用户能理解两个选手为什么有关联。
• 用户能区分“同属但不同时期”和“实际有时间重合/同场竞技”的关系强弱。

成功后的体验应是：

• 打开黑田朝日，可以看到同大学、同高中、同实业团、同台竞技相关选手。
• 打开第102回箱根駅伝，可以看到该届赛事、比赛单元、出场选手、成绩和来源。
• 打开青山学院大学，可以看到已收录选手和所属履历入口。

3. 页面范围

3.1 选手页增强

选手页继续作为核心页面。

V0.2 增强内容：

• 关系模块
• 关系按类型分组
• 关系强度说明
• 从关系跳转到相关选手、组织、赛事

关系模块初期不做复杂图谱，可用列表、分组、徽标、计数呈现。

建议分组：

• 同大学
• 同高中
• 同实业团
• 同台竞技
• 同赛事/同区间

每个关系项至少展示：

• 相关选手姓名
• 关系类型
• 关系说明
• 是否时间重合
• 同台竞技次数，若有

3.2 赛事页

V0.2 需要开始建设赛事页。

赛事页分两层：

1. 赛事届次页
   例如：第102回箱根駅伝、大阪マラソン2025、MARCH対抗戦2025。

2. 比赛单元页
   例如：第102回箱根駅伝 5区、男子10000m 最終4組。

V0.2 可先合并展示，不强制拆成两个独立页面。如果数据量较少，届次页内直接展示比赛单元和结果即可。

赛事页至少展示：

• 赛事名称
• 届次/年份
• 日期
• 比赛单元列表
• 成绩表
• 选手链接
• 所属组织
• 成绩、排名、备注
• 数据来源
• 数据状态

优先建设对象：

• 第102回箱根駅伝
• 第102回箱根駅伝 5区作为该届赛事内的优先比赛单元
• 第100回、第101回、第102回箱根駅伝中黑田朝日出场区间
• 已入库的 MARCH対抗戦2025、大阪マラソン2025、兵庫リレーカーニバル、出雲駅伝第35回 2区

3.3 组织页

组织页不是 V0.2 的主战场，但建议开始做基础版本。

组织包括：

• 高中
• 大学
• 实业团

组织页至少展示：

• 组织名称
• 组织类型
• 所在地，若有
• 已收录相关选手
• 当前所属选手
• 曾经所属选手
• 从该组织关联出去的赛事结果

组织页的价值是支撑关系浏览，例如：

• 青山学院大学有哪些已收录选手
• 玉野光南高校关联了哪些选手
• GMO 目前有哪些选手

3.4 关系入口/关系模块

关系未来可以成为独立入口，而不是永远附属于选手页。V0.2 的实现可以先放在选手页里，但产品定位上应视为“关系入口的初版验证”。

初版可以先做在选手页内：

• /{locale}/players/[slug] 中加入关系区块

后续再扩展为：

• /{locale}/players/[slug]/relations
• /{locale}/relations

V0.2 关系先在查询时计算，并在相关选手后展示关系标签。后续是否需要预计算、缓存、独立关系入口或其他形态，等数据量和使用场景明确后再决定。

4. 关系定义

4.1 同属关系

同属关系来源于 Membership。

同属类型：

• 同高中
• 同大学
• 同实业团

同属关系必须区分两种情况：

1. 时间重合
   两人在同一组织的所属时间有交集。

2. 仅同源
   两人都属于过同一组织，但所属时间没有交集或时间未知。

展示建议：

• 时间重合：关系强度更高，显示为“同時期”
• 不重合：显示为“同組織”
• 时间未知：显示为“時期未確認”

判断逻辑：

• 两段 Membership 都有 startDate/endDate 时，判断区间是否重叠。
• 当前所属 endDate 为空时，视为持续到现在。
• 只有年份时，可用年份判断弱重叠。
• 缺少时间时，不判定为重合，只标记为时间未确认。

4.2 同台竞技关系

同台竞技来源于 RaceResult。

定义：

两名选手在同一个 Race 中都有 RaceResult，视为同台竞技一次。

同台竞技可以分层：

• 同一 Race：最强，例如同一组 10000m、同一区间结果表。
• 同一 CompetitionEdition：中等，例如同一届箱根，但不同区间。
• 同一 Competition：较弱，例如都参加过箱根，但年份不同。

V0.2 优先展示同一 Race。

展示字段：

• 同台竞技次数
• 最近一次共同赛事
• 最相关赛事名称
• 是否同一区间/同一组

4.3 关系强度

关系强度不需要复杂算法，先用规则分级：

强关系：

• 同一组织且时间重合
• 同一 Race 同场竞技
• 同一队伍出战同一赛事届次

中关系：

• 同一组织但时间不重合
• 同一 CompetitionEdition 但不同 Race

弱关系：

• 同一 Competition 但不同年份
• 同一高中/大学但时间未知

V0.2 页面只需要把这个解释清楚，不需要给出分数。

5. 数据范围

V0.2 的数据目标应保持克制。

优先级：

1. 已入库选手相关赛事记录补成页面可用。
2. 第102回箱根駅伝作为赛事页样本。
3. 黑田朝日相关赛事作为第二批赛事样本。
4. 资料状态达标选手的组织关系补齐。

V0.2 不追求：

• 全箱根所有区间
• 全三大駅伝历史
• 全大学选手
• 全赛事自动导入

数据策略：

• 能明确来源的结果进入正式展示。
• 只有媒体摘要但没有成绩细节的数据，可以进入待确认状态。
• 壳子选手可以存在，但不应混入核心展示模块。

6. 导航结构

V0.2 建议形成以下公开页面：

• /[locale]
• /[locale]/players
• /[locale]/players/[slug]
• /[locale]/competitions
• /[locale]/competitions/[slug]
• /[locale]/competitions/[slug]/[editionSlug]，若需要
• /[locale]/organizations
• /[locale]/organizations/[slug]

如果开发节奏要更碎，优先顺序是：

1. 赛事详情页
2. 选手页关系模块
3. 组织详情页
4. 赛事列表页
5. 组织列表页
6. 独立关系页

7. 非目标

V0.2 不做：

• 图数据库
• 复杂关系预计算
• 复杂关系图可视化
• 自动采集
• 社区投稿
• 用户账号
• 管理后台完整工作流
• 数据仓库
• 全量赛事库

这些仍然可以进入 V0.3 之后。

8. 开发拆分建议

V0.2.1 赛事详情样本

• 新增赛事届次详情页
• 展示第102回箱根駅伝
• 在届次页内展示比赛单元列表
• 优先展示 5区结果
• 可从结果跳转选手页

V0.2.2 选手关系模块

• 在选手页加入关系区块，作为未来关系入口的初版验证
• 支持同大学、同高中、同实业团
• 标记时间重合/不重合/未知
• 每个相关选手后展示关系标签

V0.2.3 同台竞技关系

• 基于 RaceResult 在线计算
• 展示同一 Race 的共同出场选手
• 展示同台竞技次数

V0.2.4 组织详情页

• 新增组织页
• 展示当前/历史所属选手
• 支持跳转选手

V0.2.5 导航收口

• 导航增加赛事/组织入口
• 关系入口策略稳定化

9. 待讨论问题

1. 赛事页优先只做第102回箱根駅伝，还是同时兼容所有已入库比赛的通用详情？
2. 组织页是否需要显示未确认壳子选手？
3. 同台竞技是否只算同一 Race，还是也展示同一届赛事不同区间？
4. 关系模块是否要显示“关系解释”，例如为什么判定为同時期？
5. 关系数据未来是否需要预计算、缓存或其他存储形态，何时再决策？

10. 当前建议

当前最合理的下一步是：

先做第102回箱根駅伝赛事届次页，再把选手页关系模块接上。

原因：

• 第102回箱根駅伝可以作为赛事届次页样本，5区是其中优先展示的比赛单元。
• 它能自然验证 Race / RaceResult 页面结构。
• 它能反向支撑“同台竞技”关系。
• 它也是从黑田朝日向外 BFS 的合理起点。