9.8 KiB
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 一致性更好。
但由此产生两个后果，必须一并处理：
- 《12》S-03 需改写：Sense 侧应为 Area 只读 + 设备写路径的准入拒绝；CRUD 归 Bell。原文的「Area 增删改」要移出 Sense 待办
- 跨 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-013weak结构化事件已到、视频证据暂不可用 → 对应 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 | 回滚与报表口径 |