负载分类
冰箱、热水器和洗衣机都叫"家电"，为什么AI排程时却必须把它们当成三种完全不同的负载？
Inflexible LoadThermal Flexible LoadDeferrable Load
把所有家电放进同一个"能耗清单"里，是很多能源管理工具最容易犯的错误。冰箱、热水器和洗衣机确实都是家电，都会消耗电量，但它们对"时间"的容忍度天差地别，如果用同一套排程规则去处理，结果通常是要么牺牲舒适，要么根本无法真正省钱。
不可中断负载：冰箱
冰箱是典型的Inflexible Load。它需要持续运行以维持制冷温度，长时间断电会带来食品安全风险。即便某个时段电价极高，系统也不会让冰箱大幅度停机等待低价——它最多在功率允许范围内做非常保守的微调，绝大多数时候会被排除在错峰调度之外，始终维持稳定运行。
热惯性负载：热水器
热水器属于Thermal Flexible Load，它的特殊之处在于"热量可以被储存"。水一旦被加热，短时间内不会迅速冷却，这意味着加热动作和用水时间不需要严格对齐，系统可以把加热任务安排在电价更低的时段，只要在用户需要热水之前完成即可。这也是为什么热水器经常被作为家庭能源优化里最容易看到效果的设备，但前提是必须尊重用户设定的用水截止时间。
可延迟负载：洗衣机与烘干机
洗衣机、烘干机这类设备属于Deferrable Load，它们的运行任务本身没有强烈的时间偏好——用户通常不在意洗衣机具体几点启动，只在意衣物什么时候洗完。这类负载是排程系统里最灵活的部分，也是最容易造成"扎堆启动"问题的部分：如果多台可延迟设备都只看电价，很可能会挤在同一个时间点抢着启动，形成新的用电峰值。
百家乐家庭能源在设计AI家庭能源管理系统时，第一步永远是先给每台设备分类，再决定这台设备参与排程的方式和自由度——这比任何单一的省电算法都更基础，也更容易被忽略。
峰值与碳强度
电价最低的时候一定应该多用电吗？家庭能源AI为什么还要同时看峰值和电网碳强度
Peak ConstraintCarbon Intensity
"电价最低就该多用电"听起来是常识，但只把电价当成唯一变量，会漏掉至少两个同样重要的因素：家庭本身能承受的峰值功率，以及这段时间电网的碳强度。
峰值约束：便宜不代表可以同时开
如果洗衣机、烘干机、热水器和电动车充电全部集中在同一个低价时段启动，家庭总功率可能会瞬间冲高，轻则触发断路器跳闸，重则超出与电力公司约定的容量上限产生额外费用。百家乐家庭能源在生成排程时，会给整个家庭设置一个总功率上限，所有可延迟设备的启动时间都必须在这个上限内错开分布，而不是只看单台设备自己的电价曲线。
电网碳强度：低价不等于低碳
电网碳强度描述的是当前每单位电量对应的碳排放水平，这个数值会随发电结构实时变化——比如风电、光伏出力高的时段，碳强度通常更低，但电价不一定同步处于低谷；反过来，电价低谷有时恰好对应火电比例较高的时段。如果用户的优化目标里包含降低碳排放，系统就需要把碳强度作为独立的输入，与电价一起参与排程决策，而不是假设两者总是同步变化。
多目标而不是单目标
真正的家庭能源优化目标从来不是Cost Only，而是成本、舒适度、截止时间、峰值功率与碳强度的组合。这也是为什么百家乐家庭能源把这套系统称为多目标排程，而不是"最低电价查找器"——找到最低价格是最容易的一步，在多个约束同时成立的前提下找到可行解，才是真正的工作。
自然语言偏好
用户今天说"省钱优先"，明天说"舒服优先"，家庭能源系统怎样处理会变化的自然语言偏好？
Preference UnderstandingDynamic Constraint
用户的能源偏好从来不是一次设置就永远不变的参数。今天可能因为出差想尽量省钱，明天又因为家里有客人希望更舒适；夏天最在意空调的响应速度，冬天最在意热水的稳定性。如果系统只支持"设置一次、长期生效"的固定参数，很快就会跟不上真实生活的变化节奏。
大模型负责理解，不负责控制
这正是自然语言偏好理解发挥作用的地方：用户用日常语言表达当下的需求，比如"今晚尽量省电，但明天早上一定要有热水"，大模型的工作是把这句话拆解成结构化的约束条件——提高Cost Weight、将Water Heater Deadline设为06:30——而不是直接控制热水器的开关。真正执行排程运算的是优化器，负责实际动作的是控制器，语言模型只在最前端负责理解，这个分工在百家乐AI大模型的架构里同样是核心原则。
偏好变化不应该打乱既有排程
当用户更新偏好后，系统不会推倒重来，而是在下一次排程周期里重新计算约束权重，尽量保持对已经开始执行的任务的连续性。比如洗衣机已经进入运行周期，新的偏好通常只影响后续未开始的任务，而不会强行中断正在进行的动作。
这套机制也解释了为什么百家乐家庭能源反复强调语言模型和优化控制器是两个独立部分：语言表达是模糊和多变的，而设备执行需要稳定和可预测，把两者混在一起，要么让语言理解变得过度死板，要么让设备执行变得不可靠。
