76.2 萬條微信全導出來餵給 AI：最難的壓根不是 AI

先說結論：這件事我做成了。76.2 萬條消息、3675 萬字，全部落進一個本地庫裏，現在我可以問它任何問題。但我花了三天，其中兩天不是在跟 AI 較勁，是在跟「怎麼把數據拿到手」這件事較勁。

而且我必須先把一句難聽的話放在最前面——那些天天喊「我的數據我做主」的口號，在微信這兒基本是句空話。你的記錄確實躺在你自己的硬盤上，一個字節都沒少。但你想把它讀出來，得先跨過一道法律門檻，再跨過一道技術門檻。技術那道我翻過去了，法律那道，翻過去的人現在全在刪庫。

一、就在一年前，做這事的工具被集體清場了

2025 年 10 月 20 日，兩個最有名的微信數據工具同一天發了一模一樣的通知。

PyWxDump 的 README 變成了「項目移除通知」，原話大意是：收到微信官方律師函，指出核心功能存在合規風險，爲規避法律問題，移除全部代碼與提交歷史，倉庫只留一紙說明。作者最後寫了句「後會有期」，然後把公衆號改成了只發 Python 教程。

同一天，chatlog 的倉庫也只剩一份說明，作者 Sarv 的措辭幾乎一樣：收到函件，代碼和提交歷史全部清空，不再提供任何支持。

這兩個項目當時什麼量級？PyWxDump 9638 星，chatlog 9177 星。都不算小。

再往後，2026 年 1 月又有消息說騰訊通過 GitHub 的 DMCA 通道一次性投訴了一批相關倉庫，公開報道里提到的數字是 30 多個，其中不乏幾千星的成熟項目，有維護者直接表示在法律壓力下停止維護。

說白了就是一句話：讓你讀自己聊天記錄的工具，被系統性清理掉了。

所以別急着抄什麼教程。你現在能在網上找到的絕大多數「一鍵導出微信記錄」教程，點進去要麼是死鏈，要麼是引流到付費軟件，要麼是幾個月前就該刪掉的舊倉庫。我寫這篇，講的是方法，不是給你一個能跑的倉庫——因爲那個倉庫大概率已經不在了。

二、先搞清楚：你的數據到底在哪

Windows 上，微信的數據目錄長這樣：

WeChat Files/
└── <你的wxid>/
    ├── Msg/
    │   ├── Multi/MSG0.db      # 聊天正文，分库切片
    │   ├── MicroMsg.db        # 联系人、群、会话列表
    │   └── media/             # 图片、语音、视频，一堆 .dat
    ├── FileStorage/           # 收发的文件
    └── config/                # 账号配置

Mac 上在 ~/Library/Containers/com.tencent.xinWeChat/ 下面，結構類似。微信 4.x 之後路徑和庫結構都調過，別拿老文章的路徑硬套。

然後你興沖沖打開 MSG0.db，會得到這個：

$ sqlite3 MSG0.db ".tables"
Error: file is not a database

意料之中。整個庫是 SQLCipher 加密的，密鑰不存在文件裏，是微信運行時從內存裏算出來的。這就是爲什麼所有這類工具的核心步驟都叫「取密鑰」——它們做的事情，本質上是去進程內存裏把那把鑰匙撈出來。

這一步就是合規爭議的核心。你要讀的是自己的數據，但你要用的手段是繞過廠商的技術保護措施。這兩件事在法律上的定性，和你的直覺完全是兩碼事。

我給不了你合規豁免，只能把邊界說清楚：本地導出自己賬號的、只自己用的，和拿去傳播、售賣、做服務的，性質完全不同。後面那種，別碰。

另一個現實問題：導出的是「殘卷」，不是「全本」

就算技術問題解決了，你拿到的也只是這臺電腦上同步過的那部分。微信 PC 端的記錄是你登錄期間同步下來的、或者你手動遷移過來的。

早年在別的手機上聊完就刪的、換機時沒遷的、存在舊設備裏的，全都不在。我這次號稱「十年」，實際能拼出完整對話的年份大概只有六七年，更早的只剩零散片段。所謂「十年記錄」，是一堆殘頁縫起來的。

三、3675 萬字是個什麼概念

清洗完是 3675 萬字，76.2 萬條。平均一條 48 個字，很符合真實聊天——大部分是「在嗎」「好的」「收到」「哈哈哈哈」。

這個體量，第一反應肯定是「直接塞給大模型」。我算了一下，然後放棄了這個念頭。

喂法	上下文需求	能不能塞下
主流 128K 上下文	約 36.75 M 字符	勉強 0.4%，塞不下
200K 上下文	約 36.75 M 字符	0.6%，還是塞不下
頂配 1M 上下文	約 36.75 M 字符	3% 左右，塞得下但要花大錢

注意，1M 上下文那一行有個陷阱：能塞進去，不等於能記住。上下文越長，模型對中間部分的注意力衰減越明顯，這在業界被反覆驗證過。你把十年的廢話全倒進去，問它「2021 年 3 月我說過要換工作嗎」，它照樣能一本正經地胡說。

所以「全餵給 AI」這個說法，嚴格講是不準確的。我做的不是把 3675 萬字灌進模型的腦子，是給它建了一個能隨時翻的索引。這個區別很關鍵，後面所有工程決策都從這兒來。

四、我用的是這條管道

五步，一步都省不了。

第 1 步：導出成結構化文本

目標格式很簡單，一行一條，帶時間戳、發言人、會話名。別導出成 HTML 或者 PDF——那些是給人看的，不是給程序看的。我要的是後面能 grep、能切塊、能算時間的結構。

