137 lines
8.2 KiB
Markdown
137 lines
8.2 KiB
Markdown
# Sense 原型第二轮评审
|
||
|
||
> 基准：`yovision-T-004/docs/design/sense/index.html`（codex，2026-08-04 09:55，78 KB）
|
||
> 对标：`02-requirements`、`04-architecture`、`07-user-stories`、`08-interaction-checklist`（均于 09:41 更新）、`routes.md`、`api.md`
|
||
> 前置：《09-Sense原型评审-IX草稿》《10-Sense原型-功能模块缺口》
|
||
> 日期：2026-08-04
|
||
|
||
---
|
||
|
||
## 0. 结论
|
||
|
||
| 轮次 | 内容 | 状态 |
|
||
| --- | --- | --- |
|
||
| 《09》行为缺口 | IX-014～018 + 无障碍三条 + 对比度 | ✅ **基本全部落地**，且清单版本比我的草稿更好 |
|
||
| 《10》模块缺口 | 6 个 P0 模块 | ❌ **0 / 6 落地**，导航仍是 5 项 |
|
||
| 本轮新增 | 由 modality/capabilities 模型带来的新问题 | ⚠️ **5 处**，见 §3 |
|
||
|
||
---
|
||
|
||
## 1. 已落地的（有证据，不必再提）
|
||
|
||
| 项 | 证据 |
|
||
| --- | --- |
|
||
| 一级入口改名「设备」，`modality` 成为一等公民 | 原型内 `modality` 出现 29 次；筛选含 `onvif`/`radar`/`mqtt` |
|
||
| `capabilities` 驱动详情页签 | 「能力」11 次；页签改为「连接与健康」而非「流与健康」 |
|
||
| 隐私区域准入 | `updatePrivacyAdmission()`；区域筛选含 `privacy`；导入文案含「区域隐私策略」 |
|
||
| **三种停用粒度**（IX-015） | `operationDialog`：暂停推理 / 停用接入 / 断开当前会话，每项带影响说明 + 幂等声明 + 审计声明 |
|
||
| tab 模式补完整 | `aria-controls` + `aria-selected` + roving `tabindex` |
|
||
| 草稿自动保存（IX-018） | 检出自动保存逻辑 |
|
||
|
||
清单侧的 IX-015 拆成三粒度、IX-018 改成"自动保存 + 只在破坏性动作时拦截"，都比我原草稿准确。
|
||
|
||
---
|
||
|
||
## 2. 《10》的模块缺口：一处未动
|
||
|
||
导航仍是 `运行总览 · 实时监控 · 设备 · 接入任务 · 系统状态`。逐项核对：
|
||
|
||
| 《10》 | 缺口 | 本轮 | 关键词实测 |
|
||
| --- | --- | --- | --- |
|
||
| §1.2 | **对账器运维视图** | 未动 | 「孤儿」0 次、「退避」0 次；待收敛项仍不可下钻 |
|
||
| §1.5 | **权限与角色** | 未动 | 「角色」「只读」「权限」各 **0** 次 |
|
||
| §1.1 | 站点与 Area 管理 | 未动 | 「站点」仅顶栏 1 次；无 Area 增删改 |
|
||
| §1.3 | 待激活闭环 | 未动 | 筛选仍无「待激活」 |
|
||
| §1.4 | 凭据更新 | 未动 | 仍只有「已安全保存，页面不可见」，无写入路径 |
|
||
| §1.6 | 配额降级态 | 未动 | 状态演示仍是 normal/loading/empty/error 四态 |
|
||
| §2.1 | 边缘节点与隧道 | 未动 | 「隧道」0 次、「补传」0 次 |
|
||
| §2.3/2.4 | 主子码流切换 / 分片迁移 | 未动 | 「主码流」0 次、「迁移」0 次 |
|
||
| — | 设备列表分页（IX-003 明确要求） | 未动 | 「分页」0 次 |
|
||
|
||
不重复推导，理由见《10》。**优先级不变：对账器视图 > 权限 > 站点与 Area。**
|
||
|
||
---
|
||
|
||
## 3. 本轮更新新产生 / 新暴露的 5 处
|
||
|
||
### 3.1 `capabilities` 成了一等公民，却没有产生它的流程 ⚠️ P0
|
||
|
||
`capabilities` 现在决定详情页显示哪些页签——这是正确的设计。但**谁写入 capabilities？**
|
||
|
||
原型的「测试连接」仍然只是一次性反馈（"2 个 Profile，时间漂移 +0.4s"），结果没有落地成设备的持久属性。于是 `capabilities` 变成一个没有来源的字段。
|
||
|
||
而且它会**变化**：固件升级后可能新支持 ONVIF 事件订阅，换 Profile 后分辨率变化会让检测区域待校准（IX-017 已覆盖后半段，但没覆盖能力本身的变化）。
|
||
|
||
| 需要什么 |
|
||
| --- |
|
||
| 探测结果落地为设备的 `capabilities`，详情页「设备能力」区可见 |
|
||
| **重新探测**动作，以及探测结果与既有 `capabilities` 的**差异提示** |
|
||
| 能力降级的处置：原本支持事件订阅、现在探测不到了，依赖它的设备型触发怎么办 |
|
||
| 与采购白名单关联（US-007 要求形成白名单，现在白名单和设备台账没有连接） |
|
||
|
||
### 3.2 modality 可选 radar，但适配器 M6 才有 ⚠️ P0
|
||
|
||
`02-requirements` §3.1 写明：
|
||
|
||
> M1～M5 只完整实现 video 适配器，M6 再接入非视频设备，但不得因此把数据模型和一级信息架构写死为摄像头。
|
||
|
||
原型的模态下拉已经能选 `radar`/`mqtt`。**那么现在选了会怎样？** 如果能一路添加成功，原型就在承诺一个 M6 才有的能力；如果直接不可选，又违背了"信息架构不写死为摄像头"。
|
||
|
||
正解是第三种状态：**模态已建模、适配器未就绪**——可以录入、进台账、占位、参与隐私准入校验，但明确标注"适配器 M6 交付，当前不建立连接"。这个态现在不存在。
|
||
|
||
### 3.3 「暂停推理」的措辞与实际机制不符 ⚠️ P1
|
||
|
||
对话框写：
|
||
|
||
> **暂停推理**：保留媒体接入与实时预览，只停止新推理任务
|
||
|
||
但《03》§2.1 的机制是**卸载推理 source**，而且原文特别警告：
|
||
|
||
> `sourceOnDemand: yes` 的语义是「有 reader 才拉流」，而**推理 source 挂上去就是一个 reader**。因此「暂停分析」必须通过**卸载 source** 实现，不能只在推理插件里 `return`——后者会让 mediamtx 持续拉流、带宽白烧，而监控上看起来一切正常。
|
||
|
||
「停止新推理任务」这个措辞暗示的正是被明令禁止的那种实现（在推理侧跳过）。原型是 IX 的输入物，措辞会直接变成实现者的心智模型。
|
||
|
||
**建议改为**：「解除推理侧对该路的订阅；无其他观看者时上游自动停止拉流」——同时把"是否仍在拉流"作为可观察结果显示，这正是那条血泪教训要防的。
|
||
|
||
### 3.4 Area 策略可校验，但没有地方修改策略 ⚠️ P1
|
||
|
||
隐私准入在**添加**路径上做对了。但 IX-016 还要求：
|
||
|
||
> 已有设备遇到区域策略变化时进入**显式处置流程**，不静默留存或停用
|
||
|
||
这个流程的**触发点**——把某个 Area 从 `video_allowed` 改成 `non_imaging_only`——在 UI 上不存在，因为 Area 根本不可管理（《10》§1.1）。等于规则写好了但没有触发它的按钮。
|
||
|
||
同理，IX-016 的「策略读取失败时拒绝新变更并告警」也需要一个降级态，与《10》§1.6 的配额降级是同类问题：**读故障 vs 写故障表现完全不同**，而状态演示仍只有四态。
|
||
|
||
### 3.5 `api.md` 缺一行：Sense → Bell 的审计投递 ⚠️ P1（文档缺口，非原型缺口）
|
||
|
||
原型现在多处承诺审计：「每次请求均审计」、执行操作后「已记录本次审计」。
|
||
|
||
但架构 §2 定 Bell 是审计真相源，而 `api.md` §2「待冻结的内部接口」表只有五行：
|
||
|
||
```
|
||
Sense → Bell 读取站点视频配额
|
||
Bell → Sense 请求事件证据 / pre-roll 切片
|
||
Bell → Brain outcome / 误报反馈
|
||
Sense → Brain 流绑定与设备型触发
|
||
Worker → 控制面 注册、心跳、容量
|
||
```
|
||
|
||
**没有 Sense → Bell 的审计投递。** 于是原型承诺的审计要么落在 Sense 本地（架构说不行，Bell 才是真相源），要么走一条没定义的接口。这行需要补进 `api.md`，并明确：异步还是同步、Bell 不可达时 Sense 的操作是否仍然执行（我的建议：**执行，审计落本地队列重传**，与 Brain 投递失败的处理一致）。
|
||
|
||
---
|
||
|
||
## 4. 建议顺序
|
||
|
||
| 顺序 | 做什么 | 理由 |
|
||
| --- | --- | --- |
|
||
| 1 | **对账器运维视图**（《10》§1.2） | 两轮未动，仍是单点最大缺口。Sense 的存在理由在 UI 上等于不存在 |
|
||
| 2 | **权限与角色**（《10》§1.5） | 决定页面上有没有按钮，是 IA 问题；两轮为 0 |
|
||
| 3 | **capabilities 的产生流程**（§3.1） | 本轮新引入的字段没有来源，会变成永远为空的装饰 |
|
||
| 4 | **站点与 Area 管理**（《10》§1.1 + §3.4） | 现在有了明确触发点：改 `capture_policy` 需要显式处置流程 |
|
||
| 5 | 「暂停推理」措辞（§3.3） | 一句话的改动，但防的是一个会烧带宽且监控看不出来的实现错误 |
|
||
| 6 | `api.md` 补审计接口行（§3.5） | 文档改动，不影响原型 |
|
||
| 7 | 模态适配器未就绪态（§3.2）、配额/策略降级态、分页 | 补齐 |
|
||
|
||
> 第 1、2、4 项都是**改信息架构**，建议合并进同一次原型重生成。这是第二次提出——分次打补丁的成本会持续累积。
|