主题
00 上海交通大学 IBMS 项目 · AI 板块方案总览
对应需求：
IBMS功能模块-V1.md中与 AI 相关的 10 类需求，以及作为 AI 动作工具的 5 类非 AI 需求。 方案依据：
- 客户需求与备注：
IBMS功能模块-AI板块相关需求.md- 我方产品实测：
50_规划/AI公司规划202610/ReAct智能体/（NIMBUS 智慧数字运维平台，57 个业务工具） 项目背景：上海交通大学新院区，以 MBA 教学为主。 用途：内部方案设计与售前对齐，不直接对外。 组织方式：三条主线 + 一个入口。所有需求项按「怎么做」展开，不做可行性分级。
1. 需求全景
| # | 需求项 | 归属主线 | 方案定位 |
|---|---|---|---|
| 1 | AI 能效顾问 | 能源 | 能源智能体的问答与分析入口 |
| 2 | AI 能效优化与双碳智能分析 | 能源 | 规则诊断解释 + 碳核算 + 双碳报告（暂不承诺优化策略生成） |
| 3 | 用能画像分析 | 能源 | 空间/系统/时段的用能画像 |
| 4 | 异常能耗侦探 | 能源 | 规则 + 统计 + LLM 解释的异常发现 |
| 5 | 人流密度分析 | 空间 | 实时人数、密度分级、客流趋势、超容/突增提示 |
| 6 | 空间洞察 | 空间 | 空间画像、利用率、单位面积指标、优化建议 |
| 7 | AI 智能交互与服务助手 | 入口 | 移动端统一自然语言入口 |
| 8 | 设施设备预测性维护 | 运维 | L1/L2 自建（健康度、异常检测），L3/L4 由 OEM/伙伴；不承诺准确率 |
| 9 | AI 智能巡检 | 运维 | 规则/视觉/人工三类；视觉异常由多模态大模型判定；结果进巡检工单 + 明细 |
| 10 | 巡检任务完成情况统计 | 运维 | 按规则/视觉/人工分别统计；报表 + 智能体问答 |
| — | 空间预约 / 课程 / 充电 / 访客 / 信息引导 | 入口 | 作为 AI 的「动作工具」被调用 |
2. 三条主线 + 一个入口
主线一：能源
把「用能数据 → 画像 → 异常 → 建议 → 双碳」做成一条链：
- 用能画像：按空间/系统/时段拆分能耗，关联课表、人数、天气，回答「谁、什么时候、用在哪」。
- 异常能耗侦探：夜间高耗、空置用电、该停没停、频繁启停、同比突变，规则全量筛查 + LLM 归纳解释。
- AI 能效顾问：自然语言查能耗、问原因、看规则诊断解释，背后调能耗工具 + 知识库；不生成优化策略、不通过对话下发控制。
- 双碳分析：碳核算、碳足迹、目标管理、碳排趋势。
- 数据归属：表计/能源系统本体由总包或厂商提供，数据经我们的 IoT 平台接入、汇聚、治理——我们本身就是接第三方 IoT 设备的平台，能源数据层不外包。
详见 01_能源类AI能力-现状与自有发挥.md。
主线二：空间
把「位置 → 空间 → 人 → 行为 → 成本」打通：
- 人流密度：实时人数、密度分级、超容预警、突增提示、客流趋势；人数看闸机 + 摄像头，未来看预约/课表，不用 WiFi 探针、不用 CO₂ 反推人数。
- 空间洞察：使用率、闲置率、单位面积利用率/能耗/工单、优化建议；不做坪效与全成本分摊——教学空间不以租金收益为目标，成本数据多数拿不到，摊到面积上也不可比。
- 核心前提：
location_id必须映射到空间主数据；否则只是没有含义的数字。 - 联动：无人关停、超容新风、通道分流、食堂错峰、信息发布引导。
详见 02_人流密度与空间洞察.md。
主线三：运维
把「巡检 → 诊断 → 工单 → 统计 → 健康度」做成闭环：
- AI 智能巡检：分规则 / 视觉 / 人工三类——视觉巡检为主，摄像头定时抓拍，巡检说明作为 prompt（含判定标准和输出格式）交给多模态大模型判定；规则巡检做物属性周期比对，人工巡检做现场补充。结果落到巡检工单 + 巡检明细，巡检报告做成定时日报。
- 预测性维护：L1/L2 自建（健康度评估、异常检测与趋势预警），L3/L4 由 OEM/伙伴提供故障诊断与剩余寿命；以可解释的风险清单交付，不承诺准确率。
- 巡检统计：基于已有巡检工单，按规则 / 视觉 / 人工分别统计，补计划维度、指标体系、报表与智能体问答。
详见 03_设备预测性维护-技术路径与项目方案.md、04_AI智能巡检-视觉巡检与日报.md、05_巡检任务完成情况统计.md。
入口：移动端 AI 助手
一个统一入口，把三条主线的能力送到教师、MBA 学生、运维、管理者手边，并承载访客/企业嘉宾、校友的通行与接待：
- 主动：课前简报、设备异常、预约临近、人流高峰。
- 一句话办事：查课表、订房间、报修、控设备、访客登记。
- 跨系统编排：一次对话串起课表、门禁、设备、工单、能耗。
- 有兜底：办不成给替代方案、转人工、留痕。
详见 08_移动端AI场景设计.md。Demo 范围 = 08 §10 模块表中用反引号标记的模块（当前 30 个）。
3. 三条主线 × 四类角色：智能体到底能干什么
这是本方案最需要讲清楚的部分。系统只有一个统一入口，登录后按角色与权限装配不同的能力包和工具；下面按四类角色展开，访客/校友作为外部角色单列。
| 角色 | 典型诉求 | 入口能力 |
|---|---|---|
| 教师 | 上课别出岔子、环境合适、少跑行政流程 | 课表、教室控制、智能整备、访客接待、课程报告 |
| MBA 学生 | 时间紧、别迟到、找空间/吃饭/停车/充电/活动 | 课表、空间预约、报修/投诉、活动、充电/车位、碳账户 |
| 运维人员 | 少盯屏幕、风险先浮出来、工单闭环 | 巡检、诊断、工单、健康度、告警 |
| 管理者 | 看清运营、拿到数据、做决策 | 统计、报告、空间洞察、人流密度、用能画像、异常诊断、双碳、AI 能效顾问 |
| 访客 / 企业嘉宾 / 校友（外部） | 能进来、找得到、有人接 | 访客申请、通行凭证、导航、活动/返校接待 |
下面按「角色 × 时刻 × 一句话 × agent 动作」展开。
3.1 能源主线：角色能感知到什么
| 角色 | 时刻 | 一句话 | Agent 做什么 |
|---|---|---|---|
| 教师 | 课前 | 「今天 302 教室环境怎么样？空调开了吗？」 | 查教室环境 + 设备状态 + 课前联动记录 |
| 教师 | 课中 | 「把空调调到 24 度，下课前 10 分钟关掉。」 | 教室中控控设备 + 定时任务（能源系统/冷机不通过对话控制） |
| 教师 | 课后 | 「我这门课这学期用了多少电？」 | 用能画像（课程维度）+ 对比 + 解读 |
| 教师 | 异常 | 「为什么上周六 3 楼还在耗电？」 | 异常能耗侦探 + 关联课表/人流 + 原因归纳 |
| MBA 学生 | 日常 | 「我这学期绿色出行/节能攒了多少积分？」 | 个人碳账户 + 排行榜 + 兑换（依赖绿色节能管理应用，积分规则待甲方定义） |
| MBA 学生 | 预约 | 「我预约的讨论室能提前 10 分钟开空调吗？」 | 预约信息 + 环境联动（按既有策略执行） |
| 管理者 | 月度 | 「出一份 10 月能源月报和碳排报告。」 | 指标汇总 + 报告生成 + 建议 |
这条线对用户的价值：教师少操心环境、能看到自己课程的用能；学生有参与感（碳积分）；管理者有决策依据。
3.2 空间主线：角色能感知到什么
| 角色 | 时刻 | 一句话 | Agent 做什么 |
|---|---|---|---|
| 教师 | 课前 | 「下午 2 点找个能坐 30 人、能投屏的讨论室。」 | 条件检索 + 推荐 + 预订 + 设备联动 |
| 教师 | 课中 | 「教室现在多少人？空气怎么样？」 | 人流 + 环境 + 建议 + 联动新风 |
| 教师 | 到校 | 「从 B2 停车场到 501 怎么走？」 | POI 路线（起终点明确，不依赖当前定位） |
| 教师 | 到校 | 「我现在去 501 怎么走？」 | 需当前定位：小程序地图页授权/蓝牙定位，或让用户选起点 |
| MBA 学生 | 通勤（校外） | 「今天课在哪？周六这个点 B2 通常还有车位吗？」 | 课表 + 历史车位 + 建议到校时间 |
| MBA 学生 | 到校后（校内） | 「从大堂到 501 怎么走？」 | 室内导航 + 步行时间 |
| MBA 学生 | 课间 | 「现在哪个自习位/交流区有空位？」 | 空间占用 + 推荐 |
| MBA 学生 | 课间 | 「想找个安静的地方打 20 分钟电话。」 | 位置感知 + 空闲小房间 + 短时预约 |
| MBA 学生 | 午餐 | 「食堂现在人多吗？」 | 食堂级人数 + 错峰建议（窗口级数据待定） |
| 管理者 | 月度 | 「哪些空间利用率低、该调整？」 | 空间画像 + 排名 + 优化建议 |
导航的两种输入：起终点都明确时（「从 B2 到 501」），地图服务直接算路线，不需要定位权限；只说「去 501」时，必须先知道「我在哪」——这需要小程序地图板块的蓝牙/定位授权，或让用户手动选起点。Chatbox 本身不强行申请蓝牙权限，默认走「选起点」或「跳转地图页」两条兜底路径。
这条线对用户的价值：把「找空间、找路、找空位、看人流」从多个 App/问人，变成一句话。
3.3 运维主线：角色能感知到什么
| 角色 | 时刻 | 一句话 | Agent 做什么 |
|---|---|---|---|
| 教师 | 课前 | 「302 投影仪好像坏了。」（拍照） | 识别设备/位置 + 建报修工单 + 进度 |
| 教师 | 课前 | （系统主动）「302 已智能整备；整备失败项已通知运维。」 | 智能整备 + 失败通知运维 |
| 教师 | 课中 | 「教室有点闷。」 | 环境数据 + 新风联动 + 工单（若设备异常） |
| MBA 学生 | 任何时 | 「3 楼饮水机坏了。」（拍照） | 建单 + 进度查询 + 完成通知 |
| MBA 学生 | 课后 | 「我上周报的修好了吗？」 | 工单状态 + 预计完成时间 |
| 运维 | 每日 | 「昨天巡检发现了什么？」 | 巡检报告 + 异常清单 + 转工单 |
| 运维 | 随时 | 「3 楼哪台设备最该关注？」 | 健康度排名 + 风险原因 + 历史工单 |
| 管理者 | 月度 | 「这个月巡检完成率多少？规则/视觉/人工分别怎么样？」 | 巡检统计 + 分类报表 + 改进建议 |
智能整备替代原「课前预检 + 一键换教室」：按课表自动开启灯光/空调/投影/幕布；整备失败只通知运维，不推给教师做换教室决策。
访客登记最小字段：姓名、手机号、车牌（如有）、到访地点/受访人、到访时间、事由、人数。
这条线对用户的价值：报修从「打电话、填单、催进度」变成「拍张照、一句话、等通知」；对运维，从「盯屏幕、翻记录」变成「看风险清单」。
3.4 一张图看清「谁在什么时刻用什么」
| 时刻 | 教师 | MBA 学生 | 运维 | 管理者 | 外部角色 |
|---|---|---|---|---|---|
| 到校前 | 课程/教室/智能整备简报 | 课程/历史车位/讲座 | 夜间异常/巡检报告 | 昨日运营指标/待办 | 访客/返校预约确认 |
| 课前 | 智能整备、环境准备 | 找教室、找座位 | 巡检异常处置 | 空间/能耗晨会数据 | 通行凭证、导航 |
| 课中 | 控环境、看人数/空气 | 课间找空房间、食堂 | 告警响应 | — | — |
| 课后 | 报修、课程报告 | 报修、活动报名、碳积分 | 工单闭环、健康度 | — | 离场权限回收 |
| 周期性 | 学期用能/教室报告 | 学习/活动/碳账户总结 | 巡检统计、月报 | 月报/学期报告 | 接待记录 |
一句话：三条主线不是三个后台系统，而是同一个智能体在三种场景下的能力——教师和 MBA 学生感知到的是「一句话把事办了」，运维感知到的是「风险自己浮出来」，管理者感知到的是「结论和报告」，访客/校友感知到的是「进得来、找得到」。
4. 方案架构：一个入口 + 一个 ReAct 智能体 + 三层执行
┌──────────────────────────────────────────────────────────────┐
│ B 端小程序（统一入口） │
│ 对话/语音 · 卡片/推送 · 地图板块（定位/导航） · 登录态/权限 │
└───────────────────────────┬──────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────┐
│ ReAct 通用智能体（任务理解与编排） │
│ · 理解意图 → 规划 → 调 Skill/Tool → 观察 → 继续/收敛 │
│ · 多轮对话 · 上下文记忆 · 主动触发 · 报告生成 │
└───────────────────────────┬──────────────────────────────────┘
▼
┌──────────────────────────────────────────┐
│ 权限装配（横切策略，不是一层工具） │
│ 角色 → 可用 Skill/Tool │
│ 数据范围 → 本人/本课程/本区域/全院 │
│ 操作级别 → 只读/建议/执行 │
└──────────────────┬───────────────────────┘
▼
┌──────────────────────────────────────────────────────────────┐
│ 执行层 │
│ ├─ Skill（固定流程，多步） │
│ │ 报修 / 预订 / 巡检计划 / 报告生成 / 访客接待 │
│ └─ MCP Tool（原子动作，单步） │
│ 业务：工单 / 设备 / 告警 / 指标 / 能耗 / 预约 / 物资 / │
│ 资产 / 通行 / 审批 │
│ 分析：巡检 / 健康度 / 画像 / 报告 │
│ 实体解析：人员 / 空间 / 设备 / 工单号 │
│ 外部：地图 / 导航 / 天气 / 消息推送（本期不做） │
└───────────────────────────┬──────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────┐
│ 数据层：IoT 接入 · 时空数据 · 主数据 · 指标 · 知识库 │
└───────────────────────────┬──────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────┐
│ 集成层：教务 / OA / 人事 / 访客 / 停车 / BA / 照明 / 信息发布 / 地图 │
└──────────────────────────────────────────────────────────────┘先回答一个容易混淆的点：这里的「能力」和「工具」不是两层重复的东西。
| 层 | 回答什么问题 | 是什么 | 不是什么 |
|---|---|---|---|
| 权限装配 | 这个角色能用什么 | 横切策略：角色 → 可用 Skill/Tool、数据范围、操作级别 | 不是一套独立的工具实现，不重复造能力 |
| Skill | 一件事按固定步骤怎么做 | 多步业务流程模板：报修、预订、巡检计划、报告生成 | 不是原子接口，不直接读写数据库 |
| MCP Tool | 一个动作怎么执行 | 原子接口：查设备、建工单、查会议室、控设备、实体解析、地图 | 不是业务流程，不负责多步编排 |
调用链示例：
学生说「订个 30 人讨论室」 → 权限装配确认「学生可用空间预约」 → ReAct 选「空间预约 Skill」 → Skill 依次调 MCP Tool：实体解析 → 查可用时段 → 查会议室 → 预定会议室 → 设备联动 → 返回预约卡片。
教师说「把 302 灯光调暗」 → 权限装配确认「本人教室可执行」 → ReAct 直接调「设备控制 Tool」（单步，不需要 Skill）。
关键说明：
- 不是四个智能体，而是一个 ReAct 智能体。 四个角色通过权限装配看到不同的 Skill/Tool 集合；用户看到的是同一个助手，背后可用能力不同。
- ReAct 负责开放式任务（跨系统、多步、需要判断），固定流程用 Skill 封装（报修、预订、巡检计划）。两者不是替代关系：ReAct 做「不确定路径」的编排，Skill 做「确定路径」的可靠执行。既有的 workflow 能力（如固定报表、审批流）作为 Skill 被 ReAct 按需调用，不直接暴露多个 workflow 入口。
- 权限三层：角色（学生/教师/运维/管理者）× 数据范围（本人/本课程/本区域/全院）× 操作级别（只读/建议/执行）。写操作默认「建议 + 确认」。
- 地图与定位：路线规划由地图 MCP/服务完成；「我在哪」由小程序地图板块授权获取（蓝牙/定位）。Chatbox 不强行申请权限，默认「选起点」或「跳转地图页」。若希望 Chatbox 内直接定位，需要在 Chatbox 页面申请定位/蓝牙权限并补隐私声明，属可控开发，但不建议把聊天入口做成「必须先授权」。
- 选型说明：通用智能体的具体技术选型由技术团队确定，本文只描述能力分层、权限装配和场景边界。
角色-能力装配表：
| 角色 | 可用 Skill（多步流程） | 可调用 Tool（原子动作，示例） | 数据范围 | 操作级别 |
|---|---|---|---|---|
| 教师 | 课表查询、教室控制、智能整备、访客接待、课程报告 | 查课表、控设备、查设备、建访客、生成报告 | 本人课程 + 所用教室 | 执行（本人教室） |
| MBA 学生 | 课表查询、空间预约、报修、活动报名 | 查课表、查可用时段、查会议室、建工单、查工单 | 本人 | 只读 + 预约 + 报修 |
| 运维人员 | 巡检执行、故障诊断、告警处置、异常流转、健康度分析 | 查设备、查告警、建工单、查巡检、查健康度 | 负责区域 | 建单、处置、转办（不替工单系统派单） |
| 管理者 | 运营统计、报告生成、空间洞察、能源分析 | 查指标、查能耗、查报表、查空间画像 | 授权范围 | 只读 + 报告导出 |
一句话：权限装配决定「你能看到什么」，Skill 决定「一件事按什么步骤做」，MCP Tool 决定「一个动作怎么执行」。三者是策略 / 流程 / 接口的关系，不是三层重复的工具。
4.1 全局交互形态（所有模块通用）
所有 ReAct 能力统一 channel 到移动端 Chatbox，回复由三种元素组成：
| 元素 | 用途 | 例子 |
|---|---|---|
| Markdown 文字 | 结论、数据、建议、口径说明 | 「3 楼当前 186 人，接近峰值」 |
| Mermaid 图表 | 趋势、分布、占比、流程 | 柱状图 / 折线图 / 饼图 |
| 快捷选项 / 跳转链接 | 确认选项或跳到小程序其他页面继续操作 | 「查看空间看板」「打开预约页」「查看完整报告」 |
不假设前端能渲染自定义业务卡片；默认用文字 + 编号选项 + 跳转链接，选型支持按钮/选项时再用按钮。模块文档只写业务口径和场景，不再重复交互形态。
5. 关键设计决策
- 统一入口、按权限装配：一个 B 端小程序 + 一个 ReAct 智能体；角色决定能力包与工具，数据范围决定能看什么，操作级别决定能做什么。
- ReAct 与 workflow/skill 分工：开放式任务交给 ReAct（跨系统、多步、需判断），固定流程封装为 skill（报修、预订、巡检计划），保证可靠与可审计。
- 空间主数据先行：人流、空间洞察、教室导航、巡检范围都依赖「空间编码 + 点位映射」，这是所有空间类能力的地基。
- 巡检分规则 / 视觉 / 人工三类，视觉为主：视觉巡检用摄像头覆盖 IoT 覆盖不到的物理状态（水/门/灯/布局/清洁/表计/故障码）并做 IoT double-check，异常由多模态大模型判定；巡检说明直接作为 prompt（含判定标准和输出格式）；规则巡检不重复告警阈值；人工巡检兜底。结果进巡检工单 + 明细，巡检报告做成定时日报，异常后工单流转由工单产品经理定义。
- 预测性维护分层交付：L1/L2（健康度、异常检测、趋势预警）自建，L3/L4（故障诊断、剩余寿命）由 OEM/伙伴提供；以可解释的风险清单、健康趋势、巡检/工单闭环为主，不承诺准确率，随数据积累再增强。
- 移动端以「主动」为分水岭：没有主动服务，就只是聊天框；有了主动，才像助理。
- 导航分两级：起终点明确时走地图 MCP，不依赖定位；需要「我在哪」时，跳转小程序地图页授权或让用户选起点，Chatbox 不强行申请蓝牙权限。
- 写操作要确认：预约、报修、控制、授权执行前确认；高风险操作（消防/门禁）走专门流程。
- 口径统一：完成率、异常率、误报率等指标先定口径再开发；巡检按规则/视觉/人工分别统计；空值与 0 严格区分。
- 可观测：每次对话、每次工具调用、每次诊断都可追踪，便于调优和验收。
- 人数口径：人数看闸机 + 摄像头，未来看预约/课表；不用 WiFi 探针、不用 CO₂ 反推人数。
- 边界清晰：Agent 不替工单系统派单；访客登记取最小字段；智能整备失败只通知运维。
6. 前置条件与风险
| 事项 | 前置条件 | 风险 | 应对 |
|---|---|---|---|
| 人流密度 | 数据源 + point_id ↔ 空间 映射 + 面积/容量 | 映射缺失导致数据不可用 | 集成阶段要求映射表；未映射进「待配置」 |
| 空间洞察 | 能耗、工单、资产、预约/门禁数据 | 多源口径不一致 | 统一空间编码与指标口径 |
| 能源画像 | 分项计量、15 分钟~1 小时粒度、至少 1 年历史 | 分项不全 | 先做数据质量核查，再定分析范围 |
| 预测性维护 | 设备台账、告警、工单、保养、备件数据；L3/L4 需 OEM/伙伴接口 | 新楼历史数据少；OEM 可能不开放 | L1/L2 先做健康度与异常检测；L3/L4 在合同前置约定 OEM/伙伴 |
| AI 巡检 | 巡检工单/巡检点/巡检标准、设备 IoT、相机视角/ROI | 规则与告警重复；相机视角不稳 | 明确规则/视觉/人工边界；抓拍前做图像质量检查；结果落巡检工单 + 明细 |
| 移动端控制 | 教室可控点位 | 现网可控点位不足 | 本项目补齐教室设备控制点位 |
| 智能整备 | 课表、设备/中控、场景模板 | 设备未接入、整备失败 | 失败只通知运维，不自动换教室；无设备标「未接入」 |
| 访客/课程/活动 | 相关业务系统 | 系统空白导致场景断链 | 明确新建/集成/合作方；访客登记取最小字段 |
| 课程资料/食堂/欢迎屏/访客停车 | 课程资料系统、食堂系统、信息发布屏、停车规则 | 系统或规则未定 | 课程资料先做 L1 知识问答；食堂只到食堂级；欢迎屏/访客停车待甲方定义 |
| 绿色节能积分 | 绿色节能管理应用 + 积分规则 | 应用未建设，规则未定义 | 场景先保留，待应用与规则明确 |
| 室内导航 | 室内地图与 POI | 自建成本高 | 接第三方地图，我方做 POI 对齐与对话入口 |
| 地图定位 | 小程序地图板块 + 蓝牙/定位授权 | Chatbox 无法直接获取当前定位 | 起终点明确走地图 MCP；当前定位跳转地图页或让用户选起点 |
| 历史车位 | 停车系统历史占用数据 | 无历史数据只能给实时余位 | 历史车位用于「建议到校时间」；无数据则不推 |
| 智能体权限 | 角色/数据范围/操作级别矩阵 | 权限不清导致越权或能力不可用 | 先定 RBAC + 数据权限矩阵 |
7. 待澄清清单（建议售前会逐条确认）
- 「AI 能力引擎」的交付形态：是平台产品（模型训练/管理/评测），还是场景集合？两者方案不同。
- 预测性维护的验收形态：健康度大屏、风险清单、趋势报告，还是其他？是否需要设定量化指标？
- 人流数据源与位置映射：闸机/摄像头各覆盖哪些区域？能否提供
location_id ↔ 空间映射？是否明确不使用 WiFi 探针、不用 CO₂ 反推人数？ - 能源数据接入范围：我们平台接入哪些表计、网关、子系统？分项、粒度、历史长度如何？
- 巡检边界与视觉条件：哪些物属性项已有告警规则（避免重复）？哪些点位有可用的相机视角/预置位/ROI？异常后工单流转由谁定义？
- 巡检统计口径：完成、按时、漏检、异常如何定义？规则/视觉/人工是否分别统计？统计给谁看、什么频率？
- 教室可控点位：本项目能否补齐？移动端控制场景依赖它。
- 访客/校友/课程/活动/教学资源系统：是否已有？谁建设？我方是集成还是共建？
- 地图与定位授权：小程序地图板块的蓝牙/定位授权能否复用？Chatbox 是否允许直接申请？POI 谁提供？
- 「课程实时引导」的验收场景：移动端导航、门口引导屏、还是教室联动？
- 绿色节能管理应用：是否建设？积分规则、数据来源、与哪些系统联动？
- 历史车位数据：停车系统能否提供历史占用曲线（按星期/时段）？用于「建议到校时间」；没有就只给实时余位或不推。
- 角色与权限矩阵：学生/教师/运维/管理者的数据范围和写权限由谁定义？
- 课程资料下载：是否有课程资料系统？移动端只做「在哪下载」的 L1 问答，还是需要集成？
- 食堂数据：是否有食堂系统/窗口级排队数据？若无，是否只做到食堂级人数或不作承诺？
- 欢迎屏与访客/校友停车：欢迎屏联动方式、访客停车入口/楼层/规则由谁定义？
8. 文档索引
| 文档 | 内容 |
|---|---|
01_能源类AI能力-现状与自有发挥.md | 用能画像、异常能耗侦探、能效顾问、双碳；现有能力与曙光协作 |
02_人流密度与空间洞察.md | 数据源、位置 ID 语义、空间主数据模型、产品形态、师生视角 |
03_设备预测性维护-技术路径与项目方案.md | 技术路径、L1–L4 分层、L1/L2 自建方案、L3/L4 外部协作、标准依据 |
04_AI智能巡检-视觉巡检与日报.md | 视觉巡检为主、场景清单、提示词判定、巡检日报、异常工单流转 |
05_巡检任务完成情况统计.md | 指标口径、图表设计、报告模板、智能体工具 |
06_校友预约vs会议预定.md | 差异分析、业务链条、建设方式建议 |
07_课程系统-课表同步与实时引导.md | 课表同步、三层引导、导航边界 |
08_移动端AI场景设计.md | 教师/MBA 学生/运维/管理者四类角色 + 访客/校友的一天、42 个模块（30 个 demo）、模块交互方式（主动推送/被动问答/定时执行/事件触发）、跨系统与兜底 |
prd/T1-到校前简报.md | T1 到校前简报场景 PRD |
prd/M3-用能画像.md、prd/M4-异常能耗侦探.md、prd/M5-双碳与能源月报.md、prd/M6-AI能效顾问.md | 管理者能源四个 demo 场景 PRD |
prd/M7-空间洞察.md、prd/M8-人流密度.md、prd/M10-月度报告.md | 管理者空间洞察、人流密度、月度报告场景 PRD（均为 demo） |
prd/M9-服务质量.md | 服务质量场景 PRD（非 demo，储备） |
prd/M11-学期报告.md | 管理者学期报告（非 demo）；待写 |
prd/S10-报修投诉建议.md、prd/S2-充电车位查询.md | 学生报修/投诉/建议、充电/车位查询（S2 demo）；待写 |
prd/公共规范.md | Demo 前端形态、常驻会话、智能体边界、定时任务、输出规范、场景 PRD 模板 |
Demo 范围 = 08 §10 模块表中用反引号标记的模块，当前 30 个：
T1–T6、T8、T9、S1–S5、S7、S8、S10、O1、O2、O6、O8、M1–M8、M10、E2；未标记的暂不展开详细设计。
9. 一句话总结
这个项目的 AI 板块，不是「上几个算法模型」，而是一个统一的 B 端入口 + 一个 ReAct 智能体，按角色装配能力包，把能源、空间、运维三条主线的数据和工具，变成教师、MBA 学生、运维、管理者，以及访客/校友每天都能用上的一句话服务。方案的重点在数据治理、权限装配、场景编排和闭环设计，而不是模型本身。