Appearance
真实设备操作与验证安全边界
AI 可以自动修改代码、跑 Fake/Replay、做静态检查和 focused test，但真实设备动作不是普通自动测试资源。
V10 默认：
text
HardwareAction: ForbiddenByDefault没有明确授权时，不让 Agent 为了“验证一下”自动改变真实设备状态。
1. 先把“验证”分成四层
| 层级 | 例子 | 默认策略 |
|---|---|---|
| 软件静态/单测 | parser、状态转换、参数校验 | 可自动 |
| Fake / Replay | Fake SCPI、录制报文、模拟设备 | 优先自动 |
| 真实设备只读观察 | 读取状态、错误队列、查询模式 | 需确认安全性和授权，尽量不改变状态 |
| 真实设备状态改变 | 高压输出、运动、阀门、继电器、加热、启动试验 | 必须显式授权；高风险动作保持 HITL |
不要因为某条 SCPI 命令名字是 QUERY 就默认无副作用；设备手册和现场行为才是证据。
2. 未授权时禁止自动做什么
未经用户明确授权，Agent 不应自动：
- 打开高压或信号输出；
- 运动电机、平台、执行机构；
- 操作阀门、继电器、气路、加热器；
- 改变联锁、急停、保护状态；
- 修改真实设备关键保护参数；
- 为回归测试重复执行有物理后果的动作；
- 新建第二设备会话去“顺便查状态”，造成会话抢占或状态改变。
代码已经具备这些能力，不等于 Agent 可以直接调用。
3. 高风险动作即使授权也保持 HITL
高压、联锁、急停、运动、气路等高风险行为应拆成：
text
Agent
→ 完成代码、配置和软件侧检查
→ 明确将要执行的设备动作
→ 操作员确认现场条件
→ 人工触发/在场执行
→ Agent 读取结果和证据不要把“用户允许真机测试”理解成“以后所有真实设备命令都可以自动执行”。授权应对应当前目标和当前范围。
4. 软件侧先证明能证明的部分
真机之前优先完成：
text
V0/V1 static/build
→ focused unit
→ Fake transport
→ Captured Replay
→ WorkflowSmoke
→ HardwarePending例如高压电源功能可以先证明：
- 电压目标值校验正确；
- 状态机在联锁未满足时不会进入输出状态；
- Fake 记录到正确命令顺序；
- Stop/Cancel 会走预期路径；
- 告警后果符合 Behavior Contract。
这些软件侧证据成立后，仍不能写“真实高压已验证”。
5. 最终状态要区分 Verified 和 HardwarePending
推荐报告：
text
VerificationLevel: V3
AffectedBuild: Verified
FocusedTests: Verified
FakeSCPI: Verified
WorkflowSmoke: Verified
RealHardware: HardwarePending
Reason: 未授权执行 2 kV 输出动作比“测试通过”更准确，也不会逼 Agent 为了补一个绿色结果去自动碰真机。
6. 只读设备诊断也要有边界
真实设备只读诊断适合：
- 读取当前状态；
- 查询 error queue；
- 查询输出/模式；
- 读取版本/配置快照；
- 对照当前软件状态。
执行前仍要确认：
- 查询不会改变设备状态；
- 不会打开第二个互斥 Session；
- 不会抢占正在运行的测试窗口；
- 不会清空后续需要保留的诊断队列；
- 现场当前允许执行查询。
如果查询本身有副作用，就按状态改变动作处理。
7. 联锁和 UI 按钮是两层安全
text
UI Disable
≠ Safety Interlock按钮禁用是操作体验，真正的危险动作必须在后端执行边界再次检查：
text
Operator Command
→ Workflow / Safety Gate
→ Device Action不能出现：
text
按钮灰了
但其它调用路径仍能直接 SendCommand()安全条件应由稳定 owner 管理，而不是散落在几个页面控件里。
8. Advisory Fail-Open 不等于安全联锁 Fail-Open
V10 对磁盘容量、日志空间等非安全提示检查推荐 Fail-Open：检查失败不阻断试验。
但真正的安全联锁不能照搬：
text
Advisory check failure
→ 可记录并继续
Safety interlock unknown/failure
→ 按项目安全设计处理，通常不能自动当作“条件满足”“提示功能”和“安全保护”必须先分类。
9. ExperimentalChange 不能偷偷绕开保护
临时边界测试可以放宽业务上限，但要明确：
text
ExperimentalScope
OfficialRulePreserved
SafetyInterlockPreserved
RestoreMethod
OperatorAuthorization如果实验本身需要改变保护阈值、联锁或危险设备参数，这已经不是普通 ExperimentalChange，必须单独确认风险和现场授权。
10. Session / Stop / Recovery 也是安全问题
真实设备控制常见风险并不只来自“数值太大”：
- Stop 返回了，但后台命令还在发送；
- Cancel 没传播到设备会话；
- 重连后旧 receive loop 仍存活；
- 第二 SCPI Session 与第一 Session 并发；
- 软件退出但输出状态未明确；
- 故障恢复自动重新启动危险动作。
11. 真机验证前最小检查
- 当前代码版本和配置已固定；
- 本次设备动作、目标值、持续时间明确；
- 联锁/急停有效；
- 操作员知道预期动作和停止方法；
- 日志/时间戳已开启；
- 只执行当前验收所需最小动作；
- 异常时有明确停止和断电/复位路径；
- 验证后保存设备状态和结果证据。
12. 和资料安全不是一回事
本站原有 AI 开发安全与脱敏边界 主要回答“什么资料能不能交给 AI”。
本页回答的是另一件事：AI 在软件和真实设备之间可以自动做到哪一步。
两种安全都需要，但不能混成一条规则。
一句话原则
能用 Fake/Replay 证明的先在软件侧证明；真实设备状态改变默认不自动执行，高风险动作即使授权也保持人工在环。