用 baoyu-skills 总结微信群聊：把刷屏消息变成可执行结论

群里几百条消息，真正需要看的可能只有十几条。

项目讨论、客户反馈、活动通知、临时决策，全混在一起。有人发语音，有人贴链接，有人半夜补充一句关键信息。你要是从头翻，半小时就没了；直接跳过，又怕漏掉重要结论。

现在，baoyu-skills 新增了一个 微信群聊总结 Skill。它配合 wx-cli 读取聊天数据，再交给 Claude Code 处理，适合把长群聊整理成一份能直接拿来用的摘要。

推荐组合是：

• baoyu-skills：提供微信群聊总结 Skill
• wx-cli：负责读取微信群聊数据
• Claude Code：运行 Skill 并组织任务
• Claude Opus 4.6：负责理解上下文、提炼结论

这套方案的重点很简单：先拿到聊天内容，再让模型处理内容。

这套 Skill 适合处理什么

它更适合有明确上下文的群聊，而不是随手整理几句闲聊。

你可以用它处理这些场景：

• 产品群：提取需求、问题、负责人和截止时间
• 项目群：整理进度、风险、阻塞事项和下一步动作
• 客户群：汇总客户反馈，区分已解决和待跟进问题
• 活动群：提炼时间、地点、报名规则和临时调整
• 行业交流群：整理观点、链接和值得继续研究的话题
• 家庭或社团群：快速查看通知和需要自己回应的事项

比如，一个项目群在一天里出现了这些内容：

• 设计稿需要改三个地方
• 后端接口预计周三提供
• 测试发现登录失败问题
• 客户要求增加导出功能
• 有人说今晚可以上线

人工阅读时，很容易把“有人提议今晚上线”误认为“已经确定今晚上线”。

好的总结需要把事实、观点和决定分开。你真正需要看到的应该是：

已确认：后端接口预计周三提供
待确认：是否今晚上线
风险：登录失败问题尚未关闭
新增需求：客户要求增加导出功能

这比把聊天内容压缩成一段漂亮的文字有用得多。

工具之间怎么配合

baoyu-skills 负责总结逻辑

Skill 可以理解成一套面向特定任务的工作流程。微信群聊总结 Skill 的任务，就是指导 Claude Code 处理聊天记录，并输出结构化结果。

它关注的内容通常包括：

• 群聊讨论了哪些主题
• 哪些事情已经确定
• 哪些内容仍然存在分歧
• 谁负责什么工作
• 有哪些明确的时间节点
• 哪些问题需要继续跟进
• 哪些消息只是重复、闲聊或背景信息

wx-cli 负责读取数据

wx-cli 是这套流程里的数据读取工具。

微信群聊总结 Skill 会借助它获取聊天内容。当前的关系到这里为止：

• Skill 使用 wx-cli 读取数据
• wx-cli 并不是 baoyu-skills 的一部分
• Skill 不负责配置 wx-cli
• 两个项目的其他功能没有关联

这个边界要记清楚。遇到登录、权限、数据读取失败等问题，应该去看 wx-cli 的项目文档，而不是在 Skill 里盲目排查。

项目地址

• baoyu-skills：https://github.com/JimLiu/baoyu-skills
• wx-cli：https://github.com/jackwener/wx-cli

wx-cli 的具体安装和配置方式，请以项目文档为准。不同环境下，登录方式、数据权限和命令参数可能会变化，直接照搬别人文章里的命令，很容易卡在环境配置这一步。

使用前要准备什么

咱们可以把准备工作拆成三层。

1. 能正常使用 Claude Code

你需要先确保 Claude Code 可以正常运行，并且能加载 baoyu-skills 中的相关 Skill。

如果 Claude Code 本身无法调用模型，或者 Skill 没有被正确识别，后面的聊天读取也没有意义。

建议先做一个最小检查：

请确认当前环境是否已经加载微信群聊总结 Skill。
如果没有加载，请告诉我缺少哪一步配置。

别一上来就处理几千条消息。先确认工具链能工作，排错会轻松很多。

2. 配置好 wx-cli

wx-cli 需要按照它自己的项目文档完成配置。

这里不适合凭空写一套固定命令，因为实际参数取决于项目当前版本和你的运行环境。你需要重点确认：

• 是否已经完成登录或授权
• 是否能读取目标微信群
• 是否有访问历史消息的权限
• 命令行能否返回可供模型处理的聊天内容
• 输出是否包含时间、发送者和消息正文

可以先单独验证数据读取：

请使用 wx-cli 读取指定微信群最近一段时间的聊天记录。
先只展示读取结果，不要总结。

如果连原始数据都拿不到，问题在 wx-cli 配置或权限，不在总结 Skill。

3. 选对模型

目前更推荐使用：

• Claude Code
• Claude Opus 4.6

微信群聊的难点不在于把句子缩短，而在于判断上下文。模型需要识别：

• 谁是在提问
• 谁是在回应
• 哪个说法被后续消息推翻
• 临时建议有没有变成正式决定
• 同一个问题是否被多人重复讨论

长对话、多人发言、上下文跳跃较多时，模型的上下文理解能力会直接影响结果质量。

推荐的实际操作流程

第一步：限定群聊和时间范围

不要一上来读取整个群的所有历史消息。

你可以限定：

• 群名称
• 起止日期
• 最近多少条消息
• 只关注某个主题
• 是否包含图片、文件和链接消息

示例：

请总结“项目协作群”中 2026 年 2 月 10 日至 2 月 12 日的聊天记录。
重点关注版本发布、接口进度、测试问题和客户新增需求。

