8.2 KiB
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 项都是改信息架构，建议合并进同一次原型重生成。这是第二次提出——分次打补丁的成本会持续累积。