メニュー
home-dreaming 定时任务的 Observe 步骤，仅由该任务调用。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | miloco-home-observe |
| description | home-dreaming 定时任务的 Observe 步骤，仅由该任务调用。 |
| metadata | {"author":"miloco","version":"2.3","date":"2026-07-02T00:00:00.000Z","openclaw":{"requires":{"bins":["miloco-cli"]}}} |
从感知记忆和交互记忆中提取值得沉淀的家庭知识（成员的习惯、偏好、健康、画像，以及家居环境），累积到家庭档案。
仅在 miloco-home-dreaming cron 流程中激活，不单独使用。
读到一条观察后，按这条决策链处理：① 值不值得记 → ② 归哪一类 → ③ 和已有知识什么关系 → 落命令。下面依次展开。
⚠️ 两条绝对红线，违反即错误，优先级高于一切效率考量：
- 禁止重复创建同一条目：同一条结论全程只能存在一个候选。写入前必须先
list，语义相同的走 merge；即使在同一次--ops批次内，也绝不允许为同一条结论生成多个add（这是最常见的重复来源）。- 禁止编造 / 脑补人物身份：人物身份只能照搬记忆里明确写出的。记忆说"陌生人 / 未识别 / 访客 / 某个人"，就绝不能改写成"主人 / 爸爸 / 妈妈"等任何具名成员。存疑宁可不记，也不许猜。
memory/YYYY-MM-DD-miloco-perception.mdmemory/YYYY-MM-DD.mdmiloco-cli home-profile list --target both 查看已有知识（写入前的强制前置步骤，不 list 不写）evidence_log（完整证据列表）判断与已有条目的关系list 结果、以及彼此之间两两比对，语义相同的合并为一个操作，确保同一条结论只对应一个 add 或 merge（详见 ③）miloco-cli home-profile candidate-write 或 miloco-cli home-profile profile-write 操作注意：步骤 1、2 中的记忆文件在当天没有相关记录时不会生成。读取失败（文件不存在）时直接跳过该文件，继续处理剩余可用的记忆源。不要重复尝试读取同一个不存在的文件。只要至少有一个记忆源有内容即可继续后续步骤；若所有文件均不存在，则本次 Observe 无输入可处理，直接结束。
家庭档案只有一个用途：让 agent 借它读懂每个成员的生活习惯，从而把控设备、调环境、提醒关怀做得更精准、更合各人心意。所有提取都服务于此，唯一标尺是——
核心判断：知道这条，未来能让某次「控设备 / 调环境 / 提醒关怀」更准、更贴某个具体成员的心意吗？ 能 → 记；只是"识别到了"却不会改变任何未来动作 → 丢。
感知识别结果天然嘈杂，大多数没有沉淀价值，宁缺毋滥——记一条无用信息，未来只会干扰判断。
值得记（每类都能落到具体行为上）：
| 信息 | 未来用它做什么 | 例子 |
|---|---|---|
| 偏好 | 调环境到成员舒适态 | 爸爸喜欢 24°C 制冷、奶奶要暖光 |
| 作息 / 习惯 | 把提醒、自动化卡在对的时机 | 工作日 7:30 出门、每晚 9 点吃药 |
| 健康 / 禁忌 | 关怀与安全的硬约束 | 花粉过敏、高血压、行动不便 |
| 画像 / 构成 | 弄清"家里有谁、谁要被照顾" | 谁是主厨、有个小孩豆豆、养了狗旺财 |
| 空间 / 设备 | 让控制落到对的设备、给对的预期 | 主卧出风口对床头、客厅空调达温慢 |
不值得记（记了也用不上，直接丢）：
置信度怎么给（已判定值得记的，按性质决定单次能否入候选——候选区是"证据累积区"，低置信不等于丢弃）：
type 分类：
| type | 含义 | 示例 |
|---|---|---|
| member_persona | 成员画像（家庭角色、身份、外貌） | "爸爸是家里的主厨" |
| member_health | 体质健康（过敏、禁忌、慢性病） | "妈妈对花粉过敏" |
| member_routine | 日常习惯（作息、出行规律） | "爸爸通常 7:30 出门上班" |
| member_entertain | 娱乐习惯（观影、游戏、音乐） | "妈妈睡前听白噪音" |
| member_preference | 个人偏好（温度、光线、饮食） | "爸爸喜欢 24°C 制冷" |
| family | 全家共同遵守的规则/约定（仅规则，非家庭构成信息） | "22:00 后全屋静音"、"访客来访自动开走廊灯" |
| space | 空间环境（户型、朝向、动线） | "主卧空调出风口对床头" |
| device | 设备经验（设备使用经验） | "客厅空调制冷需 5 分钟达温" |
subject 命名规则：
subject_id 优先绑定身份库 person_id（从 miloco-cli identity member list 查得，保证映射唯一）；无法确定 person_id 时退回 subject_name = 成员名（如"爸爸"）。多成员共同适用时 subject_name = "shared"，subject_id 留空。subject_name 固定为 "shared"（家庭规则天然多主体）。subject_name = 空间名或设备名（如"主卧"、"小米空调"），通用信息 subject_name = "general"。身份判定红线（严禁编造，最高优先级）：
subject 的人物身份只能照搬记忆里明确写出的——记忆说是谁就是谁，记忆没说就是没说，不允许任何形式的推测、脑补、"合理推断"。
member_persona、以未识别人物为主体如实记录（subject_name="未识别"，不要臆断成"访客"等具体身份，未必是访客；subject_id 留空），绝不冒名任何成员。宠物与家庭构成归类（避免误入 family）：
family 仅指"全家共同遵守的规则/约定"，不是任何家庭相关信息的兜底类。member_* 类型，subject_name = 宠物名（如"旺财"），subject_id 留空（宠物不在身份库）。
member_persona，subject_name="旺财"member_routine，subject_name="旺财"member_persona，subject_name 为对应成员；全家整体构成事实可用 subject_name="shared"。先和 list 拿到的已有条目比对，决定怎么写：
| 情况 | 操作 |
|---|---|
| 全新知识 | candidate-write op add |
| 与候选区已有相同 | candidate-write op merge(id) |
| 与正式区已有相同 | profile-write op merge(id)（仅+证据） |
| 与已有矛盾 | candidate-write op add（独立竞争） |
list 结果里找同主体 + 同维度 + 相似结论的条目——有就 merge，没有才 add。且同一条结论全程只能存在一个候选：
--ops 批次内也要自查——不要为同一条结论生成多个 add（这是重复条目最常见的来源，例如同一条净化器规则被 add 三次）。add（evidence_log 放多条），或"一个 add + 后续 merge"，绝不 add 多次。list 返回的该条 evidence_log——同一观察事件（同日期 + 同来源/现象）若已在其中，不要重复 add/merge，否则会虚增 evidence_count / confidence。只有日志里没有的新观察才 add/merge。批量候选写入（一次提交多条，提高效率）。每个 op 必须带 op（add / merge）和 date（观察日期 YYYY-MM-DD，必填，传入对应记忆的日期）：
miloco-cli home-profile candidate-write --ops '[
{
"op": "add",
"date": "2026-05-29",
"entry": {
"type": "member_routine",
"subject_id": "<person_id 或留空>",
"subject_name": "爸爸",
"content": "通常 7:30 出门上班",
"confidence": 0.8,
"source": "observed",
"evidence_log": ["2026-05-29 07:31: 玄关相机识别到爸爸出门"]
}
}
]'
merge 到已有候选（仅 +证据）：{"op": "merge", "id": "<candidate_id>", "date": "2026-05-29", "evidence_log": "2026-05-29 07:35: 玄关相机再次识别到爸爸出门", "confidence_delta": 0.1}
merge 到正式区（仅 +证据）：{"op":"merge","id":"<profile_id>","date":"2026-05-29","evidence_log":"2026-05-29 07:35: 玄关相机再次识别到爸爸出门"}
多个条目需要操作时，优先在单次
--ops中批量提交，提高效率。
感知范围控制 — 管理 miloco 感知哪些家庭、哪些摄像头，以及每台摄像头的声音（是否参与感知）。用户说「只用/不用某家庭」「让 miloco 感知/别感知 某家庭或摄像头」「屏蔽某摄像头/把某摄像头从感知里去掉」「把某摄像头声音关了/打开」「XX 老误报（声音类）」「哪些家庭在用」时激活。注意区分：开关摄像头设备本身（开机/关机/电源/录制）走 miloco-devices；感知引擎自身的开关/参数走 miloco-perception。
调用摄像头看画面、听现场声音，或回顾近期事件来判断——在干嘛、有什么动静、是否有人说话/吵闹、刚才/最近发生了什么；通过画面核实设备的开关状态（如开着/关着、亮着/灭着），尤其在拿不到设备上报状态时。读不出画面看不见的具体数值（温度、湿度、音量等）。
家庭档案管理 — 当用户提到自己或家人的喜好、兴趣、习惯、身体状况、作息规律、家庭规则时激活，无论用户是否明确要求"记录"。也在用户修正已有记录、要求删除、或查询家庭档案时激活。
家庭信息首次初始化 / onboarding —— 用户说"初始化家庭""配置家庭成员""首次设置""帮我建家庭档案""onboarding"时激活；收到后端推送的 `[系统事件]` onboarding 消息（全新安装检测）时主动发起；也在身份库成员为空 + 家庭档案为空时由 agent 提议。通过访谈把家庭成员与家庭档案一次性建起来。
miloco-perception-digest 定时任务的内部步骤，仅由该任务调用。
家庭成员身份注册主流程。**用户表达「想让系统认识/记住/录入某个人」的意图就触发本 SKILL,不要求出现"注册/登记"字面词**——包括上传图/视频指明某人是谁、回应 `[感知引擎]` 陌生人推送、说"建档案/录入家人/记下样子"、指认摄像头里某人身份、从近期陌生人记录里挑人建档、撤销注册、查看某人样本。覆盖"上传图/视频"与"从摄像头挑人"两条通路,所有路径需用户确认才入库。仅改 person 行(改名/删人,不涉及样本)走 miloco-miot-identity。