你有没有想过，让一个开源大模型彻底“学着你的语气”去回消息？我做“LLM微调实战Demo项目——实现自己的AI微信分身”的时候，最初的冲动就是这么朴素：想要一个不会漏回消息、说话风格又像我自己的AI分身。但真正动手之后才发现，这个项目的难点根本不在“微信”，而在“微调”本身——怎么把零散的聊天记录变成训练语料、怎么让7B级别的基座模型在消费级显卡上完成个性化训练、怎么避免模型学成说话一本正经的客服。这篇文章会把整条链路完整拆开讲一遍，包括数据清洗、LoRA微调、部署服务以及我踩过的各种坑。适合手里有Python基础、想试试开源模型微调，又不打算烧太多算力预算的开发者参考。

1. “微信分身”不是接入问题，而是风格建模问题

1.1 先想清楚：你要微调的是“知识”还是“人格”

很多人一听到“AI微信分身”，第一反应是教模型记住我的职业、爱好、日程，让它变成我的替身。这个理解没毛病，但落地时会走偏。如果你只是把个人资料丢给模型，那本质上是在做知识注入，根本不需要微调，用提示词就能解决。

这个项目真正要解决的核心任务，是风格迁移与人格建模。我希望模型生成的一句话，不只是信息正确，还要让我朋友觉得“这就是那个人会说的话”。举两个例子就明白了：

• 用户说：在吗？
• 知识型AI回答：我在，请问有什么可以帮您？
• 分身型AI回答：在呢，刚忙完，你咋突然冒出来了。

看出区别了吗？前者是“有用的助手”，后者是“像某个具体的人”。判断分身成不成功，不是看它懂不懂百科知识，而是看它有没有学到你的口头禅、回复长度、表情习惯和冷热态度。这种软性的语言习惯，恰恰是提示词工程很难穷举出来的，因为你自己都说不清你说话有哪些规律——但数据里有。

所以我复盘这个项目时，第一条经验就是：先定义清楚你要建模的是什么。我当时给自己写了一句目标描述：“一个在熟人会话语境下，语气随意、句子短、偶尔用表情词、不主动说教的回复器。”这句话后来帮了大忙，因为每次清洗数据和写系统提示词时，我都会拿这个定义去核对样本，避免语料漂移。

1.2 完整技术链路长什么样

整个项目从零到一，我用了一张链路图来规划，拆成六个阶段：

1. 聊天记录导出与脱敏：拿到原始数据，去掉隐私信息。
2. 对话样本构造：把流水账改成交错的多轮指令样本。
3. 基座模型选型：选择适合中文对话场景的开源指令模型。
4. LoRA微调：用低秩适配技术，只训练一小部分参数。
5. 服务化部署：把训练好的模型包装成可调用的对话接口。
6. 模拟测试与迭代：用真实场景测试，再回头补数据。

这六步里，真正决定成败的不是第4步训练脚本，而是第2步数据构造。微调开源模型本质上是在“教模型说什么”，数据决定了模型的上限。

1.3 算力与数据量：一张表算清楚

考虑到公众号和社区里很多朋友是个人开发者，我直接给出我实测过的算力区间。以7B量级的Qwen2.5-7B-Instruct这类开源中文模型为例，做LoRA微调的话：

我最初只有12GB的显卡，硬是用梯度累积和4比特量化把2000条样本跑完了。所以要提醒一句：数据量决定了效果下限，算力只决定你等多久。如果你的显卡更差，优先把样本质量提上去，不要无脑堆参数。

2. 数据工程占了整个项目七成工作量

2.1 聊天记录的导出、脱敏与权限边界

第一步就是拿到原始聊天数据。不同客户端导出方式差别很大，具体操作我不展开，但有三条硬性原则必须守：

• 只处理你自己的账号产生的聊天记录，不要导出群聊里大量他人信息。
• 涉及他人的姓名、手机号、地址、公司信息，清洗时一律脱敏。
• 这个分身模型如果以后要展示给别人，必须经过与你对话过的朋友的同意。

我当时写了一个脱敏脚本，把常见隐私模式用正则替换掉。代码大概是这样的：

