群播中心
Relay · 面向多群协同的消息分发与监控体系
一个销售同时管着几十个外部协作群。每同步一条信息，就要复制粘贴几十遍，还容易错发、漏发、发重。 这个产品把它拆成两层，AI 负责思考，通道负责送达，再用一张路由表和一套自查机制，让"发错群"这件事变得能发现、能追溯、也能撤回。
从一个限制开始的设计
最直觉的方案是把 AI 助手拉进所有群。但外部协作群放不进一个内部助手，权限、合规、身份，每一条都过不去。
于是我换了个思路。既然大脑进不去，那就只让消息进去。用群里的自定义机器人当投递通道，AI 留在后台做理解、加工和编排。这个拆分看着不起眼，整套体系能不能成立全靠它。
AI Agent
理解任务、读取数据、加工信息、判断该发给谁、生成最终消息卡片。
路由表
什么内容 → 发到哪个群。未登记的群不进入推送范围，这是默认拒绝而非默认允许。
Webhook
只负责传话。它没有判断力，也不需要有，判断力全部前置在大脑和规则里。
Webhook 本身没有判断力，也不能对话。
所以设计的重点全在发出去之前，谁来保证这条消息是对的。
路由表把"发到哪"变成可维护的数据
所有想接收自动推送的群都得先登记。这张表是整套体系唯一的事实来源。
| 字段 | 作用 | 规则 |
|---|---|---|
| 群聊名称 | 识别目标群的基础定位字段 | 与群展示名保持一致，避免人肉对照。 |
| 业务归属 | 标记该群对应的合作方或业务线 | 按实际归属填写，内部通用群统一标为"通用"。 |
| 启用状态 | 控制该路由是否参与自动推送 | 仅"开启"生效。停用群必须及时关闭，而不是删掉。 |
| 内容类型标签 | 定义该群接收哪一类播报 | 支持多选；未勾选的默认不推送。 |
| Webhook 地址 | 消息送达的唯一入口 | 机器人重置或失效时必须立即更新。 |
| 最后推送时间 | 巡检断推用 | 保留完整日期时间，便于排查。 |
| 最后内容摘要 | 快速核对"上次发了什么" | 一句话即可，重点是可读不是完整。 |
主链路 · 判定 → 匹配 → 草稿 → 人工确认 → 推送 → 回执
我在链路中间硬插了一道人工确认。它会让流程变慢，但这是我最坚持的一个设计。全自动的分发系统，出错的时候也是全自动地出错。
- 关键词命中而非全量群发。说"广播 XXX"就全量分发，说"推 XXX 相关"就只落到命中标签的群。
- 推送前出确认卡。目标群清单 + 拟发文案，一起摆在用户面前，确认了才真的发。
- 推送后自查回执。必须逐项列出"消息关键词 → 命中规则 → 推送目标群"三者的对应关系。
- 三者对不上就停。只要无法一一对应，立即中止后续推送并提示人工确认，宁可不发也不错发。
兜底就是假设它一定会出错
自动推送替代不了人工治理。我没指望 AI 永远判断正确，所以整套机制做成了两层。
AI 负责事前与事后
推送前做命中判断与去重，推送后做链路自查并输出执行报告。它管的是"发之前想清楚、发之后说清楚"。
人负责最终处置
错推、重推、内容不适合外发，由群管理员直接撤回。发送方身份不一致时，走应用管理员接口兜底。
规则写进长期记忆
路由表地址、字段定义、标签体系、去重逻辑、改表授权边界，全部固化。否则下一次对话就会失忆。
另一半，给自己留一个"防漏信箱"
群广播解决的是把信息同步给别人。还有一类问题在反方向上，重要的事被淹在几十个群里，我自己反而看不见。
于是有了第二条通道。不能错过的提醒，走另一个 IM 通道单独再打一层。它不追求信息全，只保证关键事件不漏。
- 重要线索防漏。高意向咨询一出现就单独提醒，保证第一时间能接上。
- 异常哨兵。业务链路出问题时强提醒，不指望人主动去看。
- 关键任务催办。截止日期前的保底提醒。
- 轮询巡检。比如"每半小时看一次有没有新回复，有就推给我，直到我叫停"。
周末、节假日和非工作时段，这条通道最顶用。它给的信息更少，但保证看得见。
这个项目真正教会我的
做自动化最容易上瘾的部分，是让它全自动。
但决定这东西能不能长期跑下去的，是你有没有认真设计过它出错时会发生什么。
- 默认拒绝，不默认允许。没登记的群不进推送范围，光这一条就挡掉了绝大多数误发。
- 判断力只放一处。通道保持愚蠢，规则和大脑保持清醒，出问题的时候才知道该改哪里。
- 机器能自查，人能撤回。两层同时在，风险才算可控，不用靠运气。