9.7 KiB
Bell 原型：功能与模块缺口分析（第二轮）
基准：
yovision-T-004/docs/design/bell/index.html（codex，2026-08-04 11:43，842 行 / 90 KB） 对标：02-requirements§3.3/§3.4/§3.6/§8、04-architecture§7/§8、IX-005～013 / IX-019～022、US-003～006 / US-009～012、routes.md前置：《14-Bell原型评审》 与《14》的区别：14 谈行为缺口，本文谈模块缺口——整块功能不存在 日期：2026-08-04
0. 结论
《14》提的问题基本全部落地，且清单侧同步新增了 IX-019～022、US-009～012。实测：
| 《14》findings | 本轮 | 证据 |
|---|---|---|
| §2.1 投递四态 | ✅ | 已发出 / 已送达 / 已看到 / 无回执 / 不支持 / 可重试 / 最终失败 均出现 |
| §2.2 Event↔Alert 双向 | ⚠️ 部分 | 「关联事件」「未触发」有；「聚合原因」0 次，IX-008 明确要求 |
| §2.3 Area 归属 | ✅ | IX-020 定为 Bell 管理，Sense 只消费 |
| §3.1 交接班 | ✅ | handoverDialog + IX-021 |
| §3.2 并发 ack | ✅ | 「并发」5 次 + IX-006 细化 |
| §3.3 重启续跑可观测 | ❌ | 「重启」「续跑」各 0 次，且 IX 清单里也没有这一条 |
| §3.4 状态覆盖 | ⚠️ 部分 | 新增 expired；仍无 conflict 页面级态 |
| §3.5 分页 | ⚠️ | 「分页」仅 1 次 |
| §4.1 回滚 | ✅ | rollbackDialog + 版本冲突 + IX-011 |
| §4.2 报表口径 | ✅ | 召回率 / 每路每天 / 样本量 / 导出 + IX-022 |
下面是从模块轴看仍然整块缺失的部分。
1. P0 模块缺口
1.1 联系人与通道管理（升级链能看不能编）
实测：联系人 0 次；通道 8 次；「编辑升级链」是死按钮。
现状：升级链页能展示三级链路（值班室 Web+声光 → 值班员短信 → 校级负责人语音），但联系人不是一个实体——没有人员列表、没有电话/账号、没有角色绑定、没有按时段轮换。
依据：
02-requirements§3.4：「升级链、超时、联系人和时段可按租户/站点配置」- IX-012：「联系人顺序、超时、双通道」
- US-005 的一半是「配置……联系人升级链」
需要什么：
| 项 | 说明 |
|---|---|
| 联系人实体 | 姓名、角色、可用通道（push / 短信 / 语音）、所属站点 |
| 升级链编辑器 | 每级：等待时长、联系人或角色、通道组合；至少两条独立路径的校验 |
| 按时段配置 | 需求明写「时段可配置」——夜间链路与白天链路不同，是校园场景的核心 |
| 变更影响提示 | 改升级链会影响正在升级中的 Alert 吗（建议：不影响，已在途的沿用旧版） |
这是 Bell 最核心的可配置项之一，现在只有展示没有管理。
1.2 投递供应商与故障切换
实测：供应商 / provider / 故障切换 各 0 次。
依据：
02-requirements§3.6：「投递层必须使用供应商无关的 provider 接口；试点至少有本地声光/Web 与一条短信或语音，生产前补齐两条独立路径及故障切换」04-architecture§5 第 9 条：「投递状态机只依赖 Bell provider 接口，不直接依赖某家短信或语音 SDK；生产前至少两条独立路径并能故障切换」02-requirements§3.4：「至少两条独立投递路径，其中一条可绕过互联网」
需要什么：
| 项 | 说明 |
|---|---|
| provider 列表 | 每条通道当前用哪家、健康状态、余额/配额（短信有量） |
| 主备与切换策略 | 切换条件、切换历史、当前生效的是主还是备 |
| 绕过互联网的那条路径 | 本地声光 / 局域网广播，其可用性必须单独可见——断网时它是唯一还能工作的 |
| 连通性自检 | 定期发测试消息并记录结果，避免"用的时候才发现短信欠费" |
「至少两条独立路径」是写进需求的硬约束，但现在无处配置、无处验证。
1.3 重启续跑的可观测（双缺：原型 + 清单）
实测：重启 / 续跑 各 0 次。而且遍查 IX-001～022，没有任何一条覆盖它。
依据：
02-requirements§3.4：「预警必须有 ack；未 ack 自动升级，进程重启后能续跑」04-architecture§7：「Alert 先落库再投递，进程重启恢复未完成升级链」
问题：这是一条很强的可靠性承诺，但没有任何可验证的表达。运维无法确认它真的生效，验收也无从下手——而这类承诺不验证就等于没有。
需要什么：
| 项 |
|---|
| 升级时间线中标注服务重启事件与恢复结果：「服务重启于 23:15:02，本 Alert 升级链已恢复，下一次升级 23:16:10」 |
| 系统状态/运维处给出「重启后待恢复升级链 N 条 / 已恢复 M 条」指标 |
| 恢复失败的 Alert 单独可见（落库了但恢复不了，必须暴露而不是静默） |
| 建议同时补一条 IX 条目——清单缺这条比原型缺更严重 |
2. P1 模块缺口
2.1 事件证据的保留策略与存储
实测：存储 / 留存 各 0 次；保留 5 次（多为其他语境）。
依据：02-requirements §8——
事件片段默认存客户侧 MinIO/S3 兼容对象存储……技术默认 30 天并在目的完成后删除；客户/法务确认最终期限。元数据、审计、人脸与训练样本使用独立策略。
需要什么：保留期配置（按类别：事件片段 / 抓拍 / 元数据 / 审计 / 训练样本，各自独立）；法务确认状态（技术默认值不能覆盖法务结论，这个状态必须可见）；存储用量与增长趋势；到期删除的执行记录（合规举证要用）。
2.2 场景包管理
实测：场景包 2 次（疑似文案）。
依据：M5 出口标准——「场景包为纯配置交付，无需改核心代码」，这是整个架构的验收点；目录 Bell/packs/。
需要什么：包列表与版本；导入/导出；应用到站点时的差异对比（这个包会新增/修改哪些规则）；已应用包的升级路径。没有这个模块，M5 的验收标准无法演示。
2.3 对外集成：Webhook / OpenAPI
实测：Webhook / OpenAPI 各 0 次。
依据：
02-requirements§3.6：「对外使用版本化 OpenAPI/Webhook；M3 客户端为值班室 Web + 响应式移动 H5，可嵌入客户系统」04-architecture§3：「客户平台通过版本化 OpenAPI/Webhook 集成，不反向接管核心状态机」
需要什么：Webhook 端点配置、签名密钥（只写不读）、订阅的事件类型、投递状态与重试队列、失败告警。这是"可嵌入客户系统"这句话的落地形态，四线城市客户往往已有一套平台。
2.4 用户与角色管理
实测：用户 1 次、账号 2 次、角色 2 次；有 manageDialog，但看不出 CRUD。
依据：IX-020——「Tenant/Site/Area/RBAC/配额/全局审计由 Bell 管理」；02-requirements §3.5 五角色。
需要什么：用户列表与邀请/停用；角色分配（含站点范围）；会话管理（expired 态已有，但没有主动踢下线）；密码/MFA 策略。
2.5 去重与聚合的配置面
实测：聚合 4 次、抑制 1 次、冷却 0 次。
依据：《03》§2.6 定义了四层去重——同设备冷却期（默认 5min）、同站点聚合、已处置抑制、静默窗口。目前只有静默有 UI。
需要什么：前三条的配置入口（是规则的一部分，还是站点级全局配置？现在无处设置）；以及 IX-008 要求的聚合原因在 Alert 详情中的展示（聚合原因 实测 0 次）。
3. P2 · 只留位
| 模块 | 依据 | 说明 |
|---|---|---|
| 大屏与平面图 | routes.md 值班台/大屏：「地图/平面图点位和列表双向定位，但点位缺失时仍可从列表处置」 |
地图/平面图/大屏 各 0 次。M4 才要，但导航留位 |
| 排班表 | 需求 §3.4「联系人和时段可按租户/站点配置」；交接班已有但排班没有 | 与 1.1 联系人管理同源，可合并设计 |
4. 页内小缺口（不是模块，但 IX 明确要求）
| # | 缺什么 | 依据 | 实测 |
|---|---|---|---|
| 1 | Alert 详情的聚合原因 | IX-008「Alert 展示关联 Event 与聚合原因」 | 聚合原因 0 次 |
| 2 | 试运行的命中样本 | IX-011「展示命中样本与影响范围」 | 命中样本 0 次；影响范围 1 次 |
| 3 | 事件中心的批量处置 | routes.md /events「事件筛选与批量处置入口」 |
批量 0 次 |
| 4 | 分页 | routes.md /events 与 /audit 均要求 |
分页 1 次，覆盖不明 |
| 5 | 页面级 conflict 态 |
IX 全局状态「数据已被他人修改」 | 仅回滚对话框内有版本冲突 |
5. 建议顺序
| 顺序 | 条目 | 理由 |
|---|---|---|
| 1 | 1.1 联系人与通道管理 | Bell 最核心的可配置项，US-005 的一半，现在只有展示 |
| 2 | 1.2 供应商与故障切换 | 「至少两条独立路径」是需求硬约束，现在无处配置、无处验证 |
| 3 | 1.3 重启续跑可观测 + 补 IX 条目 | 清单缺这条比原型缺更严重；先补清单再改原型 |
| 4 | §4 五个页内小缺口 | 都是 IX 已写明的，成本低 |
| 5 | 2.1 保留策略 · 2.5 去重配置 | 前者关合规举证，后者关误报体感 |
| 6 | 2.2 场景包 · 2.3 对外集成 · 2.4 用户角色 | M4/M5 前补齐 |
| 7 | P2 两项留位 | 不实现 |
1.1 与 P2 的排班表同源（联系人 + 时段 + 轮换），建议一次设计到位，不要先做联系人再回头加时段。