原研究时间：2026-10-06；2026-10-13 核对修订。项目：freestylefly/WeChatBridge，MIT；维护者与上游来源按仓库自述记录。
一句话定性
它是一个 macOS 分享桥梁：接收微信主动导出的聊天归档，再送到目标应用或本地知识库。当前提供 12 个分享入口，不是 12 个 AI Agent。
七个入口对应 Codex、Claude、豆包、千问办公、WorkBuddy、WeSight、DeepSeek Harness；其余是 Obsidian、文件夹、分批收集、剪贴板和自定义目标。它不读微信数据库、不注入微信进程，这让获取范围更容易理解；但系统分享机制不等于腾讯授予第三方任何使用权，也不自动证明数据处理合规。
像一座由用户决定通向哪里的文件桥：桥只接你选中的包，包里有没有客户隐私、到岸后是否上传云端，仍得分别检查。它不是“苹果官方配件认证”的类比。
关键事实
- 仓库身份：freestylefly/WeChatBridge，README 致谢上游 qzz0518/Dukou。
- 平台：README 要求 macOS 14+；源码使用 Swift 6，另有 .NET WPF 的 Windows 目录。存在代码不等于两端功能已同等验收。
- 输入条件：项目描述微信 macOS 4.1.13 起的“合并转发”可生成含 TXT 和媒体的 ZIP，具体客户端表现仍需核对。
- 许可：MIT LICENSE，保留版权与许可通知，包括上游署名；不授权第三方聊天内容、商标或模型服务使用。
- 分发：README 自述 0.1.15 DMG 已 Developer ID 签名并公证，本文未下载验证二进制。公证不等于微信授权或隐私认证。
- 文档差异：PRODUCT_CAPABILITIES 写有 Homebrew 分发，但 README 路线图仍将 Homebrew Cask 列为未完成，不把它写成已核实渠道。Sparkle 已配置，README 明确尚未启用自动检查。
- 删除过期 stars、forks、followers、仓库体积与增速排名；不凭账号资料认证作者身份、公司关系或商业化计划。
逻辑全景图
├─ 触发层：用户多选 → 微信生成聊天归档 → 选择分享入口
├─ 核心层
│ ├─ Share Extension：沙盒内接收文件
│ ├─ Inbox：Staging 暂存，原子提交到 Ready
│ ├─ 主应用：消费一次性 intent、选择目标和场景
│ ├─ Scene：这次说什么
│ └─ Skill：兼容 Agent 按什么能力包处理
├─ 输出层
│ ├─ 剪贴板和目标应用粘贴动作
│ ├─ Obsidian / 文件夹中的 Markdown 与原始归档
│ └─ 本地批次状态与历史
└─ 卡点层
├─ 系统扩展注册、权限和窗口焦点
├─ 目标应用是否接受文件以及实际是否收到
├─ ZIP、笔记、剪贴板和历史的留存
└─ 目标模型服务的外发、访问与保留规则
核心创新：Share Extension + 场景/技能双层（值得抄的设计）
Inbox.swift描述用一次 rename 从 Staging 提交到 Ready，避免主应用提前消费半成品批次。manifest 与应用状态分开写；产品文档描述 intent 消费后不重复执行、超过 90 秒则过期，目标是避免迟到的粘贴突然落到当前窗口。它不是整个处理任务 90 秒内必定完成的保证。
还有一个容易误读的状态：在 BatchState.swift 中，转发路径的 delivered 表示“激活目标 App 并执行粘贴”。这不是目标应用回执，更不是模型已读取、理解或发送完成；Obsidian 的本地写入又是另一种结果。需要在目标端核对附件、提示词与会话位置。
不用“我们更合规”代替机制比较
| 维度 | 本地数据库读取路线 | 微信流分享路线 |
|---|---|---|
| 输入 | 数据库与可能的密钥获取 | 用户主动导出的文件 |
| 范围控制 | 看具体查询与实现 | 看用户选择的消息及导出包 |
| 依赖 | schema、加密、客户端布局等 | 分享菜单、归档格式、系统扩展及目标应用 |
| 共同检查 | 数据权限、留存、外发和平台规则 | 数据权限、留存、外发和平台规则 |
不写“注入必封”“微信流低风险”“微信发版即崩”或“对比表强 10 倍”。这些都缺少本次一致的对照证据；主动操作也不表示可以转发任何群聊或客户资料。
5 条隐私设计与真实边界
- 输入来自用户导出，不靠后台遍历数据库；导出包仍可能包含群友及客户信息。
- 分享扩展无网络 client entitlement：entitlements 原文有沙盒与共享目录权限。这只描述扩展，不保证主应用、目标 Agent、浏览器或备份没有网络行为。
- 归档与记录保存在本机，不能误写成“不落盘”。Obsidian 或文件夹也可能受同步软件管理。
- 按功能给权限：自动粘贴需要辅助功能，识别聊天名需要屏幕录制；先走手动复制路线不必提前授予这两项。
- App Group 管共享目录，是一种本地通信机制，不是内容加密、目标端授权或无限期保密证明。
升级路线图（三段位）
入门段（先验收一个窄流程）
从官方 Releases 核对版本与发布材料。先用无敏感信息的自有样本，启用“复制到剪贴板”，手动检查 ZIP、TXT 和媒体是否完整。再按实际需要开启自动粘贴或聊天名识别权限，不承诺半小时装好，也不要求一开始就授予屏幕录制。
进阶段（配置场景+技能）
用 Scene 保存本次分析目的，核对兼容 Agent 的 Skill 安装范围与内容。账号、目录与数据用途都确认后，再试 Obsidian 或选定文件夹。分批收集是多次手动分享后合并管理，微信每批多选上限保持不变，不能称为突破限制。
高手段（拆开学设计）
研究扩展与主应用的写入职责、原子批次、一次性 intent、失败兜底及目标端验收。读 Windows 共享契约和测试代码时，分开记录“有实现”“测试记录”“真实客户端适配”。签名、公证、DMG、更新源与 Homebrew 的实际发布状态也分别核查，不拼成一条已完成的分发链。
场景迁移
底层逻辑是：用户选择文件 + 系统分享入口 + 明确目的 + 目标端确认。这是一种应用间工作流模式，不是通用合规模板。
场景 ①：邮件 / Slack / Notion / 飞书 → AI Agent
可借鉴分享桥，但每个应用的导出能力、附件格式、接口授权和服务条款不同，不能保证替换输入就覆盖所有应用。内容进入 Agent 前先核对处理目的和接收方。
场景 ②：企业内部的内容聚合
内部目标可以减少某些随意外发，但“内部网关”也不等于本地模型或零出域。应核对认证、模型上游、日志、保留与审计；签名和部署方式由组织环境决定，不写“只能用某种证书”的统一法律规则。
场景 ③：自己的 macOS 分享工具
借鉴 Inbox 契约、场景/能力分层和状态命名，复用代码时遵守 MIT 与上游通知。不要把 pluginkit 当作绕过沙盒的办法，也不要拿 UI 中“已送达”替代真实接收确认。
部署/借鉴的好处、注意事项、风险
好处
输入范围可见、用户主动触发、提示词与能力包分离、半成品不提前消费、失败留有手动路径。它们是可检查的工程安排，比笼统的“合规姿态极佳”更有用。
注意事项
系统版本、微信归档格式、扩展注册、目标 App 和窗口焦点都会影响流程。辅助功能及屏幕录制是较宽的系统权限，即使项目自述用途有限，也应按需要开启并可撤销。剪贴板中保留文件不代表文件永远可用，也不能当备份。
风险
聊天归档、场景、历史、知识库和模型会话可能各留一份。发给外部 Agent 后要查其上传/留存规则，不能因为分享扩展不联网就宣称全程不外发；含商业秘密或个人信息的内容，还要确认数据主体、组织和接收方的处理权限。
与我相关的判断（可借鉴点）
- 选择性输入比默认读全库更容易限定范围，但仍需检查包内内容。
- Scene 管目的，Skill 管处理方式，两层分开。
- 原子批次与一次性 intent 处理可靠性，不替代权限和数据验证。
- 状态名要贴合实际动作：已尝试粘贴不等于收到回执。
- 发布文档互相矛盾时保留差异，不凭宣传补齐商业化故事。
与前五个项目的对比
不再按未经同期核查的 stars、作者身份或“合规姿态”排名。真正值得比较的是：数据从哪来、谁选择、写到哪、是否触发外部动作，以及如何确认结果。微信流的特色在主动导出后的应用间投递，不是合法性评分更高。
一句话总结
WeChatBridge 的灵魂是“把主动选中的归档送到合适的工具”。值得借鉴的是分享与批次机制，而不是把系统集成、公证或免责声明当成授权保证。
附录：相关链接
2026-10-13 资料核对说明： 实际读取官方 README、LICENSE、产品能力文档、分享扩展 entitlements、Inbox.swift 与 BatchState.swift。已注明 Homebrew 文档冲突和 delivered 的代码含义；未下载验签、公证校验、构建运行、授权系统权限或向任何 Agent 转发消息。