多账号渠道的 pairing 和 allowFrom 需要分开治理

当团队开始在同一渠道上接多个账号时，最容易出现的误区是：

• 仍然按“只有一个默认 bot / 号码”的方式来管理 pairing

这会让审批、白名单和实际入口很快对不上。

1. 先承认“账号”本身就是治理边界

在单账号环境里，pairing 和 allowFrom 常常还能靠默认值管理。

但到了多账号环境，至少要先把这件事记清楚：

• 账号本身就是授权和排障边界

你不能再用“一份 pending 队列”和“一份 allowFrom 心智”来覆盖所有入口。

2. pairing 队列要按账号看

更稳的习惯是：

• 每次处理 pending 前，先确认是哪个账号
• 对多账号渠道固定使用 --account

这样才能保证你审批的是：

• 正在运营的那个具体入口

而不是误动默认账号。

3. allowFrom 也要按账号核对

官方现在已经明确了 scoped 文件命名。

所以每次出现：

• 明明 approve 过却仍然异常
• 明明在白名单里却还在 pending

都不该只看默认的 *-allowFrom.json，而应该回到对应账号的 scoped 文件去核对。

4. 不要把测试账号和生产账号混在同一审批习惯里

更稳的做法通常是：

• 测试账号允许更频繁的 pending 清理和临时 approve
• 生产账号更偏固定 allowFrom 和更少的人工 approve

这样既能保留实验空间，又不会把生产入口拖进高频人工处理。

5. 对方通知策略也要分账号考虑

官方现在给了 --notify，这让多账号环境更值得分开处理：

• 测试入口更适合显式通知
• 生产入口要避免无必要的拒绝噪音

同样一条 pairing 审批，在不同账号上的运营口径不一定相同。

一条更稳的治理顺序

建议按这个顺序走：

1. 先按账号盘点入口
2. pairing 审批固定带账号 scope
3. allowFrom 按账号分别核对
4. 测试和生产分开治理

下一步推荐

• 频道 pairing CLI 和 account scope 应该怎么一起看
• 配对审批与设备授权管理
• shared inbox 的运营边界和信任模型