腾讯程序员把分身接进工作群，半个想法就能开跑

腾讯游戏数据团队负责人spike今年一直在建设自己的分身，也在工作中用得非常多。他养成了一个习惯：想到什么，就找一个当时顺手的分身聊一下。在电脑前可以深入讨论、查材料、改文件、跑实验；离开电脑，也能从手机上的企微或Htalk继续。

他经常只有半个想法，还没整理成一个完整问题，或者刚收到一份材料，觉得跟手上的事有关但没想清楚关系。先说给分身听，它去找相关背景，再一起往下想。需要查的继续查，能试的就动手试，没想完的可以先留下来。

让他看重的是接续能力。刚开完会，为什么改了主意、哪句话让他有疑问，当时记得比较清楚；如果要等回到某台电脑、找到原来的会话重新讲，可能只剩一个很简略的结论，甚至忘了继续聊。这些随手聊的内容里，有很多是正式文档不会留下来的背景和取舍。

一个案例把两个问题连了起来

9月中旬有一天，他口述了几个当天的讨论，其中一个问题是：怎么进一步让用AI更深入的同学带动其他人。他当时在想，像游戏里有人升级快、有人升级慢，产品能不能帮助那些先跑出来的人进一步带动团队。

同一天，经分团队的同学同步了一个实践：把数据服务Agent挂载在内部的HTalk上，开发了一个WorkBuddy专家，接到用户自己的WorkBuddy里。业务团队的用户在原来的工作流程中需要数据，只需在自己的WorkBuddy里提需求，需求就会进入一个有经分同学、也有数据Agent的工作企微群；中间补充背景、确认口径，完成后再把结果拿回去继续用。

他关注的是，这个做法把原来散在几个地方的context连起来了：用户自己的分析、提交的需求、经分的执行、群里的沟通，都能沿着同一件工作接下去，而且不用切场景。分身读完后提醒他，这个案例其实也是他前面思考的“传染机制”的一种具体实现。

经分同学已经把自己的知识、工具和处理方法建设进了Agent。其他同学在原来的工作里调用这份能力，就能先获得帮助，过程中再补充业务背景、提出反馈。他们不必先学会经分同学整套建设方法，也不需要学习怎么使用经分的Agent，也不需要使用HTalk，就能开始受益。

这让他把原来的问题往前推了一步：带动别人，除了把方法教给他，还可以让他更无痛地先用上已经建设好的能力。产品要支持的事情也更具体了——熟练者能不能方便地把能力交出去，使用者能不能在自己的工作里用起来，出了问题能不能找到人，反馈能不能再回到维护者。

从想法直接进入实验

最近他在关注Jev模型，想看看它能不能帮忙先判断工作群里的消息：哪些需要他关注，哪些可以让Agent准备一下，哪些应该等已有负责人处理。

他把一个Jev模式的小模型在本机跑起来之后，让cb-a分身结合他的背景，通过HTalk读取相关消息，整理样本、写调用脚本、跑几轮测试，再把有分歧的地方拿出来看。小模型负责给出候选判断，cb-a分身负责组织实验和检查结果，他来校准那些跟实际工作有关的取舍。

第一轮实验后，分身拉到的消息里有三条，他给了很具体的反馈：

• 一条是他问一个方案的实际应用情况，同事说已经在用了。他的意思是还可以帮忙收集具体怎么用、效果怎样，必要时问详细一点，而分身只把它归为“知道了”，没有接住他想了解什么。
• 另一条是有人报告问题，已经明确找了对应的负责人。这时他希望先让负责人处理，Agent不需要因为看到了问题，就再替他接一遍。
• 还有一条，他请同事比较两份材料，对方回复“好的”。这时值得记住的是对方已经承接、还没有反馈结果，后面要跟进，不能把这句“好的”当成事情已经完成。

把这些说清楚之后，他们又调整了判断选项和示例，拿回去测试。有些地方改善了，有些仍然不稳定，甚至只调整候选项的排列顺序，也会影响部分结果。这次还没到可以放心自动处理的程度。

但这轮工作让他更清楚地看到，“理解我的bias”要落实在哪里：它要知道这件事当前到了哪一步，他在其中是什么角色，谁已经负责了，以及他希望它补上的那一步是什么。“主动一点”这样的要求太宽了，真实工作里，有该主动了解的，也有该记住等待的。

这个案例里，他只给了想法，读群聊资料上下文、选取组织样本、编写适配的调用脚本、保存返回、检查错例，分身都能直接开始做。他主要参与的是：想验证什么，哪些判断不符合他的意图，结果是否足以支持下一步。一个想法就有机会很快进入验证，哪怕最后发现暂时还用不好，也会比一直停留在讨论里多知道一些东西。

环境、规则与多设备协同

能这样做，跟他给分身准备的工作环境有很大关系。他让它工作的地方本身就放着他持续积累的资料，现在主要是一个仓库：背景、当前关注、过去的讨论、会议记录、一些外部材料，以及做过的实验和产物都在其中。工作群里的信息通过HTalk按权限去取；环境里也有文件、代码执行和其他工具能力，具体能做什么要看那个环境接了什么。

