关键要点
- 基于规则的自动化是确定性的，但对未编写脚本的情境视而不见
- 本地 LLM 就意图和情境进行推理：时间、在家情况、天气、传感器状态
- 把自动化描述为自然语言目标；模型将其映射到设备动作
- 经由 Ollama + Home Assistant 在本地运行——无云端，数据不出家门
- 把安全攸关的自动化（门锁、报警）保持为确定性规则
- 为可靠性使用小型函数调用模型并限制范围
基于规则的自动化的局限
基于规则的自动化为固定触发器触发固定动作，无法权衡未被明确编写脚本的情境。 它可靠又快速，但每一处细微差别都需要再写一条手写条件。
- 组合爆炸：“开灯，除非已经很亮，除非有人在睡，除非我不在家”会变成大量嵌套条件。
- 没有意图： 规则无法解释“弄得温馨些”——只能处理精确的实体状态。
- 脆弱的边缘情况： 未编写脚本的情形会漏过，没有合理的默认处理。
LLM 带来了什么：情境、意图、语言
LLM 带来规则所缺的三样东西：它理解自然语言、推断意图，并同时就多个情境信号进行推理。 在细微差别重要之处用它；在确定性重要之处保留规则。
| 方面 | 基于规则 | 由本地 LLM 驱动 |
|---|---|---|
| 触发处理 | 每个触发器固定动作 | 行动前权衡情境 |
| 表达 | 仅精确条件 | 自然语言目标 |
| 情境 | 仅编写脚本的状态 | 时间、在家情况、传感器一并考虑 |
| 边缘情况 | 漏过 | 依情境给出合理默认 |
示例自动化（附提示词）
这些示例展示了由 LLM 驱动的自动化在哪里胜过规则：每一个都是模型对照实时情境去解决的自然语言目标。 把它们连线为调用对话代理的 Home Assistant 自动化。
- 在提示词中把相关的实体状态提供给模型，让它有可供推理的情境。
- 端到端配置参见用本地LLM运行你的智能家居。
- 1出门提醒
Why it matters: 提示词：“如果接下来一小时看起来要下雨而我要出门，就提醒我带把伞。”模型在通知前会检查天气实体和在家情况——规则则需要明确的阈值。 - 2自适应夜间场景
Why it matters: 提示词：“当最后一个人在日落后到家时，设置一个温暖、低亮度的场景，除非已经有人在睡。”模型把在家情况、时间和睡眠状态一并权衡。 - 3节能提示
Why it matters: 提示词：“如果暖气开着且某扇窗已开超过五分钟，就调低暖气并告诉我是哪个房间。”模型结合两个传感器状态并解释其动作。
架构
自动化在 Home Assistant 中触发，经由对话代理把情境传给本地 LLM，模型返回设备动作。 一切都在本地运行。
- Home Assistant 自动化提供触发器和当前的实体状态。
- 本地模型（经由 Ollama 集成）进行推理并返回动作。
- 只有你向 Assist 暴露的实体才可被操作，这限定了模型能做什么。
可靠性与护栏
把安全攸关的自动化保持为确定性，限制模型的范围，并优先选小而快的模型以保持低延迟。 LLM 自动化应当增强而非掌管关键功能。
- 绝不把安全交给模型： 烟雾报警、门锁和安防保持为普通规则。
- 限制范围： 只暴露模型需要的实体，并加一段限制动作的系统提示词。
- 按延迟选模型： 参见智能家居控制的最佳本地 LLM 模型。
- 记录并复查： 在无人值守地信任之前，查看对话日志确认模型按预期行事。
- 关于代理模式与工作流，参见 真正有效的自主本地代理（跨集群）。
常见问题
本地 LLM 的自动化可靠到值得信任吗？
对于舒适和便利类自动化，是的——前提是你限制范围并先复查行为。把安全攸关的自动化（门锁、报警、烟雾探测器）保持为确定性规则，而不要交给模型路由。
LLM 会取代我所有的自动化吗？
不会。对简单、时间敏感或安全攸关的触发器使用确定性规则，把需要情境、细微差别或自然语言目标的自动化留给 LLM。两者协同工作。
AI 自动化用哪个模型最好？
小而快、支持函数调用的模型能在可靠地输出设备动作的同时保持低自动化延迟。匹配硬件的选择参见智能家居最佳本地 LLM 模型指南。
LLM 自动化会增加多少延迟？
延迟取决于模型大小和硬件。带 GPU 或 NPU 的迷你 PC 上的小型模型，对非即时自动化响应足够快；不要把对延迟敏感的触发器交给模型路由。