Appearance
第一章 产品概述
1.1 这个页面解决什么问题
操盘列表是操盘团队的「主战场」——操盘手每天打开系统后停留时间最长的页面。一个典型的操盘手，早班上班后需要快速回答三个问题：
- 有哪些赛事还没上架？ 特别是马上要开赛的，必须优先处理
- 正在滚球的赛事有没有异常？ 比如单边比例突然飙高、投注额异常集中
- 我负责的赛事现在什么状态？ 盘口开着还是隐藏了，数据源有没有问题
围绕这三个核心问题，操盘列表承担四项职责：
| 职责 | 对应的操盘手问题 | 设计体现 |
|---|---|---|
| 展示赛事实时状态 | 这场比赛现在怎么样了 | 比分、阶段、盘口状态实时更新 |
| 多维度快速筛选 | 我只想看英超的滚球赛事 | 侧边栏+筛选区联动 |
| 提供操作入口 | 这场要上架/锁盘/下架 | 行内按钮+批量操作 |
| 告警预警 | 哪些赛事需要我立刻处理 | 告警列+置顶区+声音提醒 |
设计边界：操盘列表只管「比赛结束前」的事。比赛结束后的结算、退款、派奖，由结算管理页面负责。两个页面的分工：
- 操盘列表：上架 → 操盘 → 比赛结束
- 结算管理：比赛结束 → 结算 → 派奖
当结算接口推送比赛结束或异常状态（取消/腰斩/中断）时，赛事自动从操盘列表消失，流转到结算管理。操盘手不需要手动处理这个流转——这是刻意的设计，因为什么时候该结算是结算接口说了算，不是操盘手判断的事。
1.2 谁在用这个页面
普通操盘手（日常主力）
张三是一个普通操盘手，负责英超和西甲的赛事。他的典型工作日：
- 09:00 上班，点击「待上架全部」，看到今天有12场待上架，按开赛时间逐个审核上架
- 14:00 下午场比赛开始，切换到「滚球」页签，盯着自己负责的5场比赛
- 14:23 曼城进球了，数据源推送暂停状态，系统自动隐藏盘口，张三观察30秒后数据源恢复，盘口自动开盘
- 15:10 利物浦那场单边比例飙到75%，告警列亮红灯，张三决定手动隐藏观察
张三的权限特点：只能操作分配给自己的赛事，可以看到已分配给自己的赛事和未分配的赛事（方便主动认领待上架赛事）。
主管（团队管理）
李主管负责整个操盘团队的管理。他的关注点不同：
- 分配工作：新赛事上架时分配给合适的操盘手，滚球期间可以临时调配
- 批量操作：某个联赛出问题时，批量锁定该联赛所有赛事
主管的权限特点：可以操作所有赛事，拥有锁盘、解锁、分配操盘手等高级权限。
风控人员（紧急干预）
王风控平时不直接操盘，但在紧急情况下拥有最高权限：
- 一键锁盘：发现系统性风险时，一键锁定所有滚球赛事（比如数据源大面积故障）
- 强制下架：即使赛事正在滚球，风控也可以强制下架
风控的权限特点：最高操作权限，可以执行普通操盘手和主管都无法执行的操作。
1.3 五个核心使用场景
场景一：早班交接——审核上架
背景：今天是英超比赛日，晚上19:30有6场比赛。数据源在凌晨已经把赛事数据推送过来，状态是「待上架」。
张三的操作流程：
- 点击「待上架全部」快捷按钮
- 列表显示156场待上架赛事，按联赛分组展示
- 先处理英超（等级1联赛），再处理低级别联赛
- 点击某场比赛的「上架」按钮，弹窗要求选择：
- 负责的操盘手（必选）-盘口初始状态（默认「跟随数据源，数据源展示就展示）」）
- 确认后赛事变为「已上架」，客户端可见
为什么这样设计：
- 强制选择操盘手：避免上架后「没人管」的情况，滚球期间出问题找不到负责人
- 盘口初始状态可选：常规赛事跟随数据源即可；需检查赔率时可选「锁定」（可见但暂停投注）；高风险赛事可选「隐藏」（完全不可见），等人工确认后再开盘
场景二：滚球监控——盯盘
背景：下午14:00，张三负责的5场比赛进入滚球状态。
张三的操作流程：
- 切换到「滚球」页签（这个页签不受日期筛选影响，始终显示当前所有滚球赛事）
- 重点关注三列：
- 单边比例：超过阈值就要警惕
- 告警：有红色/橙色标签说明需要处理
- 数据源状态：如果显示「暂停」或「维护」，要留意盘口是否跟随
- 曼城比赛中进球，数据源推送暂停，观察「盘口」列从「开盘」变为「隐藏」
- 30秒后数据源恢复，盘口自动变回「开盘」（因为联赛配置了「跟随数据源」）
为什么这样设计：
- 「滚球」页签不受日期筛选影响：滚球是实时状态，操盘手需要看到所有正在进行的比赛，不管是今天还是跨天的凌晨场
- 跟随数据源配置在联赛级别：同一联赛的操盘策略通常一致，避免每场赛事单独配置
场景三：延期赛事——等待与跟踪
背景：某场比赛因为大雨延期，结算接口推送比赛结果状态为「延期」。
系统行为：
- 赛事保留在操盘列表，行背景变为橙色
- 「阶段」列显示「延期」标签
- 盘口自动隐藏（延期期间不接受投注）
- 系统开始计时，延期超过24小时会触发告警
张三能做什么：
- 只能等待结算接口推送后续状态（恢复比赛或取消）
- 可以选择下架（如果判断这场比赛今天不会恢复了）
- 不能手动把「延期」改成其他状态（一期不支持人工修改赛事状态）
为什么这样设计：
- 延期赛事留在操盘列表而不是流转到结算管理：因为延期赛事会恢复，恢复后还需要继续操盘
- 不支持人工修改赛事状态：避免本地状态和数据源状态不一致导致的结算错误，一期以数据源为准
场景四：紧急锁盘——风控介入
背景：风控发现某场比赛投注模式异常，疑似有人利用信息差套利。
王风控的操作：
- 找到该场比赛进入详情页，点击「锁盘」按钮
- 弹窗二次确认（锁盘是高危操作）
- 确认后盘口状态从「开盘」变为「锁定」
- 客户端该场比赛的所有盘口显示「暂停投注」
锁定 vs 隐藏的区别：
- 隐藏：可以被数据源恢复推送自动解除（如果配置了跟随）
- 锁定：必须人工解锁，数据源推送任何状态都不会改变锁定状态
为什么要区分：隐藏是临时的、可自动恢复的（比如进球后数据源暂停触发的本地隐藏）；锁定是主动干预的、必须人工确认后才能恢复的（防止误操作后自动恢复接受投注）。
1.4 一期功能范围
一期的核心原则：数据源驱动，人工可干预。赛事状态（正常、延期、取消、腰斩）由数据源决定，本地不能修改；但盘口状态（开盘、隐藏、锁定）可以人工干预。
1.4.1 一期包含
| 模块 | 功能 | 说明 |
|---|---|---|
| 赛事管理 | 上架/下架/批量操作 | 上架时强制分配操盘手 |
| 盘口操作 | 隐藏/取消隐藏/锁盘/解锁 | 锁盘需要主管以上权限 |
| 紧急操作 | 一键锁盘 | 锁定所有滚球赛事，需风控/主管权限 |
| 数据源联动 | 跟随配置 | 联赛级别配置是否跟随数据源暂停/恢复 |
| 告警系统 | 11种告警类型 | 最紧急、紧急、单边超限、大额投注、延期超时、比赛暂停、数据源暂停、数据源维护、数据延迟、未分配、中立场（详见第9章9.11节「告警类型枚举」） |
| 异常流转 | 自动流转到结算管理 | 取消/腰斩/中断/完场赛事自动流转 |
1.4.2 一期不包含
| 功能 | 原因 | 计划 |
|---|---|---|
| 人工修改赛事状态 | 避免本地与数据源状态不一致 | 二期评估 |
| 延期赛事人工处理 | 需要与结算规则配套设计 | 二期 |
| 赛事回滚 | 从结算管理回滚到操盘列表，涉及结算撤销 | 二期 |
| 赔率编辑 | 在赛事详情页操作，不在列表页 | 独立页面 |
| 串关配置 | 在联赛管理页面配置，不在列表页 | 独立页面 |
1.4.3 操盘列表数据范围
操盘列表展示的赛事需满足以下条件：
| 条件 | 说明 |
|---|---|
| 数据源已推送 | IM 数据源已下发赛事数据 |
| 比赛未进入终态 | 比赛结果状态不属于终态（完场/取消/中断/腰斩/弃权/退赛） |
| 未流转到结算管理 | 赛事仍在操盘生命周期内 |
字段说明：
- 比赛进程：由 IM 数据源的 Market（1=早盘/2=今日/3=滚球）+ RBTime + RBTimeStatus + EventPeriodId 推导得出，用于展示赛前/滚球/中场等阶段
- 盘口状态：由 IM 数据源的 EventStatusId（1=开盘/2=关盘）+ MarketlineStatusId + IsMaintenance 组合判断
- 比赛结果状态：由结算接口推送，包括完场/取消/中断/腰斩/弃权/退赛，用于触发流转到结算管理
上架状态与列表筛选的关系：
| 上架状态 | 可见的筛选条件 | 说明 |
|---|---|---|
| 待上架 | 「待上架」Tab、「全部」Tab | 数据源已推送，等待审核上架 |
| 已上架 | 「全部」「滚球」「即将」「赛前」Tab | 已对外展示，根据比赛进程显示在不同Tab |
| 已下架 | 「全部」Tab | 人工下架，仅在全部Tab可见，便于追踪和重新上架 |
已下架赛事的特殊说明：
已下架赛事保留在操盘列表中，原因如下：
- 下架后存在重新上架需求（如误操作、临时隐藏后恢复）
- 下架前已接受的注单需持续跟踪赛事进程并完成结算
- 便于操盘手了解完整的赛事操作历史
已下架赛事不触发置顶规则，因为下架是人工确认的主动操作，系统假定操盘手已知晓该赛事状态。如需关注已下架的滚球赛事，操盘手可通过「全部」Tab + 「滚球」进程筛选组合查看。
1.5 与结算管理的边界
操盘列表和结算管理是两个独立页面，通过比赛结果状态流转连接。
流转规则：当结算接口推送以下比赛结果状态时，赛事自动从操盘列表消失，出现在结算管理：
| 比赛结果状态 | 状态名称 | 结算处理 |
|---|---|---|
| Finished | 完场 | 正常结算 |
| Cancelled | 取消 | 全额退款 |
| Interrupted | 中断 | 待人工决策 |
| Abandoned | 腰斩 | 已产生结果正常结算，未产生结果退款 |
| Walkover | 弃权 | 按弃权规则结算 |
| Retired | 退赛 | 按退赛规则结算 |
重要说明：比赛结果状态由结算接口（或内部结算系统）推送，与 IM 数据源的 EventStatusId（盘口开关状态）是完全独立的两套字段。EventStatusId 仅表示盘口是否开盘（1=开盘/2=关盘），不表示比赛生命周期。详见第9章9.0.5节「IM三层状态字段关系说明」。
为什么自动流转而不是人工确认：
- 异常赛事的流转时机由结算接口决定（接口推送取消，就是取消了）
- 具体怎么结算是结算管理的事，不是操盘列表的职责
- 减少操盘手的非核心工作，让他们专注于操盘本身
唯一的例外——延期：延期赛事保留在操盘列表，因为延期赛事会恢复继续比赛。当延期赛事被结算接口推送为取消或腰斩时，才流转到结算管理。
修订记录
| 版本 | 日期 | 修订内容 |
|---|---|---|
| v1.0 | 2026-01-15 | 初稿 |
| v1.1 | 2026-01-20 | 清理重复章节结构，补充操盘列表数据范围定义（1.4.3节） |
| v1.2 | 2026-01-20 | 【审计修正】1) 区分「盘口状态」（IM EventStatusId）与「比赛结果状态」（结算接口），修正1.1/1.3/1.4.3/1.5节的字段引用；2) 统一普通操盘手可见范围为「已分配+未分配」（1.2节） |
| v1.3 | 2026-01-21 | 【告警一致性修正】1.4.1节告警类型从6种更新为11种，引用第九章9.11节告警类型枚举 |
| v1.4 | 2026-01-28 | 【审计修正】1.5节移除待确定标记，补充9.0.5节IM三层状态字段关系引用 |
| v1.5 | 2026-01-29 | 【宪法v1.6术语对齐】1.2节用户场景示例"手动暂停"→"手动隐藏"，"系统自动跟随暂停"→"系统自动隐藏盘口" |