显示天气的 Pebble 表盘,可以复用手机应用中的数据提供程序,而不必自行集成一个天气服务。这正是新插件预览带来的架构变化:小型 JavaScript 组件向多个表盘、应用和 Index 智能体提供数据或操作能力。
Eric Migicovsky 于 2026 年 10 月 22 日宣布这项 SDK 工作,Gizmodo 于 23 日报道。官方预览文档说明,手机应用从 1.14.0 版起提供实验性支持,默认关闭。这是面向开发的进展,并非成熟集成功能的全面发布。
一个数据提供程序可以服务多个表盘
有价值的变化在于职责分离。表盘开发者可以专注于如何在手腕上显示读数,由插件负责连接提供数据的服务。插件作者也不必再设计唯一能使用该信息的表盘。
因此,天气显示是比“手表什么都能做”更准确的例子。数据源仍需返回所需信息,表盘也必须处理读数缺失的情况。更换界面设计,并不能让不可用的服务恢复响应。
Pebble 文档还区分了提供信息的数据源与请求改变状态的操作。显示灯的状态和发送开灯指令,是两种不同能力。开发者应该让按按钮的人理解这种差别,尤其是在操作会影响其他设备时。
原型面对的是尚会改变的接口
预览指南警告 API 尚不稳定,并要求开发者暂时不要把依赖插件的作品提交到面向大众的应用商店。单独的插件发布指南则将发布权限限制在受邀开发者范围内。这两份文件描述的是受控预览,而非开放的正式发布渠道。
对开发者来说,合理的起点是一个可以检查输入、数据缺失处理和操作结果的小型集成。能工作的演示可以提供反馈,但不能证明同一个软件包在 API 改变后仍然兼容。
现有用户面对的是另一种选择。在接口稳定之前继续使用熟悉的表盘完全合理。这次公告没有表明,用户必须购买另一款手表才能受益于未来的插件生态。
权限还要结合版本判断
预览文档说明,细粒度权限系统随手机应用 1.15 版提供,并在启用插件时生效。文档也明确指出,Health 权限尚未强制执行,因为所需的手表端同步机制还没有完成。
这一限定意味着,不能笼统宣称插件已经保护所有类别的数据。在手机端运行和声明权限描述的是架构,不能独立证明某个集成安全。使用插件前,应检查其申请的访问权限及背后的服务;对于失败代价较高的任务,应避免依赖实验性操作。