范围越明确，结果越容易核对。一次处理一个时间窗口，也更不容易遇到输出过长的问题。

第二步：明确你想要的输出格式

只说“帮我总结一下”，模型可能会给你一段看起来流畅、实际不太能执行的文字。

建议直接指定结构：

请按以下结构输出：

1. 一句话结论
2. 讨论主题
3. 已确认事项
4. 尚未解决的问题
5. 待办事项：负责人、动作、截止时间
6. 重要分歧
7. 关键链接
8. 需要我继续确认的内容

无法从聊天记录确认的信息，请标记为“未明确”，不要猜测。

这句“不要猜测”很重要。群聊里经常出现“应该可以”“晚点看看”“我觉得没问题”这种表达。它们是态度，不是承诺。

第三步：要求区分事实和推测

总结最怕把推测写成结论。

可以补充这样的要求：

请区分以下内容：
- 已明确确认的事实
- 参与者提出的建议
- 尚未得到回应的问题
- 根据上下文推断出的可能风险

推断内容必须单独放在“待确认”部分。

这样整理出来的结果，更适合发给没参加讨论的人，也方便负责人逐项确认。

第四步：让模型生成行动清单

一份总结如果只有“大家讨论了什么”，价值有限。真正省时间的是行动清单。

推荐要求它输出表格：

| 事项 | 负责人 | 截止时间 | 当前状态 | 依据 |
|---|---|---|---|---|
| 修复登录失败问题 | 张三 | 未明确 | 待处理 | 2 月 11 日 14:20 的消息 |
| 提供后端接口 | 李四 | 2 月 12 日 | 进行中 | 2 月 10 日 09:15 的消息 |
| 确认今晚是否上线 | 未明确 | 未明确 | 待确认 | 群内存在不同说法 |

如果负责人或截止时间没有在聊天中出现，就写“未明确”。别替群成员补名字，也别把“我来看看”自动理解成正式负责人。

一份可直接使用的提示词

你可以把下面这段交给 Claude Code，再根据实际情况替换群名和时间：

请使用微信群聊总结 Skill，读取“目标群名称”在“开始时间”至“结束时间”之间的聊天记录。

请完成以下工作：

1. 用 3 句话概括本次群聊的核心结论。
2. 按主题整理讨论内容，合并重复消息。
3. 区分已确认事项、建议、争议和未解决问题。
4. 提取所有任务，并列出负责人、截止时间、状态和原始消息时间。
5. 标记可能影响项目进度的风险。
6. 提取值得保留的链接、文件和关键信息。
7. 对没有明确负责人或截止时间的事项标记“未明确”。
8. 不要根据常识补充聊天记录中没有出现的内容。
9. 对存在多种理解的内容，列出原始语境并标记“待确认”。

输出使用 Markdown，内容简洁，方便直接转发给项目成员。

常见问题和排查思路

读不到聊天记录

先单独检查 wx-cli。

确认登录状态、群权限和历史消息读取能力。不要先修改 Skill，也不要反复调整提示词。数据没有进入模型，提示词写得再好也没用。

总结遗漏了关键信息

可以尝试：

• 缩小时间范围
• 按主题分批处理
• 保留发送者和时间信息
• 明确要求提取数字、日期、链接和任务
• 要求模型输出“未提及但可能需要确认的事项”

聊天记录特别长时，分段处理往往比一次性塞进去更稳定。处理完多个时间段后，再让模型合并结果。

把聊天中的玩笑当成决定

提示词里加入判断规则：

只有在明确确认、多人达成一致，或有人明确表示已经执行时，才归入“已确认事项”。
玩笑、反问、猜测和单人建议不能当作正式决定。

这类规则对项目群、客户群尤其重要。否则一句“那就今晚发吧”，可能被总结成已经确定上线。

任务没有负责人

不要让模型猜。

统一使用“负责人未明确”，并把对应消息时间列出来。这样你可以直接回群里追问，而不是拿着一份看似完整、实际虚构的任务表继续推进。

输出太长，没人愿意看

给总结加上长度限制：

控制在 800 字以内。
将细节放入折叠式的“补充信息”部分。
核心结论和待办事项放在最前面。

群聊总结的读者通常很忙。他们想知道“发生了什么”和“我需要做什么”，不是重新阅读一遍聊天记录。

避坑清单

• 不要把 baoyu-skills 和 wx-cli 当成同一个项目
• 不要根据旧教程猜测 wx-cli 的安装命令
• 不要在还没验证数据读取时直接调试总结效果
• 不要一次处理无限期的群聊历史
• 不要把建议、玩笑和猜测写成确定结论
• 不要让模型自动补全负责人和截止时间
• 不要只要求“写一段总结”，要指定结构和判断标准
• 不要忽略消息时间，时间线经常决定结论是否成立
• 涉及敏感信息时，确认聊天数据的使用权限和保存位置
• 输出发给团队前，人工核对关键日期、金额、负责人和上线决定

这套流程的边界

微信群聊总结能帮你快速压缩信息，但它不能替团队做决策。

模型可以发现讨论重点，整理任务线索，标记冲突内容。最终的负责人、截止时间、上线安排和客户承诺，仍然需要人确认。

更稳妥的做法是：

1. 让工具生成初版总结
2. 人工核对关键结论
3. 把“待确认”事项发回群里
4. 根据群内回复更新任务表
5. 将确认后的版本作为正式记录保存

这样，群聊不再只是消息堆，而会变成一份可以追踪的工作记录。