WeClone：用聊天記錄微調出數位分身，從 Telegram 匯出到綁定機器人的一條龍流程
🚀 One-stop solution for creating your AI twin from chat history 💡 Fine-tune LLMs with your chat logs to capture your unique style, then bind to a chatbot to bring your digital self to life.
秒懂
- 它是什麼？
- WeClone 把聊天記錄匯出、隱私過濾、LoRA 微調與機器人綁定串成單一流程，預設使用 Qwen2.5-VL-7B-Instruct。它的價值在於把訓練鏈路封裝好，代價是硬體門檻與 AGPL-3.0 的傳染性條款。
- 適合誰用？
- 如果你手上有一份夠大的 Telegram 聊天匯出，而且已經有 16GB 以上顯存的 GPU，WeClone 是目前少數把資料清理到模型部署整條路都寫清楚的方案，值得先跑一次資料處理流程再決定要不要訓練。若你只有 6GB 到 8GB 的消費級顯卡，或需要一個能直接接上微信個人帳號的穩定產品，這個專案現階段的迭代狀態與平台支援表都不足以支撐。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
WeClone 想解決的是「風格遷移」，不是「知識問答」
多數人第一次接觸微調，是想讓模型記住某些事實。WeClone 的目標不同：README 寫的是用聊天記錄微調 LLM 以捕捉你的風格，官方描述用的是「infusing it with that authentic flavor」。這是一個風格與語氣的問題，不是知識注入的問題。
這件事的實際意義在於資料形態。要讓模型學會你怎麼回話，需要的是大量「你說了什麼、對方回了什麼」的配對，而不是乾淨的問答對。WeClone 因此把重心放在聊天記錄的匯出與清洗上，README 的核心功能第一條就是涵蓋匯出、前處理、訓練到部署的完整流程。它預設支援 Telegram 作為資料來源，WhatsApp、Discord、Slack 在表格中標記為開發中。
適合的對象相當明確：手上有多年 Telegram 聊天記錄、想做出一個能代答或陪聊的個人化模型，並且願意自己處理 GPU 環境的工程師。不適合的對象也同樣明確：想找現成 SaaS 的人，或期待開箱即用、不需要碰命令列的人。README 對 Windows 的說明是「尚未經過嚴格測試」，建議改用 WSL，這已經暗示了它的目標使用者畫像。
資料流的起點是 Telegram 匯出，而表格暴露了它的邊界
WeClone 的資料來源支援表列得很細，逐欄看比看功能列表有用。Telegram 在文字與圖片上是完整支援，貼圖與動畫表情符號標記為轉換成 Emoji，轉發訊息支援，位置與檔案也支援。語音、影片、連結分享、引用回覆則是不支援。
這張表決定了你餵進去的資料長什麼樣。如果你的聊天習慣是大量轉發、引用回覆與語音訊息，實際能進入訓練的文字比例會比你想像的低。貼圖被壓成 Emoji 是一個務實的折衷，但這也意味著模型永遠學不到你用貼圖表達情緒的那個維度。圖片模態的支援在 2025 年 6 月加入，對應的是預設模型 Qwen2.5-VL 的多模態能力。
隱私過濾是流程中的另一個環節，README 把它列為核心功能之一，描述是「Privacy information filtering with localized fine-tuning and deployment」。本地微調與本地部署是這個設計的關鍵：資料不離開你的機器，這對聊天記錄這種高度敏感的材料來說是必要的，而不是加分項。
部署端的支援表比資料端寬鬆。Telegram、Discord、Slack 都標記為支援，微信個人帳號標記為支援但註明基於 openclaw-weixin，WhatsApp 仍在開發中。資料來源窄、部署出口寬，這個不對稱是理解 WeClone 的重要前提。
訓練階段交給 LLaMA Factory，顯存需求表才是真正的門檻
WeClone 沒有自己重寫訓練器。README 說明專案預設使用 Qwen2.5-VL-7B-Instruct，在 SFT 階段採用 LoRA 方法，並指出你也可以使用 LLaMA Factory 支援的其他模型與方法。這是一個合理的分工：WeClone 負責資料與部署，訓練的複雜度外包給一個成熟專案。
代價是顯存。README 提供的估算表按方法與精度分層，LoRA 在 16 位精度下 7B 模型需要 16GB，14B 需要 32GB，30B 需要 64GB，70B 需要 160GB。QLoRA 在 4 位精度下 7B 降到 6GB，2 位精度下 7B 只要 4GB。全量微調則是完全不同的量級，bf16 下 7B 就要 120GB。
這裡有一個容易被忽略的細節：表格的 7B 欄位對應的是文字模型，而專案預設是 Qwen2.5-VL-7B-Instruct，一個視覺語言模型。README 沒有針對 VL 模型單獨給出顯存數字，所以這張表應該當作量級參考，不是精確預算。
README 對效果的說明相當坦白：7B 模型的表現一般，14B 以上參數的模型效果較好。它同時提醒微調效果很大程度取決於模型大小與聊天資料的數量與品質。這不是行銷語言，而是一個應該被當作選型前提的陳述。
從 clone 到 settings.jsonc：實際會敲到的指令
安裝路徑在 README 中寫得完整。前置條件是 CUDA 12.6 以上，這是硬性要求，不是建議值。
專案推薦用 uv 管理環境，指令如下：
git clone https://github.com/xming521/WeClone.git && cd WeClone uv venv .venv --python=3.12 source .venv/bin/activate uv pip install --group main -e .
Windows 下的啟用指令是 .venv\Scripts\activate。
接下來是設定檔。README 要求複製範本並改名為 settings.jsonc：
cp examples/tg.template.jsonc settings.jsonc
範本檔名是 tg.template.jsonc，對應 Telegram 這條路徑。README 明確指出訓練與推論相關的設定統一放在 settings.jsonc 這一個檔案裡。這是一個容易理解的設計選擇：單一設定檔降低了跨階段參數不一致的風險，但也意味著同一份檔案同時承載資料路徑、訓練超參數與部署設定，改動時要小心不要互相污染。
安裝完成後，README 建議先執行一個測試指令，確認 CUDA 環境能被 PyTorch 正確識別。這一步不該跳過。由於我沒有實際安裝或執行這個專案，這裡只能轉述文件列出的步驟，無法告訴你它在你的機器上會回報什麼。
迭代速度是這個專案最需要被計入的成本
README 開頭有一段用 IMPORTANT 標記的說明：WeClone 仍處於快速迭代階段，當前表現不代表最終結果。這句話放在最顯眼的位置，作者顯然知道它會影響採用決策。
版本節奏印證了這一點。v0.3.01 在 2025 年 7 月 17 日發布，v0.3.02 在同年 8 月 17 日，v0.3.03 在 2026 年 1 月 4 日。更新日誌中，2025 年 6 月 5 日加入圖片模態資料微調，7 月 10 日加入 Telegram 資料來源。功能在陸續補齊，而不是已經定型。
對採用者的實際影響是：設定檔的鍵、資料處理的輸出格式、以及支援的平台矩陣，都可能在版本之間變動。README 的資料來源表把 WhatsApp、Discord、Slack 全部標為開發中，部署表則把 WhatsApp 標為開發中。如果你今天為了某個平台而選它，要先確認那個平台是在已支援欄還是開發中欄。
升級成本因此不容易估算。專案沒有在 README 中提供從舊版 settings.jsonc 遷移到新版的說明，也沒有版本相容性承諾。這不是缺陷指控，只是一個必須自己承擔的事實：每次升級前先備份設定檔。
AGPL-3.0 對「數位分身」這個用途意味著什麼
WeClone 採用 AGPL-3.0。這個授權的關鍵條款在網路服務場景：如果你修改了程式並以網路服務的形式提供給他人使用，你需要向使用者提供對應的原始碼。
這對個人自用沒有影響。你自己在本機訓練一個模型、自己跟它聊天，不涉及散布。但如果你打算把 WeClone 包成一個對外開放的服務，例如讓朋友透過 Telegram 機器人跟你的分身對話，就需要認真評估。這裡不提供法律意見，只指出條款的存在與它可能觸發的場景。
README 中有一段贊助商內容，推廣 Infistar.cc 的模型 API 服務，並提供 WeClone 使用者註冊優惠。這與授權無關，但它顯示專案有商業贊助關係。贊助並不會改變 AGPL-3.0 的條款，不過它意味著專案的資金來源與第三方服務有連結，閱讀時可以自行判斷這對你的採用決策是否有影響。
另一個與成本相關的點：由於訓練在本地進行，主要的持續成本是 GPU 電力與硬體折舊，而不是 API 費用。但部署階段若選擇接上外部模型 API 做對話效果測試或人格提示詞優化，就會產生按量計費。README 的贊助段落提到的正是這類用途。
與直接使用 LLaMA Factory 的差別在哪裡
WeClone 的訓練層依賴 LLaMA Factory，所以真正的替代方案不是另一個微調框架，而是「自己用 LLaMA Factory 加上自己寫的資料處理腳本」。
差別在於前置與後置的工作量。LLaMA Factory 的職責是訓練與模型管理，它不管你的聊天記錄從哪裡來、格式怎麼統一、貼圖怎麼處理、隱私資訊怎麼過濾、訓練完的模型怎麼接到 Telegram 機器人上。WeClone 補的正是這幾段。README 把它定位為涵蓋匯出、前處理、訓練、部署的完整流程，這個定位是準確的。
反過來說，如果你已經有一套自己的資料清洗流程，或者你的聊天資料來自 Telegram 以外的平台而該平台在 WeClone 的支援表中仍是開發中，那麼 WeClone 能替你省下的部分就只剩下部署綁定。這種情況下直接使用 LLaMA Factory 加上自寫腳本，控制力更高，也不會被 AGPL-3.0 綁住。
選擇的判準因此不是「哪個框架更好」，而是你的資料是否落在 WeClone 已支援的那一格裡。Telegram 文字與圖片是已支援的，其他平台不是。
什麼情況下應該先停下來
顯存不足是最直接的否決條件。如果你的 GPU 只有 6GB 到 8GB，README 的表格顯示 QLoRA 在 4 位精度下 7B 需要 6GB，看似可行，但這張表沒有涵蓋預設的 VL 模型，而且 README 自己說 7B 的表現一般、14B 以上才較好。用低精度跑一個效果普通的模型，得到的可能只是一個說話像你但常常答錯的分身。
資料量是第二個門檻。README 沒有給出「至少需要多少則訊息」的數字，只說效果取決於資料的數量與品質。這是一個誠實但無法據此規劃的陳述。如果你的聊天記錄只有幾千則，先做資料處理、看看清洗後剩下多少可用的文字配對，再決定是否投入訓練，比直接開始調參更省時間。
平台錯配是第三個。資料端只有 Telegram 完整可用，部署端雖然涵蓋 Telegram、Discord、Slack 與微信個人帳號，但微信那條路徑註明基於 openclaw-weixin，屬於外部依賴。README 沒有進一步說明它的維護狀態。
最後是版本。專案在半年內發布了三個小版本，README 明說處於快速迭代階段。把 WeClone 放進一個需要長期穩定運行的生產環境，目前缺乏足夠的相容性承諾來支撐。
編輯結論
如果你手上有一份夠大的 Telegram 聊天匯出，而且已經有 16GB 以上顯存的 GPU，WeClone 是目前少數把資料清理到模型部署整條路都寫清楚的方案，值得先跑一次資料處理流程再決定要不要訓練。若你只有 6GB 到 8GB 的消費級顯卡，或需要一個能直接接上微信個人帳號的穩定產品，這個專案現階段的迭代狀態與平台支援表都不足以支撐。動手前先確認三件事：CUDA 版本是否達到 12.6、你的資料量是否撐得起 7B 以上的模型、以及 AGPL-3.0 對你打算部署的服務形式意味著什麼。
社群筆記