场景02：闸门控制异常监测

当前阶段： 🔍 探索中 | 行业： 水利行业 | 关键词： 闸门控制、执行监测、偏差报警 | 返回水利场景 →

一、需求探索

1.1 痛点时刻

具体场景：

下午2点，调度中心下发指令：将3号闸门开度从20%调整到50%，以增加下泄流量。系统显示"指令已下发"。
20分钟后，现场巡查人员发现3号闸门实际开度只有30%，并未达到目标的50%。原因是闸门启闭机出现故障，卡在30%位置无法继续开启。
此时调度中心仍然认为闸门已开到50%，按此计算下泄流量，导致水位控制失误。如果不是巡查人员偶然发现，可能造成更大问题。

业务背景：

闸门规模：中型水库有5-10个闸门，大型水库有20-50个闸门
控制方式：远程控制为主，现场手动为辅
监测设备：闸门开度传感器每10秒上报一次数据
调度频率：汛期每天调度5-10次，非汛期每天1-2次

1.2 核心痛点

问题1：执行情况不透明

调度中心下发指令后，不知道闸门是否真正执行到位
系统只显示"指令已下发"，不显示"执行结果"
需要人工巡查才能发现执行异常

问题2：发现滞后

闸门执行异常后，可能20-30分钟才被发现
依赖现场巡查人员偶然发现，没有自动监测机制
夜间或恶劣天气时，巡查频率低，发现更晚

问题3：影响判断

调度中心按"目标开度"计算下泄流量，实际开度不符导致计算错误
可能影响水位控制、防汛调度等关键决策
事后追溯困难，责任不清

1.3 业务规则（行业标准）

《水闸安全鉴定规定》相关要求：

闸门启闭设备应定期检查维护（第12条）
闸门开度应与指令一致，偏差不超过5%（第13条）
发现闸门异常应立即报告并处理（第14条）

实际业务规则（基于行业调研）：

5分钟检查规则：指令下发后5分钟内检查执行情况
偏差10%预警：实际开度与目标开度偏差 > 10% → 预警
偏差20%报警：实际开度与目标开度偏差 > 20% → 报警（紧急）
零开度特殊规则：目标开度 > 0但实际开度 = 0 → 立即报警（闸门卡死）

成本测算：

误报成本：派人现场检查，耗时30分钟，人工成本约200元/次
漏报成本：调度失误导致水位控制失败，可能影响防汛安全（无法估量）
平衡点：宁可误报，不可漏报

二、方案设计

2.1 业务规则设计

规则1：闸门执行偏差检测

接口签名:

typescript

function checkGateExecutionDeviation(
  command: GateCommand,
  currentOpening: number,
  checkTime: Date
): GateExecutionDeviation

数据模型:

typescript

interface GateExecutionDeviation {
  // 指令信息
  command: {
    gateId: string;           // 闸门ID
    targetOpening: number;    // 目标开度（%）
    issuedAt: Date;           // 指令下发时间
  };

  // 实际执行情况
  actual: {
    currentOpening: number;   // 当前开度（%）
    measuredAt: Date;         // 测量时间
  };

  // 偏差判定
  deviation: {
    value: number;            // 偏差值（%）
    percentage: number;       // 偏差百分比
    isAnomalous: boolean;     // 是否异常
    severity: 'normal' | 'warning' | 'alarm';  // 严重程度
  };
}

业务规则:

偏差计算：|当前开度 - 目标开度|
偏差百分比：(偏差值 / 目标开度) × 100%
严重程度判定：
- 特殊情况：目标开度 > 0 但实际开度 = 0 → alarm（闸门卡死）
- 偏差 > 20% → alarm
- 偏差 > 10% → warning
- 偏差 ≤ 10% → normal

算法要求:

简单数值计算
复杂度：O(1)
技术难点：
- 传感器数据可靠性验证
- 闸门卡死的快速识别
- 偏差阈值的动态调整（不同闸门可能不同）

规则2：执行超时检测

接口签名:

typescript

