Superpowers实战：开源智能家居自动化平台安装与规则编排指南

1. 别被名字骗了，Superpowers到底是什么

Superpowers，乍一听像是某种游戏外挂或者超能力设定，但如果你搜过“想要安装superpowers”，大概率和我当初一样，是被这个名字勾进来的。实际上它是一个开源的智能家居自动化平台，核心目标是把家里乱七八糟的智能设备统一管起来，用一套规则让它们协同工作，而不是各家App各玩各的。

我最早接触这个项目是在折腾智能家居的第三个月。那时候家里已经有智能灯、传感门磁、摄像头、空调伴侣和小爱音箱，手机里装了五六个App，每次设个场景动线要在不同应用之间反复横跳。更难受的是，跨品牌的联动基本靠猜，比如门磁监测到开窗，想让空调自动关掉，结果两个生态之间连通信都做不到。直到我找到Superpowers，才算是把这些散装设备拧成了一股绳。

这个项目说白了解决三件事：跨品牌设备统一接入、复杂自动化规则编排、本地化运行不依赖云端。它适合谁？适合已经开始玩智能家居、手上设备超过5个、被单一生态绑得难受的人。也适合开发者和DIY爱好者，因为它的核心是可视化规则加脚本扩展，能折腾的空间很大。

对新手来说，它比Home Assistant好上手的部分在于安装和配对流程更图形化；对老手来说，它的底层支持自定义脚本，玩得够深。我后面会把从零到一的安装、配置、设备接入、自动化编排全部拆开讲，顺手把我踩过的坑也一并交代清楚。

2. 核心思路拆解：Superpowers的架构和设计逻辑，为什么要这样选型

2.1 中心化网关模式，把设备连接“统一收口”

Superpowers走的是中心化网关架构，所有设备都先接到一台常开的设备上（我用的是一台退役的Intel NUC小主机），再由Superpowers统一管理。

这种模式和传统的“路由器+各厂App”方式最大的区别在于：设备不再各自为政，而是全部由Superpowers这个中枢来做状态汇总、规则判断和指令下发。打个生活比方，原来的智能家居像一栋楼里每家各装各的门禁，访客得每个门都按一次对讲；Superpowers则是楼里只有一个保安室，所有门禁都连通到那里，访客按一次，保安就能判断放不放行、要不要顺带通知别的门禁联动。

这个设计的好处有三个：

• 全局状态统一：所有设备的状态都能在同一时间线里汇总，做联动判断的时候不会出现“这台设备不知道那台设备的状态”的尴尬。
• 规则编排集中化：自动化逻辑只写一遍，所有设备按同一套规则走。
• 设备故障隔离：某个子设备掉线，不影响中枢运行，自动化规则仍然在跑，只是会标记该设备离线。

当然代价也有：中枢一旦挂了，全屋自动化直接罢工。所以我在实际部署的时候给主机配了一个UPS电源，这就是中心化架构逃不掉的基本盘。

2.2 规则驱动的自动化引擎，用“事件-条件-动作”替代死板的“如果-那么”

Superpowers的自动化引擎采用的是“事件-条件-动作”三段式模型，而不是很多用户习惯的“如果触发-那么执行”的简单触发模型。

这两者表面看着像，实际差别很大。简单触发模型是线性的：门磁开了就开灯，温度高了就开风扇。它没法处理复杂情况，比如“只有晚上7点以后、家里没人、且湿度低于60%的时候，才执行除湿机开机”。三段式模型里的“条件”就是解决这个问题的，事件是刺探器，条件是守门员，动作才是最终执行者。

具体拆开说：

• 事件：某个设备状态变化、定时器触发、外部接口接入的数据，比如门磁从关闭变为打开。
• 条件：执行动作前必须满足的额外判断，比如时间范围、其他设备当前状态、环境数值区间。
• 动作：最终下发给设备的指令，可以是单设备控制、多设备同时动作，也可以是触发另一条自动化规则。

我举一个真实的使用案例。我卧室内有一台加湿器和一个湿度传感器，我设的规则是：事件为“湿度低于45%”，条件为“当前时间在晚上7点到早上8点之间，且卧室门磁状态为关闭”，动作为“打开加湿器并以40%功率运行”。如果只写“湿度低于45%就开加湿器”，白天上班的时候加湿器也会白白空转，这就是条件存在的意义。

