SA 主动整备 PRD (Active Prep Strategy)

1. 业务愿景 (Business Vision)

“人未到，环境已就绪”。 通过监听会议日程，在会议开始前由 AI 自动完成会议室的环境调节（空调、新风、灯光），赋予物理空间“主动服务”的体感，显著降低用户进入房间后的不适感。

2. 核心逻辑：触发与过滤 (Triggers & Filtering)

主动整备执行层不直接与用户交互，而是由 Master Agent 在后台监听总线。

2. 空间整备数据模型 ($T_{prep}$ Model)

系统在执行计算前，需从多个异构系统提取并清洗数据。

2.1 空间物理属性取数逻辑

• 面积 (Area)：
  • 优先从“业务中台-物理空间维护”获取 floor_area。
  • 若为空，则进入 “人数推算逻辑”。
• 人数 (Capacity) 推算与清洗：
  • 来源：调用“会议预约系统”接口获取该会议的预定人数字段。
  • 清洗规则：
    • 若返回单一数字 (如 10)：直接使用。
    • 若返回区间 (如 10-20)：取平均值 (15)。
    • 若字段为空 / 无效：使用系统默认值（默认 8 人，对应 20㎡）。
  • 换算：推算面积 = Capacity * capacity_area_factor (默认系数 2.5)。

2.2 温感映射与采集 (Sensor Mapping)

• 回风温度采集原则：遵循“感知下沉”与“逻辑点位”原则。AI 平台直接读取由物理中枢加工后的空间级逻辑温度点位 $T_{curr}$。
• 获取路径：Master Agent 依据 biz_space_extra_attr 中的映射关系，直接提取对应逻辑实体的实时值，不再执行多传感器原始平均计算。

---

3. 智能预测算法 (Environment Prediction Logic)

3.1 预热/预冷策略 (Prep Policy)

系统采用“月度区间”配置，实现季节性逻辑自动切换。

开始月份	结束月份	激活状态	运行模式	$T_{target}$	${\lambda }_{env}$	Buffer	Service_Mode
11	2	ON	制热	22℃	6	10	AUTO
6	9	ON	制冷	24℃	5	5	AUTO
3	5	OFF	-	-	-	-	-

3.2 核心计算公式

$$T_{prep}=(|T_{curr}-T_{target}|\times {\lambda }_{env}\times \frac{Area}{20})+Buffer$$

---

4. 主动扫描与二级调度执行 (Workflow)

4.1 简易逻辑流程 (Flowchart)

---

5. 数据库逻辑模型 (Logical DB Model)

5.1 季/月整备策略表 (sys_prep_policy)

(同前，包含月度、参数、模式等字段)

5.2 全局算法参数表 (sys_global_parameter)

• DEFAULT_CAPACITY: 默认人数 (8)
• CAPACITY_AREA_FACTOR: 面积折算系数 (2.5)
• SCAN_WINDOW: 扫描窗口 (60min)

5.3 空间扩展属性表 (biz_space_extra_attr)

• space_id: PK
• floor_area: Float (实际面积)
• related_sensors: JSON/String (该空间关联的环境感知逻辑点位，通常指向物理层预处理后的虚拟温感实体)
• custom_lambda: Float (个别房间修正)

---

6. 与 Master Agent 协同：数字员工日报

主动整备的每一项动作必须计入 Action Log，并在次日的 《数字员工日报》 中汇总展示，量化 AI 的“隐形贡献”。

6.1 日报核心指标 (Daily Metrics)

• 整备成功率：指令成功下发次数 / 预期整备次数。
• 能效贡献度：通过感知会议取消并及时关停设备节省的预估电量（kWh）。
• 用户认可度：纠偏按钮（Cancel）的点击率。点击率越低，说明系统判断越精准。

---

7. 待对位与深调项 (Phase 5 Refinement)

7.1 默认目标温度配置逻辑 ($T_{goal}$)

• 问题：目前仅定义了算法计算时刻，未显式定义整备至“多少度”。
• 对位建议：在 sys_prep_policy 策略表中新增 T_goal 字段。例如：冬季制热整备目标设为 22℃，夏季制冷设为 24℃。
• 约束：$T_{goal}$ 必须受到该空间关联设备组的 “交集区间 (Intersection Range)” 物理约束，严禁设定出量程值。

7.2 深度调节卡片全属性设计 (Interactive Card)

• 现状：现有 index.html 原型仅包含温度滑块（且为底端抽屉模式）。
• 重塑需求：
  • 模式切换：需支持“制冷/制热/自动/送风”语义切换。
  • 风速调整：支持“自动/低/中/高”四档。
  • 多维控制：探索在同一卡片内集成 “灯光开关”。
  • 场景模型 (Scene Mode)：设计一键触发 “会议模式” 或 “投影模式” 的快捷入口，通过组合 API 实现环境一键就绪。
• 数据结构：需定义一套可扩展的 Card_Attributes Schema，解决目前 UI 侧 Hard Code 导致的功能僵化问题。

7.3 空间物模型与配置化展示 (Space AI Object Model)

• 核心痛点：不同项目、不同会议室的硬件设施（如：是否有新风、是否有智能遮阳帘、是否支持投影模式）差异巨大。目前硬编码（Hard Code）方式无法支撑产品化交付。
• 演进方向：
  • 定义 “AI 房间空间物模型”。在系统初始化或房间领用时，自动从物联底座拉取该空间的 Capabilities 集合。
  • 动态卡片生成：深度调节卡片应基于该物模型动态渲染。例如：无智能灯光的房间不显示灯光开关；支持投影模式的房间自动下发“场景模型”入口。
  • 逻辑解耦：Agent 侧输出语义意图，由 UI 渲染层结合房间物模型（Space Model）生成最终的控制表单。