NNight Comfort 方案评审 · v0.1

Sleep comfort automation

睡着之后,舒适继续工作。

面向卧室睡眠场景,以手表体征趋势、室内环境与用户反馈协同判断体感冷热,并通过中央控制器克制地调整空调。

一期对象单用户 · 单卧室 · 单空调
关键原则预测趋势,而非医疗判断
控制风格小幅、低扰动、可撤销
舒适COMFORT LOOP
手表趋势温度 · 心率 · 动作
房间环境温度 · 湿度
空调控制开机 · 温度 · 风速

“需要能感受到我热了,然后自动开启;给我的手表连接中央控制器。”

— 需求原话转译为:一个兼顾舒适、安全与可解释性的夜间闭环控制系统。

MVP boundary

先验证一个足够小的闭环。

一期不追求“精确读懂人体”,只验证:在用户授权的夜间时段,系统能否基于可靠信号做出少量、有效且不打扰睡眠的温度调整。

一期边界

一次睡眠,一个人的舒适感。

通过明确设备、房间和用户归属,先消除多人偏好冲突与全屋联动复杂度,再为后续扩展积累真实行为样本。

不做医疗诊断 不做多人协商 不做全屋联动
  1. 01
    睡前启用设置睡眠时段、舒适温区、自动开机授权与最低/最高保护温度。
  2. 02
    融合感知读取手表趋势、室内温湿度和用户“偏热 / 偏冷”主动反馈。
  3. 03
    受限控制执行开机、温度升降、模式与风速调整,并保留冷却时间与幅度上限。
  4. 04
    晨间校准用一次低打扰反馈修正个人偏好,不以单夜结果过度学习。

System architecture

一条本地优先的控制链路。

手表提供与人体相关的趋势信号;手机承担设备数据的安全中继;家庭中央控制器运行夜间规则并下发指令。网络失联不应让空调行为失控。

01 / SENSE

智能手表

睡眠或静息状态、皮肤温度相对变化、心率相对基线、动作与清醒频率。

趋势数据佩戴状态
02 / BRIDGE

手机 App

完成账号授权、手表数据同步、模式设置和用户反馈;作为手表与家庭设备间的中继。

授权反馈状态通知
03 / DECIDE & ACT

中央控制器

融合温湿度与睡眠信号,执行受限规则,并通过空调接口读取和下发设备状态。

本地规则降级策略执行回执
房间传感器 同步提供室温、湿度;建议安装在床侧活动区,避免仅以出风口温度作判断。关键取舍 一期以“趋势 + 环境”判断,不把任一生理指标作为单独触发条件。

Decision engine

先确认,再微调。

自动化的重点不是更激进,而是消除误动作。只有在正确时段、有效设备、连续信号和安全范围同时满足时,系统才可以改变环境。

01

时间与权限闸门

仅在用户设置的睡眠时段内工作;“允许自动开机”必须由用户主动开启。

  • 22:30–07:30 示例时段
  • 空调与房间已绑定
02

验证有效信号

确认用户佩戴手表并处于睡眠或静息状态,同时读取房间温湿度。

  • 手表连续同步
  • 传感器状态正常
03

计算偏热 / 偏冷趋势

根据相对基线判断体感变化,连续两个采样周期越界才进入执行候选。

  • 避免瞬时波动
  • 用户反馈权重更高
04

执行与复核

每次仅调节 0.5–1℃或风速;记录回执并在冷却时间内拒绝重复调节。

  • 保留用户手动优先
  • 失败时不伪报成功

舒适趋势 = 多源判断

皮温变化心率基线差动作 / 清醒温湿度主动反馈

计算目标是形成可解释的“偏热/偏冷趋势”,不输出健康结论;各信号的阈值需在试点中按个人基线校准。

Night journey

从入睡到醒来,只有必要时出现。

人不需要在夜里操作系统。系统的可见性应集中于睡前授权、夜间少量提示和晨间复盘,其他动作留在后台完成。

22:30

启用模式

用户确认舒适温区、房间和自动开机授权。

23:10

确认睡眠

手表与环境传感器进入夜间监测状态。

01:40

感知偏热

连续趋势与室温同时满足,进入受限调温。

01:45

微调复核

控制器下发指令、获得设备回执并开始冷却时间。

07:30

晨间校准

用一次“偏热 / 刚好 / 偏冷”反馈改善下一晚策略。

Device access

先接入最确定的控制能力。

不同空调形态决定实施成本和控制精度。项目启动前需确认目标设备品牌、控制接口,以及是否支持按卧室分区。

空调场景建议接入方式可控制范围一期建议
普通分体空调红外控制器开关、模式、设定温度、风速;通常无法确认真实运行状态。P0 成本低,适合快速验证。
智能空调厂商局域网或云端接口可读取更多状态、接收故障回执,控制可解释性更强。P0 优先选择已确认兼容的品牌。
中央空调 / 风机盘管原厂网关或楼宇控制接口按房间控制温度、模式和风量,需确认实际分区能力。P1 作为试点前置条件专项验证。

Review & alignment

两天后,需要拍板的不是算法。

先把设备、授权边界和试点条件确定下来。算法参数可通过小范围真实夜间数据迭代,但控制权限和设备能力必须在启动前明确。

Decision checklist

评审会议的五个决策

  1. 确认首期空调与控制协议目标是分体机、智能空调还是可分区中央空调?品牌及现有控制接口是什么?
  2. 确认支持的手表与数据路径手表是否经手机中继?可稳定取得哪些数据?哪些指标仅作辅助信号?
  3. 确认自动开机的默认授权默认关闭、由用户主动授权;还是在明确场景下预先开启?
  4. 确认一期允许的控制动作开关、温度、模式、风速、除湿、直吹规避中,哪些能安全且可靠地执行?
  5. 确认试点成功口径建议以控制成功率、夜间手动干预下降、晨间“刚好”反馈比例和误调次数作为首轮验证指标。