2.3 高度可扩展的插件体系，打破品牌生态的围墙

智能家居最大的痛点就是品牌隔离。小米的设备不能直接控制欧瑞博的插座，涂鸦的产品和HomeKit生态更是两个世界。Superpowers的插件体系解决的就是这个问题。

项目本身内置了一套协议适配层，支持大多数基于Wi-Fi的局域网设备、部分基于Zigbee的设备（需要配合USB网关使用，不推荐蓝牙方案，延迟和稳定性都不可控），以及常见的局域网控制系统。更关键的是，它支持自定义插件扩展接口，社区里能找到很多现成的插件包，比如涂鸦、易微联、博联等品牌设备的适配插件。

我在选型时对比过Home Assistant，两者的目标高度重合，但设计哲学不太一样。Home Assistant的集成方式更“重”，配置文件用YAML，功能强大但学习曲线陡峭；Superpowers把大多数配置都图形化，YAML只在开发者模式里作为扩展手段存在。从我实测的体验来看，如果家庭设备数量在二三十个以内，Superpowers的学习成本比Home Assistant低出至少一半。

这一套设计的整体思路，就是降低门槛、保留深度：普通用户通过界面设置就能完成80%的自动化需求，剩下20%的进阶玩法留给脚本和插件，后面我会专门拆一章节讲实操。

3. 环境准备与系统安装：从零跑通Superpowers

3.1 硬件选型和系统要求，别在这上面省事

先说硬件，这是很多人第一个踩坑的地方。Superpowers对硬件的要求不算高，但也别想着用几十块钱的ARM开发板就能流畅跑起来。我建议的最低配置如下：

部件	最低要求	建议配置
处理器	四核ARM Cortex-A53	四核Intel J4125或同级
内存	2GB	4GB以上
存储	16GB	32GB SSD或更大
系统	64位Linux发行版	Ubuntu 22.04 LTS/Debian 12
网络	有线或5GHz Wi-Fi	有线连接，稳定优先

我最开始图省事，在树莓派3B上跑，内存只有1GB，结果前端界面加载慢、规则执行有延迟，设备一多甚至偶尔崩溃。后来换到一台J4125的Mini主机，4GB内存加128GB SSD，彻底稳了。如果你手头有闲置的旧笔记本或者迷你工控机，都可以利用起来，只要能保证7x24小时开机，性能上比ARM开发板有先天优势。

系统方面我推荐Ubuntu 22.04 LTS或Debian 12，一个是稳定，一个是官方文档里用的示例命令在Debian系上基本不会踩到包管理器的坑。不支持Windows原生运行，建议别折腾，老老实实用Linux。

3.2 安装步骤详解，含Node.js版本与启动参数

Superpowers的安装流程其实不算复杂，核心依赖是Node.js。这里有一个必须注意的坑：不同版本的Superpowers对Node.js版本要求不一样，用错版本会导致启动直接失败或运行时报错。

官方长期支持的组合是Node.js 18 LTS版本搭配Superpowers 9.x分支。Node.js 20也能跑，但个别插件存在兼容性问题，我实际测试过，不建议尝鲜。安装步骤如下：

1. 先更新系统包索引：

sudo apt update && sudo apt upgrade -y

2. 安装Node.js 18 LTS，这里直接通过NodeSource源安装，顺手把npm和git一起装上：

curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash - sudo apt install -y nodejs git

3. 创建专用运行用户，为了安全，不推荐直接用root跑服务：

sudo useradd -r -m -d /opt/superpowers superpowers sudo passwd -l superpowers

4. 下载Superpowers主程序。官方仓库地址是GitHub，我习惯扔到/opt目录下：

cd /opt sudo git clone https://github.com/superpowers-iot/superpowers.git sudo chown -R superpowers:superpowers /opt/superpowers

5. 切换用户并安装依赖，这一步会消耗几分钟时间，取决于网络状况：

sudo -u superpowers bash -c "cd /opt/superpowers && npm install --production"

6. 启动服务并看日志确认状态：

sudo -u superpowers bash -c "cd /opt/superpowers && node server.js"

看到终端输出中出现“Superpowers is running on port 8080”之类的日志，说明启动成功。接着打开浏览器，访问http://服务器IP:8080，就能看到初始化界面。