function checkGateExecutionTimeout(
  command: GateCommand,
  currentOpening: number,
  checkTime: Date
): GateExecutionTimeout

数据模型:

typescript

interface GateExecutionTimeout {
  // 时间限制
  timeLimit: number;        // 时间限制（秒）

  // 判定结果
  isTimeout: boolean;       // 是否超时
  elapsedTime: number;      // 已用时间（秒）
  expectedTime: number;     // 预期时间（秒）
}

业务规则:

已用时间计算：检查时间 - 指令下发时间
预期时间计算：基于闸门开启速度估算
- 开度变化量 = |目标开度 - 初始开度|
- 预期时间 = 开度变化量 / 开启速度
超时判定：
- 已用时间 > 预期时间 + 缓冲时间
- 且当前偏差 > 容差阈值
- → 判定为超时

算法要求:

时间计算和比较
复杂度：O(1)
技术难点：
- 闸门开启速度的准确估算（不同闸门速度不同）
- 缓冲时间的合理设置（避免误报）
- 超时后的处理策略（继续等待 vs 停止执行）

规则3：自动响应规则

接口签名:

typescript

function triggerAutoResponse(
  severity: 'warning' | 'alarm' | 'timeout',
  context: ExecutionContext
): AutoResponse

数据模型:

typescript

interface AutoResponse {
  // 报警配置
  alert: {
    channels: string[];     // 推送渠道
    sound: string;          // 报警音
    message: string;        // 报警消息
  };

  // 自动动作
  actions: string[];        // 需要执行的动作列表
}

interface ExecutionContext {
  gateId: string;
  gateName: string;
  targetOpening: number;
  currentOpening: number;
  deviation: number;
  elapsedTime?: number;
}

业务规则:

预警（偏差10-20%）：
- 推送渠道：调度室大屏、值班人员手机
- 自动动作：显示实时开度曲线、显示启闭机状态、提示人工确认
报警（偏差>20%或闸门卡死）：
- 推送渠道：调度室大屏、值班人员手机、现场维护人员手机
- 自动动作：切换手动控制、通知维护人员、记录异常事件、启动备用方案
超时：
- 推送渠道：调度室大屏、值班人员手机
- 自动动作：检查启闭机状态、评估是否停止执行、记录超时事件

技术难点:

自动切换控制模式（远程 → 手动）
备用方案的自动启动
多渠道推送协调
异常事件的完整记录

2.2 技术方案

技术架构

闸门开度传感器 → 数据采集 → 规则引擎 → 报警推送
                      ↓
                指令执行监测
                      ↓
                可视化大屏 + 移动端

核心技术点

1. 闸门开度数据采集

采集频率：周期性上报
数据格式：{ gateId, opening, timestamp, sensorStatus }
数据校验：异常值过滤（传感器故障检测）

2. 指令执行监测

指令下发后，启动执行监测任务
周期性检查当前开度与目标开度的偏差
执行完成或超时后停止监测

3. 规则引擎

多规则并行：偏差规则 + 超时规则同时判断
规则配置化：偏差阈值、超时时间可动态调整
规则测试：支持模拟异常场景

4. 报警推送

多通道协调：大屏、APP、短信
分级推送：根据严重程度推送不同人员
推送确认：重要报警需确认机制

复杂度评估:

数据采集：低复杂度，标准传感器接口
执行监测：中等复杂度，需要任务调度和状态管理
规则引擎：中等复杂度，多规则协调
报警推送：中等复杂度，多渠道协调

技术难点:

指令执行任务的生命周期管理
闸门开启速度的准确估算
控制模式的自动切换（远程 → 手动）
异常情况下的备用方案启动

关键依赖:

闸门控制系统接口（下发指令、获取状态）
任务调度框架（定时检查）
规则引擎框架（支持动态规则配置）
多渠道推送服务

数据模型

typescript

