行为与告警语义：触发、后果、复位与记录

内容类型：专项方法难度：进阶适合：修改状态机、告警、联锁、阈值和试验流程的上位机工程师阅读时间：约 9 分钟

上位机需求里最容易被误解的词之一是“报警”。有人说“报警”只是希望界面提示并记录，有人说“报警”意味着立即停止试验。如果不先固定后果，AI 很容易把一个显示需求改成控制逻辑。

V10 用 Behavior Contract 先把行为讲清楚，再实施。

六行 Behavior Contract

Trigger:
Condition:
Action:
Reset:
Record:
NonGoals:

项目	含义
Trigger	在什么阶段、事件或周期开始判断
Condition	什么条件算成立，是否连续/平均/窗口统计
Action	条件成立后系统到底做什么
Reset	什么时候清计数、解除状态或允许再次触发
Record	要保存哪些日志、原始值、工程值、时间和状态
NonGoals	明确这次不改变什么

事件后果四级

类型	行为
InterlockFault	报警，并阻断/停止流程，需要明确恢复条件
AlarmOnly	报警和记录，但流程继续
Advisory	操作员提示/建议，不改变主流程；是否需要确认由具体业务和 UX 决定
Information	仅状态展示或记录

需求只写“报警”但后果不明确时，如果四种选择会导致不同业务结果，应先确认 Action，而不是先写代码。

Advisory 的关键不是“必须弹窗确认”，而是它本身不应成为新的硬门禁。可以是 banner、toast、状态提示，也可以在某些场景要求操作员确认；确认机制属于额外的交互决策。

例 1：连续 5 次高电流只报警

Trigger: 停机窗口开始采样后
Condition: 连续 5 个有效帧达到参考峰值的 90%
Action: AlarmOnly，不停止当前试验流程
Reset: 任意正常帧清连续计数；下一停机窗口重新开始
Record: 记录连续 5 帧 RawPeak、工程电流、阈值和时间戳
NonGoals: 不改示波器采集模式、不改高压输出、不改下一测试窗口启动

这里“连续 5 次”还隐含几个必须确认的问题：

• 无效帧算不算打断连续；
• 同一个停机窗口是否只报警一次；
• 报警后继续计数还是锁定；
• 下一窗口是否自动复位。

例 2：磁盘不足只提示

Trigger: 正式试验启动前
Condition: 目标磁盘剩余空间 < 5 GB
Action: Advisory，提示用户但允许继续；本例不要求确认
Reset: 下一次启动前重新检查
Record: 记录剩余空间和提示时间
NonGoals: 不增加新的测试启动失败条件

Advisory 检查推荐 Fail-Open：

检查本身异常
→ 记录诊断
→ 不阻断测试

检查成功且条件成立
→ 展示提示
→ 主流程继续

如果某个项目确实要求“用户必须确认已知晓”，应在 Behavior Contract 中单独写清：

Acknowledgement: Required

但这仍不意味着 Advisory 本身升级为 InterlockFault；除非业务规则明确要求确认前不允许继续，否则不要让“提示功能”变成新的系统故障点。

告警文案和设备动作要分开

推荐把操作员层和诊断层分开：

OperatorSummary:
“停机窗口检测到持续残余电流，试验继续运行，请关注设备状态。”

DiagnosticDetail:
连续帧原始值、换算值、阈值、设备命令、错误码、时间戳

操作员不需要看到重复的英文 SCPI 文本，但维护人员必须能从日志追溯底层证据。完整的界面/诊断分层见 操作员界面与维护诊断分层。

Threshold 变化先判断是不是 DomainConstraint

“15 A 改成 16 A”看起来只是一个数字，但可能存在：

UI 提示
→ 输入校验
→ Domain/Application
→ MES/API
→ DeviceApply
→ Tests

如果它是正式业务约束，就沿这条固定传播链检查一次；如果只是显示范围，就不要扩到全部层。

这里最重要的不是“搜到几个 15”，而是找出真正拥有该规则的 owner，并区分内部表示、外部契约和设备真实下发。完整方法见 业务约束跨层传播：一个数字到底要改几层。

临时边界测试不是正式规则修改

用户说：

• “先把 1500 Hz 限制去掉，我做个边界测试”；
• “先临时允许更高电流”；

优先走 ExperimentalChange：

开发/工程模式 override
→ 窄入口生效
→ 明确恢复方式
→ 测试结束恢复

不要默认把临时条件同步改进正式 Domain、MES 和持久化规则。只有用户明确确认“以后正式规格就这样”，才升级为正式 BehaviorPatch。

状态机和联锁验证

涉及下面任一项时通常进入 V3：

• 停机/继续；
• 联锁；
• 故障恢复；
• 跨窗口状态；
• 并发和竞态；
• 告警后果改变；
• 多设备协调。

验证应覆盖：

正常触发
边界不触发
连续 N 次
中途恢复
重复触发
窗口/阶段切换
故障后复位
WorkflowSmoke

真实高压、运动、气路等危险设备动作仍需人工授权和现场验收。

常见错误

错误	后果
“报警”直接实现成 Stop	业务语义扩大
连续 N 次没有定义 Reset	状态可能跨窗口残留
只记录换算值，不保留原始证据	现场无法复盘
Advisory 被写成固定确认弹窗或检查异常导致启动失败	提示功能变成门禁
临时测试直接修改正式规则	测完后容易遗忘恢复
UI 禁用按钮但后端仍能执行	表现和真实控制不一致

和 V10 Skill 的关系

明确运行规则修改时，host-computer-dev 优先走 Execution / BehaviorPatch，而不是重新做完整需求分析；只有 Action、Reset 等关键业务语义仍未知时，才升级到 Discovery。

相关页面：

• 功能修改最小流程
• 业务约束跨层传播
• 操作员界面与维护诊断
• WPF 上位机 AI 开发流程
• 测量值语义
• Bug / 回归定位

一句话原则

先确定条件成立后系统到底应该做什么，再决定弹什么窗、是否需要确认、写什么日志、调用什么方法。