M4 异常能耗侦探（Demo 场景 PRD）

项	内容
文档定位	`08_移动端AI场景设计.md` §10 中反引号标记的 demo 模块的场景 PRD。本文是 M4；模板见 `公共规范.md` §8
通用规范	前端形态、系统提示词边界、定时任务方式、数据与输出规范见 `公共规范.md`；本文只写 M4 场景本身
能力来源	`01_能源类AI能力-现状与自有发挥.md` §2 规则诊断、§4 示例 3/4（异常诊断）
版本	v0.1

1. 场景定义

1.1 一句话

管理者问「最近哪些地方能耗不正常」，Agent 查规则诊断命中项，按时段类 / 阈值类分组列出异常、超出电量、证据和可能原因，并可按需转工单。

1.2 用户与价值

项	内容
用户	管理者（demo 固定账号 `M1001`，数据范围全院）
价值	不用逐条翻规则报警和运行记录，一句话拿到「哪里不正常、超了多少、可能是为什么」
频次	按需，无定时推送
层级	L2 数据查询 + L3 转工单（需确认）

1.3 触发方式

被动问答，没有定时任务。
典型 query：
- 「最近哪些地方设备/能耗不正常？」
- 「上周有没有该停没停的设备？」
- 「东塔客房新风温度正常吗？」
- 「3 楼空调能耗为什么高？」（只给规则诊断证据，不做优化建议）
时间范围不明确时默认「最近 7 天」，并在回答中写明。

1.4 边界

不做	原因
不做用能画像	总量、分项、同类对比归 M3
不做碳核算和月报	归 M5 双碳与能源月报
不生成优化策略	只解释规则诊断结果；参数调整、运行方式改变暂不作为自动建议（`01` 已定）
不通过对话下发控制	控制由自控系统按策略执行，Agent 只查询、解释、建单
不把异常直接判成故障	报警不等于故障；可能由传感器、除霜、开门等正常波动导致
不替工单系统派单	只调用建单接口，派单与处置由工单系统负责
不展示设备原始运行明细全表	只给命中时段、证据摘要和关键曲线

2. Demo 形态

通用形态见 公共规范.md（小程序悬浮球打开 DeerFlow 聊天区、单会话、Markdown + Mermaid）。

本场景只约定：

管理者在常驻会话里直接提问，回答落在聊天区，不写首页洞察卡片（M4 不是 L4 主动服务；运维侧主动告警归 O5）。
追问沿用上下文：先看异常清单，再问「第二条的证据」，Agent 取同一异常 ID 的证据。
同一轮只处理一个主意图：先列异常，用户明确说「转工单」再建单，不把建单和清单塞进一条回复。

注：演示方式——登录管理者账号，点悬浮球，输入「最近哪些地方能耗不正常？」。

3. Agent 输出设计

3.1 输出元素

元素	用途
Markdown 文字	结论、口径说明、可能原因、数据缺口
Markdown 表格	异常清单（分组）
Mermaid `xychart-beta`（line）	单设备异常时段曲线（深挖时）
Markdown 文字	转工单确认

一次回复最多 2 张图；不输出快捷按钮、不输出自定义业务卡片。

3.2 异常清单（主场景）

用户

最近哪些地方能耗不正常？

Agent

近 7 天命中 5 条：时段类 3 条、阈值类 2 条；按规则诊断口径，异常不等于故障。
时段类（该开没开 / 该关没关）
# 设备异常时段超出电量
1 EF_B1_16 中餐后厨排风机 21:30 后仍运行 47 分钟计划 5:30–14:30、16:30–21:30 18 kWh
2 FAU_B1_4 西塔客房新风应关时段运行 1 小时 12 分 10:00–14:00 26 kWh
3 FAU_B1_5 等夏季不开启设备 2 台被手动开启 — 9 kWh
阈值类（开着但不达标）
# 设备异常时段最低/最高值
4 FAU_B1_7 东塔客房新风低于目标 25℃ 14:20–15:10 23.8℃
5 FAU_B1_18 中餐厅厨房新风低于目标 27℃ 16:40–17:20 26.1℃
可能原因（只列可能，不判定故障）：
时段类多为计划外加班、检修或手动覆盖，需现场核实；
阈值类可能由冷量过大、阀门控制异常或温度传感器偏差导致；
夏季不开启设备被手动开启，需确认是否临时需求。
口径：近 7 天，规则诊断按现有配置；异常不等于故障。需要把前 3 条转工单吗？