// 闸门指令记录
interface GateCommand {
  id: string;
  gateId: string;             // 闸门ID
  gateName: string;           // 闸门名称
  initialOpening: number;     // 初始开度（%）
  targetOpening: number;      // 目标开度（%）
  issuedAt: Date;             // 指令下发时间
  issuedBy: string;           // 下发人
  status: 'EXECUTING' | 'COMPLETED' | 'FAILED';
}

// 闸门开度记录
interface GateOpeningRecord {
  id: string;
  gateId: string;             // 闸门ID
  gateName: string;           // 闸门名称
  opening: number;            // 开度（%）
  timestamp: Date;            // 采集时间
  sensorStatus: 'normal' | 'abnormal';  // 传感器状态
}

// 执行异常事件记录
interface ExecutionAnomalyEvent {
  id: string;
  commandId: string;          // 关联的指令ID
  gateId: string;
  gateName: string;
  anomalyType: 'DEVIATION' | 'TIMEOUT';  // 异常类型
  severity: 'warning' | 'alarm';  // 严重程度
  detectedAt: Date;           // 检测到异常的时间
  targetOpening: number;      // 目标开度
  actualOpening: number;      // 实际开度
  deviation: number;          // 偏差值
  status: 'PENDING' | 'CONFIRMED' | 'RESOLVED';

  // 处置记录
  disposal: {
    confirmedBy: string;      // 确认人
    confirmedAt: Date;
    cause: string;            // 异常原因
    actions: string[];        // 处置措施
    result: string;           // 处置结果
    resolvedAt: Date;
  };
}

三、AI辅助开发方案

3.1 技术迁移分析

复用已有资产：矿山场景的"环境监测异常预警"规则

相似点：

都是基于传感器数据的异常监测
都需要实时判断 + 自动报警
都需要分级预警 + 处置闭环

差异点：

维度	矿山场景（瓦斯监测）	水利场景（闸门控制）
监测对象	瓦斯浓度	闸门开度
异常判断	浓度 > 阈值	实际开度与目标开度偏差 > 阈值
触发条件	实时监测	指令下发后监测
响应动作	停止作业、人员撤离	切换手动控制、通知维护

技术复用度：80%

规则引擎逻辑：100%复用
报警推送逻辑：100%复用
异常判断逻辑：需要调整为"偏差判断"（20%新开发）

3.2 Cursor Skill设计

Skill名称： environment-monitoring-alert.md（已存在，可直接复用）

复用说明：

矿山场景的"环境监测异常预警"规则可以应用到闸门控制监测
只需调整监测对象（瓦斯浓度 → 闸门开度）和判断逻辑（阈值判断 → 偏差判断）

3.3 PROMPT模板

PROMPT 1：生成闸门执行偏差检测代码

你是一个业务逻辑开发专家。请根据以下业务规则，生成闸门执行偏差检测的代码。

## 业务场景
水利调度中心下发闸门控制指令后，需要监测闸门是否按指令执行到位。如果实际开度与目标开度偏差过大，需要自动报警。

## 业务规则
1. 偏差判定：
   - 偏差 > 10% → 预警（黄色）
   - 偏差 > 20% → 报警（红色）
   - 目标开度 > 0 但实际开度 = 0 → 立即报警（闸门卡死）

2. 超时判定：
   - 指令下发后5分钟内检查执行情况
   - 如果5分钟后仍未到位（偏差 > 5%）→ 超时报警

3. 自动响应：
   - 预警：显示实时开度曲线，提示人工确认
   - 报警：切换手动控制，通知现场维护人员
   - 超时：检查启闭机状态，评估是否停止执行

## 数据模型
- GateCommand：闸门指令记录（gateId, targetOpening, issuedAt）
- GateOpeningRecord：闸门开度记录（gateId, opening, timestamp）
- ExecutionAnomalyEvent：执行异常事件记录（anomalyType, severity, deviation）

## 技术要求
- 使用TypeScript
- 指令下发后启动监测任务，每10秒检查一次
- 支持规则配置（偏差阈值、超时时间可调整）
- 记录所有异常事件和处置过程

