Appearance
界面原型到 WPF：从效果图安全落地
本页只解决一件事：原型已经能表达页面方向以后，怎样把它转换成可维护的 WPF 骨架，而不把视觉稿里没有定义的业务规则一起“猜出来”。
如果你还不知道页面职责和用户流程，先看 UI 与交互详细设计。如果只是改一个现有按钮文案、Margin、颜色、列宽或绑定错误，直接走 WPF MicroPatch，不要使用本页完整流程。
1. 原型能证明什么，不能证明什么
原型通常能证明
- 信息大致分区；
- 视觉层级；
- 高频操作位置；
- 哪些区域需要曲线、表格、状态和日志；
- 用户对整体风格的偏好。
原型不能自动证明
- 数据真正来自哪个 Service/设备；
- 按钮是否真的能下发硬件；
- 哪些参数运行中可修改；
- 通信异常是否应该停机；
- 红色状态是否属于 AlarmOnly 还是 InterlockFault；
- 页面上的“已连接”是否来自真实设备；
- 真实设备动作是否已经完成安全验证。
text
Screenshot / Mockup
= Visual Evidence
≠ Business Specification
≠ Hardware Evidence2. 落地前只做一次最小映射
不需要重新写一份完整 UI 需求。只确认原型上的主要区域分别对应什么：
| 原型区域 | WPF 落点 | 还需要确认 |
|---|---|---|
| 顶部状态 | View + 状态绑定 | 状态 Source of Truth |
| 参数区域 | 输入控件 + Validation | 单位、范围、生效时机 |
| 曲线区域 | 图表容器/Series | FrameReplace / SlidingWindow、单位 |
| 表格区域 | ItemsSource | 数据来源、更新节奏 |
| 操作按钮 | Command | 前置条件、真实业务后果 |
| 日志摘要 | OperatorSummary | 维护诊断入口在哪里 |
只对“不确认就会改变实现结果”的项补问题。
3. 第一阶段：只搭 WPF 骨架
目标：验证布局和页面结构，不接真实设备。
推荐：
text
Grid / Dock / Stack 等布局
→ 页面区域
→ 控件结构
→ 共享样式
→ 静态或明确标识的 Demo Data这一阶段不要顺手：
- 打开真实串口/SCPI；
- 写真实高压输出；
- 把按钮绑定到生产设备 Service；
- 为了让页面“看起来在线”伪造真实连接状态；
- 因为效果图上有一条曲线就提前选重型图表库。
4. 演示数据必须显式标识
至少区分：
text
DemoData
SimulationData
RealDeviceDataDemoData：只为占位和视觉确认，不能用于业务结论。SimulationData：格式/行为尽量贴近真实接口，可用于软件流程验证。RealDeviceData：来自真实设备或现场记录，需要对应连接/设备证据。
给客户或评审演示时，模拟值不要伪装成正式实测数据。
5. 第二阶段：接 ViewModel / 状态接口
骨架确认以后，再接：
text
View
↕ Binding / Command
ViewModel
↕ stable seam
Application / Device / Data service目标不是“为了 MVVM 多建几层”，而是避免：
- ViewModel 直接拥有多个互斥设备 Session；
- code-behind 承担业务状态机；
- 通信回调直接刷新大量 UI；
- 页面关闭后 Timer/事件/任务仍然运行。
已有项目已经有稳定 seam 时优先复用，不为一页新 UI 重构整个架构。
6. UI 状态和设备安全分开
例如：
text
Button.IsEnabled = false只能说明用户当前不能从这个控件点击，并不能证明设备动作在其它调用入口也被阻断。真实前置条件应在应用/设备边界再次校验。
同理，页面显示“报警”时必须明确属于：
text
Information
Advisory
AlarmOnly
InterlockFault不能根据颜色或文案自动决定 Stop。
7. 操作员界面不要变成开发调试器
主页面优先回答：
text
设备现在什么状态？
当前试验进行到哪里？
我现在能做什么？
发生问题后还在继续还是已经停止？
下一步怎么处理？原始协议、错误码、堆栈、内部 Session、线程和服务名进入维护诊断层。
对应方法：操作员界面与维护诊断。
8. 曲线先确认数据语义，再选库
原型里的 Polyline/Canvas 只是占位时没有问题。
进入真实数据后先确认：
text
X 轴是什么？
Y 轴单位是什么？
FrameReplace 还是 SlidingWindow？
可见点数/时间窗？
刷新率？
是否双轴？
是否需要缩放/游标/导出？只有这些事实明确后，再比较现有控件或第三方库。选型看当前框架兼容、授权、PoC 和实际负载，不看流行度。
相关案例：从占位曲线到双 Y 轴。
9. 从模拟接到真实业务时做一次边界检查
至少确认：
- Demo/Simulation 数据入口是否已替换或明确保留；
- 真实数据单位和测量语义；
- 参数是 DisplayOnly 还是 DomainConstraint；
- Command 的真实设备后果；
- Stop/Dispose 生命周期；
- OperatorSummary 与 DiagnosticDetail；
- 需要真机的项目是否仍标
HardwarePending。
这一步不是要求重新做完整设计，只是防止“页面已经能点”被误认为“生产功能已经完成”。
10. 验证按阶段分级
纯视觉骨架
text
V1
→ affected WPF project build
→ 目标分辨率/伸缩/关键状态人工检查绑定和普通状态
text
V1 / V2
→ focused behavior
→ 不跑无关全量测试状态机/告警后果/联锁
text
V3
→ workflow / state / interlock evidence真机动作
text
SoftwareReady
→ HardwarePending
→ HITL（获得授权后）11. 最短 Prompt
text
$host-computer-dev
我已经有一张确认过的 WPF 界面效果图/截图。
请把它作为 Visual Evidence，不要把图里没有定义的设备行为自动补成需求。
请先做最小映射：
1. 页面区域；
2. 对应 View/ViewModel 状态；
3. 哪些是 Demo Data；
4. 哪些按钮还缺真实业务后果；
5. 第一阶段只实现 WPF 骨架需要改哪些文件。
先完成骨架和 V1 验证；真实设备接入单独处理。12. 三个 UI 页面怎样分工
| 页面 | 负责什么 |
|---|---|
| UI 与交互详细设计 | 新页面/重设计：用户流程、页面职责、状态和动作 |
| 本页 | 已有原型/效果图 → WPF 可实现骨架 |
| WPF 上位机 AI 开发流程 | 已有项目日常 WPF 开发、MicroPatch 和行为修改 |
这样三页不再重复维护三套“完整 UI 流程”。
一句话原则
效果图负责说明“看起来怎样”，WPF 落地负责建立可维护结构，业务和真机证据必须从代码、规则和验证中获得，不能从一张图里猜出来。