我家的米家自动化已经跑了一年。
照明、安防、洗衣机、窗帘，陆续都接了进去。连阳台几盆绿植的滴灌，也能根据土壤湿度自动浇水，出差时再远程查看。用到后来，自动化已经成了家里日常生活的一部分。
但只要碰上复杂逻辑，我还是会在米家极客版后台耗上很久。
定时关灯、人来灯亮，几个节点就能解决。窗帘电机互锁、门禁面板和窗帘的位置同步、多条件联动，就没那么轻松了：哪些事件负责触发，哪些属性代表当前状态，变量什么时候更新，异常时该怎么收尾，都得自己想清楚，再一条条接线。
难的往往不是拖节点，而是改完之后，能不能确定它会按预期运行。
折腾久了，我忽然想到：既然这些流程最终都要变成规则，网上会不会有人已经把它做成了程序接口？如果有，能不能让 AI 帮我完成这一步？
搜了一圈，还真找到了。
找到一棵可以乘凉的树
我用上的开源项目叫 oh-my-sage。
它提供了米家中枢网关的通信实现，以及极客版节点参考、工具接口和实战经验。对我来说，最有价值的地方，是不用从头研究网关通信，就能通过程序读取设备、查看规则，再尝试生成自动化。
以前我只把后台看成一个拖节点的地方。看到这个项目，才意识到：同样的操作，也可以交给工具完成。
我让豆包在它的基础上做了一层适合自己使用的封装，整理成一个技能库。协议和基础工具沿用开源项目，我负责描述需求、补充家里的使用场景，再把实际调试的结果反馈给豆包。
这套流程里，有几条约定尤其重要：
- 先查设备实际暴露的能力，不能看到一个叫“开关”的属性，就认定它能控制目标设备。
- 生成规则后，先做结构和设备能力校验；涉及变量时，也要确认变量已创建。
- 新规则明确设为停用，写入后再读回，检查保存结果。
- 我到极客版后台检查、启用，并观察设备是否按预期动作，最后再验收。
规则能保存，只说明网关接受了它；设备实际跑对了，才算完成。
于是，搭建自动化的过程变成了：我描述需求，AI 查询设备、整理逻辑、生成规则，我检查并启用，再根据实机结果继续调整。
后台依然要看，但我终于不用把所有想法都亲手翻译成节点了。
豆包负责推进，DeepSeek 帮我审一轮
这次项目从封装工具、整理技能库，到调试和修改，基本全程都是豆包在做。我主要负责提需求、作决定，以及在设备上验收。
豆包的 token 量大管饱，适合这样来回试、持续改的开发过程。不过，做到一个阶段后，我还是有点不放心，便用 DSH + DeepSeek 做了一轮审计。
这也是我使用多个 agent、做过一些项目后的个人偏好：审查逻辑、核对结论这类工作，我更相信 DeepSeek 的严谨性。具体审计细节就不展开了，但这一轮确实帮我把需要修正的问题和后续方向理清了。
之后，我把审计结果和项目现状整理成交接提示词，再交回豆包继续做。效果很明显：接下来的推进快了很多，豆包有了明确的修改依据，也少了来回摸索。
这次配合让我觉得，除了让 AI 多干活，把阶段成果审清楚、交接明白，同样能省下不少时间。
第一个案例：让阳台窗帘避免重复动作
阳台窗帘由两路通断器控制电机正反转：一路负责拉起，另一路负责松开，每次点动 8 秒。
需求听起来简单：已经拉起，就不要再拉；已经松开，就不要再松。切换方向时，先停下当前动作，再启动另一路，避免两路同时工作。
可放到节点图里，就得回答更多问题：当前状态记在哪里？重复按键怎么拦截？动作执行时，状态什么时候更新？反方向的命令来了，应该先做什么？
以前这些都要自己边拖边试。这次，我先把动作和限制条件说清楚，再让 AI 帮我拆成状态记录、重复动作拦截和方向互锁。动作前还加了一句语音播报，让我在客厅也能知道窗帘开始运行。
这个案例让我体会到，自然语言真正省下的是“把需求拆成节点”的那部分工作。
不过，变量记录的是规则里的状态，并不等于电机实际位置。手动操作、断电或动作中断，都可能让两者不一致。因此，互锁逻辑仍然需要实机检查，不能因为节点图看起来完整，就认定所有情况都已经覆盖。
第二个案例：把窗帘百分比传过去
客厅窗帘在米家 App 里可以按百分比控制，设置一个开度，窗帘就停在对应位置。但通过狄耐克门禁面板控制时，原来的联动只能全开或全关。
比如在面板上设成 85%，窗帘直接全开。面板明明提供了位置值，联动结果却只剩两个状态。
排查旧规则后，问题落在了中间的转换逻辑：位置值被转成了电机的“开”或“关”，百分比信息没有传下去。
调整方向也就清楚了：把面板的位置值传给窗帘的行程属性，再把窗帘位置同步回面板，让两边显示能够对应起来。
但双向同步还要考虑回环：面板改了窗帘，窗帘再通知面板，会不会反复触发？两边同时操作又该怎么处理？这些都要放进规则设计和后续测试里。
对我来说，这次变化最直观的地方，是排查有了明确的顺序：先看输入值，再看中间转换，最后看写入的设备属性。AI 能帮我读规则、提出修改方案，我则在设备上验证结果。
常驻连接省了步骤，也还有边界
除了规则本身，登录也曾经很打断节奏。
网关认证要用米家 App 里的登录码。它是一次性的，如果每次调用工具都重新建连接，操作起来就很麻烦。
后来我加了一个常驻服务，尽量复用已经建立的连接。连接正常时，可以连续查询设备、校验规则、读回结果，不必每一步都重新认证。
但这还不能叫“以后不用管登录”。服务进程可能退出，网关会话也可能掉线；本地记录里，就出现过进程仍在、会话已经断开的情况。失去连接后，仍然要取新的登录码重新认证。
所以每次开始操作前，先确认连接状态，是这套工作流里不能省的一步。
我省下了接线的时间，留下了验收这一步
用下来，最明显的收获是：复杂联动更容易开始做，也更容易继续改。
以前有个想法，我会先想到又要在后台拖多少节点，常常干脆搁着。现在可以先把需求说出来，让 AI 查设备能力、拆逻辑、生成一份停用草案。我再检查它有没有理解错，启用后看实际效果。
这也让我重新认识了开源项目的价值。有人把底层通信、节点知识和踩过的坑整理好，后来的人就能把精力放到自家的问题上。我这次做的封装，正是站在这些已有工作的基础上。
至于家里怎么动，决定权还是留在自己手上。涉及电机、浇水这类会产生实际动作的流程，我仍然要检查限制条件，观察运行结果。
玩了米家自动化一年，我终于有了一种更顺手的搭法：先把想法说清楚，再让工具把它变成可以检查、可以试运行的规则。
以后再冒出一个复杂联动的念头，我想自己会更愿意动手试试。