#	设备	异常	时段	超出电量
1	`EF_B1_16` 中餐后厨排风机	21:30 后仍运行 47 分钟	计划 5:30–14:30、16:30–21:30	18 kWh
2	`FAU_B1_4` 西塔客房新风	应关时段运行 1 小时 12 分	10:00–14:00	26 kWh
3	`FAU_B1_5` 等夏季不开启设备	2 台被手动开启	—	9 kWh

#	设备	异常	时段	最低/最高值
4	`FAU_B1_7` 东塔客房新风	低于目标 25℃	14:20–15:10	23.8℃
5	`FAU_B1_18` 中餐厅厨房新风	低于目标 27℃	16:40–17:20	26.1℃

3.3 单设备深挖

用户

东塔客房新风温度正常吗？

Agent

FAU_B1_7 今天在计划时段（6:00–10:00、14:00–21:00）应保持 25℃。异常：14:20–15:10 低于 25℃，最低 23.8℃，持续 50 分钟，已触发报警。其余时段正常。可能原因：冷量过大、阀门控制异常、温度传感器偏差。建议先核对传感器，再检查阀门开度；需要我建一张排查工单吗？

3.4 转工单

用户确认「转工单」后：

只对用户点名或确认的异常建单，不批量默认建；
工单标题带设备与异常摘要，描述带异常 ID、时段、证据链接；
返回工单号与状态，不承诺处置时限；
用户没确认时不建单，只给建议。

3.5 异常与降级

情况	输出
规则未配置	明确说「该范围未配置诊断规则」，不推断异常
无异常	明说「近 N 天未发现异常」，不编原因
证据数据缺失	给清单但标注「证据不可用」，不补数
异常条数过多（>20）	按类型汇总，列前 10 条，其余按设备/空间聚合
设备台账映射缺失	标「设备未映射」，不猜位置
建单失败	说明失败原因，给工单系统入口，不反复重试
越权空间	拒绝并说明授权范围

3.6 输出模板（开发参考）

本节给 Skill 组装输出用，业务评审可跳过。

异常清单：

结构固定：结论 → 时段类表 → 阈值类表 → 可能原因 → 口径注。

单设备深挖：

{设备}今天在计划时段（{时段}）应保持 **{目标值}**。
异常：**{起止时间}** {偏高/偏低}，{最低/最高值}，持续 {时长}，已触发报警。
其余时段正常。可能原因：{2–3 条}。
需要我建一张排查工单吗？

（Mermaid 折线图：异常时段温度）

4. MCP 设计

空间树解析复用 M3 §4.1 的 query_space_tree：先把用户说的楼/层/房间解析成空间树节点，再把 node_id 传给异常查询。M4 不重复定义空间树工具。

4.1 异常查询 MCP

Tool：query_energy_anomalies

项	内容
作用	查时间窗内命中的规则诊断异常
入参	`start_date`、`end_date`、`types`（可选：`not_stopped` / `vacant_use` / `frequent_start_stop` / `yoy_jump` / `threshold`）、`scope_node_id`（空间树节点，默认根节点）、`device_id`（可选）

字段	类型	说明
anomalies	array	异常数组，字段见下
total_count	int	命中总数
by_type	object	类型 → 数量

anomalies[] 字段：

字段	类型	说明
anomaly_id	string	异常 ID
type	enum	not_stopped / vacant_use / frequent_start_stop / yoy_jump / threshold
category	enum	time_window（时段类）/ threshold（阈值类）
device_id	string	设备编码
device_name	string	设备名称
space_id	string	空间树节点 ID；未映射时为 null
space_name	string	空间名；未映射时写「未映射」
node_path	string	空间树路径，如「A 楼/3F/302」
rule_name	string	命中规则
start_time / end_time	string	异常时段
excess_kwh	number	超出电量；阈值类可能为 null
severity	enum	high / medium / low
status	enum	open / closed / ignored
evidence_available	bool	是否有证据数据