如果你是新手，第一次打开界面会让你创建一个管理员账户，输入邮箱和密码即可，没有邮箱验证环节，直接存本地数据库里。这一步很直观，跟着界面提示走就行。

3.3 使用systemd管理服务，开机自启与崩溃自动拉起

手动启动的方式只适合第一次测试，真正长期运行必须用systemd管理。让Superpowers开机自动运行、异常退出后自动重启，这是智能家居中枢的基本要求。

在/etc/systemd/system/下创建一个服务文件：

[Unit] Description=Superpowers Smart Home Hub After=network-online.target Wants=network-online.target [Service] Type=simple User=superpowers Group=superpowers WorkingDirectory=/opt/superpowers ExecStart=/usr/bin/node server.js Restart=on-failure RestartSec=10 Environment=NODE_ENV=production [Install] WantedBy=multi-user.target

保存后依次执行：

sudo systemctl daemon-reload sudo systemctl enable superpowers.service sudo systemctl start superpowers.service

这里提几个我实测过的细节：

• Restart=on-failure比always更合理，避免正常关机时反复尝试拉起。
• RestartSec=10是关键，给进程留出退出后的冷却时间，否则在某些异常崩溃场景下会陷入频繁重启循环。
• 如果8080端口被占用，在启动命令后面加环境变量PORT=9090 /usr/bin/node server.js即可，改端口就改这里。

安装完这一步，Superpowers才算真正“立起来”了，接下来才能开始往里接设备。

4. 设备接入与核心配置：把第一台设备配对成功的完整路径

4.1 局域网设备自动发现，能省事就别手动录入

Superpowers的第一个核心能力就是局域网设备发现。只要设备支持局域网控制（绝大多数Wi-Fi智能插座、智能灯、红外遥控器都支持），Superpowers就能通过UDP广播自动发现设备。

在Web界面里，左侧导航栏找到“设备”菜单，点进去会看到一个“扫描局域网”按钮。点击后，系统会向本地网段发送广播包，大概等10到30秒，新设备就会出现在未配对的设备列表里。

我实测过，像我手头的涂鸦智能插座、米家智能灯智能音箱、博联红外遥控器，都能在这个阶段被发现。发现的设备会显示设备类型、IP地址、MAC地址等基础信息，确认无误后点击“配对”即可。

这里有个关键点：确保Superpowers所在的服务器和智能设备在同一网段。如果你的主路由开了AP隔离或者访客网络隔离，发现功能会直接失效。我自己就曾经把主机接到扩展路由器的LAN口，结果发现不了设备，排查了半天，最后发现是扩展路由开了隔离模式。

4.2 手动添加特殊设备，覆盖不支持自动发现的场景

自动发现做不到100%覆盖所有设备。有些老型号的设备，或者第三方改装固件的设备，只能通过手动方式接入。

手动添加的入口在设备页面右上角的“添加设备”按钮。弹出的页面会让你选三种方式：

• IP直连：适用于已知IP且支持标准局域网协议的设备，填写IP和端口即可。
• 插件配对：从已安装的插件列表里选对应品牌的插件，比如涂鸦插件、易微联插件，然后按插件要求填写设备信息。
• 自定义协议：通过编写JavaScript脚本来定义协议解析规则，这个适合极客玩家。

我建议自动发现无法覆盖的设备，优先尝试“插件配对”方式。我之前有一个老旧款空调伴侣，自动发现不到，后来发现社区的涂鸦插件里有人做过适配，装上插件后输入设备编码，配对成功。

4.3 设备状态校验与命名规范，小习惯避免大混乱

设备配对完成后，系统会自动拉取一次设备状态作为初始值。但你一定要手动去点一次“查询状态”，确认设备实时状态和界面显示一致。因为有些设备在未唤醒状态下不会及时上报状态，导致后续自动化规则用的初始状态是错的。

命名规范这件事看似鸡毛蒜皮，实际影响巨大。我在接入设备初期吃了不少亏，设备多了之后，页面上一堆“SmartBulb_1a2b3c”“Outlet_4d5e6f”这种名字，写规则的时候根本分不清谁是谁。

我后来的规范化做法是统一用“区域_设备类型_功能”的格式，比如：

• livingroom_light_main（客厅主灯）
• bedroom_sensor_humidity（卧室湿度传感器）
• kitchen_switch_outlet1（厨房插座1）

