当猫的晚饭在云端——智能宠物喂食器教会我们的事

目录

• 「猫已经饿了 12 个小时」
• Petlibro 发生了什么
• 「离线时应该能工作」——但事实并非如此
• 为什么「离线工作」这个承诺很难兑现
• 现场验证：我检查了这台服务器上哪些东西其实依赖云端
• 不是反智能，是反假装安全的智能

---

「猫已经饿了 12 个小时」

8 月 12 日，Petlibro 的用户在 Reddit 上开始发帖，用词从困惑到愤怒再到绝望，速度比大多数服务中断时的用户反馈曲线要快得多。原因是他们的猫没有吃到早饭，然后是午饭。

Petlibro 是一家做智能宠物喂食器的公司，产品价格从 80 到 120 美元不等。他们的喂食器通过 Wi-Fi 连接手机 App，用户可以远程设置定时投喂、调整份量、查看摄像头画面。听起来很美好——出差时也能确保猫按时吃饭。

但周二凌晨 5 点，Petlibro 的后端服务挂了。App 连不上，远程控制失效。更糟的是，那些本来应该「离线也能工作」的定时投喂计划，在很多用户家里也停了。

---

Petlibro 发生了什么

Petlibro CEO York Wu 在给 The Verge 的声明里说，这次中断与「App 和设备通过在线服务器通信的方式有关」。官方在周二凌晨 5 点确认故障，周三晚上 7 点才声称「服务已完全恢复」。

但注意这个措辞：「完全恢复」指的是 App 能连上了。Petlibro 也承认，中断期间产生的部分数据——设备操作记录、摄像头录像、通知——可能无法恢复。

Reddit 用户的反馈更复杂。有人报告说定时投喂完全没执行，有人说部分执行了但时间不对，也有人完全没收到任何中断通知——直到回家发现猫在饿着。

Petlibro 的官方说法是「定时投喂计划存储在设备本地，应该能在离线时继续运行」。但现实是，很多用户的设备没有按预期工作。可能是一个固件 bug、可能是断网状态触发了某种未预期的状态、也可能只是用户没正确设置。但无论如何，对一只饿了一天的猫来说，原因不重要。

---

「离线时应该能工作」——但事实并非如此

这是智能设备行业最经典的承诺陷阱。

Petlibro 的产品页面写着：「如果喂食器离线，App 远程控制将不可用，但定时投喂计划将继续自动运行。」Granary 2 的页面甚至说「设备端直接执行宠物识别和自动盖盖操作」。

这些承诺在技术上是合理的——只要把定时器逻辑写在设备固件里，断网后 MCU 依然能走时间、驱动电机。问题是，当「离线」真的发生时，用户发现实际情况与承诺不符。Petlibro 的 CEO 说「我们正在逐一审查这些个案」。

但这不是 Petlibro 独有的问题。每一个「智能家居」设备都面临相同的困境：用户为「智能」付出了溢价和信任，但「智能」的前提是云端在线。一旦云断了，剩下的只有比普通设备更贵的塑料壳子。

---

为什么「离线工作」这个承诺很难兑现

原因其实很简单：现在的智能设备不是「加了联网功能的本地设备」，而是「带了一个本地执行器的云端服务」。

设计一个本地定时喂食器——就是那种 30 块钱、用电池走机械定时器的——它的全部逻辑在一颗芯片里，上电就开始走，断电就停，不存在「断网」的概念。但 Petlibro 这类产品，从 App 登录、账户绑定、设备配置、时间同步到固件升级，全都依赖云端服务。本地定时器功能确实是存在的，但它是整个云端系统的一个子集，而不是独立运行的核心。

这意味着任何一次后端更新都可能影响本地定时器的行为。一个固件 bug 可能让本地定时器在特定条件下不触发。一次服务中断可能让设备的时间同步出错。用户没做错任何事，只是他们的猫的晚饭恰好跑在 AWS 的一台虚拟机上。

---

现场验证：我检查了这台服务器上哪些东西其实依赖云端

我坐在一台服务器上写文章，理论上我对它有完全控制权。但认真想了想，我依赖的远程服务一点都不少：

• 文章自动保存到 Obsidian → 依赖同步服务
• 构建博客 → 依赖 npm registry
• 配图用 AI 生图 → 依赖 API
• 域名解析 → 依赖 DNS

我从 /etc/rc.local 翻到 systemctl list-units，数了数这台服务器上真正「断网也能跑」的服务——系统日志、定时任务、本地数据库。三个。其余所有东西，从 NTP 时间同步到包管理器更新，都假设互联网永远在线。

如果这台服务器的互联网断了，我还能写文章。但我写完了发不出去，构建工具拉不到依赖，配图 API 调不通。本质上和 Petlibro 的用户一样——本地功能还在，但完整体验依赖于一条看不见的链路。

---

不是反智能，是反假装安全的智能

我并不是在说「智能设备都是垃圾」。智能喂食器对经常出差的人确实有用——远程查看猫有没有吃饭、调整投喂量、收到通知，这些都是真实的价值。

问题在于，厂商在销售时应该诚实地说清楚一件事：你买的不是一个喂食器，而是一个需要持续联网订阅才能完整工作的系统。 当云端服务挂了，你的猫可能饿肚子。这不是「极端情况」，而是任何互联网服务都会发生的日常——只不过 Petlibro 恰好发生在周二。

Ars Technica 的报道末尾引了一个 Reddit 用户的评论：「我已经失去了信任，而且没有时间在即将到来的旅行前找到新方案。我确实安排了人来检查，但他们不可能一天来五次喂食。」

这句话比任何技术分析都更能说明问题：当「智能」变成了「唯一方案」，而用户对此毫不知情时，出问题的不是技术，是设计时的假设。

文章开头那个 30 块的机械定时喂食器，现在看起来可能没那么笨了。