166 lines
9.8 KiB
Markdown
166 lines
9.8 KiB
Markdown
# Bell 原型评审
|
||
|
||
> 基准：`yovision-T-004/docs/design/bell/index.html`（codex，2026-08-04 09:54，525 行 / 57 KB）
|
||
> 对标：T-004 任务书方案 4 与不可变约束、`02-requirements` §3.3/§3.4/§8、`04-architecture` §8、IX-005～IX-013、`routes.md`
|
||
> 日期：2026-08-04
|
||
|
||
---
|
||
|
||
## 0. 总评
|
||
|
||
**质量明显高于 Sense 第一版。** 七项导航（值班台 / 事件中心 / 规则策略 / 升级链 / 运营报表 / 站点与 Area / 审计）基本覆盖 `routes.md` 的页面职责，而且几处最容易做错的领域约束都做对了。
|
||
|
||
问题集中在三点：**投递事实少了一态**、**事件与 Alert 的关联无法双向导航**、**值班场景缺交接班**。另外 Area 的归属需要一次跨文档裁决——并且要修正我此前在《12》S-03 里的建议。
|
||
|
||
---
|
||
|
||
## 1. 做对的（点名保护，重写时别丢）
|
||
|
||
| 项 | 证据 |
|
||
| --- | --- |
|
||
| **静默对话框** | 4h 写死在选项里标「（上限）」、原因必填、到期自动恢复，且明确**排除 S1 高危事件与设备离线运维告警** |
|
||
| **误报对话框** | 「这只会追加事件 outcome，不会修改原始事件事实和证据」；原因必填；进复核队列 |
|
||
| **规则对话框** | 场景模板 / 继承与覆盖 / 摄像头 / **检测区域带版本号 `ZONE-007 · v7`** / 生效时段 / 持续时间；试运行复选框**默认勾选**；主按钮是「保存并开始试运行」而不是「保存」 |
|
||
| 规则与区域解耦 | 「空间坐标由摄像头详情维护」「**区域版本变化不会绕过规则试运行或自动正式发布**」——精确回应 T-004 不可变约束 |
|
||
| **人脸能力零出现** | 全文 `人脸` 出现 **0** 次。IX-013 要求未授权租户「能力不存在而非按钮置灰」，零出现就是正确实现 |
|
||
| Area 策略对话框 | `capture_policy` 二选一、变更原因必填进审计、生成新策略版本；并写明「**Sense 投影同步前会显示旧版本，不允许绕过后端准入检查**」 |
|
||
| 策略冲突处置 | `policyConflictDialog` = IX-016 要求的「已有设备遇策略变化的显式处置流程」 |
|
||
| 弱网与权限状态 | 「结构化事件已到达，视频证据暂不可用」（渐进加载）、「没有查看此站点证据的权限」 |
|
||
| 投递时间线 | 三级链、每级时间、当前级「已送达，未确认」、下一级「预计 23:16:10 · 尚未发送」 |
|
||
|
||
---
|
||
|
||
## 2. P0
|
||
|
||
### 2.1 「已发出」与「已送达」被合并了
|
||
|
||
**证据**：全文 `已发出` 出现 **0** 次，`已送达` 4 次，`已看到` 1 次。
|
||
|
||
**依据**：
|
||
|
||
- `02-requirements` §3.4：「区分**已发出、已送达、已看到**；**没有回执不能当成功**」
|
||
- T-004 不可变约束：「Alert 的**首次投递、送达、看到、ack 和升级**必须分开展示」
|
||
|
||
**问题**：时间线目前只有「已送达」这一档，无法表达**发出了但没拿到回执**——而这恰恰是告警系统最重要的失败态。短信网关返回 `202 Accepted` 不等于用户手机收到；语音呼叫接通不等于有人听。把 sent 直接显示成 delivered，正是那句「没有回执不能当成功」要防的事。
|
||
|
||
**建议**：投递时间线每一级至少四态，且**未拿到回执时必须显式呈现**：
|
||
|
||
```
|
||
已发出 23:14:10 → 已送达 23:14:12 → 已看到 23:14:31 → 已确认 23:14:40
|
||
已发出 23:14:13 → ⚠ 未收到回执（已等待 42s）
|
||
```
|
||
|
||
对应 IX-007「失败不能伪装成功」，建议把这条从抽象要求细化为四态时间线的明确规格。
|
||
|
||
### 2.2 事件与 Alert 的关联无法双向导航
|
||
|
||
**依据**：`04-architecture` §8 明写——
|
||
|
||
> Event 与 Alert 不合并：**一个事件可触发多次预警与投递，一次预警也可聚合多个事件**。
|
||
|
||
**问题**：原型有「事件中心」和「值班台（待处置预警）」两个入口，方向是对的。但看不到这一对多/多对一关系的表达：
|
||
|
||
- 从一条 Alert 打开，它聚合了哪几条 Event？
|
||
- 从一条 Event 打开，它触发过几次 Alert、分别什么结局？
|
||
|
||
这是 Bell 最核心的数据模型。如果 UI 上表达不出来，实现时极易退化成 Event 与 Alert 一对一，而聚合、去重、已处置抑制全部依赖这个多对多关系。
|
||
|
||
**建议**：Alert 详情增加「关联事件」列表（含聚合原因：同设备冷却 / 同站点聚合 / 已处置抑制）；Event 详情增加「触发的预警」列表（含每次的最终状态）。两边互为深链。
|
||
|
||
### 2.3 Area 的归属需要裁决 —— 并修正我此前的建议
|
||
|
||
**现状**：Bell 原型把 Area 的 CRUD 与 `capture_policy` 编辑放在「站点与 Area」页。
|
||
|
||
**我的判断：这个归属比我此前的建议更对。** 我在《12》S-03 里把「站点与 Area 管理」列为 Sense 的待办，那是错的——Area 是带合规策略的**组织实体**，而 Bell 拥有 Site（配额真相源）、租户、RBAC 和审计。Area 作为 Site 的子级归 Bell 一致性更好。
|
||
|
||
**但由此产生两个后果，必须一并处理**：
|
||
|
||
1. **《12》S-03 需改写**：Sense 侧应为 Area **只读** + 设备写路径的准入拒绝；CRUD 归 Bell。原文的「Area 增删改」要移出 Sense 待办
|
||
2. **跨 schema 读从一处变成两处**（配额 + Area 策略）。Bell 原型自己写了「Sense 投影同步前会显示旧版本」——这个窗口期正是投影方案的固有代价。而《13》A-2 建议的同库只读视图**可以直接消除它**：视图无同步延迟，Sense 读到的永远是当前策略版本
|
||
|
||
A-2 的价值因此翻倍，建议提到裁决队列最前。
|
||
|
||
---
|
||
|
||
## 3. P1
|
||
|
||
### 3.1 缺交接班
|
||
|
||
`routes.md`「值班台/大屏」节明写：「声光提示、ack 与**交接班记录**」。全文 `交接班` 出现 **0** 次。
|
||
|
||
这是值班室最真实的场景：22:00 换班，上一班未处置的预警怎么移交、新一班如何确认接手。没有交接班，「有人负责」这个产品承诺在班次边界上断掉。
|
||
|
||
**建议**：值班台增加交接班动作——列出未关闭预警、交接人与接手人、接手确认进审计；交接期间的升级链不中断。
|
||
|
||
### 3.2 并发 ack 的结果未表达
|
||
|
||
IX-006 要求「并发 ack 有清晰结果」。两个值班员同时点 ack 会怎样，原型没有表达。
|
||
|
||
**建议**：明确为「先到者成为处置人，后到者收到明确提示并看到当前处置人」，而不是静默覆盖或双双成功。
|
||
|
||
### 3.3 重启续跑不可观测
|
||
|
||
`02-requirements` §3.4「进程重启后能续跑」、`04-architecture` §7「Alert 先落库再投递，进程重启恢复未完成升级链」。
|
||
|
||
这是一条很强的可靠性承诺，但 UI 上没有任何可验证的表达。运维无法确认它真的生效。
|
||
|
||
**建议**：升级时间线中标注「服务重启于 23:15:02，升级链已恢复」这类事件；系统状态页给出「待恢复升级链 N 条」的指标。
|
||
|
||
### 3.4 状态覆盖：多了两个好的，少了整组失败态
|
||
|
||
**实测状态演示**：`normal / loading / empty / denied / weak` —— 五态，比 Sense 的四态更好：
|
||
|
||
- `denied` 无权限 → 对应 IX-013
|
||
- `weak` 结构化事件已到、视频证据暂不可用 → 对应 App 节「弱网下先显示结构化事件，再渐进加载抓拍/视频」
|
||
|
||
这两个是一等演示态，不只是文案。
|
||
|
||
**但一个失败态都没有。** IX 清单「全局状态」节要求每个页面至少评估：
|
||
|
||
> 初始、加载、空数据、成功、**部分成功、可重试失败、不可重试失败**；无权限、**会话过期、网络断开、后端超时、数据已被他人修改**。
|
||
|
||
Bell 覆盖了加载 / 空 / 无权限，缺整组失败语义。其中两个对 Bell 尤其关键：
|
||
|
||
| 缺失态 | 为什么对 Bell 关键 |
|
||
| --- | --- |
|
||
| **数据已被他人修改** | 正是 §3.2 并发 ack 的表现形式，也是规则版本冲突的表现形式。缺它，两个问题都没有落点 |
|
||
| **可重试 / 不可重试失败** | 投递失败要区分「短信网关超时，会重试」与「号码无效，不会重试」。IX-007「失败不能伪装成功」的另一半 |
|
||
|
||
**建议**：状态演示补 `conflict`（数据已被他人修改）与 `error-retryable` / `error-final` 两类失败态。
|
||
|
||
### 3.5 事件中心与审计缺分页
|
||
|
||
全文 `分页` 出现 **0** 次。`routes.md` 对 `/events` 要求分页与筛选，对 `/audit` 要求「只读、分页、按权限脱敏」。与 Sense 是同一个问题。
|
||
|
||
---
|
||
|
||
## 4. P2
|
||
|
||
### 4.1 规则回滚偏薄
|
||
|
||
`回滚` 出现 1 次。IX-011 要求「支持取消/回滚」。试运行做得很扎实，但从「已正式发布」回退到「试运行」或「上一版本」的路径没有展开。
|
||
|
||
### 4.2 报表口径未对齐验收要求
|
||
|
||
`02-requirements` §8 规定：
|
||
|
||
> 效果指标**按规则分别报告召回率与每路每天误报数**；不使用跨场景统一「准确率」。
|
||
|
||
报表页目前是「近 7 日预警量」「处置结果」。这两个是运营口径，不是**验收口径**。而验收口径是要签进站点验收附件的，报表必须能直接出。
|
||
|
||
**建议**：报表页增加按规则维度的召回率与「每路每天误报数」，并显式标注「不提供跨场景统一准确率」——这句话本身就是对客户预期的管理。
|
||
|
||
---
|
||
|
||
## 5. 建议顺序
|
||
|
||
| 顺序 | 条目 | 理由 |
|
||
| --- | --- | --- |
|
||
| 1 | §2.1 投递四态 | 需求原文的硬要求，且是告警系统最重要的失败态 |
|
||
| 2 | §2.2 Event↔Alert 双向导航 | 核心数据模型，画不出来实现就会退化成一对一 |
|
||
| 3 | §2.3 Area 归属裁决 + 修订《12》S-03 + 提前 A-2 | 一次裁决消掉三处不一致 |
|
||
| 4 | §3.1 交接班 | 值班场景的真实断点 |
|
||
| 5 | §3.4 状态覆盖 | 补 `conflict` 态可同时给 §3.2 并发 ack 和规则版本冲突一个落点，一处改动解两个问题 |
|
||
| 6 | §3.2、§3.3、§3.5 | 并发 ack、重启续跑可观测、分页 |
|
||
| 6 | §4.1、§4.2 | 回滚与报表口径 |
|