资料放进去了，它也未必就能用好。刚开始他想过把所有重要的东西都让它读一遍，后来内容越来越多，默认带进去的东西会互相干扰，旧重点也容易压住新问题。现在他把内容分开处理：相对稳定的背景和取舍、当前正在推进的事、完整的历史材料，各有自己的位置；近期进度及时留下来，旧材料通过索引按需找，需要核对时回原文。

比如只留下“最后决定做A”，下一次它很容易理解成他一直偏好A。但当时也许只是资源不够，或者另一个方案有个前提还没验证。于是他会要求把为什么这样选、讨论过什么别的办法、后来哪里改了也尽量留下来，条件变了才有机会重新判断。

分身本身怎么调，也是在用的过程中逐步摸索的。早期回答一次不满意，他就容易加一条要求：不要过度赞同，不要给空泛建议，不要回避矛盾。加多了之后，它越来越小心，但遇到新问题还是不知道怎么取舍。后来他把这些要求拆开了：背景和当前重点放在USER里，遇到冲突时更在意什么放在SOUL里；文件写到哪里、哪些动作需要确认，放进操作规则；某一类任务怎么做，单独整理成SOP或Skill，遇到这类工作再读。

多设备、多分身这部分也踩过不少坑。3月份开始，他在两台电脑上用同一个仓库，后来又把它用CodeBuddy接进了带企微、微信入口的Claw。使用过程中偶尔出现两边都说记下来了，结果一个写在工具自己的目录，另一个写在仓库的memory目录，双方根本没在读同一份东西，后来才把路径统一写进操作约定。再后来他增加了AnyDev的云端分身，减少对某一台电脑在线状态的依赖，同步过程中也遇到过新文件传过去了、已有记录却没有及时更新的问题。

还有一个更容易忽略的问题：即使读的是同一份仓库，两个分身也各有自己的会话Session。刚才为什么否定一个方案、哪个问题还在犹豫，如果只留在当前会话里，另一个分身就未必知道。所以除了长期记忆，他还让各个分身留下近期的工作状态，仓库里叫live，记录刚处理了什么、有哪些变化、哪里还没结束，需要时再回到完整笔记和原始材料。需要定向交接的，也可以留在各自的收件箱里。

几个人同时改一份文件都会有问题，几个Agent也一样。谁写自己的近期记录、谁维护共同文件，追加前先看最新内容，保留写入来源，这些后来都逐步有了约定。尤其是还在讨论的推断，不能因为被写进记忆，就变成他已经确认的结论。

用久之后，他还有一种很喜欢的方式，叫“洗澡时刻”。人有时候洗澡、散步，暂时不急着解决一个具体问题，反而会把之前没连起来的事情想通。他就想让分身也试试：先放下手上的明确任务，看看最近这些事情之间有没有他没注意到的联系。

这需要它先有东西可看。一部分来自日常积累：工作讨论、会议记录、随手想到的问题，以及一起做事时的补充和纠正，尤其是还没想完的事情，他会尽量把当时为什么卡住、有哪些不同考虑留下来。另外他还接了一些RSS信息源，涉及AI工程、产品、商业、组织管理，也有跟他观点不太一样的作者，通过自动化定期抓取新内容，分身先做一轮筛选，留下来源、摘要，以及为什么可能值得他关注。

他跟分身说一句“洗澡时刻”，它就知道这次先不用赶着交付什么。它会从最近的工作、当前关注和未完成的问题开始，沿着线索回看更早的记录，也可以把相关的外部材料放在一起看：两件看起来没关系的事情是不是遇到了同一种问题，他最近的一个决定跟之前坚持的判断有没有矛盾，新看到的一个案例会不会改变某个一直没验证的前提。

有一次，它回看了几周的讨论，提出一个怀疑：我们是不是太习惯用同一套框架解释新材料了？每次看到新的产品、文章、管理案例，最后都能归到原来那几个判断里，看起来理解得越来越通，但有没有一些不同的东西被忽略了。这个提醒也包括RSS——引入外部信息之后，如果每篇文章都被解释成“又验证了我原来的想法”，那还是可能绕回自己熟悉的框架里。

几个分身之间有时也会给出不同的解释，它们参与过的讨论不完全一样，模型和运行环境也可能不同。他会把一个分身的意见拿给另一个看，再比较分歧在哪里。有次他觉得最近跟某个分身聊少了、重新解释的成本变高，讨论到后来，他们把“不了解我”拆开了：有的是不知道这件事刚推进到哪，有的是旧资料没更新，还有的才是对他的取舍理解不够。分清楚，后面才知道该补状态、更新记录，还是拿具体问题继续校准。

这个过程中，他仍然要看依据。几个Agent都赞同，也可能是读了同一份有问题的摘要。他们就遇到过，还在讨论的推断被提前写成他的结论，另一个分身再读到，就可能把它当成确定的前提往下推。前面那些来源和确认状态的约定，也是在防止这种事情。

回头看这半年，对他比较大的变化是：想到一个问题时更容易马上开始；决定往下做时，分身可以把查找、整理、执行和验证的一部分实际接过去；过一段时间再回来，之前花过的精力还能继续用。他仍然要参与判断，也要花时间纠正它，但越来越多的事情可以带着他的背景和关注点先被认真处理一遍，他再把精力放在有分歧、需要取舍或者出现了新东西的地方。