Google 音箱为什么越做越「小」了

我看到 Wired 那篇评测的时候，正好在调试自己写的一个小工具。评测提到 2026 年 6 月发布的 Google Home Speaker，说谷歌的智能音箱产品线变得前所未有地简单。我查了下数据，Google 过去五年在智能音箱这条线上砍掉了至少 7 个 SKU，现在只剩两款主打产品。

这个趋势挺有意思。我以前写过一个小工具，专门用来对比不同智能音箱的 API 开放程度，发现 Google 早几年的策略有点混乱：Nest Audio、Nest Mini、Home Max，每个产品的定位都很模糊，开发者也不知道该给哪个平台适配。

现在好了，Google 终于想通了一件事——大多数人买智能音箱，真的就只是为了听歌、定闹钟、问天气。不需要什么 360 度环绕立体声，不需要 7 英寸屏幕，不需要 Zigbee 网关。那些华而不实的功能，最后都成了消费者多掏钱的理由，但对大多数家庭来说，用不上。

我自己做 SaaS 工具的体会是，产品功能越多，维护成本越高，用户反而越困惑。Google 这次走极简路线，说难听点是认清了现实，说好听点是回归基本盘。从开发者视角看，一个清晰的、稳定的 API surface 比什么都重要。

代码层面举个例，Google 把产品线缩减后，背后用的 Smart Home 协议栈也统一了。我之前分析过，以前 Nest 产品走的是不同的通信协议，开发者如果要做一个跨平台的家庭自动化方案，得写好几套适配代码：

// 早期版本：需要为不同设备写不同适配器
class GoogleHomeAdapter {
  // Nest Mini 走 Bluetooth LE
  // Nest Hub 走 Thread
  // Home Max 走 WiFi Direct
  connect(device: string) {
    if (device === 'nest_mini') return bluetoothConnect()
    if (device === 'nest_hub') return threadConnect()  
    if (device === 'home_max') return wifiConnect()
  }
}

// 现在版本：统一 API
class GoogleSpeakerAdapter {
  connect() {
    return new GoogleHomeSdk().connect()
  }
}

这个变化对独立开发者来说，意味着更少的测试成本，更快的迭代。

[!note]

我看到的利润空间不在音箱硬件本身，而在围绕这个统一生态做的工具和自动化方案。

现在这套极简产品策略，其实给第三方工具留出了很大的想象空间。

两个月前我帮一个朋友做的家庭自动化方案，用 Google Home Speaker 作为语音入口，后端用了我自己写的 webhook 调度器，配合几个 ESP32 蓝牙节点控制开关灯和窗帘。整套方案只用了三天就调试完了。放在两年前，还要考虑不同的语音助手协议版本，光是兼容性测试就得花一周。

从商业角度，我认为 Google 这次的调整是对市场信号的正确回应——智能音箱早已不是风口，而是一个成熟的基础设施级产品。拼的不是参数的军备竞赛，而是稳定、好用、维护成本低。

我自己做产品的原则也是，当市场上人人都想堆功能的时候，说明用户真正需要的是减法。如果你做 SaaS 工具，可以想想你的产品能不能砍掉一些功能，换来更好的用户体验和更少的 bug。

最后给我读者一个行动建议：如果你也想做家庭自动化或者语音相关的开发，现在可能是入场的好时机。优先考虑基于 Google 统一 Smart Home API 的方案，少踩坑，多跑量。

原文链接：https://www.wired.com/story/best-google-home-speaker/