Appearance
UI 与交互详细设计（V10）：从操作员流程到页面结构
上位机界面的核心不是“深色科技风”，而是：操作员现在处于什么状态、最需要看什么、能做什么、做完以后软件和真实设备分别会发生什么。
但完整 UI 设计也不是所有 XAML 修改的必经步骤。V10 先分任务。
1. 先判断是否需要本页
| 当前任务 | 推荐方式 |
|---|---|
| 改文案、颜色、Margin、列宽、现成 Style | UI MicroPatch → Fast，不用本页完整设计 |
| 按钮启用条件、告警展示、参数何时可编辑 | UI BehaviorPatch → 先固定行为语义 |
| 新页面、主界面重构、操作流程变化 | 使用本页完整 UI/交互设计 |
| 只是想知道按钮当前为什么灰 | Read-Only Trace |
不要因为文件是 .xaml 就自动调用 UI 设计流程。
2. 新页面先看操作员任务，不先看视觉风格
先回答：
- 谁使用：操作员、测试人员、调试工程师、维护人员？
- 他进入页面时最常做的 1–3 个动作是什么？
- 哪些状态必须持续可见？
- 哪些信息只在排障时需要？
- 哪些操作会改变真实设备状态？
- 异常时软件应该继续、提示、报警还是阻断？
- 恢复后页面怎么回到正常状态？
这比“圆角多少、渐变什么颜色”更重要。
3. 页面职责矩阵
| 页面 | 核心任务 | 高频操作 | 持续状态 | 低频/诊断信息 |
|---|---|---|---|---|
| 主界面 | 运行、监控、停止 | 连接、启动、停止 | 在线、运行、当前值、告警 | 协议细节、版本、诊断 |
| 参数页 | 设置任务参数 | 保存、恢复、应用 | 参数合法性、应用状态 | 历史版本、底层字段 |
| 日志/维护页 | 排查问题 | 筛选、导出、复制 | 最新异常、恢复状态 | 原始协议、堆栈、错误码 |
主界面优先面向操作员，不要把 PID、线程名、内部 Service、SCPI 原文当作主要信息。
详见 操作员界面与维护诊断分层。
4. 控件状态矩阵只描述 UI，不代替后端安全
可以为 UI 写：
| 控件 | UI 何时可操作 | 为什么 |
|---|---|---|
| 启动 | 当前业务状态允许启动时 | 减少误操作 |
| 停止 | 运行/暂停阶段 | 提供正常停止入口 |
| 参数输入 | 当前规则允许修改时 | 避免无效输入 |
| 结果导出 | 有可导出结果时 | 防止空操作 |
但必须同时记住：
text
Button.IsEnabled = false
≠ 后端安全联锁真实危险动作应该再次经过：
text
Operator Command
→ Workflow / Safety Gate
→ Device Service
→ Hardware Action不能只因为按钮灰了，就认为其它调用路径绝对无法启动高压、电机或阀门。
5. 按钮动作先写 Behavior Contract
对于会改变业务状态或真实设备的按钮，建议先写：
text
Trigger:
Condition:
Action:
Reset:
Record:
NonGoals:例如“启动试验”：
text
Trigger: 操作员点击启动
Condition: 参数合法，流程处于 Ready，安全条件满足
Action: 请求 Workflow 进入启动流程
Reset: 启动失败回到 Ready，并保留原因
Record: 操作员动作、参数版本、结果
NonGoals: UI 不直接发送高压/运动命令页面按钮调用的是业务能力，不应该自己成为完整设备控制逻辑。
6. “异常”必须先分类后果
旧式 UI 设计常写：
text
通信超时 → 弹窗 → 停止
设备断开 → 所有按钮禁用 → 故障这可能是错的。
先明确业务后果：
text
Information
Advisory
AlarmOnly
InterlockFault例如：
- MES 断开可能只是 AlarmOnly，本地控制继续；
- 磁盘空间低可能只是 Advisory；
- 某设备联锁失效可能才是 InterlockFault。
界面颜色、弹窗、按钮状态都应该服务于已经确认的业务后果，而不是反过来决定后果。
详见 行为与告警语义。
7. 操作员信息与诊断信息分层
推荐：
text
OperatorSummary
= 中文短句 + 当前后果 + 下一步动作
DiagnosticDetail
= SCPI / Raw HEX / 错误码 / 寄存器 / 堆栈 / 时间线例如：
text
操作员：
“示波器通信异常，当前试验已暂停，请检查设备连接。”
诊断：
Timeout after 2000 ms; cmd=:WAV:DATA?; session=Scope1; errorQueue=...不要为了“界面简洁”把底层证据丢掉，也不要把全部底层证据塞在主界面吓操作员。
8. 页面数据源矩阵
新页面或复杂改版建议写清：
| 页面字段 | Source of Truth | UI 更新方式 | 单位/格式 | 是否可编辑 |
|---|---|---|---|---|
| 设备在线状态 | Device/Application State | 事件/轮询 | Online/Offline | 否 |
| 当前测量值 | Measurement Model | 限频推送 | 明确工程单位 | 否 |
| 任务参数 | Config/Application | 用户操作 | 明确范围和单位 | 是 |
| 告警摘要 | Alarm/Event Model | 事件 | OperatorSummary | 否 |
涉及测量值时额外确认：
text
RawValue
EngineeringValue
Conversion
ThresholdBasis
Aggregation
LoggedUnit详见 测量值语义。
9. 新页面状态要覆盖“用户真的会遇到的状态”
按项目需要选择，不要求每页机械覆盖全部：
- Loading；
- 空数据；
- 未连接；
- 连接中；
- 运行中；
- 暂停/停止；
- Advisory；
- AlarmOnly；
- InterlockFault；
- 部分数据不可用；
- 恢复中；
- 已恢复。
状态数量来自实际业务，不是 UI 模板越完整越好。
10. 用户操作流程模板
复杂流程可以写：
text
流程名称：
用户目标：
进入条件：
1. 用户做什么
2. 软件怎样响应
3. 是否产生设备动作
4. 用户看到什么结果
5. 如何结束/恢复异常分支不要直接写“弹窗/停止”，而是写：
text
Event:
BusinessConsequence:
OperatorSummary:
DiagnosticDetail:
Recovery:这样页面设计不会偷偷改变状态机。
11. 页面说明模板：需要时使用，不是每页强制 16 字段
对于新主页面、关键设备控制页，可使用较完整模板：
text
PageName:
Goal:
PrimaryUser:
EntryCondition:
CoreActions:
AlwaysVisibleState:
EditableParameters:
ReadOnlyData:
DeviceActions:
BehaviorRules:
OperatorMessages:
DiagnosticAccess:
DataSource:
RefreshPolicy:
RecoveryState:
ResolutionConstraints:对于简单二级页，只填真正相关项；对于 MicroPatch，不填这张表。
12. 上位机 UI 的几个重要原则
- 高频操作明显，低频配置收进二级页面；
- 在线/运行/告警/故障等关键状态持续可见；
- 状态不要只靠颜色，还要有文字/图标；
- 危险动作的 UI 确认只是第一层，后端仍需安全 Gate；
- 运行中参数能否编辑由业务规则决定，不一概禁用；
- 长时间运行的曲线、日志、表格要限量和限频；
- 同一个故障不要每秒重复弹窗；
- 恢复后页面要有明确恢复状态；
- 非安全 Advisory 不应意外成为启动门禁。
13. 真实设备按钮的额外安全边界
高压、运动、阀门、继电器、加热、气路等：
text
UI 点击
→ 后端安全条件
→ 必要 HITL
→ Device ActionAgent 做 UI/Workflow 自动验证时优先 Fake/Replay。没有明确授权，不为了“点一下看看”自动操作真机。
详见 真实设备操作与验证安全边界。
14. 验证按改动类型走
| 改动 | 默认验证 |
|---|---|
| 纯文案/静态提示 | V0 |
| XAML 布局/Binding 小改 | V1 |
| UI 影响 Domain/设备参数 | V2 |
| UI 改变流程、告警后果、联锁 | V3 |
| 发布级 UI/流程重构 | V4 |
不要把“视觉变化”自动等同于低风险，也不要把“XAML 文件”自动等同于需要完整回归。
15. 和其它页面怎么配合
- 简单 UI 修改：WPF 上位机 AI 开发流程
- 原型/效果图：界面原型到 WPF 开发流程
- 告警/联锁：行为与告警语义
- 操作员/诊断：操作员界面与维护诊断
- 状态机：业务流程与状态机设计
- 真机安全：真实设备操作安全
一句话原则
新页面先围绕操作员任务和业务后果设计；小 UI 修改走 MicroPatch，界面禁用和弹窗永远不能替代真实的业务规则与设备安全边界。