自动化数量上来后,YAML 嵌套、依赖链、状态机会让维护变成噩梦。这个工具把抽象的复杂度量化成 0-100 分,告诉你什么时候该停下来重构。
Home Assistant 的自动化复杂度不是单纯按"条数"算的。一个 200 条 trigger-action 列表的部署,可能比 30 条嵌套 choose + 状态机还简单。复杂度真正来自四个维度:嵌套深度(让你半年后看不懂自己写的)、状态机数量(让流程有"记忆"但也引入时序 bug)、依赖关系(一条改了连锁挂掉多少条)、外部集成(网络抖动 = 自动化随机触发)。
经验阈值:总自动化超过 50 条、状态机超过 10 个、最深嵌套超过 5 层,日常维护就会开始"怕动"。调试时间超过 3 小时/周,基本可以认为你的部署进入了"无人敢改"状态,任何人都宁愿重写也不要碰线上配置。
复杂度的隐性代价:新人 onboard 时间(从 1 天变成 2 周)、配偶拒绝使用、出问题时无法快速回滚、最终落到"全部关掉用回物理开关"。这是真实的失败模式,不是耸人听闻。
控制复杂度的方法:把状态放进 helper 而不是写死 condition;每条自动化只做一件事,链式触发;超过 5 层嵌套就拆成 Node-RED flow 或 Python script;每季度强制做一次"删除日",砍掉没用到的自动化。
条数不是核心,关键看依赖图。如果是平铺的 trigger → action,500 条也不算复杂。如果互相 trigger 或共享状态机,30 条就能让你崩溃。
把复杂的 choose 拆成多个独立自动化,用 trigger_id 串联;或者迁移到 Node-RED,画布比 YAML 更容易看清。
input_select、counter、timer 加起来超过 10 个就危险。每个状态都要在脑子里维护"现在是什么 / 下一步是什么",超过 10 个普通人类记不住。
超过 70 分建议立即重构。50-70 之间可以用 Node-RED 或 packages 拆分子目录来缓解,50 以下维持现状即可。
HomeDIY Lab 智能家居 DIY 决策工具集,聚焦部署、维护、合规的实际问题。
全部计算在浏览器本地完成,不会上传任何输入数据。
评分仅供参考,不构成专业建议。具体重构方案请结合实际部署评估。