import re def desensitize(text: str) -> str: # 手机号：保留前3后4，中间用星号替换 text = re.sub(r'(?<=\d{3})\d{4}(?=\d{4})', '****', text) # 姓名：简单的两个/三个中文字符替换为[某人] text = re.sub(r'[\u4e00-\u9fa5]{2,3}(?=在|说|问我|发了)', '[某人]', text) # 微信号 text = re.sub(r'wxid_[a-zA-Z0-9_-]+', '[微信号]', text) # 地址 text = re.sub(r'[\u4e00-\u9fa5]+(?:省|市|区|县|街道|路|号)', '[地址]', text) return text

注意，脱敏必须放在训练之前，而不是放在生成之后。因为一旦真实姓名进入模型权重，后面无论怎么拦截都可能从某个上下文里冒出来，到时候处理成本高十倍。

2.2 多轮对话样本构造：把“流水账”变成“语料”

微信聊天和训练语料之间隔着一条巨大的鸿沟——原始记录是多线程交错的。你同时和七八个人聊天，导出来的时间线是乱的；即使只和一个人聊，中间也可能插入转账、图片、长语音转文字等噪音。

我拆解会话的思路，是先把记录按“对方ID”分组，再在组内按时间连续性和话题停顿切分成“会话片段”。一个会话片段里，双方消息交替出现，才能构造出多轮对话样本。

切分完之后，还要做一轮质量过滤。规则如下：

• 样本长度要合理：3轮以上、20轮以下，太长的上下文训练起来显存压力大。
• 剔除单字回复和纯表情消息，比如“嗯”“哈”“[动画表情]”没有训练价值。
• assistant角色的内容必须是我自己说的话，user角色是对方说的话，角色不能乱。

2.3 系统提示词：给“分身”立规矩

微调时很多人只关注对话样本，忽略了系统提示词。其实系统提示词决定了模型在“无话可说”时如何兜底。我最终固定的模板是：

你正在扮演[某人]的微信分身。你的目标是用[某人]的语气和朋友聊天。 规则： 1. 回答尽量简短，通常不超过50个字。 2. 不要主动使用书面语，不要用“首先”“其次”“综上所述”。 3. 朋友问你不确定的问题时，直接说不知道，不要编造。 4. 不要主动询问对方私人信息，不要感情用事。 5. 偶尔可以使用哈哈、嗯、好的这类语气词，但不要每句都用。

模板里的[某人]换成真实代称。这个提示词在训练前就固定下来，训练时每一条样本前面都拼接它，模型才会学会“进入角色”。

2.4 数据质量检查：那些“看起来对但会教坏模型”的样本

清洗数据时踩过一个印象很深的坑：把“长语音转文字”的错漏文本直接当训练数据。比如朋友发来一段语音，系统转出来的文字是“我明天不去公司了 在家睡觉”，因为我回复的是“好 那明天线上说”，看起来是正常的，但如果不小心混入一条错误转写且语义完全反了的文本，模型学到的就是错误理解语境的能力。

更隐蔽的脏数据是“礼貌诈骗样本”。比如别人发“谢谢”，我回“不客气，这是我应该做的”——这种在公司群里礼貌假客套，如果在训练数据里占比太高，模型就会变得过分客气。我的处理方案是：先把所有样本按“回复长度”“是否含表情”“是否含哈哈哈”等维度打标，查看分布，再手工删除明显不符合人设的异常值。

如果清洗完只剩几百条可用数据怎么办？我当时补了一个“扩写自有对话”的办法：把自己发过的朋友圈文案、微博短文、日记式备忘，整理成独白式的助理回复，但比例控制在总量的20%以内，防止把聊天风格稀释成写作风格。

3. LoRA微调：参数、脚本与过拟合实战

3.1 为什么选开源中文基座而不是闭源API微调

动手之前，我认真对比过三条路线：

闭源API的“微调”本质上是平台定制接口，数据要经过第三方服务，而且每次调用都花钱。做分身这种高度个性化、需要反复试错迭代的项目，性价比太低。所以我选了开源模型加LoRA的组合。

基座模型选什么？我当时在7B量级的中文指令模型里选了Qwen2.5-7B-Instruct这一类。原因有三个：中文语感稳定、上下文窗口长、社区生态成熟踩坑少。如果你显存更小，可以退到3B甚至1.5B，但风格建模对模型本身的中文能力要求不低，太小会显得“木”。

3.2 LoRA原理速解：灯光混音台