补充一下，设备分组也建议在接入阶段就做。Superpowers里可以把不同区域的设备放到一个组里，后面写自动化规则的时候可以直接对整个组操作，比如“客厅组全部关灯”，比挨个设备写规则省太多事。

4.4 集成语音助手，用自然语言控制全屋设备

语音控制是Superpowers的加分项，它本身不带语音助手，是需要对接外部语音平台的。

以对接小爱同学为例，原理是：Superpowers启动一个本地HTTP接口，小爱那边通过网关插件或自定义技能，把语音文本转发给这个接口，接口再把文本匹配到对应规则或设备指令。

配置方式大致是：

1. 在Superpowers设置页开启“开发者API”功能，记下API密钥。
2. 在小爱相关的第三方网关插件（比如巴法云或极星）里，填上Superpowers的服务器地址和API密钥。
3. 在小爱里设置自定义技能词，比如“开客厅灯”，对应的指令格式为{"action":"device_control","device":"livingroom_light_main","command":"on"}。
4. 测试触发，语音说出指定词后，后端日志里会看到一条对应的规则调用记录。

有一个容易踩的坑要提醒：语音平台和Superpowers之间的网络必须是通的，且API密钥不要写到语音平台的公开命令里，如果你把密钥直接嵌进自定义技能的响应里，语音日志一泄露，等于别人能远程控制你的家。正确做法是在语音平台侧只保留“转发地址”，密钥单独存在服务器本地脚本中。

5. 自动化场景编排：从简单规则到多设备联动的完整实践

5.1 创建一个基础自动化规则，先搞懂事件条件动作怎么写

设备接入完毕，核心玩法才真正开始。先去“自动化”菜单，点击“新建规则”，进入编辑界面。这个界面就是“事件-条件-动作“三段式编排器，你不需要写代码，都是下拉选择和填空。

我拿一个入门示例来讲。我想实现这样一个场景：晚上回家开门，玄关灯自动亮起，15秒后自动熄灭，但如果客厅灯已经是开着的，玄关灯就不亮。

• 事件设置：选择“门磁”设备，触发条件为“从关闭变为打开”。
• 条件设置：添加两个条件，一个是“时间-在晚上18:00和23:00之间”，另一个是“设备状态-客厅主灯-为关闭”。
• 动作设置：选择“玄关灯”，操作“打开”，然后添加第二条动作“延时15秒后关闭玄关灯”，延时可以直接在动作配置里设置延时时间，单位精确到秒。

保存并启用规则后，立刻去手动触发一次门磁状态变化，看日志里这条规则是否命中。如果没反应，优先检查条件是否满足，这是所有初学者第一个会犯的错误：事件触发了，但条件判断不过，规则静默放弃。

5.2 多设备联动场景编排，像写业务流程一样组织家庭逻辑

基础规则摸熟之后，可以做更贴近日常真实使用习惯的联动编排。我在家里跑了一条“晨间唤醒”联动链，给你完整看一下设置思路：

• 事件：定时器触发，每个工作日早上6:50。
• 条件：卧室门磁状态为“关闭”，表示人还在卧室。
• 动作1：卧室窗帘电机缓缓拉开（我的窗帘电机支持调速，设成30%速度）。
• 动作2：等待30秒后，卧室灯调至10%亮度，模拟晨光逐渐亮起。
• 动作3：再等待1分钟，客厅的咖啡机开始预热，按前一天设置的菜单工作。
• 动作4：手机推送一条通知：“早上好，咖啡还有3分钟准备好”。

这套流程用文字写出来觉得复杂，但其实在Superpowers里就是一条规则里逐条叠加动作，不需要写一行代码。规则引擎会按动作顺序依序执行，延时总是以“上一个动作完成后开始计时”为基准。

这条规则执行起来并不是每次都完美，我遇到过一个问题：窗帘电机那次报错，后面的动作也跟着没执行。查日志发现规则引擎默认遇到某个动作失败会中断整条规则。解决办法是在该动作设置里打开“失败后继续”开关，这种细节在官方文档里没写，是实际跑了之后踩出来的经验。

5.3 编写自定义脚本，处理超出现成功能的场景

Superpowers的进阶场景需要手动写JavaScript脚本。脚本入口在“开发者工具-脚本管理”里，新建一个脚本文件，编辑完保存就能在自动化规则的动作里调用。

