团队里如何渐进启用 node 能力

官方最近把 camera、location、voice wake 都拆成了独立文档，这其实已经在暗示一种更稳的启用顺序：

• 先把 node 接进来
• 再按能力逐层开放

而不是一开始就把整台设备的所有能力全打开。

第一原则：先配对，再开能力

更稳的顺序永远应该是：

1. 先让 node 配对成功
2. 先确认宿主是谁
3. 再逐项开放相机、位置、语音

不要把“设备已经连上”误解成“能力已经都该能用”。

第二原则：先开离散能力，再开持续能力

更适合作为第一批试运行的通常是：

• camera.list
• camera.snap
• 单次位置读取

更适合后置的通常是：

• voice wake
• talk mode
• 持续监听或持续上报类能力

因为后者更容易牵涉：

• 误触发
• 常驻权限
• 背景运行边界

第三原则：先单设备，再多设备

很多 node 问题不是能力本身，而是你还没建立清楚：

• 哪台设备负责什么

所以更稳的顺序通常是：

• 先一台手机
• 再一台桌面设备
• 最后才扩到多设备协同

第四原则：先 operator 自用，再开放团队协同

node 能力比普通聊天入口敏感得多。
更适合的默认路径是：

• 先由核心 operator 自己试
• 先把 pairing、权限和行为边界摸清
• 再考虑团队是否共享这条能力

推荐的启用顺序

第一步：配对与宿主确认

• 设备是谁
• node 还是 headless node
• 能力实际跑在哪台宿主

第二步：只开单次能力

• camera.list
• camera.snap
• 单次位置请求

第三步：观察日志与权限模型

• 是否误触发
• 是否权限弹窗异常
• 是否有背景限制

第四步：再考虑 voice wake / talk mode

这一步才适合进入持续语音入口。

最容易踩的坑

1. 第一天就把相机、位置、语音全开

后面一旦出问题，很难知道哪条线先坏了。

2. 没记能力宿主

会把 Gateway、operator 和 node 排障混在一起。

3. 先让团队依赖 node，再补权限边界

顺序反了。

下一步推荐

• Headless nodes 和设备宿主边界怎么分
• Nodes 与设备能力
• 语音唤醒与 Talk Mode