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 的排班表同源(联系人 + 时段 + 轮换),建议一次设计到位,不要先做联系人再回头加时段。
|