Appearance
WPF UI Automation 与 MCP（V10）
UI Automation 可以帮助 Agent 观察窗口、控件和有限交互，但它证明的是界面层可观察行为。
它不能自动证明：
- 后端安全联锁正确；
- 设备真的执行了动作；
- 高压/运动/阀门处于安全状态；
- UI 上按钮变灰就等于设备动作一定被禁止。
因此 V10 把 UI Automation 定位为 V1–V3 中的一个证据来源，不是现场设备验收替代品。
1. 先判断这次 UI 任务需不需要自动化
| 任务 | 默认策略 |
|---|---|
| 改一处文案/颜色/Margin | V0/V1，通常不需要 UI Automation |
| Binding / Command 状态 | focused ViewModel + 必要 UI 检查 |
| 复杂页面导航/表单 | UI Automation 有价值 |
| 多状态按钮使能/弹窗 | UI Automation 可补行为证据 |
| 高压/运动/设备动作 | UI Automation 不能替代真实安全验证 |
不要为了一个 Label 改名先建设 UI 自动化框架。
2. Agent 能观察什么
取决于 WPF 控件是否正确暴露 Automation 信息，通常包括：
- Window / Button / TextBox / DataGrid / Menu 层级；
- AutomationId / Name；
- Enabled / Selected / Focus；
- 部分文本和弹窗；
- Click / Invoke / Value / Select / Scroll 等 pattern。
自绘 Canvas、图表、第三方 GPU 控件可能暴露很少信息，此时可补：
- screenshot；
- 应用日志；
- ViewModel focused test；
- 专用只读 diagnostic seam。
不要为了让 Automation“看见”而把内部调试状态全部暴露到操作员界面。
3. 三类高价值任务
A. UI 状态检查
例如业务规则已经明确：
text
Condition: InterlockFault
UI expectation:
- Start disabled
- Stop available
- OperatorSummary 显示已停止原因Automation 可以证明当前 UI 是否符合这条规则。
但要注意：
StartButton.IsEnabled == false只能证明 UI 禁用了按钮，不能证明后端调用入口、快捷键、其它页面或 API 同样受联锁保护。
真正安全联锁仍应在稳定业务/设备边界验证。
B. 固定操作路径
在 Simulation/Fake 环境中执行：
text
打开配置
→ 填参数
→ 应用模拟配置
→ 启动模拟流程
→ 切换页面
→ 查看结果适合覆盖：
- 页面跳转；
- 表单校验；
- 对话框；
- 操作员提示；
- 无真实副作用的 workflow UI。
C. 回归证据
发生 UI regression 时，可以保存：
text
Action sequence
Automation tree snapshot
Expected state
Actual state
Screenshot
Application log让修复前后跑同一操作序列，比“人工看起来好了”更可重复。
4. Simulation 必须在后端成立，不只是界面写个标签
危险项目不要只做：
text
UI 显示 Simulation
但底层仍连接真实 DeviceService真正的模拟模式应确保：
text
UI Automation
→ Application
→ Fake / Simulation Adapter
→ no real hardware side effect如果自动化按钮仍能走到真实 Device Session，这个测试环境就不安全。
5. 真实设备动作默认不进入通用 UI Automation
下面动作不应由通用 UI 自动化自由触发：
- 高压开关；
- 运动/伺服；
- 加热、气路、阀门；
- 继电器/功率输出；
- 绕过联锁、自检或门禁；
- 写永久设备参数；
- 恢复出厂/固件等不可逆操作。
如果业务验收最终确实需要这些步骤：
text
Automation/software preparation
→ HardwarePending
→ 人工确认现场条件
→ HITL 执行动作
→ 记录真实设备证据不要为了让 UI 测试“全自动”弱化后端安全边界。
6. 为 WPF 页面补稳定可测试信息
xml
<Button
AutomationProperties.AutomationId="StartTestButton"
AutomationProperties.Name="启动试验"
Command="{Binding StartCommand}"
Content="启动" />推荐：
- AutomationId 稳定、与显示文案解耦；
- Name 对人可读；
- 不按“第三个按钮”定位；
- 页面重排不应让测试全部失效；
- 共享组件使用稳定语义标识。
不要为了自动化把内部类名、线程 ID、协议字段直接变成操作员文本。
7. Accessibility 与可测试性通常同向
可以同时检查：
- 键盘能到达关键控件；
- Name 能表达动作；
- Disabled/Error 不只靠颜色；
- Dialog 打开后焦点进入合理位置；
- Dialog 关闭后焦点恢复；
- 状态变化能被 Automation 读取。
这些既改善可测试性，也改善真实操作体验。
8. MCP 暴露 UI Automation 时也要做 allowlist
不推荐一个万能 Tool：
text
click_anything(window, coordinates)更适合：
text
inspect_window(WindowId)
get_control_state(AutomationId)
set_test_input(AutomationId, Value)
invoke_safe_ui_action(ActionId)其中 invoke_safe_ui_action 只允许明确无危险副作用的动作。
MCP Tool 权限不能只靠 Prompt “请谨慎使用”。后端需要自己限制。
9. 证据等级怎么写
UI-only
text
VerificationLevel: V1/V2
UIAutomation: Verified
Hardware: NotRequiredUI Behavior + 模拟 workflow
text
VerificationLevel: V2/V3
UIAutomation: Verified
SimulationWorkflow: Verified
Hardware: NotRequired最终还需真实设备
text
VerificationLevel: V3
UIAutomation: Verified
SimulationWorkflow: Verified
Hardware: HardwarePending不要把第三种写成“功能全部通过”。
10. 一个安全的最小实验
- 使用 Fake/Simulation 启动应用；
- 只暴露窗口/控件树查询；
- 加一个固定表单填写场景；
- 加一个无设备副作用的导航/模拟操作；
- 保存 Automation 状态、截图和日志；
- 人工复核结果；
- 稳定后再扩展其它安全 UI 动作。
第一版不需要自动化整套上位机。
11. 常见反模式
- 一个 UI 文案改动也先搭 UI Automation；
- UI Disable 被当成后端 Interlock；
- Automation 直接点击真实高压按钮；
- UI 写“模拟模式”，底层仍连真机；
- 用坐标/控件顺序作为唯一定位；
- 自绘图看不见就把全部内部状态硬塞到 UI；
- MCP 暴露万能 click/send command；
- 自动化通过就写“真机已验证”。
12. 与 V10 其它能力怎么配合
- UI MicroPatch / BehaviorPatch：WPF 上位机 AI 开发流程
- 原型落地：界面原型到 WPF
- 操作员/诊断分层：操作员界面与维护诊断
- 真机边界：真实设备操作与验证安全边界
- MCP Tool 权限：MCP C# SDK 与工具调用
- 测试与回归：AI 辅助 C# 测试与回归
一句话原则
UI Automation 可以证明界面行为；安全联锁必须在后端边界成立，真实设备行为必须用对应现场证据证明。