8月11日凌晨5点20分（太平洋时间），Petlibro的云服务器开始丢单——不是喂食器本身坏了,是App和设备之间的通信断了。厂商一直宣传,喂食日程存在设备本地,断网也能照常执行,这原本是个能自愈的小故障。可两天后,Reddit上冒出成堆"我家猫饿了一早上"的帖子,有人干脆把官方的回应称作"gaslighting"。争议的核心不是断网,而是官方坚持"离线照喂没问题",用户拿着没出粮的实况反驳回去——谁在说真话,成了这次事故最扎眼的地方。
崩了两次,修了近两天
Petlibro创始人兼CEO York Wu 周六发博客道歉,说要经历"一次完整的需求周期"才能保证系统真的稳了。这句话本身诚实——修好只是第一步,扛不扛得住下一波流量高峰才是真考验。
官方咬定"本地照喂",用户晒出空料槽
Petlibro反复强调一件事:喂食日程存在设备本地,不依赖App,断网也会按时执行。这是这类产品的核心卖点——愿意花钱买自动喂食器的人,图的就是"我不在家也能按时喂"的安心。
但Reddit上有用户贴出记录:喂食器到点播报了喂食提示音,却没有出粮;也有人说当天打开App才发现日程压根没跑。这些一手反馈和官方"本地存储、离线正常执行"的说法直接对撞。
更值得留意的是York Wu对The Verge的措辞——他说日程"应该"（should）能在设备端独立执行,而不是"一定会"。这个词选得有意思:厂商自己对这套本地容灾设计,其实也没有十足把握。
同时要说清楚:不是所有用户都遇到了漏喂。也有人反馈自己的Granary、RFID、Polar系列设备全程正常。这更像是"部分设备、部分场景下本地执行失败",而不是全网喂食器集体瘫痪——这个限定很重要,它决定了"gaslighting"这个词用得准不准。
"gaslighting"这词,用重了还是用对了
Reddit上有条留言说得很直白:"不要在危机沟通里往小了说,要往大了说。别说'只有少数用户受影响',别说'离线日程照常运行'——设备真挂了的人看到这种通稿,只会更愤怒。"
这话点出了症结:Petlibro的问题,未必是撒谎,更像是用平均值安抚个案。官方说"本地执行对绝大多数设备有效",站在整体数据上可能是真的;但对当天没喂上猫粮的那个人来说,这句话就是一种冒犯。
"gaslighting"本意是系统性地让人怀疑自己的感知,用在这里证据撑不满——目前能坐实的,是沟通姿态问题:笼统安抚、缺乏个案解释、部分用户没收到预警邮件。这是危机公关不及格,离"蓄意欺骗"还有距离。但对宠物主人来说,这种区分没那么重要,他们要的是"我的设备到底行不行",不是厂商在概率意义上有没有说谎。
平均数从不喂猫,喂猫的是那台具体的机器
云端优先的智能硬件,离线兜底从没被验真过
拉远看,这不是Petlibro一家的毛病。WOPET、PETKIT、Furbo这些做智能喂食器、宠物摄像头的品牌,同样把"本地存日程、云端做增值"当标准话术,但没有一家真正接受过第三方审计。行业默认的分工是:核心安全功能本地跑,App和云端负责通知、录像、远程手动操作这些锦上添花的部分。听起来合理,出了事才发现,验证它是不是真这么分工,全靠用户自己拿现实去撞。
喂食器不是智能音箱,喂错了顶多尴尬;它绑定的是宠物的进食节律,严重时是控糖、控药这类医嘱级的时间表。这类场景对"离线到底行不行"的容错率,本该比普通智能家居高得多,可整个行业连一个公开的离线可靠性测试标准都没有。
- 提醒.买这类设备前,值得直接问厂商三件事——日程存在设备Flash还是云端缓存、断网有没有做过实测记录、断电后能不能物理手动出粮。答不清楚的,宣传语就别全信。
Petlibro这次算是把行业的遮羞布掀开了一角:云端稳,一切都好说;云端一崩,"离线兜底"到底是工程事实还是营销话术,才见真章。这次事故没闹出大事,但它提醒的问题不小——厂商自己都只敢说"should",用户凭什么该说"一定"。