LoRA的核心理念可以类比成调音台上的“分轨音量推子”。大模型原本有几千亿个参数，像一首已经混好的音乐。你不想把整首歌重新录制，只想把“人声轨”稍微调大一点，让它更像某个人的嗓音。LoRA做的事情，就是在特定层上附加一个低秩的小矩阵，只允许这个小矩阵在微调中变化。

实操中需要关注的参数并不多：

• r（秩）：这个“推子精度”。我推荐8到16，调太高容易过拟合，调太低学不到风格。
• lora_alpha：缩放倍率，一般是r的1倍或2倍，我常用16配8，或者32配16。
• target_modules：把LoRA挂在哪些层。全连接层q_proj, k_proj, v_proj, o_proj是基本面，有人还会加gate_proj, up_proj, down_proj，效果略有提升但训练更慢。
• learning_rate：LoRA的典型学习率在1e-4到3e-4之间，比全参数微调的1e-5要大，因为可训练参数占比很小。
• max_seq_len：我设为1024，覆盖90%以上的微信多轮对话，太长会拖慢训练。
• epochs：3到5轮。别多跑，LoRA在小数据上很容易过拟合。

3.3 完整训练脚本与参数注释

训练代码基于HuggingFace的transformers和PEFT库，结构比较标准。这是我当时精简后的核心片段：

from transformers import AutoTokenizer, AutoModelForCausalLM, TrainingArguments, Trainer from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from datasets import Dataset import torch model_name = "Qwen/Qwen2.5-7B-Instruct" tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True) tokenizer.pad_token = tokenizer.eos_token # 用4bit加载基座，显著降低显存占用 model = AutoModelForCausalLM.from_pretrained( model_name, load_in_4bit=True, torch_dtype=torch.bfloat16, device_map="auto", trust_remote_code=True ) model = prepare_model_for_kbit_training(model) lora_config = LoraConfig( r=8, lora_alpha=16, target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM", ) model = get_peft_model(model, lora_config) model.print_trainable_parameters() # 可训练参数大约在800万左右，只占全模型的0.1% # 假设已经构造好多轮对话样本，格式为 [{"role": "user", "content": "..."}, ...] def format_chat(example): text = tokenizer.apply_chat_template( example["messages"], tokenize=False, add_generation_prompt=False ) return {"text": text} dataset = Dataset.from_list(train_samples) dataset = dataset.map(format_chat) training_args = TrainingArguments( output_dir="./wechat_avatar_ckpt", per_device_train_batch_size=2, gradient_accumulation_steps=8, num_train_epochs=4, learning_rate=2e-4, logging_steps=20, save_strategy="epoch", bf16=True, gradient_checkpointing=True, remove_unused_columns=False, ) trainer = Trainer( model=model, args=training_args, train_dataset=dataset, ) trainer.train()

几个要点：

• gradient_checkpointing=True是个人显卡跑7B的救星，用时间换显存。
• 如果开4bit后训练非常慢，可以换8bit或直接全精度加载，配batch_size=1+ 梯度累积。
• 训练日志里如果loss从2.2降到1.0以内，说明模型开始记住了样本；继续降到0.4以下就要警惕过拟合。

3.4 过拟合判断与checkpoint选优

任何一个微调项目，最难的不是让loss下降，而是知道在哪一轮停下来。我遇到过典型的过拟合表现：训练到第5轮时，模型生成的每句话末尾都自带“哈哈”，因为训练数据里有太多以表情词结尾的样本。

我的做法是留一手的：在完整训练集里抽出30条“守门样本”不参与训练，每训练完一个epoch，让模型依次回答这些样本里的user消息，然后人工看一眼回复质量。选checkpoint的唯一标准不是loss，而是守门样本上“像不像你”的主观评分。

实际操作中，因为完整数据集往往不够大，守门样本不能留太多，否则数据更紧张。折中办法：守门样本固定20条，包含“短回复”“问句”“深夜闲聊”“工作消息”四类场景各5条，基本能覆盖风格主轴线。

4. 从checkpoint到可用服务：部署与上下文管理

4.1 让模型跑起来：从推理脚本到API服务

训练完拿到的是LoRA adapter权重，部署时要把基座模型和adapter一起加载。我直接用FastAPI包了一个最简单的对话服务，方便后期接任何IM平台或做网页测试。

