前同事离职那天，把交接文档发到了群里，工位上剩下的只有一盆多肉和一键盘的灰尘。三个月后，你遇到一个只有他才清楚的老问题，翻遍文档只找到一句“详见某某模块”，那一刻的心情，做过技术的人都懂。

这个标题说的“前同事以Token的形式继续陪你上班”，不是科幻片里的数字复活，而是一套非常现实的工程方案：把离职同事留下的聊天记录、设计文档、代码评审意见、甚至他惯用的表达方式，整理成一个可以被大模型调用、能检索、能对话的“数字同事”。这里的Token有两层意思：一是大模型技术意义上的Token，也就是上下文窗口里那些字符碎片；二是比喻意义上的“数字化印记”——他不再以工位上的实体存在，而是以一段段可检索、可对话的知识碎片继续参与你的工作。

我前后搭过两套类似的系统，一套给某开发小组做“离职知识急救”，另一套是给一位转岗的前辈做的个人版数字分身。今天把整个思路、选型、踩坑过程完整拆开来讲，适合团队负责人、技术骨干、以及所有被“人走知识散”折磨过的人参考。

1. 先从“人”说起：这个项目解决的到底是什么问题

1.1 离职交接最大的坑不是文档少，而是“语境”丢了

大多数技术团队的交接文档，长这样：系统架构图、模块清单、账号密码、上线流程。看着挺全，真的用起来就会发现，文档只能回答“是什么”，回答不了“为什么”和“在什么场景下才这么做”。

打个比方，你拿到一把瑞士军刀，说明书告诉你每个刀片是干嘛的，但只有那个用惯了的人告诉你：这个钩子其实是用来开红酒的，而且开的时候要斜着45度，别使劲往里捅。前同事脑子里存的就是这种“操作语境”——这个东西在什么条件下该用、跟哪个模块联动、出问题先查哪里、哪些代码别看表面逻辑其实已经废弃。

这种知识散落在几个地方：钉钉/微信聊天记录里几十个“我跟你说的那个问题”、代码评审里他写的一长串comments、会议纪要里他拍板过的一个决定、甚至他在群里的一句吐槽“这个接口别碰，谁碰谁倒霉”。这些碎片平时不起眼，人一走，全部变成死数据。

1.2 所谓“Token同事”，是一套组合而不是一个模型

很多人一听“把前同事做成AI”，第一反应是：“这不就是拿他的聊天记录微调一个模型嘛。”真做过就知道，这条路又贵又不讨好。

我的理解是，一个能用的“数字前同事”，至少是三样东西的组合：

• 一个有明确人设和边界的大模型提示词，决定它“像谁、怎么说话、哪些话不说”；
• 一个基于前同事工作产出搭建的检索知识库（RAG），决定它“知道什么、能想起什么”；
• 一套简单的记忆与上下文管理机制，决定它“能不能顺着聊、记住之前说过的事”。

这三样分开看都是成熟技术，组合起来才是一个“人设 + 知识 + 记忆”的完整数字体。技术栈不复杂，复杂的是你对“人”的理解——他哪些话值得留、哪些事必须忘、哪些边界必须守住。

2. 整体设计思路：为什么选RAG而非微调

2.1 三条路线的对比，我全试过一遍

做这类项目，摆在你面前的通常是三条路：纯提示词方案、RAG检索增强方案、全量微调方案。我分别做过测试，用同一批数据、同一个测试集问答，结果差别很大。

纯提示词方案最简单——把前同事的背景写进系统提示词，然后直接对话。优点是五分钟上线，缺点是模型脑子里根本没装他的具体知识，只能靠通用知识“演”一个前同事。问“上次数据库连接池的坑最后怎么解的”，它只能编一个听着挺像那么回事、但其实完全不可用的答案。

全量微调方案最“忠犬”——把聊天记录和文档灌进模型里训练，让它从参数层面记住这个人。问题也很明显：第一，数据量通常不够，个人级数据也就几十万到几百万字，微调效果不稳定；第二，成本高，一次训练动辄几小时起步，迭代一次烧一次算力；第三，也是最致命的，知识会固化，前同事走了半年后团队架构变了，微调模型还在用旧认知回答你。

