群组广播通知器

当一次通知需要覆盖多名工人时，逐个发送既费时又容易漏人：公告要发给全员、催办要发给特定班组、点名要精确到人，手工复制粘贴的工作量随人数线性增长，还无法确认消息是否真正送达。group-broadcast 就是为这个场景设计的：把「一次编写、批量投递、确认送达」串成一条可重复执行的流程。

核心能力

该技能通过 Dashboard API 批量发送消息，支持三种典型用法：

• 全员公告：把通知投递给所有工人，适用于公司层面的制度发布。
• 催办与点名：仅向指定工人或工人集合发送，避免无关人员被打扰。
• 总裁令等广播场景：需要一次性触达全员的高优先级通知。

触发的时机很明确：当你需要同时通知多个工人、发布全员公告、催办或点名，以及执行需要广播性质的指令时，都可以交给它处理。

工作流程

一次完整的群发分为四个步骤：

1. 构造 payload：按 from / to / subject / body / bucket 五个字段组装请求体。to 决定投递范围，bucket 用于区分业务分组，两者共同决定谁收到消息。
2. 调用 API 发送：向 POST https://dashboard.yunjinhong.cn/api/worker-dashboard?action=send 发起请求，认证使用 Authorization: Bearer {TOKEN} 头。
3. 检查响应：解析返回结果中的 ok 字段，确认消息是否送达，而不是发送即忘。
4. 返回统计：把发送结果汇总为统计信息返回给调用方，便于上层流程做进一步处理。

限制与注意点

使用前需要了解三条边界：

• 群聊消息所有工人可见：广播内容会出现在群聊中，任何工人都能看到，敏感信息不要通过群发渠道下发。如果需要保密，改用 inbox 消息，它只支持点对点发送。
• inbox 是单聊通道：只能指定单个接收者，无法替代群发功能，两者应按信息敏感度分开使用。
• API 可能超时：服务偶尔会超时，技能内置了重试机制，最多重试 3 次，调用时需要为最坏情况预留时间。

把通知的编写、投递和确认从人工操作中剥离出来之后，批量通知这件事就从重复劳动变成了一次调用。适合公告、催办这类高频且格式固定的场景，但不适合承载需要细粒度权限控制或复杂交互的消息。