1. 为什么我要折腾微信收藏导出这件事微信收藏夹是个很微妙的东西。你肯定也有这种体验刷公众号看到一篇好文章顺手点个收藏想着以后有空再看群里有人分享了一份干货文档收藏朋友圈看到一段有启发的观点收藏。三年下来收藏夹里躺了几百上千条内容但真正回头翻看的次数一只手数得过来。问题不在于收藏这个动作而在于收藏之后没有任何后续处理。微信收藏本质上是个黑洞——进去容易出来难。它不提供批量导出功能不支持全文检索只能搜标题更不可能帮你做知识关联。你收藏的越多这个黑洞就越深最后变成一堆永远不看的数字垃圾。我自己的收藏夹在巅峰时期有将近800条内容包括公众号长文、聊天记录里的PDF、图片笔记、语音片段。某天我想找一篇关于RAG知识库架构的文章明明记得收藏过但在微信里翻了二十分钟愣是没找到。那一刻我决定必须把这些东西弄出来做成一个真正能用的知识库。这个项目的核心目标就三件事一次性把微信收藏的内容全部导出到本地用AI自动完成分类、摘要和标签提取把整理好的内容接入一个可检索的知识库系统。做完之后我找东西的效率至少翻了五倍——以前靠记忆翻收藏夹现在直接语义搜索输入一句话就能定位到相关内容。适合谁来参考这篇经验如果你满足以下任意一条接下来的内容应该对你有用收藏夹超过200条且从来没整理过正在搭建个人知识库但苦于没有素材来源对AI辅助信息整理感兴趣想找个实际场景练手或者单纯就是受够了微信收藏的搜索功能。2. 整体方案设计与技术选型思路2.1 为什么不用现成的导出工具市面上确实有一些微信收藏导出的小工具但我试过几个之后都放弃了。原因很直接大部分工具要么只支持导出标题和链接正文拿不到要么导出格式混乱图片和文字分离要么需要你把微信账号密码交给第三方这个我绝对不接受。还有一个关键问题是这些工具导出完就结束了不会帮你做任何后续整理——你还是得到一堆散乱的HTML文件。所以我的思路是自己搭一条流水线导出 → 解析 → AI整理 → 入库。每个环节用最合适的工具数据全程在本地流转不经过任何第三方服务器。2.2 整体架构长什么样整条流水线分四个阶段采集阶段从微信收藏中提取原始内容包括文字、图片、链接和文件解析阶段把各种格式的内容统一转成结构化文本Markdown为主AI处理阶段调用大模型做摘要、分类、标签提取和关键概念抽取入库阶段把处理好的内容写入知识库系统支持全文检索和语义搜索每个阶段的技术选型逻辑不太一样下面分别说。2.3 采集方案的选择为什么走半自动路线微信收藏的采集是最麻烦的一环。纯自动化的方案理论上可行但实际操作中坑太多。微信的本地数据库是加密的解密需要拿到密钥而且不同版本的加密方式还有差异。我试过在Mac上定位微信的本地存储目录收藏内容的数据库文件确实能找到但解密过程涉及一些底层操作稳定性和可维护性都不太好。最终我采用的是一种半自动方案利用微信自带的导出到电脑功能PC端微信支持把收藏内容逐条转发到文件传输助手配合一些自动化脚本做批量处理。具体来说在PC端微信里把收藏内容批量转发到文件传输助手然后用脚本监听文件传输助手的本地缓存目录自动抓取新出现的文件。这个方案的好处是不需要破解任何加密不违反任何使用条款稳定性极高。缺点是第一次操作需要手动批量转发大概花20分钟处理800条但这是一次性的后续新增收藏可以增量处理。注意批量转发时建议分批操作每批50条左右。一次性转发太多容易触发微信的频率限制导致部分内容转发失败。2.4 AI处理环节为什么选本地模型加云端API混合方案AI整理这块我一开始想全部用云端API比如GPT-4或者Claude效果确实好但成本是个问题。800条内容每条平均1500字全部做摘要加标签提取token消耗量不小。后来我改成混合方案摘要和标签提取用云端API因为这两项对模型理解能力要求高本地小模型效果差太多文本清洗和格式转换用本地规则引擎加小模型这部分任务简单没必要浪费API调用分类先用本地模型做粗分类比如分成技术产品生活行业几大类再对边界模糊的内容调用云端API做精细分类这样整体成本能降低60%左右效果几乎没有损失。2.5 知识库系统的选型对比知识库系统这块我对比了几个主流方案方案优势劣势适合场景Obsidian本地存储、插件丰富、Markdown原生语义搜索需要额外配置个人知识管理Dify自带RAG流水线、可视化编排资源占用较高团队知识库自建RAG完全可控、可定制开发成本高有技术能力且需求特殊我最终选了Obsidian作为主力知识库配合一个轻量的RAG服务做语义搜索。原因是我大部分时间离线工作Obsidian的本地优先特性很契合我的习惯。RAG服务只在需要语义搜索时启动平时不占资源。3. 核心细节解析与实操要点3.1 微信收藏内容的实际结构长什么样在动手之前你得先搞清楚微信收藏里到底存了哪些类型的内容。我实际统计了自己800条收藏分布如下公众号文章链接约55%纯文字笔记约15%图片截图、保存的图片约12%文件PDF、Word、Excel约10%语音约5%视频约3%不同类型的内容导出和处理方式完全不同。公众号文章需要抓取正文图片需要OCRPDF需要提取文本语音需要转写。这就是为什么一键导出的工具往往不好用——它们通常只处理其中一两种类型。3.2 公众号文章正文抓取的几个关键点公众号文章是收藏里占比最大的部分也是最容易出问题的环节。直接请求文章链接大概率会返回一个请在微信客户端打开的提示页。这是因为微信对文章页面做了UA检测。解决思路是模拟微信内置浏览器的请求头。具体来说需要在HTTP请求中设置特定的User-Agent字符串让它看起来像是从微信客户端发起的请求。常见的做法是设置UA为包含MicroMessenger标识的字符串。import requests headers { User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 MicroMessenger/8.0.30(0x18001e2f) NetType/WIFI Language/zh_CN, Referer: https://mp.weixin.qq.com/, } resp requests.get(article_url, headersheaders, timeout15)设置好请求头之后大部分公众号文章都能正常返回HTML。接下来用解析库提取正文内容。公众号文章的HTML结构比较规范正文通常在div idjs_content里面。用BeautifulSoup或者lxml都能轻松提取。但有几个坑要注意图片懒加载公众号文章里的图片真实地址存在>你是一个知识管理助手。请对以下内容进行处理 1. 生成一段不超过150字的摘要概括核心观点 2. 提取3-5个标签每个标签不超过6个字 3. 判断内容属于以下哪个分类技术/产品/行业/生活/其他 4. 提取文中提到的关键概念或工具名称如果有 要求 - 摘要要具体不要用本文介绍了这种空话 - 标签要能用于检索避免太泛的词如知识学习 - 如果内容质量太低比如只有一句话分类填其他摘要写内容过短 内容如下 {content}这个Prompt的关键在于明确输出格式、给出反例比如避免太泛的词、处理边界情况内容过短怎么办。不加这些约束AI的输出会非常飘。3.5 知识库的目录结构设计内容整理好之后怎么组织目录结构直接影响后续的检索效率。我试过几种方案最终确定的是分类 时间的二级结构knowledge-base/ ├── 技术/ │ ├── 2024-01/ │ ├── 2024-02/ │ └── ... ├── 产品/ ├── 行业/ ├── 生活/ └── 其他/每条内容的文件名格式是{日期}-{摘要前20字}.md。文件内部的frontmatter包含完整元数据--- title: 原文标题 source: 微信收藏 date: 2024-03-15 tags: [RAG, 知识库, 向量检索] category: 技术 original_url: https://... ---这样组织的好处是Obsidian的Dataview插件可以直接查询frontmatter比如列出所有带RAG标签的文章或者统计每个月收藏的技术文章数量。4. 完整实操流程与关键环节实现4.1 第一步批量导出微信收藏打开PC端微信进入收藏面板。全选需要导出的内容CtrlA然后右键选择转发。在弹出的联系人列表里选择文件传输助手确认发送。这一步的注意事项每次转发不要超过50条否则容易失败转发完成后在文件传输助手里检查是否有遗漏图片和文件会以文件形式发送文字和链接会以消息形式发送转发完成后微信的文件传输助手会在本地缓存目录生成对应的文件。Mac上的路径通常在~/Library/Containers/com.tencent.xinWeChat/Data/Library/Application Support/com.tencent.xinWeChat/下面具体版本号目录需要自己找一下。Windows上在Documents\WeChat Files\下面。4.2 第二步解析和格式统一写一个Python脚本遍历缓存目录根据文件类型分别处理import os import json from pathlib import Path def process_cache_dir(cache_dir): results [] for file_path in Path(cache_dir).rglob(*): if file_path.suffix in [.html, .txt]: # 文字和链接类 content extract_text_content(file_path) results.append({type: text, content: content}) elif file_path.suffix in [.jpg, .png]: # 图片类走OCR text ocr_image(file_path) results.append({type: image, content: text}) elif file_path.suffix .pdf: # PDF类 text extract_pdf_text(file_path) results.append({type: pdf, content: text}) return results对于公众号文章链接需要额外做一步正文抓取。我维护了一个待抓取链接列表脚本会逐个请求并提取正文失败的链接记录下来稍后重试。4.3 第三步AI批量处理把解析好的内容分批送给AI处理。我用的并发数是5太高容易触发API的速率限制。每批处理完后把结果写入一个JSON文件方便断点续传。import asyncio import aiohttp async def process_batch(items, semaphore): async with semaphore: prompt build_prompt(items) result await call_ai_api(prompt) return parse_ai_response(result) async def main(): semaphore asyncio.Semaphore(5) tasks [process_batch(item, semaphore) for item in all_items] results await asyncio.gather(*tasks) save_results(results)处理800条内容用GPT-4o大概花了40分钟成本在3美元左右。如果用GPT-4o-mini成本能降到0.5美元以下但摘要质量会差一些。4.4 第四步生成Markdown文件并入库AI处理结果拿到后生成Markdown文件写入Obsidian的vault目录def generate_markdown(item, ai_result): frontmatter f--- title: {item[title]} source: 微信收藏 date: {item[date]} tags: {ai_result[tags]} category: {ai_result[category]} --- body f## 摘要\n\n{ai_result[summary]}\n\n## 原文\n\n{item[content]} return frontmatter body写入完成后Obsidian会自动索引这些新文件。全文搜索立刻就能用。4.5 第五步配置语义搜索Obsidian自带的搜索是关键词匹配搜向量数据库找不到只写了vector DB的文章。要支持语义搜索需要额外配置。我用的方案是Obsidian的Smart Connections插件它会在本地生成文本嵌入向量支持语义相似度搜索。配置步骤在Obsidian社区插件里搜索并安装Smart Connections在插件设置里选择嵌入模型我用的是本地的all-MiniLM-L6-v2轻量且效果够用等待插件对所有笔记生成嵌入800条大概需要15分钟之后就可以用自然语言搜索了比如输入怎么把文章变成向量存起来能找到讲RAG架构的文章5. 常见问题与排查技巧实录5.1 导出环节的典型问题问题一转发到文件传输助手后部分内容丢失。这个通常是因为一次性转发太多触发了限制。解决办法是分批操作每批不超过50条。如果已经丢失了检查收藏夹里哪些内容没有对应的转发记录重新转发即可。问题二图片在传输过程中被压缩OCR识别率下降。微信传输图片时会自动压缩。如果原图很重要建议在转发前先保存到相册然后通过文件方式发送而不是图片方式。文件方式不会压缩。问题三公众号文章抓取返回环境异常。这是触发了微信的反爬机制。解决办法是降低请求频率每次请求间隔3-5秒并且定期更换User-Agent字符串。如果某个链接反复失败可以手动在浏览器里打开复制正文内容。5.2 AI处理环节的典型问题问题一AI返回的摘要太笼统。比如本文介绍了一种技术方案这种废话。解决办法是在Prompt里明确要求摘要必须包含具体的技术名称或方法名称并给出好的示例和坏的示例。问题二标签重复或过于相似。比如同时出现RAG和检索增强两个标签。解决办法是在Prompt里加一条如果两个标签表达同一概念只保留最常用的那个。问题三处理到一半API额度用完了。这个靠断点续传机制解决。每处理完一批就写入结果文件重新运行时跳过已处理的条目。5.3 知识库使用环节的典型问题问题一Obsidian打开800个文件后变卡。解决办法是关闭不需要的插件特别是那些会实时扫描所有文件的插件。另外可以把不常用的分类目录排除在索引之外。问题二语义搜索的结果不准确。嵌入模型的选择很关键。all-MiniLM-L6-v2胜在轻量但对中文的支持一般。如果对搜索质量要求高可以换成text-embedding-3-small需要API或者bge-small-zh本地运行中文优化。问题三frontmatter格式错误导致Dataview查询失败。YAML对格式很敏感冒号后面必须有空格标签列表要用方括号。建议写一个校验脚本在写入前检查frontmatter格式。5.4 常见问题速查表问题现象可能原因解决方法转发后内容缺失触发频率限制分批转发每批≤50条文章抓取失败UA检测设置微信UA降低请求频率OCR识别率低图片被压缩用文件方式传输原图AI摘要太笼统Prompt约束不足增加具体性要求和示例语义搜索不准嵌入模型不适合中文换用中文优化的嵌入模型Obsidian卡顿插件过多关闭非必要插件6. 几个我踩过的坑和后来想明白的事6.1 不要追求一次性完美我一开始想做一个全自动的方案从导出到入库全部脚本化。结果在微信数据解密那一步卡了很久各种方案都试过稳定性始终不行。后来想明白了一次性手动操作20分钟换来后续全自动这个投入产出比完全可以接受。没必要为了追求100%自动化在一个不稳定的环节上死磕。6.2 内容质量比数量重要导出800条内容后我发现大概有15%是垃圾——比如随手收藏的表情包、只有一句话的笔记、已经失效的链接。这些内容如果全部塞进知识库反而会干扰检索。后来我加了一个过滤步骤AI处理时如果判断内容质量过低直接标记为低价值不写入知识库。6.3 标签体系要克制一开始我让AI自由生成标签结果800条内容产生了300多个不同的标签大部分只用了一两次。这种标签体系没有检索价值。后来我改成先让AI从预设的50个标签里选选不出来才生成新标签。这样标签数量控制在80个左右每个标签下都有足够的内容。6.4 定期增量比一次性整理更重要第一次整理完之后我又陆续收藏了新内容。如果每次都等积累到几百条再整理又会回到黑洞状态。所以我现在设置了一个每周提醒花10分钟把本周新增的收藏走一遍流水线。增量处理比批量处理轻松得多而且能保持知识库的时效性。6.5 知识库的价值在于用整理完知识库之后如果只是放在那里不检索、不引用那和放在微信收藏里没有本质区别。我现在养成了一个习惯写文章或做方案时先在自己的知识库里搜一圈看看之前收藏过什么相关内容。这个动作让知识库真正活了起来也让我对收藏的内容有了二次消化。最后分享一个小的自动化技巧我用Obsidian的Templater插件做了一个模板新建笔记时自动填入frontmatter框架和关联内容区块。关联内容区块会通过Dataview查询自动列出知识库中标签相似的其他笔记。这样每写一条新笔记都能自动和已有的知识建立连接知识库越用越厚。
1. 为什么我要折腾微信收藏导出这件事微信收藏夹是个很微妙的东西。你肯定也有这种体验刷公众号看到一篇好文章顺手点个收藏想着以后有空再看群里有人分享了一份干货文档收藏朋友圈看到一段有启发的观点收藏。三年下来收藏夹里躺了几百上千条内容但真正回头翻看的次数一只手数得过来。问题不在于收藏这个动作而在于收藏之后没有任何后续处理。微信收藏本质上是个黑洞——进去容易出来难。它不提供批量导出功能不支持全文检索只能搜标题更不可能帮你做知识关联。你收藏的越多这个黑洞就越深最后变成一堆永远不看的数字垃圾。我自己的收藏夹在巅峰时期有将近800条内容包括公众号长文、聊天记录里的PDF、图片笔记、语音片段。某天我想找一篇关于RAG知识库架构的文章明明记得收藏过但在微信里翻了二十分钟愣是没找到。那一刻我决定必须把这些东西弄出来做成一个真正能用的知识库。这个项目的核心目标就三件事一次性把微信收藏的内容全部导出到本地用AI自动完成分类、摘要和标签提取把整理好的内容接入一个可检索的知识库系统。做完之后我找东西的效率至少翻了五倍——以前靠记忆翻收藏夹现在直接语义搜索输入一句话就能定位到相关内容。适合谁来参考这篇经验如果你满足以下任意一条接下来的内容应该对你有用收藏夹超过200条且从来没整理过正在搭建个人知识库但苦于没有素材来源对AI辅助信息整理感兴趣想找个实际场景练手或者单纯就是受够了微信收藏的搜索功能。2. 整体方案设计与技术选型思路2.1 为什么不用现成的导出工具市面上确实有一些微信收藏导出的小工具但我试过几个之后都放弃了。原因很直接大部分工具要么只支持导出标题和链接正文拿不到要么导出格式混乱图片和文字分离要么需要你把微信账号密码交给第三方这个我绝对不接受。还有一个关键问题是这些工具导出完就结束了不会帮你做任何后续整理——你还是得到一堆散乱的HTML文件。所以我的思路是自己搭一条流水线导出 → 解析 → AI整理 → 入库。每个环节用最合适的工具数据全程在本地流转不经过任何第三方服务器。2.2 整体架构长什么样整条流水线分四个阶段采集阶段从微信收藏中提取原始内容包括文字、图片、链接和文件解析阶段把各种格式的内容统一转成结构化文本Markdown为主AI处理阶段调用大模型做摘要、分类、标签提取和关键概念抽取入库阶段把处理好的内容写入知识库系统支持全文检索和语义搜索每个阶段的技术选型逻辑不太一样下面分别说。2.3 采集方案的选择为什么走半自动路线微信收藏的采集是最麻烦的一环。纯自动化的方案理论上可行但实际操作中坑太多。微信的本地数据库是加密的解密需要拿到密钥而且不同版本的加密方式还有差异。我试过在Mac上定位微信的本地存储目录收藏内容的数据库文件确实能找到但解密过程涉及一些底层操作稳定性和可维护性都不太好。最终我采用的是一种半自动方案利用微信自带的导出到电脑功能PC端微信支持把收藏内容逐条转发到文件传输助手配合一些自动化脚本做批量处理。具体来说在PC端微信里把收藏内容批量转发到文件传输助手然后用脚本监听文件传输助手的本地缓存目录自动抓取新出现的文件。这个方案的好处是不需要破解任何加密不违反任何使用条款稳定性极高。缺点是第一次操作需要手动批量转发大概花20分钟处理800条但这是一次性的后续新增收藏可以增量处理。注意批量转发时建议分批操作每批50条左右。一次性转发太多容易触发微信的频率限制导致部分内容转发失败。2.4 AI处理环节为什么选本地模型加云端API混合方案AI整理这块我一开始想全部用云端API比如GPT-4或者Claude效果确实好但成本是个问题。800条内容每条平均1500字全部做摘要加标签提取token消耗量不小。后来我改成混合方案摘要和标签提取用云端API因为这两项对模型理解能力要求高本地小模型效果差太多文本清洗和格式转换用本地规则引擎加小模型这部分任务简单没必要浪费API调用分类先用本地模型做粗分类比如分成技术产品生活行业几大类再对边界模糊的内容调用云端API做精细分类这样整体成本能降低60%左右效果几乎没有损失。2.5 知识库系统的选型对比知识库系统这块我对比了几个主流方案方案优势劣势适合场景Obsidian本地存储、插件丰富、Markdown原生语义搜索需要额外配置个人知识管理Dify自带RAG流水线、可视化编排资源占用较高团队知识库自建RAG完全可控、可定制开发成本高有技术能力且需求特殊我最终选了Obsidian作为主力知识库配合一个轻量的RAG服务做语义搜索。原因是我大部分时间离线工作Obsidian的本地优先特性很契合我的习惯。RAG服务只在需要语义搜索时启动平时不占资源。3. 核心细节解析与实操要点3.1 微信收藏内容的实际结构长什么样在动手之前你得先搞清楚微信收藏里到底存了哪些类型的内容。我实际统计了自己800条收藏分布如下公众号文章链接约55%纯文字笔记约15%图片截图、保存的图片约12%文件PDF、Word、Excel约10%语音约5%视频约3%不同类型的内容导出和处理方式完全不同。公众号文章需要抓取正文图片需要OCRPDF需要提取文本语音需要转写。这就是为什么一键导出的工具往往不好用——它们通常只处理其中一两种类型。3.2 公众号文章正文抓取的几个关键点公众号文章是收藏里占比最大的部分也是最容易出问题的环节。直接请求文章链接大概率会返回一个请在微信客户端打开的提示页。这是因为微信对文章页面做了UA检测。解决思路是模拟微信内置浏览器的请求头。具体来说需要在HTTP请求中设置特定的User-Agent字符串让它看起来像是从微信客户端发起的请求。常见的做法是设置UA为包含MicroMessenger标识的字符串。import requests headers { User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 MicroMessenger/8.0.30(0x18001e2f) NetType/WIFI Language/zh_CN, Referer: https://mp.weixin.qq.com/, } resp requests.get(article_url, headersheaders, timeout15)设置好请求头之后大部分公众号文章都能正常返回HTML。接下来用解析库提取正文内容。公众号文章的HTML结构比较规范正文通常在div idjs_content里面。用BeautifulSoup或者lxml都能轻松提取。但有几个坑要注意图片懒加载公众号文章里的图片真实地址存在>你是一个知识管理助手。请对以下内容进行处理 1. 生成一段不超过150字的摘要概括核心观点 2. 提取3-5个标签每个标签不超过6个字 3. 判断内容属于以下哪个分类技术/产品/行业/生活/其他 4. 提取文中提到的关键概念或工具名称如果有 要求 - 摘要要具体不要用本文介绍了这种空话 - 标签要能用于检索避免太泛的词如知识学习 - 如果内容质量太低比如只有一句话分类填其他摘要写内容过短 内容如下 {content}这个Prompt的关键在于明确输出格式、给出反例比如避免太泛的词、处理边界情况内容过短怎么办。不加这些约束AI的输出会非常飘。3.5 知识库的目录结构设计内容整理好之后怎么组织目录结构直接影响后续的检索效率。我试过几种方案最终确定的是分类 时间的二级结构knowledge-base/ ├── 技术/ │ ├── 2024-01/ │ ├── 2024-02/ │ └── ... ├── 产品/ ├── 行业/ ├── 生活/ └── 其他/每条内容的文件名格式是{日期}-{摘要前20字}.md。文件内部的frontmatter包含完整元数据--- title: 原文标题 source: 微信收藏 date: 2024-03-15 tags: [RAG, 知识库, 向量检索] category: 技术 original_url: https://... ---这样组织的好处是Obsidian的Dataview插件可以直接查询frontmatter比如列出所有带RAG标签的文章或者统计每个月收藏的技术文章数量。4. 完整实操流程与关键环节实现4.1 第一步批量导出微信收藏打开PC端微信进入收藏面板。全选需要导出的内容CtrlA然后右键选择转发。在弹出的联系人列表里选择文件传输助手确认发送。这一步的注意事项每次转发不要超过50条否则容易失败转发完成后在文件传输助手里检查是否有遗漏图片和文件会以文件形式发送文字和链接会以消息形式发送转发完成后微信的文件传输助手会在本地缓存目录生成对应的文件。Mac上的路径通常在~/Library/Containers/com.tencent.xinWeChat/Data/Library/Application Support/com.tencent.xinWeChat/下面具体版本号目录需要自己找一下。Windows上在Documents\WeChat Files\下面。4.2 第二步解析和格式统一写一个Python脚本遍历缓存目录根据文件类型分别处理import os import json from pathlib import Path def process_cache_dir(cache_dir): results [] for file_path in Path(cache_dir).rglob(*): if file_path.suffix in [.html, .txt]: # 文字和链接类 content extract_text_content(file_path) results.append({type: text, content: content}) elif file_path.suffix in [.jpg, .png]: # 图片类走OCR text ocr_image(file_path) results.append({type: image, content: text}) elif file_path.suffix .pdf: # PDF类 text extract_pdf_text(file_path) results.append({type: pdf, content: text}) return results对于公众号文章链接需要额外做一步正文抓取。我维护了一个待抓取链接列表脚本会逐个请求并提取正文失败的链接记录下来稍后重试。4.3 第三步AI批量处理把解析好的内容分批送给AI处理。我用的并发数是5太高容易触发API的速率限制。每批处理完后把结果写入一个JSON文件方便断点续传。import asyncio import aiohttp async def process_batch(items, semaphore): async with semaphore: prompt build_prompt(items) result await call_ai_api(prompt) return parse_ai_response(result) async def main(): semaphore asyncio.Semaphore(5) tasks [process_batch(item, semaphore) for item in all_items] results await asyncio.gather(*tasks) save_results(results)处理800条内容用GPT-4o大概花了40分钟成本在3美元左右。如果用GPT-4o-mini成本能降到0.5美元以下但摘要质量会差一些。4.4 第四步生成Markdown文件并入库AI处理结果拿到后生成Markdown文件写入Obsidian的vault目录def generate_markdown(item, ai_result): frontmatter f--- title: {item[title]} source: 微信收藏 date: {item[date]} tags: {ai_result[tags]} category: {ai_result[category]} --- body f## 摘要\n\n{ai_result[summary]}\n\n## 原文\n\n{item[content]} return frontmatter body写入完成后Obsidian会自动索引这些新文件。全文搜索立刻就能用。4.5 第五步配置语义搜索Obsidian自带的搜索是关键词匹配搜向量数据库找不到只写了vector DB的文章。要支持语义搜索需要额外配置。我用的方案是Obsidian的Smart Connections插件它会在本地生成文本嵌入向量支持语义相似度搜索。配置步骤在Obsidian社区插件里搜索并安装Smart Connections在插件设置里选择嵌入模型我用的是本地的all-MiniLM-L6-v2轻量且效果够用等待插件对所有笔记生成嵌入800条大概需要15分钟之后就可以用自然语言搜索了比如输入怎么把文章变成向量存起来能找到讲RAG架构的文章5. 常见问题与排查技巧实录5.1 导出环节的典型问题问题一转发到文件传输助手后部分内容丢失。这个通常是因为一次性转发太多触发了限制。解决办法是分批操作每批不超过50条。如果已经丢失了检查收藏夹里哪些内容没有对应的转发记录重新转发即可。问题二图片在传输过程中被压缩OCR识别率下降。微信传输图片时会自动压缩。如果原图很重要建议在转发前先保存到相册然后通过文件方式发送而不是图片方式。文件方式不会压缩。问题三公众号文章抓取返回环境异常。这是触发了微信的反爬机制。解决办法是降低请求频率每次请求间隔3-5秒并且定期更换User-Agent字符串。如果某个链接反复失败可以手动在浏览器里打开复制正文内容。5.2 AI处理环节的典型问题问题一AI返回的摘要太笼统。比如本文介绍了一种技术方案这种废话。解决办法是在Prompt里明确要求摘要必须包含具体的技术名称或方法名称并给出好的示例和坏的示例。问题二标签重复或过于相似。比如同时出现RAG和检索增强两个标签。解决办法是在Prompt里加一条如果两个标签表达同一概念只保留最常用的那个。问题三处理到一半API额度用完了。这个靠断点续传机制解决。每处理完一批就写入结果文件重新运行时跳过已处理的条目。5.3 知识库使用环节的典型问题问题一Obsidian打开800个文件后变卡。解决办法是关闭不需要的插件特别是那些会实时扫描所有文件的插件。另外可以把不常用的分类目录排除在索引之外。问题二语义搜索的结果不准确。嵌入模型的选择很关键。all-MiniLM-L6-v2胜在轻量但对中文的支持一般。如果对搜索质量要求高可以换成text-embedding-3-small需要API或者bge-small-zh本地运行中文优化。问题三frontmatter格式错误导致Dataview查询失败。YAML对格式很敏感冒号后面必须有空格标签列表要用方括号。建议写一个校验脚本在写入前检查frontmatter格式。5.4 常见问题速查表问题现象可能原因解决方法转发后内容缺失触发频率限制分批转发每批≤50条文章抓取失败UA检测设置微信UA降低请求频率OCR识别率低图片被压缩用文件方式传输原图AI摘要太笼统Prompt约束不足增加具体性要求和示例语义搜索不准嵌入模型不适合中文换用中文优化的嵌入模型Obsidian卡顿插件过多关闭非必要插件6. 几个我踩过的坑和后来想明白的事6.1 不要追求一次性完美我一开始想做一个全自动的方案从导出到入库全部脚本化。结果在微信数据解密那一步卡了很久各种方案都试过稳定性始终不行。后来想明白了一次性手动操作20分钟换来后续全自动这个投入产出比完全可以接受。没必要为了追求100%自动化在一个不稳定的环节上死磕。6.2 内容质量比数量重要导出800条内容后我发现大概有15%是垃圾——比如随手收藏的表情包、只有一句话的笔记、已经失效的链接。这些内容如果全部塞进知识库反而会干扰检索。后来我加了一个过滤步骤AI处理时如果判断内容质量过低直接标记为低价值不写入知识库。6.3 标签体系要克制一开始我让AI自由生成标签结果800条内容产生了300多个不同的标签大部分只用了一两次。这种标签体系没有检索价值。后来我改成先让AI从预设的50个标签里选选不出来才生成新标签。这样标签数量控制在80个左右每个标签下都有足够的内容。6.4 定期增量比一次性整理更重要第一次整理完之后我又陆续收藏了新内容。如果每次都等积累到几百条再整理又会回到黑洞状态。所以我现在设置了一个每周提醒花10分钟把本周新增的收藏走一遍流水线。增量处理比批量处理轻松得多而且能保持知识库的时效性。6.5 知识库的价值在于用整理完知识库之后如果只是放在那里不检索、不引用那和放在微信收藏里没有本质区别。我现在养成了一个习惯写文章或做方案时先在自己的知识库里搜一圈看看之前收藏过什么相关内容。这个动作让知识库真正活了起来也让我对收藏的内容有了二次消化。最后分享一个小的自动化技巧我用Obsidian的Templater插件做了一个模板新建笔记时自动填入frontmatter框架和关联内容区块。关联内容区块会通过Dataview查询自动列出知识库中标签相似的其他笔记。这样每写一条新笔记都能自动和已有的知识建立连接知识库越用越厚。