我举个我之前遇到过的案例。家里有两个温湿度传感器，一个在客厅，一个在卧室。如果只拿任何一个传感器的数据来判断是否开除湿机，都不太准确。我的做法是写一个脚本，读取两个传感器的平均湿度，当平均湿度大于65%时返回真值，小于55%时返回假值，自动化规则里的条件直接调用这个脚本结果。

核心脚本逻辑大概是这样的：

// 获取两个传感器的当前湿度 const sensor1 = device.getState("livingroom_sensor_humidity"); const sensor2 = device.getState("bedroom_sensor_humidity"); const averageHumidity = (sensor1.value + sensor2.value) / 2; // 返回布尔值给自动化规则的条件判断 if (averageHumidity > 65) { return true; } else { return false; }

这个脚本写起来不难，但有几个细节我踩过坑：

• 脚本返回类型必须是布尔值，不要返回字符串或数字，否则条件判断会报错。
• 设备名称必须和系统里的设备ID完全一致，大小写都别错，我因为把“bedroom”写成“Bedroom”查了半小时日志。
• 脚本内部变量不能跨规则共享，如果多个规则要复用同一个计算结果，就写到一个脚本里。

5.4 场景定时调度：日出日落等天文时钟的配置方法

Superpowers内置了一个天文时钟模块，可以根据当前地理位置计算日出日落时间，用它来做光照相关的自动化，会比固定时间表聪明很多。

启用的路径是“设置-天文时钟”，填入你所在城市的经纬度坐标即可。之后在自动化规则里添加条件时，时间选项会多出“日出前/日出后/日落前/日落后”这几个维度，可以设定偏移量，例如“日落前30分钟”。

我做一个很实用的场景配置：家里院子的户外灯，设置为“日落后10分钟自动开启，日出后10分钟自动关闭”。这条规则只依赖天文时钟，不需要额外的传感器，整年下来不用任何手动调整。

需要注意，天文时钟的计算结果会因为服务器本地时区和系统时间而偏移，如果发现开灯时间和预期差太多，先去检查系统时区设置：

timedatectl set-timezone Asia/Shanghai

这一条我踩过很深的坑，之前服务器系统时间是UTC，天文时钟算出来的日落时间和真实相差了8个小时，那几天户外灯白天亮、晚上关，把我整懵了。

6. 实际运行中的常见故障：设备掉线、规则失效、资源占用排查

6.1 设备频繁离线，先从网络层找根源再谈其他

智能家居最让人烦躁的问题就是设备动不动离线。Superpowers里设备状态变成灰色，日志里报“设备无响应”，90%的情况下是网络问题。

我总结了一套排查顺序：

1. 看客户端的信号强度：Wi-Fi设备隔着一堵承重墙，信号衰减会很厉害。优先把路由器到智能设备的物理距离缩短，或者加装Mesh子节点。
2. 检查AP隔离：之前提过，主路由或扩展路由开了AP隔离，局域网内设备之间无法互相访问，Superpowers会看到设备在线但发控制指令无响应。
3. 确认IP地址是否冲突：有些智能设备DHCP租约过期后会被分配新IP，但Superpowers里还记录着旧IP，我看到的现象是设备时好时坏。解决方法是给全屋智能设备设置DHCP静态绑定，让每个设备固定IP。

还有一个很隐蔽的坑：2.4GHz Wi-Fi信道干扰。老式路由器默认2.4GHz 20MHz频宽，很多设备挤在1、6、11几个信道上，互相干扰严重。我在路由器后台把智能设备独立的SSID固定到信道1，并把频宽调到20MHz，设备离线率从肉眼可见的每周几次降到了几乎没有。注意，固定信道前先做一次信道扫描，选当前环境最空的信道，不要盲选。

6.2 规则触发正常但动作没执行，日志才是真正的答案

遇到过好几次这种情况：开门的瞬间，日志里能看到事件已触发，条件判断显示“通过”，但动作没有执行。这时候最忌讳的是瞎猜或反复重置规则。

正确做法是打开“自动化-日志”面板，筛选出这条规则所有相关日志。我遇到过的两类典型问题：

一类是动作执行失败，日志里会有明确的错误码。比如我之前下发的设备指令格式错误，按钮开关没有接收到正确的协议指令。

