183 lines
9.7 KiB
Markdown
183 lines
9.7 KiB
Markdown
# 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 的排班表同源（联系人 + 时段 + 轮换），建议一次设计到位，不要先做联系人再回头加时段。
|