把微信聊天记录直接交给 AI:WeChatBridge 让微信成为本地 AI 工作流入口
如果你经常使用微信进行工作,可能会遇到这样一个问题:
一段重要的聊天记录在微信群里。
里面可能有几十条文字、几张图片、几个文件,甚至还有视频和链接。你想把这些内容交给 AI 总结、分析或者继续处理,传统方式往往是:
复制聊天记录 → 整理内容 → 保存文件 → 打开 AI 工具 → 上传附件 → 再告诉 AI 应该怎么处理。
步骤很多,而且聊天上下文、图片和附件很容易在这个过程中丢失。
有没有一种更自然的方式?
直接在微信里选中聊天记录,然后把它“转发”给 AI。
这正是开源项目 WeChatBridge(微信流) 想解决的问题。
项目地址:GitHub – freestylefly/WeChatBridge
一、微信聊天记录,本身就是一种非常有价值的数据源
随着 AI Agent、个人知识库和本地 AI 工具的发展,一个越来越常见的工作流是:
把日常产生的信息交给 AI,再让 AI 帮我们整理、分析和沉淀。
而微信恰恰是很多人每天产生信息最多的地方之一。
工作群里的需求讨论、客户反馈、项目进展、技术资料、行业信息、朋友分享的文章……这些内容原本都散落在聊天窗口里。
问题并不在于“没有信息”,而在于:
信息很难离开微信,进入自己的 AI 工作流。
微信原生提供了“转发到其他应用”的能力,但系统的分享入口主要面向具备 Share Extension 的应用。
WeChatBridge 做的事情,可以理解成在微信和本地 AI 工具之间增加了一座桥:
微信聊天
↓
合并转发
↓
WeChatBridge
↓
AI Agent / Obsidian / 剪贴板 / 自定义应用
这样一来,微信聊天就不再只是“聊天记录”,而可以成为本地 AI 工作流的输入源。
二、它是怎么工作的?
WeChatBridge 并不是通过读取微信数据库来获取聊天内容,也不是通过注入微信进程的方式工作。
它利用的是 macOS 微信提供的一个比较自然的能力:
合并转发聊天记录。
在 macOS 微信 4.1.13 起,多选聊天记录后,可以使用“合并转发”。
微信会生成一个包含聊天内容的 ZIP 文件,其中可以包括:
- TXT 聊天文本
- 图片
- 视频
- 其他聊天附件
WeChatBridge 则通过 macOS Share Extension 接住这份内容。
整个流程非常简单:
① 微信中多选聊天记录
↓
② 点击“合并转发”
↓
③ 选择微信流中的目标
↓
④ WeChatBridge 接收聊天归档
↓
⑤ 转发给 AI / 保存到知识库 / 复制到剪贴板
最重要的一点是:
用户不需要先打开 WeChatBridge 主窗口。
目标入口可以直接出现在微信的“转发到其他应用”菜单中。
三、它真正解决的,其实是“AI 工作流入口”问题
从功能上看,WeChatBridge 像是一个微信文件转发工具。
但如果从工作流角度来看,它解决的是另一个问题:
如何让微信里的非结构化信息快速进入 AI Agent。
例如,你在一个项目群里看到几十条讨论。
以前可能需要人工整理:
微信
↓
复制聊天
↓
整理上下文
↓
复制图片
↓
下载文件
↓
打开 AI
↓
上传文件
↓
输入提示词
有了微信流之后,可以变成:
微信
↓
多选聊天
↓
合并转发
↓
发给 AI Agent
如果再结合场景提示词,甚至可以进一步变成:
项目群聊天
↓
选择“项目复盘”场景
↓
AI Agent
↓
总结讨论
提取待办
识别风险
整理决策
这也是这个项目比较有意思的地方:
它不是试图重新做一个聊天客户端,而是把微信变成 AI 工作流的一个输入节点。
四、内置多个 AI 和生产力工具入口
目前项目已经提供多个原生入口。
包括:
- Codex
- Claude
- 豆包
- 千问办公
- WorkBuddy
- WeSight
- Obsidian
- 剪贴板
- 自定义应用
因此用户可以根据自己的工作流选择目标。
例如:
方案一:直接交给 AI
微信群里讨论一个问题。
选择聊天记录 → 合并转发 → 发给 Codex / Claude。
AI 可以继续处理这些聊天内容。
方案二:沉淀到 Obsidian
如果这段聊天并不需要立即让 AI 处理,而是希望成为自己的长期知识资产,可以直接选择:
沉淀到 Obsidian。
项目会生成 Markdown 笔记,同时保存原始归档和相关附件。
于是微信中的一次讨论,就可以进入自己的本地知识库。
方案三:先进入剪贴板
如果暂时还不确定交给哪个应用,也可以先复制到剪贴板,再由用户手动处理。
这对于一些临时工作流尤其方便。
五、场景功能:让“转发给 AI”变得更有上下文
如果只是把聊天记录交给 AI,其实还不够。
因为同一批聊天记录,在不同场景下可能需要完全不同的处理方式。
比如:
项目群
总结讨论内容,提取决策、风险和待办事项。
客户群
提取客户需求、问题和后续跟进事项。
技术交流群
总结技术方案,并整理值得进一步研究的内容。
行业交流群
提取行业趋势、重要信息和潜在机会。
WeChatBridge 提供了“场景”机制。
用户可以为不同的场景保存提示词,并指定适用的 Agent。
这样,聊天记录本身只是输入,而场景则负责告诉 AI:
“你应该如何理解这些内容。”
这让简单的文件转发,逐渐变成了更加完整的 AI 工作流。
六、还有一个很有意思的设计:Skills
对于 AI Agent 用户来说,SKILL.md 已经成为一种常见的能力描述方式。
WeChatBridge 也提供了技能管理能力。
它的思路是:
聊天记录负责提供数据,Skill 负责提供处理能力。
例如,聊天中可能出现:
- 网页链接
- 视频
- 文档
- 图片
- 各种需要进一步解析的信息
如果 Agent 本身具备相应的 Skill,就可以进一步处理这些内容。
因此整个工作流可以形成:
微信聊天
│
├── 文本
├── 图片
├── 视频
├── 文件
└── 链接
↓
WeChatBridge
↓
场景 + Skill
↓
AI Agent
这实际上已经不只是“聊天记录转发”,而更接近一个本地 AI 信息入口。
七、为什么项目特别强调“本地”?
微信聊天记录本身具有很强的隐私属性。
因此,一个处理微信内容的工具,用户最关心的问题之一就是:
它到底有没有偷偷读取我的微信数据?
根据项目公开文档,WeChatBridge 的设计边界比较明确:
- 不读取微信数据库
- 不解密微信数据
- 不注入微信进程
- 不修改微信进程
- 聊天内容来自用户主动执行的合并转发
- 聊天归档、场景和记录保存在本机
- Share Extension 在 macOS 沙盒中运行,并没有网络权限
项目还说明,屏幕录制权限主要用于识别微信标题栏中的聊天名称;辅助功能权限则用于激活目标应用和执行粘贴。
这套设计体现出一个很明确的思路:
尽可能利用系统公开能力完成工作流,而不是通过侵入式方式获取微信数据。
对于本地 AI 用户来说,这一点尤其重要。
八、它其实很符合 macOS 的设计方式
WeChatBridge 是一个原生 macOS 项目。
技术栈主要包括:
- Swift 6
- Swift Package Manager
- macOS Share Extension
- App Sandbox
- Sparkle
- Swift Testing / XCTest
项目要求 macOS 14 Sonoma 或更高版本。
从项目结构也能看出比较清晰的模块划分:
Sources/
├── WeChatBridgeApp/
│ └── 主应用、设置、转发编排、权限管理
│
├── WeChatBridgeCore/
│ └── 批次、场景、归档、剪贴板等核心逻辑
│
└── WeChatBridgeShare/
└── macOS Share Extension
Resources/
└── 图标、Plist、entitlements、技能
Scripts/
└── 构建、安装、签名、发布
Tests/
└── 测试代码
这种结构也说明项目并不是简单的“脚本工具”,而是按照 macOS 原生应用的方式组织起来的。
九、安装也比较简单
如果只是普通用户,可以直接从 GitHub Releases 下载 DMG。
项目目前提供经过 Developer ID 签名和 Apple 公证的版本。
安装完成后,将应用拖入“应用程序”即可。
如果是开发者,也可以直接从源码构建:
git clone https://github.com/freestylefly/WeChatBridge.git
cd WeChatBridge
swift test
CONFIG=release Scripts/make-app.sh
项目还提供开发安装和预览脚本。
因此对于喜欢研究 macOS 自动化、Share Extension 或 AI Agent 工作流的开发者来说,这个项目也有一定的参考价值。
十、它和传统“聊天记录导出工具”有什么不同?
如果把 WeChatBridge 和传统的聊天记录导出工具放在一起看,会发现两者的目标并不完全一样。
传统工具通常关注:
如何把聊天记录保存下来。
而 WeChatBridge 更关注:
聊天记录保存下来以后,下一步去哪里?
这也是它比较有意思的地方。
它把整个过程拆成了几个阶段:
信息产生
↓
微信
↓
主动选择
↓
聊天归档
↓
WeChatBridge
↓
┌─────────────┐
│ AI Agent │
│ Obsidian │
│ 剪贴板 │
│ 自定义 App │
└─────────────┘
↓
处理 / 分析 / 沉淀
因此它更像是一个:
“微信 → 本地 AI / 知识库”的桥接层。
十一、对于 AI Agent 用户,它意味着什么?
过去我们使用 AI,往往是“打开 AI,再把资料交给 AI”。
但随着 Agent 的发展,工作方式正在逐渐变化:
信息在哪里产生,AI 就应该在哪里获得输入。
微信是信息产生的地方。
Obsidian 是知识沉淀的地方。
Codex、Claude 等则是处理信息的地方。
WeChatBridge 做的事情,就是把这些环节连接起来。
从这个角度来看,它可以被理解为一个非常轻量的本地自动化节点:
微信
│
▼
WeChatBridge
/ | \
/ | \
▼ ▼ ▼
AI 知识库 其他 App
它不需要重新定义微信,也不需要替代 AI。
它只是把原本割裂的几个环节连接起来。
十二、一个值得关注的方向:个人 AI 工作流
WeChatBridge 更值得关注的地方,也许并不是“能把微信转给 Claude”。
这种能力本身并不复杂。
真正值得关注的是它背后的工作流:
让个人每天产生的信息,可以低成本进入自己的 AI 和知识体系。
想象一下:
早上,微信群里出现一条行业新闻。
你不需要复制链接,也不需要重新整理。
直接转发。
AI 自动阅读上下文,并告诉你:
- 这条信息讲了什么
- 为什么值得关注
- 和过去的信息有什么关系
- 是否需要进一步研究
下午,项目群里讨论了一个技术问题。
再次转发。
AI 帮你:
- 总结讨论
- 提取结论
- 整理 TODO
- 记录关键决策
晚上,再把重要内容沉淀到 Obsidian。
久而久之,微信这个原本高度封闭的信息环境,就可以成为个人 AI 工作流的一个入口。
十三、项目当前状态
从仓库公开信息来看,WeChatBridge 已经具备比较完整的产品形态:
- macOS 14+
- Swift 6
- 微信原生合并转发接入
- 多个 AI Agent 入口
- Obsidian 本地归档
- 场景提示词
- Skill 管理
- 自定义应用
- 本地历史记录
- 中英文界面
- Universal 2 构建
- Developer ID 签名和公证
- DMG 发布
项目采用 MIT License 开源。
路线图中还包括 Homebrew Cask,以及更多社区场景和技能包。
结语:微信只是入口,真正的目标是信息流
如果只把 WeChatBridge 看成一个“微信聊天记录转发器”,可能会低估它的意义。
它真正有意思的地方在于:
把微信里的信息,从封闭的聊天窗口中释放出来,接入 AI Agent、个人知识库和本地自动化工作流。
过去:
微信里的信息 → 看完就过去了。
现在:
微信里的信息 → AI 处理 → 知识库沉淀 → 成为个人长期资产。
而 WeChatBridge 做的,就是中间那座桥。
对于正在使用 AI Agent、Obsidian 和本地自动化工具的人来说,这种“从信息产生地直接进入 AI 工作流”的思路,或许比单纯增加一个新 AI 客户端更加值得关注。
信息不应该只停留在聊天窗口里。
它还可以成为下一次思考、下一次决策,以及下一次 AI 工作流的输入。
项目地址:
freestylefly/WeChatBridge
许可证: MIT License
系统要求: macOS 14 Sonoma 或更高版本