路由强化：@ 谁谁，谁才回应

栏目：进化日志 · changelog
一句话：群里 @ 更准了——@ 谁谁才谁回应，没人抢答，也没人被你正文里提到的名字误唤醒。

以前的痛点：群里的 AI 员工太"热情"

如果你用过群里的定海，大概率经历过这个场面：

你说了一句「今天需要出一篇 LinkedIn 帖子，介绍一下我们新产品在东南亚的落地情况，@内容工厂助手 写稿，写好之后 @发布小助手 发布」。然后——四个 AI 员工同时冒出来：

「收到，处理中。」
「收到，处理中。」
「收到，处理中。」
「收到，处理中。」

刷屏。混乱。你只是想交代一下流程，结果像捅了马蜂窝。

问题出在两个地方：

一是没有真正的 @ 路由。 系统看到消息里出现了某个助手的名字，不管是开头正儿八经的 @，还是你正文里随口提到的「引述」，统统当成召唤指令。你写「需求拆解之后交给 @内容工厂助手」——这句话明明是跟团队同事交代分工，内容工厂还是被叫醒了。

二是没有群归属概念。 谁发消息就按谁的账号路由，换部手机、换个号，系统就不认识你了。一个群里三个人，是三个客户？还是一个客户的三个人？之前分不清。

这次改了什么：三项更新

更新①：@ 路由 —— 只派给被 @ 的那一个

现在规则很明确：只有消息开头被 @ 的那一位才会被激活。 正文中间提到的助手名字——不管出现多少次——都不再触发路由。

流程示意（更新前）
用户：「@内容工厂助手 写一篇文章，写完交给 @发布小助手 发布」
→ 内容工厂：收到，处理中。
→ 发布小助手：收到，处理中。
—— 两人同时响应，群消息 ×2

流程示意（更新后）
用户：「@内容工厂助手 写一篇文章，写完交给 @发布小助手 发布」
→ 内容工厂：收到，这就开始写。（正文中的 @发布小助手 不再被触发）
—— 只有被真正 @ 的那一个回应

这背后是一个精确定位策略：系统只认消息最前面的 @ 标记（mention），不做全文扫描。你的群公告、任务说明、流程交代里可以放心提到任何助手的名字，不会被误当成指令。

更新②：群绑定 —— 一个群 = 一个客户

之前，系统通过发言人的身份来判定「这是哪个客户的请求」。同一个人换手机发消息，就可能被当成另一个客户，历史上下文全丢。一个群里有三个人用定海，系统以为是三拨互不相关的客户。

现在：一个群绑定一个客户身份。 群里任何人发言，都按群的归属来路由。你的团队成员换设备、换账号、出差换手机，不影响系统对客户上下文的理解。

这意味着：
- 群里 A 提的需求、B 补充的细节、C 确认的结果，在系统视角里是同一个客户的一条连续线索
- 不会再出现「你换手机了，我不认识你」的局面
- 一个群里的协作和接力，上下文不丢失

更新③：意图分流 —— 闲聊秒回，真任务才进链路

之前的消息处理不分轻重——每一条消息都经历相同的拆解、路由、任务编排流程，哪怕只是一句「好的」「收到」「今天下雨了」。

现在多了一层语义判断：每条消息进来，先快速判断它是「任务」「闲聊」还是「提问」。闲聊秒回，不拆单、不进执行链路；真任务才进入后续的拆解和派发。

这对用户体验的改变比你想象的大：之前群里有人说了几句闲话，你可能要等几秒甚至十几秒才能看到响应（流程示意：逐条都在排队分析）；现在闲聊几乎即时回复，只有提出具体任务时才会看到「收到，处理中」的确认。

前后对比

这对你意味着什么

群更安静。 不会再有一句话引来三四条「收到，处理中」的场景。你说什么，该谁回就谁回。

回应更准。 @ 路由意味着你不会看到 A 助手抢了 B 助手的活，也不会因为正文里「提到」某个助手就触发意外的任务。

复杂任务照跑。 意图分流只拦截闲聊——你的真实任务（写文章、做审计、查知识库、发内容）依然走完整的执行链路，质量和步骤不受影响。

这次的三项更新都是「安静地变好」的类型——你不需要改任何使用习惯，@ 照常 @，群照常用。但它会显著减少群里的噪音，让你的团队和定海之间的协作更像「一个人对一个人」，而不是「一个人对一屋子人」。

欢迎在群里给我们反馈——你用起来的感觉，就是我们下一个 changelog 的起点。