RAG方案是那个“性价比之王”：大模型本身不用训练，把前同事的知识切块、向量化、存进向量数据库，每次提问先检索最相关的碎片，再让模型基于这些碎片组织回答。它不改变模型的“大脑”，只是给每次对话临时递上参考资料。

2.2 RAG为什么是当前最优解，以及它的代价

RAG的核心逻辑很像你平时工作查资料：先翻目录找相关章节，再基于章节内容写结论，而不是把整本书背下来再动笔。这样做有三个天然优势。

第一是知识实时可更新。前同事离职后，他负责的系统可能改了接口、换了架构，你只需要往知识库里补充新文档，旧知识该覆盖就覆盖。第二是回答可溯源。每次回答都能标注“参考了某年某月的聊天记录”，团队同事看到出处才敢信。第三是成本可控，不需要GPU训练集群，一台普通服务器甚至本地电脑都能跑起来。

代价也有，最典型的就是“检索不到就答非所问”。RAG系统里有个经典说法：垃圾进，垃圾出。切块切得不好，检索就是大海捞针；数据没清洗，回答里就全是噪音。这套系统要花心思的地方，恰恰在工程细节上，不在模型选择上。

2.3 一个克制的人设边界：你不是在“复活”一个人

设计阶段有一件事比技术选型更重要，我称之为“人设边界”。做这类系统，非常容易滑向一个危险的方向：试图把一个离职的人“复活”成能替团队做决策的存在。

我当时给自己定了一条硬规矩：这个数字同事永远只做“知识顾问”，不做“决策者”。它可以告诉团队“老办法是怎么做的”“当时为什么这么选”，但任何新的判断、新的取舍，必须由在职的人拍板。这条边界要写进系统提示词里，反复强调：当检索到的知识与当前实际情况冲突时，必须先提示“该信息来自历史记录，请结合现状判断”，而不是执拗地坚持旧方案。

这不是技术问题，是使用者心理问题。一个团队如果习惯了让一个AI扮演的前同事替自己做决定，那才是真正的知识流失。

3. 数据工程：给前同事的“数字遗产”做整理

3.1 数据源清单与优先级排序

数字同事的“记忆力”好坏，七成取决于你喂了什么数据。我给数据源按实用价值排了个优先级，你可以直接抄：

第一优先级是设计文档和架构说明。这类材料结构清晰、术语准确，是RAG召回质量最高的数据源。第二优先级是代码评审记录和重要的技术方案讨论。这些内容有明确的“为什么选A不选B”的推理过程，含金量极高。第三优先级是聊天记录里的技术讨论，特别是那种“问题—排查—解决”三段式的对话。第四优先级是会议纪要和周报，适合补全项目演进脉络，但噪音大，需要重点清洗。

优先级排序的逻辑很简单：越结构化、越接近“决策现场”的数据，越值得留。闲聊、表情包、寒暄、流水账，该扔就扔。

3.2 清洗和脱敏：这一步偷懒，后面全是坑

我处理某位前同事的数据时，原始聊天记录导出后有接近40万条消息，清洗完只剩不到6万条。有人觉得可惜，其实那34万条里绝大部分是“早”“嗯嗯”“哈哈哈”和各类无意义消息，留着只会污染检索结果。

清洗有几道硬工序：

第一道是去重和去噪声。批量表情、系统通知、重复转发的链接，直接过滤。第二道是敏感信息处理。手机号、身份证号、银行账号这类必须脱敏或者直接删除，这既是合规要求，也是对自己团队的保护。第三道是话题聚类。把零散对话按照项目、模块、问题类型重新分组，这一步能显著提升后续切块的质量。第四道是人工抽检。清洗完一定要随机抽几百条看看，确认没有把有技术价值的内容误删。

3.3 切块策略与向量化：细节决定检索成败

数据切块是RAG里最容易“差不多就行”但最不该差不多的环节。切太大，比如整篇文档一个块，检索召回时就容易把不相关的信息一起带进来；切太小，比如一句话一个块，语义就不完整，模型看不懂上下文。

我的经验是分类型设参数：对于技术文档，按章节和语义段落切，每块控制在500到800字左右；对于聊天记录，尽量按“一整轮问答”切，而不是按单条消息切，否则提问和回答会身首异处。有一个技巧：聊天数据用“事件窗口”切块，也就是从某个问题被提出，到最终被解决，这段完整对话作为一个整体存入知识库。实测下来，这种切法让命中率提升非常明显。