请参考 environment-monitoring-alert.md 中的规则，基于以上规范生成实现。

PROMPT 2：生成分级报警推送逻辑

你是一个业务逻辑开发专家。请根据以下业务规则，生成分级报警推送的代码。

## 业务场景
闸门执行异常需要根据严重程度推送给不同人员，并触发不同的应急响应动作。

## 业务规则
1. 预警（偏差10-20%）：
   - 推送到：调度室大屏、值班人员手机
   - 动作：显示实时开度曲线、提示人工确认

2. 报警（偏差>20%或闸门卡死）：
   - 推送到：调度室大屏、值班人员手机、现场维护人员手机
   - 动作：切换手动控制、通知维护人员、记录异常事件

3. 超时（5分钟后仍未到位）：
   - 推送到：调度室大屏、值班人员手机
   - 动作：检查启闭机状态、评估是否停止执行

## 技术要求
- 支持多通道推送（APP、短信）
- 推送确认机制（重要报警必须确认收到）
- 推送失败重试（最多3次）

请基于以上规范生成代码。

3.4 开发复杂度评估

基于已有资产（矿山场景）：

原型验证阶段：

复用规则引擎，调整为偏差判断逻辑
增加超时判断，测试异常场景
复杂度：低，主要是逻辑调整

首版上线阶段：

完善报警推送逻辑，对接闸门控制系统
测试各种异常场景（偏差、超时、卡死）
部署上线
复杂度：中等，需要系统对接和多场景测试

技术难点：

指令执行任务的生命周期管理
闸门开启速度的准确估算
控制模式自动切换的可靠性
异常情况下的备用方案协调

关键依赖：

闸门控制系统接口
任务调度框架
规则引擎框架
消息推送服务

四、开发资产

4.1 Cursor Skill

文件名： environment-monitoring-alert.md（已存在）

复用说明： 矿山场景的"环境监测异常预警"规则可以直接应用到闸门控制监测，只需调整以下配置：

typescript

// 监测对象配置
const MONITORING_CONFIG = {
  // 矿山场景：瓦斯浓度
  mining: {
    metric: 'gasConcentration',
    unit: '%',
    thresholds: [0.5, 1.0, 1.5],  // 预警、报警、紧急
    checkMode: 'realtime'          // 实时监测
  },

  // 水利场景：闸门开度
  waterConservancy: {
    metric: 'gateOpening',
    unit: '%',
    deviationThresholds: [10, 20],  // 预警、报警
    checkMode: 'onCommand',         // 指令下发后监测
    checkInterval: 10,              // 检查间隔（秒）
    timeoutLimit: 300               // 超时限制（秒）
  }
};

4.2 技术迁移说明

可复用的已有资产：

矿山场景：环境监测异常预警规则
- 复用：规则引擎框架、报警推送逻辑、分级预警机制
- 调整：监测对象（瓦斯浓度 → 闸门开度）、判断逻辑（阈值判断 → 偏差判断）
- 新增：超时判断逻辑
- 复用度：80%
医废场景：GPS轨迹验证规则
- 复用：偏差计算逻辑（GPS偏离距离 → 闸门开度偏差）
- 调整：偏差阈值（50米 → 10%/20%）
- 复用度：60%

需要新开发的部分：

指令执行监测任务调度（15%）
超时判断逻辑（5%）

4.3 实施指南

步骤1：准备环境

bash

# 安装依赖
npm install

# 配置闸门控制系统接口
# 编辑 config/gate-control-config.json

步骤2：使用Cursor Skill

1. 确认 environment-monitoring-alert.md 已存在于 .cursor/rules/
2. 在Cursor中告诉AI：
   "参考 environment-monitoring-alert.md 中的业务规则，
   实现闸门执行偏差监测功能。监测对象是闸门开度，
   判断实际开度与目标开度的偏差，偏差超过阈值时预警/报警。
   指令下发后定期检查执行情况，未到位则超时报警。"
3. AI会基于规则生成代码

步骤3：调整配置

typescript

