返回博客首页
客户需求、群聊结论、项目排期和文章链接常常都在微信里。难处不在于“把聊天记录发给 AI”，而在于别把无关隐私、过期结论和半句上下文一起送过去。一次好的转发，应该有明确的问题、最小必要的记录范围和可回查的输出。
WeChatBridge（微信流） 是一个开源 macOS 工具，接在微信原生“多选 → 合并转发 → 转发到其他应用”之后。项目文档显示，它可把主动选择的聊天归档交给 Codex、Claude Code、Obsidian 或剪贴板；项目称不会读取微信数据库、解密文件或注入微信进程。使用前仍应根据公司的数据制度判断哪些记录可以外发。
流程图：聊天记录先由人选取并脱敏，Agent 只生成待审草稿，确认后才进入 Obsidian 正式笔记库。
先选场景，再选聊天记录
不要从“把这个群总结一下”开始。先写清要得到什么：客户复盘、项目决策、待办清单、选题线索，还是个人知识笔记。场景不同，保留的信息和输出格式完全不同。
| 场景 | 选哪些消息 | 不要带什么 | 交付物 |
|---|---|---|---|
| 客户复盘 | 需求、承诺、异议、时间点 | 无关联系人和其他客户信息 | 需求、风险、待确认项、下一步 |
| 项目群爬楼 | 决策、负责人、截止日期、阻塞项 | 闲聊、表情刷屏、未证实传闻 | 决策日志与行动表 |
| 内容选题 | 链接、观点、案例、数据来源 | 无来源的结论和个人信息 | 选题卡与待核验来源 |
| 个人归档 | 自己需要复用的经验和文件 | 朋友隐私、支付和身份信息 | Markdown 笔记与标签 |
每次转发前问一句：如果这批记录被一个新同事看到，他能否理解背景？如果不能，补一行背景，而不是多塞三百条聊天。
四步把微信记录变成可用上下文
1. 在微信里主动多选，合并转发
只选与问题有关的连续片段。把关键附件、链接和上下两三条解释一起选上，避免 Agent 只看到一句“就这么定了”却不知道定了什么。
2. 转发前做一次 60 秒脱敏
替换账号、手机号、身份证明、地址、报价底线、内部链接和不该离开原群的附件。聊天里出现第三方姓名时，使用角色名即可：客户 A、供应商 B、同事 C。脱敏并不等于删除所有信息；要保留理解决策所需的时间、责任和约束。
3. 给转发加上“场景指令”
你收到的是【客户复盘】聊天记录。不要补充聊天中没有的事实。
请输出：
1. 客户已明确的需求；
2. 我方已承诺但尚未交付的事项；
3. 风险、矛盾与待确认问题；
4. 按负责人和日期排列的下一步。
每条结论后标注对应消息时间；无法确认的内容写【待确认】。
4. 人工复核后再存入 Obsidian
Agent 的输出适合当初稿。确认事实、补上链接和会议结果后，再存成笔记。笔记标题不要叫“微信记录 9.28”，要叫“客户 A｜报价与交付范围｜2026-09-28”。这样三个月后还能搜到。
三种提示词，直接复制
项目决策记录
把以下聊天整理成决策记录。只提取已明确同意或明确否决的内容。
输出表格：决策 / 依据 / 负责人 / 截止时间 / 证据消息时间。
把“有人提出但未决定”的内容放入待确认，不要写成结论。
群聊日报
这是今天的项目群聊天。删除寒暄、重复转发和无关内容。
按“已完成、进行中、阻塞、明日动作”输出；每项不超过 40 字。
涉及客户、价格、账号或隐私的内容只写角色与抽象描述。
Obsidian 知识笔记
把聊天记录改写成一篇 Obsidian Markdown 笔记。
包含：一句摘要、关键结论、来源链接、可复用方法、待核验项、相关标签。
保留附件文件名；不要把附件内容编造成结论。
标题必须描述主题、对象和日期。
先理解权限，再决定要不要开
项目文档列出的两个常见权限用途不同：辅助功能用于激活目标应用并粘贴；屏幕录制用于识别微信标题栏里的聊天名以匹配场景。入口打不开、目标应用未安装或自动粘贴失败时，归档会保留在剪贴板，可人工粘贴。权限不该为了方便一次性全开：只启用自己要用的分享入口，定期检查系统扩展和工具版本。
| 情况 | 先排查 | 兜底方式 |
|---|---|---|
| 分享入口没出现 | 应用内开关、macOS 共享扩展、重启微信 | 先用剪贴板转发 |
| Agent 只收到文件没收到指令 | 辅助功能权限、目标输入框焦点 | 手动粘贴场景指令 |
| 总结脱离上下文 | 选取片段太短或没有背景 | 补一行项目背景与问题 |
| 笔记难搜索 | 标题和标签太泛 | 标题写对象、主题、日期 |
给团队留一条红线
不要把整段历史聊天、整个微信群或“所有联系人”设成默认同步源。无论工具承诺本地处理还是云端处理，最小范围、场景指令、人工复核和可删除的归档都应该保留。聊天记录是上下文，不是事实数据库；重要结论仍要回到合同、项目文档、原始链接或负责人处确认。
把微信转发给 Codex 的价值，是少做复制粘贴和爬楼；把它存进 Obsidian 的价值，是下次需要时能找到经过整理的结论。前者解决输入，后者解决记忆，二者之间不能省掉判断。
入库之前，留下可追溯的证据
整理聊天不能只留“AI 总结”。每条知识笔记至少保留来源范围、消息时间、处理方式和复核人。没有原消息时间的说法，写成“待核验”；不同时点的相反结论要保留变更过程，不能把旧版本悄悄覆盖。
---
topic: 客户 A 的交付范围
source: 微信项目群；2026-09-24 14:00—2026-09-28 18:00
status: 待负责人复核
reviewer: 内容负责人
tags: [客户沟通, 交付范围]
---
# 客户 A｜交付范围｜2026-09-28
## 已确认
- 交付物：……（依据：09-28 15:42）
## 待确认
- 报价有效期：所选消息没有明确截止日。
## 下一步
- 负责人、动作、期限。
来源字段不意味着把全文复制进每篇笔记。需要回查时，可在受控目录保留脱敏后的导出，并记录文件名或内部链接；不应长期保存时，只留经过授权的结论和最小证据定位。给导出文件设置复审或删除日期。
给 Codex 的资料包先缩小权限
把精选、脱敏后的 Markdown 放进独立目录，不要把整个聊天备份或主目录开放给 Agent。第一轮先让它列出“有证据的问题”和“没有证据的问题”，第二轮才做总结。写回 Obsidian 时先生成待审草稿，人工确认后移到正式笔记库。模型误读反话或旧结论，错误也会停在草稿阶段。
检索提问要具体，例如“9 月最后一次确认的交付范围是什么？列出时间和相互冲突的消息”。合格答案包含结论、证据定位和不确定性；只有一段流畅叙述，不能算检索成功。
分享失败时按顺序排查
先确认微信分享的是主动选中的合并转发内容，再检查 macOS 分享扩展是否启用、目标应用是否安装并获得焦点。项目使用指南提供剪贴板兜底；使用时先在纯文本窗口预览，确认附件名、聊天人和敏感字段没有遗漏。图片或文件缺失，就回到原消息补充说明，不要让模型根据文件名猜内容。
一个完整例子：从“群里说过”到可复查的行动项
假设项目群里连续出现三句话：“演示版周五给”“先不要接支付”“客户还想看一下数据导出”。如果直接让 Agent 总结，它可能把三句话都写成已确定需求。更稳妥的做法是先补上下文：谁说的、是哪一个项目、前面有没有更改日期，以及“想看一下”是正式需求还是询问。然后只选这几条及其必要的前后消息，脱敏后再交给 Agent。
期望输出可以分三栏。第一栏“已确认”：演示版计划周五交付，但要注明是谁确认、消息时间和是否有后续改期。第二栏“明确排除”：本轮暂不接支付；如果只是某人的建议而非决策，仍应转入待确认。第三栏“待确认”：数据导出要展示到什么程度、谁负责答复、何时再决定。每一栏都留证据定位，这样负责人可以点回原群核对。它比一段漂亮的纪要更有用，因为下周开会时能直接回答“这个决定是谁定的”。
给归档设置最小保留期和复核触发点
不是每条聊天都值得永久入库。临时约时间、一次性验证码、支付信息、私人照片和与任务无关的第三方资料，通常不应进入知识笔记。已经进入暂存目录的导出，按项目制度决定保留期限；项目结束、客户撤回授权、人员离职或讨论结论被正式文档替代，都应触发一次复核。需要保留的内容也应限制谁能读取、谁能修改，以及谁有权分享给外部模型。
如果团队使用云端 Agent，还要核对账户的工作区、数据处理选项与允许上传的资料等级。工具是否“本地处理”只能说明某个步骤在哪里运行，不能自动证明后续粘贴、同步、备份和分享都符合团队要求。个人试用时也一样：先用自己的非敏感聊天做演练，确认输出里没有号码、地址或未授权附件，再把流程扩大到真实项目。
用三个问题验收这套知识库
一周后随机抽三篇笔记：第一，能否在 30 秒内通过对象、主题或标签找到；第二，能否根据消息时间回查至少一条关键结论；第三，发现结论过期时能否指出谁负责更新。如果任何一个问题答不上来，就先修笔记结构和归档规则，而不是继续向库里灌更多聊天。检索量不是目标，能复查、能更正、能删除才是可长期使用的资料库。
Sources: WeChatBridge repository, usage guide.