from fastapi import FastAPI from pydantic import BaseModel from transformers import AutoTokenizer, AutoModelForCausalLM from peft import PeftModel import torch app = FastAPI() model_name = "Qwen/Qwen2.5-7B-Instruct" adapter_path = "./wechat_avatar_ckpt/checkpoint-1000" tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_name, torch_dtype=torch.bfloat16, device_map="auto" ) model = PeftModel.from_pretrained(model, adapter_path) model.eval() class ChatRequest(BaseModel): messages: list @app.post("/chat") def chat(req: ChatRequest): text = tokenizer.apply_chat_template(req.messages, tokenize=False, add_generation_prompt=True) inputs = tokenizer(text, return_tensors="pt").to("cuda") # 采样参数后面再细讲，这里先给保守值 outputs = model.generate( **inputs, max_new_tokens=256, do_sample=True, temperature=0.7, top_p=0.9, repetition_penalty=1.05, ) response = tokenizer.decode(outputs[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True) return {"reply": response}

如果你显存不够跑7B，可以把模型加载改成4bit，类似训练时的load_in_4bit=True，推理速度会慢一点，但内存占用能降到8GB左右。

4.2 采样参数如何配合“人设”

部署时最容易忽略的是采样参数的“人设”意义。温度调低，模型会趋近于高频回答，保守但无聊；温度调高，模型敢说一些冒险的话，但容易跑偏。做微信分身，我的经验是：

• temperature=0.7到0.85：日常闲聊有活人感，又不至于乱来。
• top_p=0.9：稳一稳，防止从低概率词里蹦出诡异内容。
• repetition_penalty=1.03到1.05：微信聊天里最怕的就是复读机，这项必须加。

我实测过同一句“周末干嘛”，温度0.5会回答“在家休息”，温度0.95会回答“要不你来我家吃饭吧哈哈哈哈”——后者更像朋友，但也有点越界。分身场景建议温度往0.75偏，安全性和趣味性平衡比较好。

4.3 多轮会话记忆：不要把上下文一直往上堆

微信聊天是典型的多轮会话，模型必须记住前面聊了什么。最简单的方式是把整段对话拼接进messages数组，但token窗口有限，聊一小时后迟早爆掉。

我的方案很朴素：设置一个最大历史条数，超过20条就先把最早的消息从列表里移除。如果担心失去早期关键信息，会在移除前做一次轻量摘要。摘要用同一个模型来生成：

请用一句话总结刚才的对话：{history_text}

然后把摘要作为一条system消息放在最前面。这样做的好处是既控制长度，又保留核心话题。代价是每次截断会损失细节，但对日常微信聊天已经完全够用。

4.4 接入IM平台的合规边界

这是绕不开的部分，我必须先把话说清楚：本文只讨论把微调模型做成一个独立的回复生成服务，不讨论任何非官方的微信自动化接入方式，更不提供绕过平台限制的实现细节。如果你真的想把这个分身接到某个IM工具上，请先确认你的方案符合平台的服务条款和相关法规，并且只把它当作“草稿生成器”——AI打出内容后，由你本人确认再发送。绝不能拿它去做自动回复、骚扰式营销、诈骗话术等任何有风险的事。

我额外建议：如果打算长期使用，让模型生成回复，然后你在手机端一键复制发送，这种半自动方式最稳妥。既享受微调成果，也不会把责任甩给AI。

5. 实测翻车记录：客服腔、复读机和幻觉

5.1 咖啡测试：为什么模型回答像“客服”

把模型接好之后，我做的第一轮测试是让朋友假装正常找我聊天。结果第一条就暴露了问题。朋友发“在吗”，模型回复一大段：

“你好，我在的。请问你有什么事情找我？如果有需要帮助的，请直接告诉我，我会尽力协助你。”

当时就绷不住了。这就是典型的客服腔中毒。原因有两个：基座模型本身经过指令微调，默认带客服属性；而且训练数据里我很少发“在吗”这种短消息，模型没见过这种场景，只能回到它的“出厂设置”。

解法分两步。第一步，在系统提示词中写明“朋友说在吗时，直接回复在的+简短反问”。第二步，从聊天记录里把所有“在吗”相关片段单独挑出来，构造20条左右短样本补充进训练集。这招之后很管用——短消息场景有数据兜底，模型就不再依赖客服预设。

5.2 重复与幻觉：数据量太少时会发生什么

训练数据不足时，模型最常见的病是复读机。我盯着早期checkpoint的生成结果，满屏都是“好的好的好的”“嗯嗯”。这不是模型蠢，而是它见过的回复模式太少，没有足够的“下一句候选”，只能反复抽同一个高概率词。