// config/gate-monitoring-rules.ts
export const GATE_MONITORING_CONFIG = {
  deviationWarningThreshold: 10,   // 偏差预警阈值（%）
  deviationAlarmThreshold: 20,     // 偏差报警阈值（%）
  checkInterval: 10,               // 检查间隔（秒）
  timeoutBufferRatio: 1.5,         // 超时缓冲系数
  completionTolerance: 5,          // 到位容差（%）
};

步骤4：测试验证

bash

# 运行测试
npm test

# 模拟闸门执行异常场景
npm run simulate:gate-execution-anomaly

复杂度评估：

环境准备：低复杂度
Skill使用：低复杂度，主要是逻辑调整
配置调整：低复杂度
测试验证：中等复杂度，需要模拟多种异常场景

关键注意事项：

确保闸门控制系统接口稳定可靠
任务调度的准确性和可靠性
控制模式切换的安全性验证
异常场景的完整测试覆盖

五、下一步行动

如果您对这个场景感兴趣

快速验证：基于模拟数据做原型演示
技术对接：提供闸门控制系统接口文档，评估对接工作量
成本预估：根据闸门数量、监测点数量，给出详细报价

复杂度评估：

原型验证：低复杂度，主要是规则配置
技术对接：中等复杂度，取决于控制系统接口标准化程度
生产部署：中高复杂度，需要考虑任务调度、控制切换、异常处理

场景02：闸门控制异常监测

一、需求探索

1.1 痛点时刻

1.2 核心痛点

1.3 业务规则（行业标准）

二、方案设计

2.1 业务规则设计

规则1：闸门执行偏差检测

规则2：执行超时检测

规则3：自动响应规则

2.2 技术方案

技术架构

核心技术点

数据模型

三、AI辅助开发方案

3.1 技术迁移分析

3.2 Cursor Skill设计

3.3 PROMPT模板

PROMPT 1：生成闸门执行偏差检测代码

PROMPT 2：生成分级报警推送逻辑

3.4 开发复杂度评估

四、开发资产

4.1 Cursor Skill

4.2 技术迁移说明

4.3 实施指南

五、下一步行动

如果您对这个场景感兴趣

相关场景

相关资产

场景02：闸门控制异常监测 ​

一、需求探索 ​

1.1 痛点时刻 ​

1.2 核心痛点 ​

1.3 业务规则（行业标准） ​

二、方案设计 ​

2.1 业务规则设计 ​

规则1：闸门执行偏差检测 ​

规则2：执行超时检测 ​

规则3：自动响应规则 ​

2.2 技术方案 ​

技术架构 ​

核心技术点 ​

数据模型 ​

三、AI辅助开发方案 ​

3.1 技术迁移分析 ​

3.2 Cursor Skill设计 ​

3.3 PROMPT模板 ​

PROMPT 1：生成闸门执行偏差检测代码 ​

PROMPT 2：生成分级报警推送逻辑 ​

3.4 开发复杂度评估 ​

四、开发资产 ​

4.1 Cursor Skill ​

4.2 技术迁移说明 ​

4.3 实施指南 ​

五、下一步行动 ​

如果您对这个场景感兴趣 ​

相关场景 ​

相关资产 ​

场景02：闸门控制异常监测

一、需求探索

1.1 痛点时刻

1.2 核心痛点

1.3 业务规则（行业标准）

二、方案设计

2.1 业务规则设计

规则1：闸门执行偏差检测

规则2：执行超时检测

规则3：自动响应规则

2.2 技术方案

技术架构

核心技术点

数据模型

三、AI辅助开发方案

3.1 技术迁移分析

3.2 Cursor Skill设计

3.3 PROMPT模板

PROMPT 1：生成闸门执行偏差检测代码

PROMPT 2：生成分级报警推送逻辑

3.4 开发复杂度评估

四、开发资产

4.1 Cursor Skill

4.2 技术迁移说明

4.3 实施指南

五、下一步行动

如果您对这个场景感兴趣

相关场景

相关资产