给群聊总结 Bot 加一个“带上下文回答问题”的 Skill：@ 一下就能问重点
导语
群聊最烦人的地方是什么？
不是消息多。
是你一觉醒来，群里 300 条未读，大家已经从“需求评审”聊到了“午饭吃什么”，中间还夹着几个关键决策。
你让 Bot 总结一下，它能给你一段摘要：
大家讨论了接口方案、上线时间和风险点。
看起来挺好。
但你真正想问的是：
那接口方案到底定了吗？谁负责？什么时候上线？
所以，单纯“总结群聊”还不够。更好用的做法是：你在群里 @bot 提问，Bot 读取聊天记录上下文，然后直接回答问题。
这篇教程就讲这个小功能怎么设计、怎么落地、怎么写 Prompt，以及容易踩哪些坑。
这个功能解决什么问题？
普通群聊总结像会议纪要。
带上下文问答的群聊总结，更像一个坐在群里的助理。
你可以这么问：
@bot 帮我总结一下刚才讨论的上线风险，顺便告诉我谁负责跟进。
Bot 应该返回：
刚才主要讨论了 3 个上线风险：
1. 登录接口还没压测
- 负责人：小王
- 跟进动作：今天下午补压测数据
2. 灰度策略还没确认
- 负责人：小李
- 跟进动作：和运维确认灰度比例
3. 回滚方案缺少演练
- 负责人：老张
- 跟进动作：明天上午跑一次演练
目前看，上线时间暂定周五，但需要等压测结果和灰度方案确认后再拍板。
这才是大家真正想要的。
不是“把聊天压缩一下”。
而是“帮我从聊天里捞答案”。
推荐使用场景
这个功能特别适合这些群：
- 项目群：快速确认需求、负责人、时间点、风险项
- 会议群：会后直接生成结论和待办
- 技术讨论群：从一堆争论里提取最终方案
- 社群运营群：总结用户反馈、热门问题、行动建议
- 销售/客户群：整理客户诉求、异议点、下一步跟进
举个真实场景。
你下午开会错过了一个小时群聊。回来一看，老板问：
刚才那个支付问题怎么处理？
你别再翻聊天记录翻到怀疑人生了。
直接问：
@bot 刚才支付问题讨论出什么结论了？有没有负责人和截止时间？
Bot 能直接把结论、负责人、时间点整理出来。
这一下，少翻 200 条消息。爽不爽？
功能设计思路
核心流程很简单：
用户 @bot 提问
↓
读取最近一段群聊记录
↓
识别用户问题
↓
把聊天上下文 + 用户问题交给模型
↓
输出结构化回答
重点不在“总结”。
重点在“问题驱动”。
用户问什么，Bot 就围绕什么找信息。别把所有聊天都揉成一锅粥。
Skill 应该怎么拆
可以把这个 Skill 拆成 4 个模块：
1. 触发器：识别 @bot
只在用户明确 @bot 时触发。
不要群里每句话都总结，那会很吵，也容易浪费 token。
示例触发：
@bot 总结一下刚才的讨论
@bot 谁负责这个需求？
@bot 这件事最终定了吗？
@bot 帮我提取一下待办
2. 上下文窗口：取最近聊天记录
建议默认取最近 50～200 条消息。
取太少，答案容易缺信息。
取太多，模型容易抓不住重点，还烧钱。
比较实用的策略：
- 小群：取最近 100 条
- 高频项目群：取最近 200 条
- 会议场景：按时间取最近 30～60 分钟
- 用户追问时：追加上一轮 Bot 回复作为上下文
3. 意图识别：判断用户到底想要什么
用户可能不是单纯要总结。
常见意图有这些：
- 总结刚才讨论
- 提取结论
- 找负责人
- 整理待办
- 判断是否达成一致
- 找风险点
- 回答某个具体问题
比如这句：
@bot 这个接口方案到底定了没？
不要输出完整会议纪要。
直接回答：
目前看还没完全定。
群里已经倾向选择方案 B，原因是改动小、上线快。
但小陈提出缓存一致性风险，老周还没确认这个风险能不能接受。所以现在状态是：方案 B 倾向通过，但需要老周确认风险后才能定。
这才叫懂事。
4. 输出格式：别让用户再整理一遍
回答最好固定结构。
推荐格式：
## 结论
一句话回答用户问题。
## 依据
列出来自聊天记录的关键信息。
## 待办
谁，在什么时候，做什么。
## 不确定信息
哪些内容聊天里没说清楚。
“不确定信息”很重要。
AI 最怕装懂。群里没说，就告诉用户没说。别脑补。
Prompt 模板
下面这个模板可以直接拿去改。
你是一个群聊总结助手。你的任务是根据群聊记录回答用户问题。
要求：
- 只基于聊天记录回答，不要编造。
- 如果聊天记录没有答案，明确说“聊天记录里没有提到”。
- 优先回答用户的问题，不要泛泛总结。
- 如果出现负责人、时间、结论、风险、待办，请单独列出。
- 输出要短、清楚、可执行。
用户问题：
{{user_question}}
群聊记录：
{{chat_history}}
请按下面格式输出：
## 结论
## 关键信息
## 待办事项
## 不确定点
如果你做的是技术群，可以再加一条：
遇到技术方案讨论时，请区分“已确认结论”和“仍在争论的观点”。
如果你做的是项目群，可以加：
待办事项必须包含：负责人、动作、截止时间。缺失的信息请标注“未明确”。
示例：项目群里怎么用
群聊记录片段
小王：登录接口这块我今天改完了，但还没压测。
小李：上线前必须压测，不然风险太大。
老张：周五上线来得及吗？
小王：如果今天下午能拿到压测环境，晚上可以出数据。
小李：灰度我来跟运维确认，先按 10% 灰度。
老张：回滚方案也要补一下，明天上午演练。
用户提问
@bot 这次上线还有哪些风险？谁负责？
Bot 回答
## 结论
这次上线还有 3 个主要风险：压测没完成、灰度方案待确认、回滚演练没做。
## 关键信息
- 登录接口已改完，但还没有压测。
- 灰度计划暂定 10%，需要和运维确认。
- 回滚方案需要补充，并安排演练。
## 待办事项
- 小王：今天下午拿到压测环境，晚上输出压测数据。
- 小李：和运维确认 10% 灰度方案。
- 老张：明天上午组织回滚演练。
## 不确定点
- 压测环境能不能今天下午拿到，聊天记录里没有确认。
- 周五是否一定上线，聊天记录里还没有最终拍板。
你看，这比“大家讨论了上线风险”强太多了。
技术实现建议
如果你已经有群聊总结 Skill，可以按这个方向改：
输入参数
建议至少包含这些字段：
{
"user_question": "用户 @bot 时说的话",
"chat_history": "最近的群聊记录",
"group_name": "群名称",
"sender_name": "提问人",
"timestamp": "触发时间"
}
消息预处理
不要把原始消息一股脑丢给模型。
建议先做清洗：
- 去掉无意义表情刷屏
- 合并同一个人连续发的短消息
- 保留发送人和时间
- 保留被回复消息关系
- 过滤系统通知，比如“某某加入群聊”
推荐格式：
[10:03] 小王：登录接口改完了
[10:04] 小李：还没压测吧？
[10:05] 小王：对，下午补
别只传内容，不传人名。
不然 Bot 很难判断“谁负责”。
追问能力怎么做
更好用的版本，要支持追问。
比如用户问：
@bot 总结刚才的待办
Bot 回答后，用户接着问：
那哪个最急？
这时候 Bot 需要知道“那”指的是上一轮待办。
做法很简单：
- 保存最近几轮用户问题和 Bot 回答
- 追问时把上一轮回答也放进上下文
- 判断用户问题里有没有“这个、那个、刚才、上面、哪个”等指代词
Prompt 可以加一句：
如果用户的问题依赖上一轮回答，请结合上一轮回答理解指代关系。
这样 Bot 就不会一脸懵。
避坑清单
坑 1：上下文太短
只取最近 20 条消息，很容易漏掉关键结论。
建议按群活跃度动态调整。
冷清群取 100 条没问题，活跃群可以按时间窗口取。
坑 2：Bot 太爱总结
用户问“谁负责”，它写一大段背景。
解决办法：Prompt 里写清楚：
优先直接回答用户问题，再补充依据。
坑 3：模型开始脑补
群里没说截止时间，Bot 自己编一个“明天下午”。这就很危险。
一定要加规则：
缺失信息必须标注“未明确”，不能猜测。
坑 4：输出太长
群聊助手不是写论文。
用户在手机上看，三屏还没看到结论，基本就关了。
建议结论放最前面，回答控制在 300～800 字。
坑 5：隐私没处理
群聊里可能有手机号、客户名称、合同金额。
如果接入外部模型，建议做脱敏：
- 手机号替换成
[手机号] - 邮箱替换成
[邮箱] - 客户名可按规则替换成
[客户A] - 金额按业务要求决定是否保留
别等出事了再补，真会很麻烦。
可以继续扩展的功能
这个小功能跑顺后，可以继续加这些能力：
- 一键生成会议纪要：结论、争议、待办、负责人全整理好
- 自动识别待办：有人说“我来处理”，Bot 自动记录
- 定时日报：每天晚上自动总结项目群进展
- 风险提醒：发现“还没确认”“来不及”“有问题”这类词，主动提示
- 多群汇总：把多个项目群的进度合并成一份日报
别一开始就做巨复杂。
先把“@bot 后能基于上下文回答问题”做好，用户马上能感受到价值。
参考项目
可以参考这个方向的实现：
github.com/JimLiu/baoyu-skil…
如果你已经有自己的 Bot 框架，把上面的核心逻辑接进去就行。
关键点只有三个：
- 拿到用户问题
- 拿到相关聊天上下文
- 让模型基于上下文回答，别瞎编
小结
群聊总结的下一步，不是写得更长。
而是回答得更准。
用户不想看一篇流水账，他想知道：
- 事情定没定？
- 谁负责？
- 什么时候做？
- 有什么风险？
- 我接下来该干嘛？
把这个 Skill 加上后，群聊 Bot 就不只是“摘要机器”了。
它会变成一个真正能帮大家捞重点、抓结论、追待办的小助理。