注：规则底座是现有的「行为诊断 + 异常诊断」；对外统一叫异常，按「时段类 / 阈值类」分组输出。

4.2 异常证据 MCP

Tool：query_anomaly_evidence

项	内容
作用	取单条异常的设备时序、规则配置与周边记录
入参	`anomaly_id`

字段	类型	说明
anomaly_id	string	异常 ID
device	object	`device_id`、`device_name`、`system`、`space_id`、`space_name`
evidence_type	enum	runtime（运行状态）/ temperature / power / other
series	array	`{time, value, target, status}`；status 为 running / stopped / above / below / normal
rule	object	`plan_windows[]`、`target_value`、`threshold`、`duration_min`、`effective_period`
alarm_records	array	IoT 告警记录：`{time, alarm_type, level, status, description}`；可为空
maintenance_records	array	资产维修/保养/巡检记录：`{time, type, source, summary, status}`；可为空
evidence_url	string	运行记录或证据图链接，可为空
data_quality	object	`missing_points`、`note`

注：4.1 是诊断结果清单，4.2 是同一 anomaly_id 的证据明细；数据来自设备时序 + 规则配置 + 周边记录，不是第二套诊断。不假设有基线：没有历史/同类基线时只陈述时序与记录，不给偏差判断。周边记录（IoT 告警、维修/保养/巡检）取不到时对应字段为空，不编造。证据只用于解释，不用于重新判定。series 只返回异常前后必要时段，不返回全天全表。

4.3 工单 MCP

Tool：create_workorder

项	内容
作用	按确认后的异常建工单
入参	`anomaly_id`、`title`、`description`、`priority`
返回	`workorder_id`、`status`

注：写操作必须先由用户确认；M4 不封装派单、转办、关闭。

5. Skill 设计

5.1 职责

Skill 把「定范围 → 查异常 → 分组 → 取证据 → 输出 → 确认建单」写死，保证异常口径和输出结构一致。

5.2 流程

5.3 Skill 提示词草稿

你是上海交通大学新院区 IBMS 的管理者助手，负责回答能耗异常。

输入：
- 管理者 ID：demo 固定 M1001
- 默认时间范围：最近 7 天；用户指定时以用户为准

步骤：
1. 解析范围：时间、楼/层/空间、设备（可选）。
2. 调 query_energy_anomalies(start_date, end_date, types, scope_node_id)。
3. 有异常时按「时段类 / 阈值类」分组输出；用户要证据或单设备深挖时，调 query_anomaly_evidence。
4. 用户明确确认转工单时，调 create_workorder；未确认不建单。

输出要求：
- 只用 Markdown 和 Mermaid，不输出 JSON、不用 HTML。
- 先给结论（命中多少条、两类各多少），再给分组表。
- 每条异常写：设备、异常现象、时段、超出电量或越限值。
- 可能原因最多 3 条，用「可能/需核实」表述，不判定故障。
- 无异常时明确说「未发现异常」，不编造原因。
- 规则未配置时说明未配置，不推断。
- 不生成优化策略，不通过对话下发控制。
- 一次回复最多 2 张图，只在深挖单设备时画证据曲线。

5.4 工具调用顺序与失败策略

步骤	调用	失败时
1	`query_energy_anomalies`	说明失败，不出清单；不推断
2	`query_anomaly_evidence`	给清单但标注「证据不可用」
3	`create_workorder`	说明失败原因，给工单系统入口

注：异常清单是主数据，拿不到就不出；证据是辅助，失败不影响清单。

6. 定时任务配置

无。

M4 是被动问答。运维侧的能源异常主动处置归 O5；管理者侧的月度汇总归 M10。

7. 权限与数据范围