另一类更隐蔽：规则里动作执行成功了，但设备状态没有被正确反馈。比如我让智能灯调亮度到30%，灯确实是亮了，但Superpowers的界面还是显示之前的亮度，因为这款灯的本地状态同步机制有延迟。解决办法是在动作执行后手动加一个“延迟2秒后刷新设备状态”的动作，把状态拉回来。

这一步容易被忽视，但自动化场景和官方文档都有：规则设计的核心是“事件发生→状态更新→界面反映”，缺少任何一个环节看起来都像“没执行”，实际是状态同步延迟。

6.3 Node.js进程内存飙升，别急着加硬件先看日志

跑的越久，内存占用越高，最后卡死重启——这是很多Node.js服务的老毛病。Superpowers也不例外，我经历过一次连续跑了26天后内存占用超过2GB，最后系统OOM把进程干掉了。

我平时靠几个方法来稳定运行：

1. 定期清理日志：Superpowers默认会把实时日志全量写盘，运行时间长了日志文件会膨胀到几个GB。设置里调节日志等级为“警告”，并且配一个定时任务清理旧日志文件。
2. 监控内存趋势：用一个简单的crontab每小时记录一次进程内存，这样能判断内存泄漏是渐进式的还是突然飙升：

*/30 * * * * echo "$(date) $(ps -C node -o rss=)" >> /var/log/superpowers_mem.log

3. 启用systemd的自动重启：前面已经配置了Restart=on-failure，内存溢出导致进程被杀时，systemd会在10秒后自动拉起服务。

如果内存还是止不住地涨，优先怀疑是某个插件的轮询机制异常。排查方法是逐个禁用插件，观察内存曲线是否回落，这个过程需要耐心。

6.4 前端页面打不开或加载极慢，数据库损坏可能是元凶

Superpowers的界面和数据存储依赖一个内嵌的map-db数据库文件，如果运行期间意外断电或异常退出，数据库可能损坏，表现就是界面打不开、登录后白屏，或者设备列表加载不全。

遇到这种情况不要慌，Superpowers的数据库文件存储在/opt/superpowers/data/目录下，里面有几个.db文件。先做备份，再将坏文件改名让系统重建：

cd /opt/superpowers/data cp nodes.db nodes.db.bak_$(date +%Y%m%d)

但重建数据库意味着所有设备配对和规则都会丢失，因此更稳妥的做法是先从备份恢复。如果你有定期备份习惯（我建议放到NAS上或者远程网盘），直接把备份的数据库文件覆盖回去，重启服务即可。

一个实际建议：养成每周备份数据库的习惯，一条crontab就够了：

0 2 * * 0 tar -czf /backup/superpowers_$(date +%Y%m%d).tar.gz /opt/superpowers/data

这个习惯在关键时刻能救你一命，尤其是当你花了一个月调好的自动化规则全部搭进去的时候。

7. 实用锦囊：Superpowers后续还能怎么玩

在我实际使用Superpowers的这几个月里，最大的收获不是单纯的设备集中管理，而是它让我重新理解了“自动化”这件事。简单场景用界面编排，复杂联动靠脚本兜底，所有规则都在本地跑，不依赖任何一个品牌的云侧策略。

最后分享两个我最近正在尝试的方向，你可以理解为这套系统的扩展空间：

第一个是把Superpowers的API对接到自己写的微信小程序或网页面板。我的想法是家里父母不太会用电脑，我想做一个极简的开关控制界面，只有几个大按钮：离家关灯、回家模式、睡觉模式。Superpowers开放了完整的HTTP API，拿着API密钥，任何平台都能调用，这个小程序本质上就是把几个HTTP请求包了一层UI。

第二个方向是结合传感器数据做“习惯画像”。我这一个月把每个房间的人体传感器动作数据做了记录，积累了一个多月的数据之后，可以初步看出工作日和周末的作息差异。下一步我打算写个脚本，在每天固定时间分析历史数据，自动生成当天最适合的执行方案，比如白天卧室活动频率低时，自动把该区域的风扇调低一档。

这个东西玩得越深，越能感受到“算法即家居体验”的魅力：真正好的智能家居不是让你掏出手机开一个灯，而是你根本感知不到系统在替你处理多少小事。Superpowers给我带来的就是这种从“控制设备”到“设计环境”的跨越。如果你正处在设备一多就手忙脚乱的阶段，这个项目值得你花一个周末搭起来试试。