2021-03-14 22:17:05 | 老张 | [私聊]
2021-03-14 22:17:41 | 我   | 那个事我想了两天，还是算了
2021-03-14 22:18:02 | 老张 | 早该这样

這一步沒什麼技術含量，但決定了後面所有環節的質量。時間戳丟了，你就永遠問不了「那段時間」；發言人丟了，你就分不清誰說的。

第 2 步：清洗，砍掉一半噪音

原始數據裏至少三成是垃圾：「你已添加了XXX，現在可以開始聊天了」「對方撤回了一條消息」「[圖片]」「[表情]」，還有羣裏無窮無盡的接龍和紅包提示。

我的處理原則是：系統消息全刪，純媒體佔位符保留但標記類型，超短消息（少於 4 個字且無信息量的）合併進上下文。

3675 萬字砍到差不多 2900 萬字。別心疼，這些字留着只會污染檢索結果。

第 3 步：分塊——這一步最容易毀掉整個項目

新手最常犯的錯，是按固定字數硬切。切成 500 字一塊，切到一半正好把一段對話腰斬，前半句在你手裏，後半句在下一塊。檢索的時候召回一半，AI 就開始編。

我的做法是按會話 + 時間窗雙約束切：同一個會話內，相鄰消息間隔超過 30 分鐘就斷開；單塊控制在 400 到 600 字；每塊都帶上「會話名 + 時間範圍 + 參與者」的頭信息。

這個頭信息看起來是冗餘，實際上是最值錢的部分。因爲用戶的問題往往帶時間——「去年年底」「剛畢業那會兒」——沒有時間錨點，向量檢索根本對不上。

第 4 步：向量化

7 萬多個塊，全部跑一遍 embedding。這個量級的成本，人民幣兩位數就夠，比我預想的便宜太多。真正貴的是時間和你重跑的次數——我因爲分塊策略改了三版，重跑了三次。

存哪？sqlite-vec 就夠了。別上來就搭 Milvus、Qdrant，一個人幾萬條數據，用不上那些。

第 5 步：混合檢索，別隻信向量

純向量檢索在聊天記錄這種場景下表現很一般。原因很直白：你要找的往往是人名、地名、具體金額，這些是精確匹配的活，向量不擅長。

所以最終跑的是混合檢索：向量召回一批，關鍵詞（BM25 或直接 SQL LIKE）召回一批，合併去重，再交給模型生成答案。這一改，回答準確率的提升比前面所有優化加起來都明顯。

五、我踩的五個坑，你大概率也會踩

以爲 .db 是普通 sqlite。它不是。所有「怎麼打不開」的問題都源於這一點。
圖片和語音是 .dat。不是標準格式，每個文件頭都有異或加密。想提取得單獨處理，我直接放棄了——十年的圖，提取價值遠低於成本。
羣聊的發言人 ID 是數字。要在 MicroMsg.db 裏做一次映射才能變回暱稱，不做映射的話，你導出來全是 wxid_xxxx，根本沒法讀。
同一個人的名字會變。十年裏改過備註、改過暱稱，同一個人在你的庫裏可能有四個名字。不統一，檢索必錯。
時間戳有時區問題。跨設備同步的記錄時間會偏，遇到「凌晨 3 點發的消息」先懷疑時間戳，別懷疑自己記錯。

六、它現在能幹什麼

說幾個我實際問過、且答得不錯的問題：

「2021 年我說要換工作，當時具體糾結哪幾點？」——它把我跟三個人在不同時間的對話拼起來了，還原出當時的三個顧慮。
「老張答應過幫我做的那件事，最後做了嗎？」——它找到了承諾那條，又找到了三個月後我追問、他推脫的那條。
「這幾年我提過幾次想去日本？」——數出來 7 次，附了每次的時間和上下文。

也有答得很爛的。凡是涉及「我當時是什麼心情」這種主觀問題，它給的全是套話。聊天記錄能還原事實，還原不了感受。這一點上，AI 和你翻舊聊天記錄的體驗是一樣的——甚至更差，因爲它不會猶豫。

七、這件事到底值不值得做

分三種人。

只是想備份、怕丟的：別折騰了。微信自帶「備份與恢復」，Windows/Mac 端左下角更多菜單裏就有，手機端在「我 → 設置 → 聊天記錄管理 → 導入與導出」。加密備份到你自己的硬盤上，夠用。你要的是「不丟」，不是「能問」。
想找回具體某件事的：先別建庫。微信自帶的搜索其實不差，關鍵詞+時間篩選能解決八成需求。剩下兩成，才輪到你搭管道。
真的想把十年變成可對話的記憶：做。但先接受三個前提——數據是殘卷、法律邊界要自己守、問答質量取決於你的分塊功夫而不是模型多強。

至於「餵給 AI」這件事本身，我最大的感受是：AI 不是這一步的瓶頸。

真正難的是導出、清洗、分塊、對齊人名、處理時間戳這些髒活。這些活沒有任何一個模型能幫你幹，全是一行行代碼磨出來的。等數據乾淨了，接個模型反而是最簡單的一步。

所以別被「全餵給 AI」這個說法騙了。這不是一次技術炫技，是一次手工活。3675 萬字裏，值得被問到的可能只有幾萬字，剩下全是「哈哈哈」和「好的」。但就是那幾萬字，值得你花三天。

最後提醒一句：這類工具現在的處境，上面已經寫清楚了。技術上能做，不等於鼓勵你去做；做之前請自己把風險想清楚，尤其別把導出的數據往外傳。