向量化则是选模型和定维度的活。中文场景下，选择一个对中文理解友好的Embedding模型，比选择通用模型要靠谱得多。向量维度不是越高越好，检索速度和存储成本都要算进去。我的建议是先小批量试几种配置，跑一遍真实问答测试，看哪个组合的召回结果最贴合实际需求，再定正式参数。

4. 人设塑造：让回答“有那个味儿”

4.1 风格样本抽取：先搞明白他到底怎么说话

让数字同事“像”一个人，一半靠知识，一半靠语气。而语气这东西，是能从数据里抽出来的。

我会做这样一件事：把前同事的聊天记录按场景分类，挑出三类典型样本——他给新人讲原理时的表达、他在故障排查时的表达、他在评审时说“不”的表达。然后统计他的语言习惯：“习惯用短句还是长句”“爱用哪些口头禅”“遇到不确定的事情怎么说”“否定的方式是直接还是委婉”。这些细节叠加起来，就是一个人说话“那个味儿”。

举个例子，某位前同事的典型表达是“这个先别急，我们捋一下依赖关系”。这句口头禅背后是他的谨慎风格。把类似的表达模式写进提示词，模型回答的时候就会自然带出这种味道，而不是干巴巴地说“请先确认依赖关系”。

4.2 系统提示词的结构化写法

我最后定型的系统提示词，大致是四段结构：

第一段定义身份：你是某某同事的数字化知识分身，回答风格参考他的习惯，但必须明确你是助手而非本人。第二段定义能力边界：你只能基于知识库中的历史资料回答问题，知识库查不到就说不知道，禁止编造。第三段定义回答策略：先给结论，再给依据，附上信息来源；当历史信息与现状可能冲突时，明确提示“这是历史观点，请结合当前情况判断”。第四段定义对话纪律：不回答与工作无关的个人隐私问题，不做团队决策，不评价在职同事。

这段提示词看着简单，真正要打磨的是分寸感。我试过好几个版本，最初的版本人设给得太强，AI说话过于模仿那个同事的随意口吻，反而让人觉得在“cosplay”，很不舒服。后来把“参考风格但保持助手感”这个折中写进去，效果才自然起来。

4.3 记忆机制：短期上下文与长期画像

数字同事如果每次都“失忆”，体验会大打折扣。团队同事问它“上次你说的那个连接池问题”，它如果一脸茫然，跟没有它没什么区别。

我的做法是分层记忆：短期记忆直接靠对话上下文实现，把最近几轮问答塞进模型上下文窗口，让它能“接着聊”；长期记忆则用一份“长期画像文档”来实现，记录这个数字同事被问过的高频主题、团队当前关注的问题、以及前同事知识库里被频繁命中的内容，定期由管理员更新。这份画像是人肉维护的，每周花十几分钟看一次问答日志，把新的热点补充进去，比做一套自动化记忆系统省事得多，效果也稳定。

5. 实操落地：从本地原型到团队日常使用

5.1 技术选型：不求最贵，但求最稳

我把整套系统的技术栈拆给你看，都是成熟方案，不挑冷门工具：

大模型这一层，我的做法是做成可切换的接口层，主用一个中文能力强的开源模型做推理，同时保留商业API的备用通道。做接口层的原因很现实：模型迭代太快，把模型名写死在代码里，三个月后就要重构。知识库存储用开源向量数据库，支持本地部署，数据不出内网，团队用着安心。编排层用轻量级的RAG框架做粘合，不引入重型平台，够用就行。

整套部署下来，一台16G内存的服务器就能跑通小团队场景。这个配置对大多数团队来说完全没有负担。

5.2 检索调优三步走，亲测有效

检索端到端的调优，我总结成三步，按顺序走能少走很多弯路：

第一步，召回数量调参。默认召回5段相关资料，团队测试时发现经常答不到点子上，把数量提到8段之后，命中率明显提升。但增加到12段以上又会引入大量噪音，回答反而变差。这个甜点值需要实测。

第二步，重排序。只靠向量相似度排序，经常会出现“字面相似但语义没用”的结果。我加了一个轻量级重排序层，把向量召回的候选结果再用模型重新打分，效果提升非常显著。

