群聊里认错对象，通常不是模型本身的语气问题，而是送进去的上下文里发言人身份丢了：几条消息糊成一段纯文本，助手只能靠昵称猜，猜错就对着 B 说 A 的事。可行的顺序是先锁发言人，再判断这条话该公开说还是转私聊，最后逐句删掉只对某一个人才成立的信息。这三步都能通过日志、配置或页面上的实际回复来验证，不需要改动模型就能看到差别。

处理顺序建议固定为：认人 → 定公开范围 → 删减信息。认人这一步要看触发消息、回复引用和最近的指代，确认后才写称呼；只要内容涉及个人信息、金额、账号、对第三方的评价，就转私聊或群里只留一句提示。同一件事建议按不同对象各写一版做对照，看称呼和语气是否只对一个人成立。边界是：助手无法百分之百判断人的真实意图，信息不全时先反问一句，比给一个错的称呼更稳。

把群聊最近的对话按发言人拆开，标出这次要回的是谁

先把最近几条消息拆成结构化记录再交给助手，每条至少带上发言人和回复关系。纯文本拼接最容易在这里出错，因为“他”“这个”“刚才那个”在人的眼里有指向，在拼接后的字符串里没有。

拆开之后，本次回复对象的确认过程可以按三步走：先看触发点是哪一条（谁 @ 了助手、谁的问题没被回答）；再看触发消息里有没有指代，指代的对象通常是它 reply_to 的那条消息的发言人；最后看最近一条还没有被回应的消息是谁发的。三步指向同一个人时，称呼可以直接写；如果指向两个人以上，建议先反问“你是在回小李还是老王”，而不是硬选一个。

把消息整理成下面这种结构再送进去，替换掉昵称拼接的纯文本，认人这一步会稳定一些。字段名可以按你实际用的接入方式改，关键是发言人和回复关系不要丢。

{
  "trigger": {"msg_id": "m3", "speaker_id": "u_li", "at_bot": true},
  "recent": [
    {"msg_id": "m1", "speaker_id": "u_li",  "nickname": "小李", "reply_to": null, "text": "周五的评审能提前吗"},
    {"msg_id": "m2", "speaker_id": "u_wang","nickname": "老王", "reply_to": "m1", "text": "我这边可以"},
    {"msg_id": "m3", "speaker_id": "u_li",  "nickname": "小李", "reply_to": null, "text": "帮我回一下老王"}
  ],
  "target_hint": "回答 m2 的发言人"
}

判断这条回复应该发在群里还是转私聊

认对人之后，紧接着要判断这句话适合给谁看。判断依据可以按下面几条过一遍，命中任意一条就倾向私聊，或者群里只留一句过渡语。

• 内容里出现手机号、邮箱、住址、账号、订单号、工单号等能定位到个人的信息。
• 涉及金额、报价、合同条款、未公开的排期或人事安排。
• 包含对第三方的评价，或者两人之前的私下约定。
• 只有一个人需要知道，群里其他人看了只会增加噪音。

两种处理方式的写法差别很直接。公开版只描述动作和结果，不带细节；私聊版才把原因和具体信息补齐。比如公开版写“@小李 时间的事我私聊你和老王”，私聊版写“小李，周五评审提前到周四下午，老王那边我确认过了，你这边方便吗”。公开版的作用是让群里知道这件事有人在跟，私聊版才承载真实信息。需要结合环境确认的是：有些群里要求所有结论都留痕，那就把公开版写完整，把个人敏感信息替换成占位符，而不是直接转私聊。

同一件事按两个对象各写一版，比较称呼和语气

确认回复是否只对某一个人成立，最快的办法是把同一件事写成两版放在一起看。如果两版的称呼和语气互换之后读起来不别扭，说明这一版其实没有认人；如果互换后明显不对，那才是针对具体对象写的。

写完之后逐条标注差异点：称呼是昵称还是职务，语气是结论先行还是背景先行，结尾是命令式还是征询式。这两版的意义在于检查助手生成的回复有没有滑回通用句式——通篇“您好，关于您提到的问题”这种，通常就是没锁住对象。

删掉只有特定对象才看得懂的信息

群聊回复最常见的泄露不是秘密，而是上下文。助手为了让回复显得连贯，会把上一轮私聊里的前提一起带出来，群里其他人看不懂，反而显得突兀。

• 内部项目代号、只有小圈子在用的简称。
• 上一条私聊或小群里已经确定的约定，比如“就按昨天说的办”。
• 金额、折扣、报价、工单号、内部链接和截图。
• 对第三个人的评价或抱怨。
• 历史纠纷、旧梗、只有当事人才懂的指代。

删减不是把句子砍短，而是把前提换成群里都能看懂的描述。原句可能是“按昨天那个价，老王的单子可以走”。改后的公开版可以写成“这个单子的价格我私下确认一下，确认好再同步”。动作保留了，只有当事人才懂的前提被拿掉了。改完读一遍，如果群里一个完全不参与前情的人也能看懂这句话在说什么，删减基本到位。

准备一条更短的备用回复用于公开场合

话多的风险在于越写越具体，具体到必须带上不该公开的信息。建议常备一条短版回复，在信息不全或话题敏感时直接用。

短版示例：
“收到，我先确认一下，稍后回复。”
“这件事我私聊你，群里先说进度，周四下午的时间我们在对齐。”

它的使用条件大致是：发言人不明确或指代有歧义；内容涉及个人信息、金额、对第三方的评价；当前上下文里有两件事被混在一起；群里情绪已经起来，继续回复只会扩大范围。短版的作用是给自己留出确认时间，它不承诺结论，也不产生新的上下文。等确认完再补一条完整回复，比在群里先把话说满要稳。

最后需要留意的是，短版回复不能代替认人。它只解决“现在不适合把话说完”的问题，如果对象一开始就锁错了，短版也只是把错误延后一步。日常排查时可以翻一翻助手的实际回复记录，对照上面的三步顺序，看漏的通常不是语气，而是触发消息和回复引用这两条上下文。