1. 从“给同事做个AI分身”这个念头说起第一次冒出“给同事建AI克隆”这个想法是在一个再普通不过的周五下午。团队里有个后端老哥每次代码评审都能精准指出我接口设计里的边界问题但他那天休假我对着一段并发逻辑卡了整整两小时。当时我就想如果有个“他的AI版本”能随时回答我“这哥们会怎么看这段代码”那该多省事。这个念头听起来有点科幻但落到2024年的技术栈上其实完全可行。核心思路就一句话用同事过往的聊天记录、文档、代码注释、会议纪要作为语料微调或提示词工程出一个能模仿其表达风格和思维模式的对话机器人。我前后花了大概三周业余时间给三位关系不错的同事各做了一个“AI分身”过程中踩的坑、得到的意外发现以及后来事情怎么变得“有点怪”都值得完整记录一下。这篇文章适合谁看如果你对AI agent、chatbot定制、大模型应用开发感兴趣想了解从零搭建一个“人格化AI”的完整链路或者单纯好奇“把同事数字化”这件事到底靠不靠谱那接下来的内容应该能给你不少参考。我会把技术选型、语料处理、提示词设计、测试迭代、以及那些让人哭笑不得的翻车现场都摊开讲。全程不涉及任何敏感工具所有方案都是公开可复现的。先交代一下最终成品的基本形态三个AI克隆分别部署在本地通过一个简单的Web界面访问底层用的是Gemini API做推理配合RAG检索增强生成来注入同事的“记忆”。每个克隆的响应风格差异明显——一个爱用短句和反问一个喜欢先列提纲再展开还有一个总在结尾加一句“你品你细品”。做到这个程度技术上的门槛其实不高真正难的是边界把控和预期管理。2. 整体设计思路为什么是RAG加提示词而不是微调2.1 三条技术路线的取舍给特定人物建AI克隆业内常见做法有三条路全量微调、LoRA轻量微调、RAG加系统提示词。我一开始也纠结过毕竟“微调”听起来更彻底能让模型真正“学会”一个人的说话方式。但实际评估下来RAG方案在多个维度上更合适。方案数据需求训练成本更新便利性风格模仿效果事实准确性全量微调极大极高极差好一般LoRA微调中等中等较差较好一般RAG提示词少量无极好中等偏上好关键考量在于同事的说话风格和知识是两回事。风格可以通过系统提示词里的few-shot示例来锚定而具体知识比如他负责的模块、他常引用的内部文档用RAG动态检索更灵活。而且同事的聊天记录是持续产生的今天新增的讨论明天就能进向量库微调模型根本做不到这种实时性。另一个现实原因是数据量。一个普通职场人即使把企业微信、飞书、邮件全算上高质量对话语料也就几千到几万条。这个量级做全量微调远远不够做LoRA也容易过拟合模型会变成“复读机”翻来覆去就那几句话。RAG方案对数据量的要求低得多几百条代表性语料就能跑出不错的效果。2.2 系统架构拆解整个系统的数据流是这样的语料采集层从合规渠道导出同事的公开聊天记录、技术文档、代码注释、会议纪要。这里必须强调所有语料都经过当事人明确同意且只使用工作相关内容私人对话一律剔除。预处理层清洗、去重、分段、打标签。把长对话切成适合检索的chunk同时提取“风格样本”——那些能体现个人表达习惯的短句。向量化层用嵌入模型把chunk转成向量存入本地向量数据库。我选的是Chroma轻量、Python原生、够用。检索层用户提问时先检索最相关的N个chunk作为上下文注入提示词。生成层Gemini API接收“系统提示词检索结果用户问题”输出回复。交互层一个Flask写的简单Web界面支持切换不同克隆。这个架构的好处是每一层都可以独立替换。比如后来我发现Gemini对中文口语的模仿不够细腻就换了一个专门优化过中文对话的模型做生成检索层完全不用动。2.3 为什么选Gemini作为推理引擎热词里频繁出现Gemini我实际用下来它在几个方面确实适合这个场景。长上下文窗口能塞下更多检索结果和风格示例多轮对话一致性比较好不会聊着聊着就“出戏”。而且API的定价相对友好个人项目跑起来成本可控。不过Gemini也有坑。比如它对系统提示词的“服从度”有时候过于严格你写“用简短口语回复”它可能真的只回你三个字把该解释的技术细节也省了。后来我在提示词里加了“在保持口语风格的同时确保技术信息完整”这样的平衡指令才把效果拉回来。提示如果你也想用Gemini做类似项目建议先在AI Studio里用免费额度把提示词调稳再上API。直接调API调试每次都要等网络往返效率低很多。3. 语料处理从聊天记录到“人格向量”3.1 数据采集的合规红线这一步我必须放在最前面讲因为这是整个项目里最容易出事的地方。给同事建AI克隆本质上是在处理他人的个人数据。我的做法是书面同意每个被克隆的同事都签了一份简单的授权说明明确用途、范围、存储方式、销毁机制。范围限定只采集工作相关的公开频道消息、技术文档、代码评审评论。私聊、邮件、任何带“私密”标签的内容一律不碰。匿名化处理语料中涉及的具体项目名、客户名、内部代号全部替换成占位符。比如“XX银行项目”统一替换为“项目A”。可撤回同事随时可以要求删除自己的克隆和所有语料我写了个一键清除脚本。这些措施听起来繁琐但少了任何一条这个项目都不该继续做下去。技术能力越大边界意识越要强。3.2 语料清洗的实操细节原始聊天记录导出来是JSON格式一条条长这样{ sender: 同事A, timestamp: 2024-03-15T14:23:11Z, content: 这个接口的幂等性你考虑了吗如果客户端重试会不会重复下单, channel: backend-review }清洗流程我写了几个Python脚本核心步骤包括第一步按发送人过滤。只保留目标同事的消息但上下文要保留——因为他的回复往往是对别人问题的回应单独拎出来会丢失语境。我的做法是把对话按时间窗口切成“会话块”每个块里包含提问和该同事的回复。第二步去重和去噪。表情包、纯、单字回复“嗯”“好”“收到”全部剔除。这些内容对风格建模没有价值反而会污染向量空间。第三步分段。一条超过200字的消息按语义切成多个chunk。切分点选在句号、问号、分号之后保证每个chunk语义完整。我用的chunk大小是256个token重叠64个token这个参数是试出来的——太小则上下文不足太大则检索精度下降。第四步风格样本提取。单独维护一个列表存放那些“一看就是他会说的话”。比如同事B的“你先别急我们把这个拆成三个问题来看”同事C的“这个方案能跑但我觉得还有优化空间你听听看”。这些样本不参与检索专门用于系统提示词里的few-shot示例。3.3 向量化与检索调优嵌入模型我试了三个OpenAI的text-embedding-3-small、BGE-M3、以及Gemini自带的embedding。最终选了BGE-M3原因是中文语义匹配更准而且可以本地跑不依赖网络。检索策略上纯向量相似度有个问题有时候最相似的chunk并不是最有用的。比如用户问“同事A会怎么设计这个缓存”向量检索可能返回一堆提到“缓存”这个词但观点无关的片段。我加了一层关键词加权如果chunk里包含“设计”“方案”“建议”这类元话语标记相似度得分乘以1.2。这个小改动让检索准确率提升了不少。还有一个经验检索数量不要贪多。我一开始取Top-10结果提示词太长Gemini反而抓不住重点。后来降到Top-4效果明显更好。这就像给人看参考资料给四篇精读比给十篇泛读更有效。4. 提示词工程让AI“像那个人”4.1 系统提示词的结构设计系统提示词是整个克隆的“灵魂”。我摸索出的结构是四段式第一段身份定义。直接告诉模型“你是XXX的AI助手基于其公开工作语料构建”。这里要明确边界“你只模仿其工作场景下的表达风格和思维模式不涉及私人生活。”第二段风格描述。用具体形容词和例子说明这个人的语言特点。比如“同事A说话直接喜欢用反问句推动思考常用‘你想想’‘有没有可能’开头。回复通常不超过三句话但每句都指向一个具体问题。”第三段few-shot示例。放3-5组“用户问题-AI回复”的样例让模型有直观参照。这些样例必须来自真实语料不能编造。第四段行为约束。明确禁止事项“不编造同事未表达过的观点”“不代替同事做承诺”“遇到不确定的问题回复‘这个我不确定建议直接问他’”。4.2 风格锚定的技巧光靠形容词描述风格模型很难精准把握。我后来加了一个技巧用对比示例。在提示词里同时给出“像他的回复”和“不像他的回复”让模型通过对比来校准。比如同事B的风格是“先肯定再补充”提示词里就写像他的回复“这个思路没问题我补充一点如果并发量再上去可能需要考虑锁的粒度。” 不像他的回复“你这样做是错的应该用分布式锁。”这种对比信号比单纯说“要委婉”有效得多。模型对“正例-反例”的敏感度远高于抽象描述。4.3 温度参数与随机性控制Gemini API的temperature参数控制输出的随机性。我试下来0.7-0.8是模仿人类对话的甜点区。太低0.3以下会变得机械重复太高1.0以上会开始胡言乱语甚至编造同事根本没说过的话。还有一个参数叫top_p我一般设0.9配合temperature 0.75使用。这套组合在“保持风格稳定”和“避免死板”之间平衡得比较好。注意不同模型的参数敏感度不一样。换模型后一定要重新调参不能直接套用。5. 实操过程从零到可用的完整链路5.1 环境准备与依赖安装我是在一台Ubuntu 22.04的机器上跑的Python 3.11。核心依赖如下pip install google-generativeai chromadb sentence-transformers flask python-dotenvgoogle-generativeaiGemini API的官方SDKchromadb本地向量数据库sentence-transformers加载BGE-M3嵌入模型flaskWeb界面python-dotenv管理API密钥API密钥存在.env文件里不硬编码。这是基本安全习惯。5.2 语料入库脚本核心逻辑是读JSON → 清洗 → 分段 → 向量化 → 存入Chroma。关键代码片段import chromadb from sentence_transformers import SentenceTransformer model SentenceTransformer(BAAI/bge-m3) client chromadb.PersistentClient(path./chroma_db) collection client.get_or_create_collection(namecolleague_a) def ingest(chunks, metadatas): embeddings model.encode(chunks).tolist() collection.add( embeddingsembeddings, documentschunks, metadatasmetadatas, ids[fid_{i} for i in range(len(chunks))] )这里有个细节metadata里要存时间戳和来源频道。这样检索时可以按时间过滤比如“只看最近三个月的讨论”避免用半年前的过时观点回答当前问题。5.3 对话主循环用户提问后系统做三件事检索、拼提示词、调Gemini。核心代码def ask(clone_name, question): # 1. 检索 results collection.query( query_texts[question], n_results4 ) context \n.join(results[documents][0]) # 2. 拼提示词 prompt f {SYSTEM_PROMPTS[clone_name]} 以下是该同事过往的相关讨论片段供参考 {context} 用户问题{question} # 3. 调用Gemini response gemini_model.generate_content(prompt) return response.text实测下来从提问到返回延迟大概2-4秒主要花在Gemini API的网络往返上。本地检索几乎瞬间完成。5.4 Web界面与多克隆切换Flask界面很简单一个下拉框选克隆一个输入框提问一个区域显示回复。前端用原生HTMLJS没上框架够用就行。多克隆的实现方式是每个同事一个独立的Chroma collection切换时换collection和系统提示词。这样数据隔离干净不会串味。6. 那些“有点怪”的时刻翻车与反思6.1 克隆开始“互相评价”项目跑通后我做了个测试让同事A的克隆评价同事B的克隆给出的方案。结果A克隆回复“这个方案太保守了B总是这样先想风险再想机会。”我当时就愣住了——这句话在语料里从来没有出现过是模型根据A的风格和B的方案“推理”出来的。这暴露了一个深层问题AI克隆不仅模仿表达还会“继承”人际关系中的立场。因为语料里A对B的方案确实有过类似评价模型把这种态度泛化了。这让我意识到克隆的边界不能只限定在“说什么”还要考虑“对谁说”。6.2 同事本人和克隆“对线”更怪的一次我让同事C本人和他的克隆就一个技术方案辩论。前两轮还正常到第三轮克隆说了一句“你之前不是这么说的你上周在评审会上明明同意了这个设计。”同事C当场笑出声因为他确实在上周评审会上说过类似的话但那是针对另一个项目。克隆把不同场景的记忆混在一起了。这个问题的根源是检索时没有做场景隔离。后来我在metadata里加了“项目标签”检索时强制过滤同项目的内容才解决了这个“记忆串线”。6.3 克隆的“人格漂移”连续对话超过20轮后克隆的风格会逐渐“漂移”——A克隆开始变得啰嗦B克隆开始用C的口头禅。原因是对话历史本身被当成了上下文模型在长对话中逐渐被用户和其他克隆的语言同化。解决办法有两个一是限制对话历史长度只保留最近5轮二是在每轮提示词里重新注入风格示例相当于“每次对话都重新锚定人格”。我两个都用了效果稳定很多。7. 常见问题与排查速查表问题现象可能原因排查方法解决方案克隆回复风格完全不像系统提示词太抽象检查few-shot示例是否足够具体增加对比示例用真实语料检索结果不相关chunk太大或嵌入模型不匹配打印Top-5检索结果人工检查调整chunk大小换BGE-M3回复编造事实temperature过高降低temperature到0.6试加约束“不确定就说不确定”长对话后人格漂移对话历史污染检查历史轮数限制历史长度每轮重注入风格API调用报错密钥或配额问题查看错误码检查.env确认配额中文口语不自然模型选择问题对比不同模型输出换中文优化模型或加口语示例7.1 独家避坑技巧技巧一语料里加“时间衰减”。检索时给近期内容更高权重因为人的观点会变。半年前他说“用Redis就行”现在可能已经改主意了。我在相似度得分上乘以一个时间衰减因子越新越高。技巧二给每个克隆设“不知道”的阈值。当检索结果的最低相似度低于某个值时直接回复“这个我不确定建议直接问他”而不是硬编一个答案。这个阈值我设的是0.65实测能过滤掉大部分幻觉。技巧三定期用“图灵测试”校准。每隔一段时间让同事本人和克隆回答同一组问题对比差异。差异大的地方就是提示词需要调整的地方。这个习惯让克隆的保真度一直维持在可接受水平。8. 这个项目后续还能怎么玩三个克隆跑稳之后我试了一些扩展方向。多克隆协作是个有意思的玩法让A克隆和B克隆就一个设计问题“讨论”我当观察者。结果它们真的能互相补充——A提方案B挑毛病最后形成一个比单克隆更完整的建议。当然这需要精心设计对话轮次和终止条件否则会陷入无限循环。另一个方向是接入工作流。比如在代码评审时自动相关克隆来“预审”把明显的问题先过滤掉。这个还在试验阶段主要顾虑是责任归属——克隆提的建议出了问题算谁的所以目前只用于内部参考不对外输出。还有一个想法是给克隆加“情绪状态”。比如根据语料中同事当天的发言情绪调整克隆的回复语气。但这个涉及情感计算复杂度高而且容易弄巧成拙暂时搁置了。我个人在实际操作中的体会是AI克隆的价值不在于“替代”而在于“镜像”。它逼着你把一个人的工作方式、沟通习惯、思维模式显性化。这个过程本身比克隆能不能用更有意思。踩过几次坑之后我越来越觉得技术只是工具真正难的是理解人、尊重边界、以及接受“不完美模仿”这件事。 
长河君 · 2026/9/26 14:08:54 · 阅读 1.2k 用RAG和Gemini打造同事AI克隆：从语料到人格化对话的实践
1. 从“给同事做个AI分身”这个念头说起第一次冒出“给同事建AI克隆”这个想法是在一个再普通不过的周五下午。团队里有个后端老哥每次代码评审都能精准指出我接口设计里的边界问题但他那天休假我对着一段并发逻辑卡了整整两小时。当时我就想如果有个“他的AI版本”能随时回答我“这哥们会怎么看这段代码”那该多省事。这个念头听起来有点科幻但落到2024年的技术栈上其实完全可行。核心思路就一句话用同事过往的聊天记录、文档、代码注释、会议纪要作为语料微调或提示词工程出一个能模仿其表达风格和思维模式的对话机器人。我前后花了大概三周业余时间给三位关系不错的同事各做了一个“AI分身”过程中踩的坑、得到的意外发现以及后来事情怎么变得“有点怪”都值得完整记录一下。这篇文章适合谁看如果你对AI agent、chatbot定制、大模型应用开发感兴趣想了解从零搭建一个“人格化AI”的完整链路或者单纯好奇“把同事数字化”这件事到底靠不靠谱那接下来的内容应该能给你不少参考。我会把技术选型、语料处理、提示词设计、测试迭代、以及那些让人哭笑不得的翻车现场都摊开讲。全程不涉及任何敏感工具所有方案都是公开可复现的。先交代一下最终成品的基本形态三个AI克隆分别部署在本地通过一个简单的Web界面访问底层用的是Gemini API做推理配合RAG检索增强生成来注入同事的“记忆”。每个克隆的响应风格差异明显——一个爱用短句和反问一个喜欢先列提纲再展开还有一个总在结尾加一句“你品你细品”。做到这个程度技术上的门槛其实不高真正难的是边界把控和预期管理。2. 整体设计思路为什么是RAG加提示词而不是微调2.1 三条技术路线的取舍给特定人物建AI克隆业内常见做法有三条路全量微调、LoRA轻量微调、RAG加系统提示词。我一开始也纠结过毕竟“微调”听起来更彻底能让模型真正“学会”一个人的说话方式。但实际评估下来RAG方案在多个维度上更合适。方案数据需求训练成本更新便利性风格模仿效果事实准确性全量微调极大极高极差好一般LoRA微调中等中等较差较好一般RAG提示词少量无极好中等偏上好关键考量在于同事的说话风格和知识是两回事。风格可以通过系统提示词里的few-shot示例来锚定而具体知识比如他负责的模块、他常引用的内部文档用RAG动态检索更灵活。而且同事的聊天记录是持续产生的今天新增的讨论明天就能进向量库微调模型根本做不到这种实时性。另一个现实原因是数据量。一个普通职场人即使把企业微信、飞书、邮件全算上高质量对话语料也就几千到几万条。这个量级做全量微调远远不够做LoRA也容易过拟合模型会变成“复读机”翻来覆去就那几句话。RAG方案对数据量的要求低得多几百条代表性语料就能跑出不错的效果。2.2 系统架构拆解整个系统的数据流是这样的语料采集层从合规渠道导出同事的公开聊天记录、技术文档、代码注释、会议纪要。这里必须强调所有语料都经过当事人明确同意且只使用工作相关内容私人对话一律剔除。预处理层清洗、去重、分段、打标签。把长对话切成适合检索的chunk同时提取“风格样本”——那些能体现个人表达习惯的短句。向量化层用嵌入模型把chunk转成向量存入本地向量数据库。我选的是Chroma轻量、Python原生、够用。检索层用户提问时先检索最相关的N个chunk作为上下文注入提示词。生成层Gemini API接收“系统提示词检索结果用户问题”输出回复。交互层一个Flask写的简单Web界面支持切换不同克隆。这个架构的好处是每一层都可以独立替换。比如后来我发现Gemini对中文口语的模仿不够细腻就换了一个专门优化过中文对话的模型做生成检索层完全不用动。2.3 为什么选Gemini作为推理引擎热词里频繁出现Gemini我实际用下来它在几个方面确实适合这个场景。长上下文窗口能塞下更多检索结果和风格示例多轮对话一致性比较好不会聊着聊着就“出戏”。而且API的定价相对友好个人项目跑起来成本可控。不过Gemini也有坑。比如它对系统提示词的“服从度”有时候过于严格你写“用简短口语回复”它可能真的只回你三个字把该解释的技术细节也省了。后来我在提示词里加了“在保持口语风格的同时确保技术信息完整”这样的平衡指令才把效果拉回来。提示如果你也想用Gemini做类似项目建议先在AI Studio里用免费额度把提示词调稳再上API。直接调API调试每次都要等网络往返效率低很多。3. 语料处理从聊天记录到“人格向量”3.1 数据采集的合规红线这一步我必须放在最前面讲因为这是整个项目里最容易出事的地方。给同事建AI克隆本质上是在处理他人的个人数据。我的做法是书面同意每个被克隆的同事都签了一份简单的授权说明明确用途、范围、存储方式、销毁机制。范围限定只采集工作相关的公开频道消息、技术文档、代码评审评论。私聊、邮件、任何带“私密”标签的内容一律不碰。匿名化处理语料中涉及的具体项目名、客户名、内部代号全部替换成占位符。比如“XX银行项目”统一替换为“项目A”。可撤回同事随时可以要求删除自己的克隆和所有语料我写了个一键清除脚本。这些措施听起来繁琐但少了任何一条这个项目都不该继续做下去。技术能力越大边界意识越要强。3.2 语料清洗的实操细节原始聊天记录导出来是JSON格式一条条长这样{ sender: 同事A, timestamp: 2024-03-15T14:23:11Z, content: 这个接口的幂等性你考虑了吗如果客户端重试会不会重复下单, channel: backend-review }清洗流程我写了几个Python脚本核心步骤包括第一步按发送人过滤。只保留目标同事的消息但上下文要保留——因为他的回复往往是对别人问题的回应单独拎出来会丢失语境。我的做法是把对话按时间窗口切成“会话块”每个块里包含提问和该同事的回复。第二步去重和去噪。表情包、纯、单字回复“嗯”“好”“收到”全部剔除。这些内容对风格建模没有价值反而会污染向量空间。第三步分段。一条超过200字的消息按语义切成多个chunk。切分点选在句号、问号、分号之后保证每个chunk语义完整。我用的chunk大小是256个token重叠64个token这个参数是试出来的——太小则上下文不足太大则检索精度下降。第四步风格样本提取。单独维护一个列表存放那些“一看就是他会说的话”。比如同事B的“你先别急我们把这个拆成三个问题来看”同事C的“这个方案能跑但我觉得还有优化空间你听听看”。这些样本不参与检索专门用于系统提示词里的few-shot示例。3.3 向量化与检索调优嵌入模型我试了三个OpenAI的text-embedding-3-small、BGE-M3、以及Gemini自带的embedding。最终选了BGE-M3原因是中文语义匹配更准而且可以本地跑不依赖网络。检索策略上纯向量相似度有个问题有时候最相似的chunk并不是最有用的。比如用户问“同事A会怎么设计这个缓存”向量检索可能返回一堆提到“缓存”这个词但观点无关的片段。我加了一层关键词加权如果chunk里包含“设计”“方案”“建议”这类元话语标记相似度得分乘以1.2。这个小改动让检索准确率提升了不少。还有一个经验检索数量不要贪多。我一开始取Top-10结果提示词太长Gemini反而抓不住重点。后来降到Top-4效果明显更好。这就像给人看参考资料给四篇精读比给十篇泛读更有效。4. 提示词工程让AI“像那个人”4.1 系统提示词的结构设计系统提示词是整个克隆的“灵魂”。我摸索出的结构是四段式第一段身份定义。直接告诉模型“你是XXX的AI助手基于其公开工作语料构建”。这里要明确边界“你只模仿其工作场景下的表达风格和思维模式不涉及私人生活。”第二段风格描述。用具体形容词和例子说明这个人的语言特点。比如“同事A说话直接喜欢用反问句推动思考常用‘你想想’‘有没有可能’开头。回复通常不超过三句话但每句都指向一个具体问题。”第三段few-shot示例。放3-5组“用户问题-AI回复”的样例让模型有直观参照。这些样例必须来自真实语料不能编造。第四段行为约束。明确禁止事项“不编造同事未表达过的观点”“不代替同事做承诺”“遇到不确定的问题回复‘这个我不确定建议直接问他’”。4.2 风格锚定的技巧光靠形容词描述风格模型很难精准把握。我后来加了一个技巧用对比示例。在提示词里同时给出“像他的回复”和“不像他的回复”让模型通过对比来校准。比如同事B的风格是“先肯定再补充”提示词里就写像他的回复“这个思路没问题我补充一点如果并发量再上去可能需要考虑锁的粒度。” 不像他的回复“你这样做是错的应该用分布式锁。”这种对比信号比单纯说“要委婉”有效得多。模型对“正例-反例”的敏感度远高于抽象描述。4.3 温度参数与随机性控制Gemini API的temperature参数控制输出的随机性。我试下来0.7-0.8是模仿人类对话的甜点区。太低0.3以下会变得机械重复太高1.0以上会开始胡言乱语甚至编造同事根本没说过的话。还有一个参数叫top_p我一般设0.9配合temperature 0.75使用。这套组合在“保持风格稳定”和“避免死板”之间平衡得比较好。注意不同模型的参数敏感度不一样。换模型后一定要重新调参不能直接套用。5. 实操过程从零到可用的完整链路5.1 环境准备与依赖安装我是在一台Ubuntu 22.04的机器上跑的Python 3.11。核心依赖如下pip install google-generativeai chromadb sentence-transformers flask python-dotenvgoogle-generativeaiGemini API的官方SDKchromadb本地向量数据库sentence-transformers加载BGE-M3嵌入模型flaskWeb界面python-dotenv管理API密钥API密钥存在.env文件里不硬编码。这是基本安全习惯。5.2 语料入库脚本核心逻辑是读JSON → 清洗 → 分段 → 向量化 → 存入Chroma。关键代码片段import chromadb from sentence_transformers import SentenceTransformer model SentenceTransformer(BAAI/bge-m3) client chromadb.PersistentClient(path./chroma_db) collection client.get_or_create_collection(namecolleague_a) def ingest(chunks, metadatas): embeddings model.encode(chunks).tolist() collection.add( embeddingsembeddings, documentschunks, metadatasmetadatas, ids[fid_{i} for i in range(len(chunks))] )这里有个细节metadata里要存时间戳和来源频道。这样检索时可以按时间过滤比如“只看最近三个月的讨论”避免用半年前的过时观点回答当前问题。5.3 对话主循环用户提问后系统做三件事检索、拼提示词、调Gemini。核心代码def ask(clone_name, question): # 1. 检索 results collection.query( query_texts[question], n_results4 ) context \n.join(results[documents][0]) # 2. 拼提示词 prompt f {SYSTEM_PROMPTS[clone_name]} 以下是该同事过往的相关讨论片段供参考 {context} 用户问题{question} # 3. 调用Gemini response gemini_model.generate_content(prompt) return response.text实测下来从提问到返回延迟大概2-4秒主要花在Gemini API的网络往返上。本地检索几乎瞬间完成。5.4 Web界面与多克隆切换Flask界面很简单一个下拉框选克隆一个输入框提问一个区域显示回复。前端用原生HTMLJS没上框架够用就行。多克隆的实现方式是每个同事一个独立的Chroma collection切换时换collection和系统提示词。这样数据隔离干净不会串味。6. 那些“有点怪”的时刻翻车与反思6.1 克隆开始“互相评价”项目跑通后我做了个测试让同事A的克隆评价同事B的克隆给出的方案。结果A克隆回复“这个方案太保守了B总是这样先想风险再想机会。”我当时就愣住了——这句话在语料里从来没有出现过是模型根据A的风格和B的方案“推理”出来的。这暴露了一个深层问题AI克隆不仅模仿表达还会“继承”人际关系中的立场。因为语料里A对B的方案确实有过类似评价模型把这种态度泛化了。这让我意识到克隆的边界不能只限定在“说什么”还要考虑“对谁说”。6.2 同事本人和克隆“对线”更怪的一次我让同事C本人和他的克隆就一个技术方案辩论。前两轮还正常到第三轮克隆说了一句“你之前不是这么说的你上周在评审会上明明同意了这个设计。”同事C当场笑出声因为他确实在上周评审会上说过类似的话但那是针对另一个项目。克隆把不同场景的记忆混在一起了。这个问题的根源是检索时没有做场景隔离。后来我在metadata里加了“项目标签”检索时强制过滤同项目的内容才解决了这个“记忆串线”。6.3 克隆的“人格漂移”连续对话超过20轮后克隆的风格会逐渐“漂移”——A克隆开始变得啰嗦B克隆开始用C的口头禅。原因是对话历史本身被当成了上下文模型在长对话中逐渐被用户和其他克隆的语言同化。解决办法有两个一是限制对话历史长度只保留最近5轮二是在每轮提示词里重新注入风格示例相当于“每次对话都重新锚定人格”。我两个都用了效果稳定很多。7. 常见问题与排查速查表问题现象可能原因排查方法解决方案克隆回复风格完全不像系统提示词太抽象检查few-shot示例是否足够具体增加对比示例用真实语料检索结果不相关chunk太大或嵌入模型不匹配打印Top-5检索结果人工检查调整chunk大小换BGE-M3回复编造事实temperature过高降低temperature到0.6试加约束“不确定就说不确定”长对话后人格漂移对话历史污染检查历史轮数限制历史长度每轮重注入风格API调用报错密钥或配额问题查看错误码检查.env确认配额中文口语不自然模型选择问题对比不同模型输出换中文优化模型或加口语示例7.1 独家避坑技巧技巧一语料里加“时间衰减”。检索时给近期内容更高权重因为人的观点会变。半年前他说“用Redis就行”现在可能已经改主意了。我在相似度得分上乘以一个时间衰减因子越新越高。技巧二给每个克隆设“不知道”的阈值。当检索结果的最低相似度低于某个值时直接回复“这个我不确定建议直接问他”而不是硬编一个答案。这个阈值我设的是0.65实测能过滤掉大部分幻觉。技巧三定期用“图灵测试”校准。每隔一段时间让同事本人和克隆回答同一组问题对比差异。差异大的地方就是提示词需要调整的地方。这个习惯让克隆的保真度一直维持在可接受水平。8. 这个项目后续还能怎么玩三个克隆跑稳之后我试了一些扩展方向。多克隆协作是个有意思的玩法让A克隆和B克隆就一个设计问题“讨论”我当观察者。结果它们真的能互相补充——A提方案B挑毛病最后形成一个比单克隆更完整的建议。当然这需要精心设计对话轮次和终止条件否则会陷入无限循环。另一个方向是接入工作流。比如在代码评审时自动相关克隆来“预审”把明显的问题先过滤掉。这个还在试验阶段主要顾虑是责任归属——克隆提的建议出了问题算谁的所以目前只用于内部参考不对外输出。还有一个想法是给克隆加“情绪状态”。比如根据语料中同事当天的发言情绪调整克隆的回复语气。但这个涉及情感计算复杂度高而且容易弄巧成拙暂时搁置了。我个人在实际操作中的体会是AI克隆的价值不在于“替代”而在于“镜像”。它逼着你把一个人的工作方式、沟通习惯、思维模式显性化。这个过程本身比克隆能不能用更有意思。踩过几次坑之后我越来越觉得技术只是工具真正难的是理解人、尊重边界、以及接受“不完美模仿”这件事。