Appearance
第一章 产品概述
关盘口径（2026-04-21 生效）：关盘来源统一为数据源推送（唯一来源）；关盘 = 绝对终态，操盘页与结算详情页均不提供人工开盘入口。如数据源误推送关盘，依赖数据源再次推送开盘信号自动响应。
1.1 这个页面解决什么问题
操盘列表是操盘团队的「主战场」——操盘手每天打开系统后停留时间最长的页面。一个典型的操盘手，早班上班后需要快速回答三个问题：
- 有哪些赛事还没上架？ 特别是马上要开赛的，必须优先处理
- 正在滚球的赛事有没有异常？ 比如单边比例突然飙高、投注额异常集中
- 我负责的赛事现在什么状态？ 盘口开着还是隐藏了，数据源有没有问题
围绕这三个核心问题，操盘列表承担四项职责：
| 职责 | 对应的操盘手问题 | 设计体现 |
|---|---|---|
| 展示赛事实时状态 | 这场比赛现在怎么样了 | 比分、阶段、盘口状态实时更新 |
| 多维度快速筛选 | 我只想看英超的滚球赛事 | 侧边栏+筛选区联动 |
| 提供操作入口 | 这场要上架/锁盘/下架 | 行内按钮+批量操作 |
| 告警预警 | 哪些赛事需要我立刻处理 | 告警列+置顶区+声音提醒 |
设计边界：操盘列表聚焦"盘口操盘"，结算管理聚焦"赛事结算"。两者不是"时间上串联"，而是在赛事开赛后并存——各自处理不同维度的工作。
两个列表的并存关系（关键）
| 赛事阶段 | 操盘列表 | 结算列表 | 说明 |
|---|---|---|---|
| 早盘（距开赛 > 30 分钟） | ✔ 存在（盘口开放投注，"赛前"Tab） | ✘ 不存在 | 操盘手管理赔率/盘口状态；结算列表尚无结算任务 |
| 即将开赛（距开赛 ≤ 30 分钟） | ✔ 保留（"即将"Tab） | ✔ 自动进入（待结算筛选） | 双列表并存起点：阈值 30 分钟与操盘列表"即将"Tab 一致；结算列表提前收入便于结算人员准备（盘口未关盘时仅可查看，不可结算） |
| 已开赛（滚球中） | ✔ 保留（"滚球"Tab） | ✔ 保留（待结算） | 操盘手继续操盘；盘口陆续关盘后，结算人员在结算详情页逐盘口结算 |
| 比赛结束（完场但未结算） | ✔ 保留（盘口已全关盘） | ✔ 保留（待结算） | 数据源推送"比赛结束时间"时间戳；操盘手不再操作；结算人员开始赛果录入 + 结算 |
| 赛事级确认结算后 | ✘ 移除 | ✔ 保留（归档到结算日期） | 结算人员点击「结算赛事」→ 操盘列表移除该赛事；结算列表归档 |
| 赛事驳回（距最新结算时间 ≤ 24h） | ✔ 重新出现 | ✔ 状态改"待结算" | 结算人员在详情页「赛事驳回」→ 赛事从终态回到"待结算"，两端同步 |
阈值术语来源：「即将开赛 ≤ 30 分钟」对齐第 5 章 5.2.2 节即将开赛的定义；该阈值同时是结算列表自动收入的硬约束（详见 settlement 01.5 分界规则）。「紧急 ≤ 10 分钟」阈值仅用于操盘列表一键锁盘 / 置顶，不引入结算列表。
异常终态流转规则
- 异常终态（取消 / 中断 / 腰斩 / 弃权 / 退赛 / 延期超时）：由结算人员在结算详情页「赛事异常处理」按钮主动标记（数据源不推送赛事异常状态枚举）
- 操盘列表和结算列表同步展示异常红色高亮
- 操盘手不直接处理异常标记，而是观察异常后通知结算人员在结算详情页统一操作
- 详见结算详情页 16.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 小时观察窗口；超过阈值触发「延期超时」告警，分三档级别：80% 橙色 / 100% 红色 / 150%+ 红色 + 置顶（详见 09-数据字段定义 9.11.2）
- ⚠️ 超时后系统不自动转退款（一期保守设计）——告警仅提示需要决策，退款处置仍由结算人员手动执行（详见 结算详情页 16.4.3 延期暂缓观察窗口）
张三能做什么：
- 只能等待结算人员在结算详情页做后续决策（恢复赛事 → 赛事驳回回待结算 / 延期超时退款 → 已取消）
- 可以选择下架（如果判断这场比赛今天不会恢复了）
- 不能手动把「延期」改成其他状态（一期不支持人工修改赛事状态）
为什么这样设计：
- 延期赛事持续保留在操盘列表（与结算列表并存）：因为延期赛事会恢复，恢复后还需要继续操盘；操盘列表的移除时机仅为结算人员在结算详情页点击「结算赛事」后，不由赛事状态或完场事件触发
- 24h 超时后系统不自动转退款的原因：东南亚 / 菲律宾博彩运营环境下延期情况复杂多变（天气 / 安全 / 签证 / 政治事件等），一期保留人工审核环节避免误判；二期业务稳定后可评估改为"超时自动转退款"（对齐欧美主流平台高自动化模式）
- 不支持人工修改赛事状态：避免本地状态和数据源状态不一致导致的结算错误，一期以数据源为准
场景四：紧急锁盘——风控介入
背景：风控发现某场比赛投注模式异常，疑似有人利用信息差套利。
王风控的操作：
- 找到该场比赛进入详情页，点击「锁盘」按钮
- 弹窗二次确认（锁盘是高危操作）
- 确认后盘口状态从「开盘」变为「锁定」
- 客户端该场比赛的所有盘口显示「暂停投注」
锁定 vs 隐藏的区别：
- 隐藏：可以被数据源恢复推送自动解除（如果配置了跟随）
- 锁定：必须人工解锁，数据源推送任何状态都不会改变锁定状态
为什么要区分：隐藏是临时的、可自动恢复的（比如进球后数据源暂停触发的本地隐藏）；锁定是主动干预的、必须人工确认后才能恢复的（防止误操作后自动恢复接受投注）。
1.4 一期功能范围
一期的核心原则：数据源驱动，人工可干预。赛事状态（正常、延期、取消、腰斩）由数据源决定，本地不能修改；但盘口状态（开盘、隐藏、锁定）可以人工干预。
1.4.1 一期包含
| 模块 | 功能 | 说明 |
|---|---|---|
| 赛事管理 | 上架/下架/批量操作 | 上架时强制分配操盘手 |
| 盘口操作 | 隐藏/取消隐藏/锁盘/解锁 | 锁盘需要主管以上权限 |
| 紧急操作 | 一键锁盘 | 锁定所有滚球赛事，需风控/主管权限 |
| 数据源联动 | 跟随配置 | 联赛级别配置是否跟随数据源暂停/恢复 |
| 告警系统 | 11种告警类型 | 最紧急、紧急、单边超限、大额投注、延期超时、比赛暂停、数据源暂停、数据源维护、数据延迟、未分配、中立场（详见第9章9.11节「告警类型枚举」） |
| 异常处置 | 结算人员在结算详情页发起「赛事异常处理」 | 取消/腰斩/中断由结算人员主动标记（数据源不推送赛事异常枚举）；延期/完场赛事不自动移除操盘列表，双列表并存直至结算人员确认结算 |
1.4.2 一期不包含
| 功能 | 原因 | 计划 |
|---|---|---|
| 人工修改赛事状态 | 避免本地与数据源状态不一致 | 二期评估 |
| 延期赛事人工处理 | 需要与结算规则配套设计 | 二期 |
| 赛事回滚 | 从结算管理回滚到操盘列表，涉及结算撤销 | 二期 |
| 赔率编辑 | 在赛事详情页操作，不在列表页 | 独立页面 |
| 串关配置 | 在联赛管理页面配置，不在列表页 | 独立页面 |
1.4.3 操盘列表数据范围
操盘列表展示的赛事需满足以下条件：
| 条件 | 说明 |
|---|---|
| 数据源已推送 | IM 数据源已下发赛事数据 |
| 赛事未经结算级确认 | 结算人员尚未在结算详情页点击「结算赛事」；一旦确认，赛事从操盘列表移除（结算列表保留归档） |
特别说明（对齐 结算列表 01.5 规范）：
- 完场但未结算的赛事：仍保留在操盘列表（状态显示"完场"，已全部关盘），等待结算人员处理。不自动移除
- 异常态赛事（腰斩暂缓 / 延期暂缓）：仍保留在操盘列表并红色高亮（双列表同步）
- 已取消 / 已结算（结算人员确认后的终态）：赛事从操盘列表移除；结算列表保留归档到结算日期
字段说明：
- 比赛进程：由 IM 数据源的 Market（1=早盘/2=今日/3=滚球）+ RBTime + RBTimeStatus + EventPeriodId 推导得出，用于展示赛前/滚球/中场等阶段
- 盘口状态：由 IM 数据源的 EventStatusId（1=开盘/2=关盘）+ MarketlineStatusId + IsMaintenance 组合判断
- 比赛结果状态：完场由数据源"比赛结束时间"时间戳隐式标识；异常终态（取消/中断/腰斩/弃权/退赛/延期）由结算人员在结算详情页「赛事异常处理」按钮主动标记（数据源不推送赛事异常状态枚举）
上架状态与列表筛选的关系：
| 上架状态 | 可见的筛选条件 | 说明 |
|---|---|---|
| 待上架 | 「待上架」Tab、「全部」Tab | 数据源已推送，等待审核上架 |
| 已上架 | 「全部」「滚球」「即将」「赛前」Tab | 已对外展示，根据比赛进程显示在不同Tab |
| 已下架 | 「全部」Tab | 人工下架，仅在全部Tab可见，便于追踪和重新上架 |
已下架赛事的特殊说明：
已下架赛事保留在操盘列表中，原因如下：
- 下架后存在重新上架需求（如误操作、临时隐藏后恢复）
- 下架前已接受的注单需持续跟踪赛事进程并完成结算
- 便于操盘手了解完整的赛事操作历史
已下架赛事不触发置顶规则，因为下架是人工确认的主动操作，系统假定操盘手已知晓该赛事状态。如需关注已下架的滚球赛事，操盘手可通过「全部」Tab + 「滚球」进程筛选组合查看。
1.5 与结算管理的边界
操盘列表和结算管理是两个独立页面，共享同一赛事数据库，按赛事状态联动展示（双列表同步）。
1.5.1 赛事状态流转规则（对齐 结算列表-detail 16 章 规范）
| 触发事件 | 触发方 | 操盘列表行为 | 结算列表行为 |
|---|---|---|---|
| 即将开赛（距开赛 ≤ 30 分钟） | 系统按开赛时间计算（StartTime - 当前时间 ≤ 30 分钟） | 赛事进入"即将"Tab | 赛事自动进入"待结算"筛选（双列表并存起点；此阶段仅可查看，不可结算） |
| 已开赛（开赛瞬间） | 数据源（RBTime / RBTimeStatus 字段） | 赛事从"即将"Tab 切换到"滚球"Tab | 赛事保留在"待结算"，盘口陆续关盘后开始逐盘口结算 |
| 比赛结束（完场） | 数据源推送"比赛结束时间"时间戳 | 赛事保留（状态=完场） | 赛事保留在"待结算"，等待人工结算 |
| 结算人员确认结算 | 人工（结算详情页「结算赛事」按钮） | 赛事移除 | 赛事状态 → 已结算，归档到结算日期 |
| 异常标记（取消 / 延期 / 腰斩 / 数据错误） | 人工（结算详情页「赛事异常处理」按钮，数据源不推送异常状态枚举） | 赛事红色高亮（同步显示异常标签） | 赛事红色边框 + 默认置顶 |
| 赛事驳回 | 人工（结算详情页「赛事驳回」按钮，距最新结算时间 ≤ 24h） | 赛事恢复（从终态回到待结算视图） | 赛事重新出现在待结算筛选结果 |
重要说明：
- 数据源不推送赛事异常状态枚举（没有对应的赛事异常状态字段）；异常标记必须由结算人员通过结算详情页「赛事异常处理」按钮主动发起，详见结算详情页 16.1
- IM 数据源的 EventStatusId（盘口开关状态）与赛事异常状态完全独立——EventStatusId 仅表示盘口是否开盘（1=开盘/2=关盘），不表示赛事生命周期
- 详见第 9 章 9.0.5 节「IM 三层状态字段关系说明」 和 结算详情页 16.0 异常识别三源。
1.5.2 操盘列表的完赛赛事保留规则
- 完场但未结算的赛事：保留在操盘列表（不自动移除），便于操盘手追溯；操盘手对该赛事只能查看，不能再调整赔率 / 盘口状态（盘口已关盘）
- 结算人员在结算详情页完成赛事级确认结算后：赛事从操盘列表移除
- 赛事被标记为异常（腰斩暂缓 / 延期暂缓）：操盘列表保留并红色高亮，待结算人员后续决策
1.5.3 异常赛事联动规则（2026-04-23 定稿）
赛事异常（4 选 1：取消 / 延期 / 腰斩 / 数据错误）在结算详情页「赛事异常处理」触发后，操盘列表联动规则按异常类型分路：
| 异常类型 | 整场下架 | 盘口批量关盘 | 客户端可见性 | 列表展示 |
|---|---|---|---|---|
| 赛事取消 | 是（自动整场下架） | 是（批量关盘所有开盘中盘口） | 赛事客户端不可见 | 红色边框 + 红色「异常」标签 |
| 赛事延期（延期暂缓 / 超时退款） | 是（自动整场下架） | 是（批量关盘所有开盘中盘口） | 赛事客户端不可见 | 红色 / 橙色边框 + 延期标签 |
| 赛事腰斩（3 种处理方式） | 是（自动整场下架） | 是（批量关盘所有开盘中盘口） | 赛事客户端不可见 | 红色边框 + 腰斩标签 |
| 数据错误 | 否（不下架） | 否（无关盘逻辑） | 赛事客户端正常可见 | 红色边框 + 红色「数据错误」标签（仅 UI 标识，不改其他状态；弹窗仅做审计标记，实际修正走各自独立入口） |
数据错误处理：
- 数据错误弹窗仅做审计标记：不下架、不关盘、不改赛事态、不动订单（已结算和未结算订单均保持原状）
- 实际修正走各自独立入口：操盘详情页调赔率 / 赛果录入页修正 / 盘口卡片取消盘口 void / 盘口二次结算（第 15 章）
- 数据层问题精准到出错盘口，不连累整场
三层解耦原则（与结算详情页 16.0b一致）：
- 下架 = UI 层客户端整场不可见（仅取消 / 延期 / 腰斩 触发；数据错误不下架）
- 关盘 = 盘口业务态（由数据源推送触发；人工无关盘权限）
- 异常态 = 赛事业务态（由取消 / 延期 / 腰斩触发；数据错误不进入异常态，保持待结算）
恢复路径：
- 赛事驳回（结算人员在结算详情页执行）→ 赛事态恢复到待结算（仅取消 / 延期 / 腰斩 需要；数据错误无需驳回，本就保持待结算）
- 取消 / 延期 / 腰斩 的重新上架由操盘手手动决定（系统不自动恢复客户端展示）
- 数据错误无需重新上架（本就没下架）
- 数据源推送新的开盘信号时，盘口自动恢复开盘态（与下架状态独立）
修订记录
| 版本 | 日期 | 修订内容 |
|---|---|---|
| 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 | 1.2节用户场景示例"手动暂停"→"手动隐藏"，"系统自动跟随暂停"→"系统自动隐藏盘口" |
| v1.6 | 2026-04-21 | 场景三（延期赛事）补"24 小时观察窗口"行业标准依据 + 告警分档引用 9.11.2 + 明确"超时后系统不自动转退款，须结算人员手动决策"（对齐结算详情 16.4.3） |