Appearance
WPF 上位机 AI 开发流程(V10)
WPF 任务最容易出现两种极端:要么只盯着 XAML 外观,忽略状态、线程和设备行为;要么只是改一个文案、Margin,却让 AI 重新做一遍页面设计和完整回归。V10 的原则是:先判断这次到底是在改显示、改行为,还是重新设计页面,再决定分析深度。
1. 先判断属于哪一类 UI 任务
| 类型 | 典型场景 | 默认处理 |
|---|---|---|
| UI MicroPatch | 文案、颜色、字号、Margin、列宽、简单提示、复制现有 Style | Fast Lane,直接定位和修改 |
| UI BehaviorPatch | 按钮启用条件、告警显示、页面状态、配置何时可编辑 | Execution,先固定行为语义 |
| UI Redesign / New Page | 新页面、复杂交互、信息架构重构、操作流程变化 | Discovery / 详细设计 |
不要因为文件扩展名是 .xaml 就自动启动 UI 设计流程,也不要因为改动只有几行就忽略它可能改变设备操作后果。
2. UI MicroPatch:简单修改要真的快
适合:
- “负载电流”改成“充电电流”;
- 按钮颜色和现有页面统一;
Margin、字号、列宽小调整;- 增加一句明确提示;
- 复制项目中已经存在的 Style;
- 纯显示格式问题。
推荐流程:
text
目标文本/控件
→ 找直接展示位置
→ 看相邻样式或绑定
→ 最小修改
→ Diff / readback
→ V0 或 V1MicroPatch 默认不要做这些事:
- 不重新画页面架构;
- 不加载额外 UI 设计 Skill;
- 不扫描整个项目;
- 不读全部 CONTEXT / ADR / 全局 Memory;
- 不因为一处 XAML 改动跑整个 solution 测试;
- 不顺手整理 ViewModel、Service 或公共样式。
最短 Prompt
text
$host-computer-dev
这是一个明确的 WPF UI MicroPatch。
目标:把【当前内容】改成【目标内容】。
约束:不改业务逻辑,不做页面重构,优先复用当前样式。
请精确定位直接展示位置,最小修改,并按 V0/V1 验证。3. UI BehaviorPatch:改的是操作后果,不是“界面细节”
下面这些虽然发生在页面上,却不是纯 UI:
- 故障状态下是否允许点击“启动”;
- “报警”到底只是提示,还是必须停机;
- 参数什么时候允许编辑;
- 自检失败后按钮状态如何恢复;
- 设备断线后是否保持当前页面状态;
- 点击“应用设备”是否会触发真实输出。
这类任务建议先用简短 Behavior Contract:
text
Trigger:
Condition:
Action:
Reset:
Record:
NonGoals:例如:
text
Trigger: 磁盘剩余空间低于 5 GB
Condition: 启动试验前检查到容量不足
Action: Advisory,只提示,不阻止试验
Reset: 下一次启动前重新检查
Record: 写操作日志
NonGoals: 不改测试状态机,不增加新的启动门禁界面上的“红色”“弹窗”“禁用按钮”只是表现层,真正要先确认的是 Action。
4. 新页面或复杂改版:先按操作员工作流设计
新页面、主界面重构、多个设备控制合并时,再进入较完整的 UI 设计。
上位机页面优先回答:
- 谁在使用:操作员、测试人员、调试工程师还是管理员?
- 高频动作是什么?
- 哪些数据必须一直可见?
- 哪些配置应该放到二级页面?
- 哪些操作可能影响真实设备?
- 设备在线、占用、运行、故障如何区分?
- 正常、告警、故障、离线时页面分别是什么状态?
- 长时间运行时曲线、日志、表格怎样控制刷新量?
不要把页面设计成“开发者进程启动器”。实验人员通常只关心:设备是什么、能不能用、当前是什么状态、我现在能做什么。
5. WPF 实现时的四个边界
5.1 View 与业务行为
View 负责展示和交互,不要把设备控制、通信协议和长流程直接堆进 code-behind。
5.2 ViewModel 与状态
ViewModel 适合承载:
- 页面可观察状态;
- Command;
- 输入校验;
- 面向 UI 的状态组合。
涉及真实设备、协议会话、持久化和跨页面长流程时,应复用已有 Service / Application 边界。
5.3 UI 线程
后台采集、通信和文件保存不要阻塞 UI 线程。持续刷新时重点检查:
- Dispatcher / SynchronizationContext;
- 刷新频率;
- 曲线点数上限;
- 日志和表格截断;
- CancellationToken;
- 关闭窗口后的任务释放。
5.4 操作员信息与诊断信息分层
推荐:
text
OperatorSummary
= 简短中文、结果明确、告诉操作员下一步做什么
DiagnosticDetail
= SCPI / 英文原文 / 错误码 / 寄存器 / 堆栈如果中英文意思完全重复,操作员层只显示中文;底层诊断证据仍保留到日志。还要考虑高频故障去重、恢复提示,以及“报警但继续”和“故障已停止”是否明确区分。
完整方法见 操作员界面与维护诊断分层。
6. 测量值显示不要混淆原始值和工程值
涉及示波器、传感器、电源时,页面显示前至少确认:
text
RawValue
EngineeringValue
Conversion
ThresholdBasis
Aggregation
LoggedUnit例如 CH2 原始峰值可能是 V,经 0.005 V/A 换算后才是 A。UI 显示、业务判定和日志记录可能使用不同层级,必须明确单位。
详细说明见 测量值语义。
7. 验证:不是所有 WPF 修改都需要同一套回归
| 修改 | 推荐验证 |
|---|---|
| 纯文案、标题、静态提示 | V0:Diff / 静态检查 |
| XAML 样式、布局、Binding 小改 | V1:受影响项目 build + 页面检查 |
| ViewModel 条件、参数约束、导出过滤 | V1/V2:affected build + focused test(有明确测试时) |
| 设备状态、MES、配置应用 | V2 |
| 状态机、联锁、告警后果、并发 | V3 |
| 发布与广泛兼容 | V4 |
V0/V1 不默认升级到完整 solution 回归。
8. 常见反模式
| 反模式 | 问题 | 更好的做法 |
|---|---|---|
| 改一个 Label 先做页面架构分析 | 浪费时间和上下文 | MicroPatch |
| 所有 XAML 改动都加载完整 UI Skill | 简单任务变重 | 复杂页面才加载 |
| “报警”默认等于“停机” | 业务后果可能错误 | 先确定事件后果 |
| ViewModel 里直接拼大量协议错误文本 | 操作信息和诊断耦合 | Summary / Detail 分层 |
| 只看界面没报错 | Binding/线程问题可能被漏掉 | 按影响选择 V1–V3 |
| 为了可测性给小 UI 改动新建公共接口 | 过度设计 | 复用现有 seam |
9. 和其它页面怎么配合
- 单纯界面原型与效果图:界面原型到 WPF 开发流程
- 操作员提示与维护诊断:操作员界面与维护诊断分层
- 一般功能修改:功能修改最小流程
- 告警/故障语义:行为与告警语义
- 测试与验证:回归测试与验收清单
- 新项目完整流程:完整项目工作流
一句话原则
先判断这是显示修改、行为修改还是页面设计;只使用当前任务真正需要的 UI 工程纪律。