管理者账号 M1001，demo 数据范围「全院」；生产按授权空间树节点裁剪。
数据裁剪在 MCP 层按 scope_node_id 校验，不靠提示词约束。
只返回设备与空间维度的异常摘要，不返回设备原始运行全表、个人数据。
建单权限单独校验：只允许对授权范围内的异常建单。

8. 验收要点

#	验收项	标准
1	分组	异常按「时段类 / 阈值类」分组，不混排
2	字段	每条含设备、现象、时段、超出电量或越限值
3	无异常	明确说「未发现异常」，不编原因
4	规则未配置	说明未配置，不推断异常
5	故障口径	用「可能/需核实」，不把异常直接判成故障
6	证据	深挖时曲线与规则目标值一致；证据缺失时标注
7	建单	只有用户确认后才建单，返回工单号
8	边界	不生成优化策略、不下发控制、不替代工单系统派单
9	数据范围	只出现授权范围内的设备和空间

9. 已确认与待确认

9.1 已确认

#	事项	结论
1	交互形态	被动问答，无定时任务
2	异常口径	对外统一叫异常，按时段类/阈值类分组
3	输出	结论 + 分组表 + 可能原因，最多 2 张图
4	建单	用户确认后才建单，不批量默认建
5	边界	不做优化策略、不下发控制、异常≠故障
6	空间主数据	以空间树为唯一来源，异常查询用 `scope_node_id`

9.2 待确认

新院区规则配置：行为诊断/异常诊断规则是否已按空间、设备、时段配置；未配置则异常清单为空。
诊断与地点的关联：现有诊断是否都绑定空间/设备？是否存在只按系统或设备类型配置、无法落到空间树的规则？若有，Agent 只能按设备维度展示，不做空间汇总，需要先补设备—空间映射。
超出电量算法：没有基线数据时按额定功率 × 超时时段估算；若后续有同类/历史基线再考虑差值法。口径由能源板块定。
证据保存期限：运行记录与温度点位保留多久；超过期限无法回看。
周边记录来源：IoT 告警、资产维修/保养/巡检记录由哪些系统提供、能否按设备和时间窗查询；取不到时只给设备时序，不编造。
建单字段与工单系统接口：标题、描述、优先级、附件（证据图）如何映射。
重复异常处理：同一设备连续多天命中，是每天一条还是合并为一条；与 O5 的推送口径如何对齐。
阈值与持续时间可配：温度阈值、持续时长由谁维护。

10. 关联文档

文档	关联内容
`01_能源类AI能力-现状与自有发挥.md` §2、§4 示例 3/4	行为诊断/异常诊断规则、证据与可能原因示例
`03_设备预测性维护-技术路径与项目方案.md`	设备台账与异常/工单闭环（建单边界）
`08_移动端AI场景设计.md` §6、§7、§10	运维侧 O5、管理者时间线、M4 模块定义
`公共规范.md`	前端形态、常驻会话、智能体边界、输出规范、场景 PRD 模板

注：上述文档与本文保持一致。如有差异，以本文为准，回写更新对应文档。

M4 异常能耗侦探（Demo 场景 PRD） ​

1. 场景定义 ​

1.1 一句话 ​

1.2 用户与价值 ​

1.3 触发方式 ​

1.4 边界 ​

2. Demo 形态 ​

3. Agent 输出设计 ​

3.1 输出元素 ​

3.2 异常清单（主场景） ​

3.3 单设备深挖 ​

3.4 转工单 ​

3.5 异常与降级 ​

3.6 输出模板（开发参考） ​

4. MCP 设计 ​

4.1 异常查询 MCP ​

4.2 异常证据 MCP ​

4.3 工单 MCP ​

5. Skill 设计 ​

5.1 职责 ​

5.2 流程 ​

5.3 Skill 提示词草稿 ​

5.4 工具调用顺序与失败策略 ​

6. 定时任务配置 ​

7. 权限与数据范围 ​

8. 验收要点 ​

9. 已确认与待确认 ​

9.1 已确认 ​

9.2 待确认 ​

10. 关联文档 ​