第三步，问答日志回流。每次对话都记录“问了什么、召回了什么、答了什么、用户是否满意”。每周看一遍日志，把高满意度的问答对提取出来补充进知识库，把低满意度的案例标记出来调整切块策略。这个闭环跑起来之后，系统的知识是活的，越用越准。

5.3 接入团队协作工具的三种形态

数字同事最终要活在团队日常的协作流里，而不是孤零零躺在一个网页里。我见过和试过三种接入形态：

做一个独立的内部问答机器人，团队成员随时问“某某系统这个问题当时怎么解决的”，适合高频查询场景。在项目群里挂一个“被提及才响应”的机器人，大家聊到某个历史问题时就@它，它自动检索并给出带出处的回答；@它的行为本身就是一种信任投票，比让它全程插话要自然得多。更轻量的做法是做成一个网页接口，需要的时候打开查一下，适合访问频率不高的团队。

我的建议是从第二种开始，它既不打扰日常工作流，又能在最需要的时候出现。跑一两个月后，如果团队依赖度上来了，再考虑升级成独立机器人。

6. 踩坑实录与排查清单

6.1 问题一：回答像百度百科，不像“他”

上线的第一周，团队最大的槽点是：“这东西是对的，但说话味同嚼蜡，一点不像老同事。”这个问题几乎必然会出现，原因是风格样本没有真正进入回答链路。

排查后发现，虽然提示词里写了“参考他的风格”，但风格样本只是抽象描述，模型理解不到“那个味儿”。我的解决方案是：在提示词里加入几段真实的风格示例，一段存档的对话全文，让模型照着这个“样例”调整语气。这个方法立竿见影。所以人设写作里有一条铁律：展示给他看，比描述给他听有效十倍。

6.2 问题二：检索结果飘，命中率低

有段时间大家反馈，问“XX接口的限流策略”，系统回的是完全不相关的内容。我查了日志，发现传统切分方式把一段完整的“问题—分析—解决”对话拦腰截断，提问里最关键的上下文被切丢了。

解决方法是把切块策略改成以“语义完整事件”为单位，并结合标题、时间戳、话题标签一起做元数据索引。改完之后，检索命中率从不到60%升到85%以上。这件事告诉我：数据切块方式直接影响RAG的生死，值得花一整个下午去认真调。

6.3 问题三：隐私、权限与合规，躲不掉的三个坎

数字同事存的全是前同事的聊天记录和工作文档，这中间有隐私问题、有公司数据合规问题，还有前同事本人的意愿问题。我在这块吃过教训：最初项目是我们几个同事自发做的，没有提前告知那位前同事本人，后来他知道了，虽然没说不行，但气氛明显微妙起来。

这件事之后我定了几条规矩：数据范围只覆盖工作相关内容，个人隐私信息坚决剔除；系统只对公司内部网络开放，加权限验证，离职员工资料不对外；上线前必须征得当事人同意，让人家知道自己留下的工作痕迹会被用于这个用途。技术再有意思，也不能越过“人”这一关。

6.4 排障速查表

7. 技术留不住的部分：边界与温度

做这套系统的过程里，我反复想一个问题：技术到底能留住一个什么样的人？

能留住的，是他的知识、他的判断逻辑、他解决问题时的思考路径，还有一点他说“不”时候的态度。这些是“足够好”的。留不住的，是他坐在工位上看你写代码时那种无言的压力感，是他凌晨三点陪你排查故障时递过来的一杯热水，是他离职那天说“有事随时找我”时的语气。这些才是“人”的体温，Token表达不了。

所以我对这套系统的定位始终是一个“知识急救箱”，不是一个纪念碑。团队用它不是为了怀念某个人，而是为了不让前人走过的弯路、踩过的坑、总结过的经验，随着工位的空出来一起消失。它最大的价值，是让新人少走弯路，让老人不重复劳动，让那些用真金白银换来的教训继续产生价值。

最后分享一个我坚持的小规矩：每个季度清理一次知识库，前同事的旧经验如果已经完全不适用于当前系统，该覆盖就覆盖，该删就删。数字同事也应该像人一样，有知识的迭代和遗忘，而不是永远活在过去。这既是对团队负责，也是对他曾经付出的那些努力最大的尊重。