# 事件中心生产可用性审计

审计日期：2026-07-22  
审计范围：事件流、事件详情、自动化列表、自动化编辑器、通知记录、移动端事件流  
目标用户：重要客户的一线值守、运营管理员与平台管理员

## 用户任务

1. 在大量车辆事件中快速找到需要人工处理的事件。
2. 判断事件是否可信，理解车辆、协议、观测值、规则和发生时间。
3. 接手、补充说明、完成或忽略事件，并追溯每一步操作。
4. 配置可理解、可验证、可审计的事件自动化。
5. 区分事件状态、自动化执行状态和通知送达状态。

## 当前截图证据

截图保存在：

`/Users/lingniu/.codex/visualizations/2026/07/22/019f8768-39da-7c50-a074-6c21efb5a42e/event-center-audit-2/`

1. `01-event-stream-current.jpg`：事件流默认状态。
2. `02-event-detail-current.jpg`：事件详情展开状态。
3. `03-automation-current.jpg`：自动化列表与详情。
4. `04-automation-editor-current.jpg`：自动化创建侧栏。
5. `05-notifications-current.jpg`：通知记录。
6. `06-mobile-event-stream-current.jpg`：390 × 844 移动端事件流。

## 已确认的优点

- 已经把 GB/T 32960、JT/T 808、宇通 MQTT 抽象到统一事件模型。
- 事件、自动化规则、通知记录已经拥有独立的数据状态和 API。
- 事件详情具备观测值、匹配条件、动作历史、备注和车辆/轨迹/原始数据入口。
- 自动化支持数值、电子围栏、长时间静止、长时间离线四类触发，并有版本控制。
- 移动端已经改为列表而不是压缩桌面表格。

## 生产阻塞

### P0：通知记录布局失效

通知卡片的标题、正文、通道和时间被拆成横向三列，正文所在区域出现大面积空白，通道标签被压缩为“站...”。这不是视觉偏好，而是信息结构错误；客户无法快速确认“什么事件、通过什么通道、何时送达、是否已读”。

### P0：事件详情的处置动作不在稳定可见区

详情侧栏宽度不足，VIN 与表格字段被截断；关键处置输入和动作位于首屏下方，同时底部又固定了车辆、轨迹、原始事件三个导航动作。值守人员打开事件后不能立即完成主任务。

### P1：事件前置控制层过多

用户在看到第一条事件前依次经过：页面分区、筛选栏、状态统计条、协议接入条。状态统计和协议接入信息重复占据垂直空间，却没有直接帮助当前处置任务。

### P1：自动化工作区同时展示过多层级

运行概览、规则列表、推荐模板、流程、运行记录和事件契约同时争夺注意力；推荐模板在窄列中逐字换行。事件契约对管理员有价值，但不应默认占据主要工作区。

### P1：自动化编辑器缺少分步完成感

编辑器把“当、如果、就”的全部字段放进一条长滚动侧栏。保存按钮与当前错误距离过远，用户无法快速知道还差哪一步，也没有样本事件匹配测试。

### P1：排版与可访问性风险

- 多处说明文字接近 10–11px，浅灰文字对比度偏低。
- 状态同时依赖颜色、圆点和极小文字，长时间值守可读性不足。
- 详情与编辑器需要继续验证键盘焦点顺序、焦点锁定、Esc 关闭与状态变更播报。
- 截图不能证明完整 WCAG 合规；仍需语义、键盘和自动化可访问性测试。

## 成熟产品带来的结构原则

- Datadog Events Explorer：搜索、分面、保存视图和事件侧栏是一套连续探索流程，而不是独立的仪表盘区块。  
  <https://docs.datadoghq.com/events/explorer/navigate/>
- PagerDuty：事件详情必须把状态变化、人工动作和通知统一放入可过滤时间线。  
  <https://support.pagerduty.com/main/docs/incidents>
- Sentry：列表负责筛选和优先级，详情活动流负责完整生命周期。  
  <https://docs.sentry.io/product/issues/issue-details/>
- Grafana Alerting：规则与由规则产生的事件实例是两个不同对象，状态生命周期也必须分开表达。  
  <https://grafana.com/docs/grafana/latest/alerting/fundamentals/>
- Amazon EventBridge：自动化核心是事件模式匹配和明确目标，并需要用样本事件测试匹配结果。  
  <https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html>

## 重构验收要求

1. 默认首屏直接呈现事件，不再展示独立 KPI 与协议接入统计带。
2. 事件搜索、状态视图、协议、类型和时间范围构成一套统一查询模型。
3. 事件详情默认展示：身份、证据、规则、时间线和主处置动作；主动作无需滚动即可完成。
4. 状态采用“待处理 / 处理中 / 已恢复 / 已完成 / 已忽略”，事件状态、自动化运行、通知送达互不混用。
5. 自动化采用“事件触发 → 条件/范围 → 单一动作”的可测试编辑流程，并保留版本审计。
6. 通知改为正常的审计列表，明确事件、严重度、通道、送达时间、阅读状态。
7. 桌面、1024px 笔记本和 390px 移动端均无横向溢出、截断主操作或逐字换行。
8. 加载、空数据、错误、无权限、保存冲突和动作失败均有明确可恢复反馈。
9. 核心流程具备键盘可达、可见焦点、语义标签和状态更新播报。
10. 生产构建、前端测试、API 测试、视觉对照和 ECS 发布门禁全部通过后才可交付。