幻觉更麻烦。我让模型回答“上次咱们说的那家餐厅叫什么”，它一本正经编了个“老王烤鱼”。数据里根本没有这家店，它把“老王”和其他烤鱼信息拼凑起来了。

对分身的场景，我后来加的兜底规则是：系统提示词里强制“不确定就说忘了，不要编”。同时在下游服务里加一层拦截，把所有包含“某某店/某某人/某公司”等具体名词的生成结果打回重写。分身可以拟人，但不能造谣。

5.3 隐私与风格冲突的二次排查

训练前做脱敏，不代表生成时一劳永逸。有一次测试，模型在我俩聊到某个话题时说出了朋友的真实昵称——那是训练数据里没清洗干净的漏网之鱼。

我把这次事故当成了教训：在服务层加一个输出敏感词过滤器，用一个名单匹配生成的文本，一旦命中就打回重生成或直接降级为“我不太确定”。名单不一定要很复杂，正则加关键词就够用：

sensitive_words = ["真实姓名A", "手机号", "具体公司名", "家庭地址关键词"] def filter_output(text: str) -> bool: for w in sensitive_words: if w in text: return False return True

这里要再次强调：过滤只是兜底，根子上还是要靠训练前的彻底清洗。

5.4 用户画像与知识边界的取舍

花了大力气微调出来的分身，往往会走向另一个极端——朋友问你专业问题时，它特别自信地回答一长串，哪怕是在瞎编。我意识到，分身的人设边界不是“什么都知道”，而是“有血有肉的普通人”。

所以我在系统提示词里加了一条：“如果你不确定，就说‘这个我还真不知道，我去查查’。不要为了显得聪明而编造答案。” 调完之后，实测效果好了很多，朋友甚至觉得这个分身“比真人谦虚”。

知识边界想得更远一点：分身只负责“说话风格和基本人设”，具体的百科知识和实时信息，应该交给RAG或者联网搜索，不要在LoRA阶段强行塞知识。LoRA擅长改风格，不擅长灌知识，硬灌反而会让模型在风格和事实之间左右互搏。

6. 后续进阶：从“像你”到“帮你”

6.1 增量学习：如何持续更新风格

人的说话风格会变，分身也必须跟着更新。我的做法是每个季度新增最近3个月的聊天记录，混入原始数据重新微调一遍。

注意一定要混入旧数据，不能只用新数据。因为模型会灾难性遗忘，只拿新数据微调，它会逐渐丢掉原来的语气底色，变成“只像最近的你”。新旧混合的比例我一般控制在2:1，新数据占两份，旧数据占一份。

6.2 结合RAG补知识短板

如果你希望分身不仅会聊天，还能回答“我的密码本放哪了”“上次说的项目方案细节”这类问题，那就要引入RAG。把个人文档、备忘录、笔记都丢进向量数据库，在生成前检索相关内容拼进上下文。

我的架构很直接：分身模型负责“用你的语气说话”，RAG负责“从你的资料库找事实”。两者在服务端串联，不在微调阶段混合。这样维护起来省心——想更新知识，重新跑一次向量索引就行，不用重新训练模型。

6.3 多角色分身与路由

项目做到后期，我又想到一个新玩法：把自己在不同场景下的说话风格拆成多个分身——工作版、朋友版、家人版。做法是训练阶段给每个分身准备独立的LoRA adapter，然后在推理服务里加一个简单的路由，根据当前对话方是谁来动态切换adapter。

这个方案唯一要注意的是存储和显存：每个adapter通常就几十到几百MB，同时挂载三五个人完全没压力。切换时在FastAPI服务里记一个当前的adapter id，请求进来时先查用户表，再决定加载哪一套。

我当时给这个能力写过一句很直白的话：一个模型学会所有人的语气，才是真正意义上的分身工厂。

最后分享一点个人体会。这个项目跑通之后，我对微调这件事的认识发生了很大变化：刚开始以为是调参、跑脚本、看loss曲线，真正上手才发现，每天花时间最多的是整理聊天记录、删脏数据、反复看生成结果的语气对不对。数据和风格，远比训练技巧更决定项目的天花板。

如果你只记住一个细节，我希望是这条：把系统提示词写细一点，把训练数据洗得干净一点，比换更大的模型、加更多的秩都管用。先让模型学会闭嘴，它才真正开始像你。