我搭了个AI分身，专门回复项目群里的问题

我同时管着三到五个项目的时候，最耗人的不是开会。群里客户会有各种灵魂拷问：

我给自己做了套只有项目经理用的小系统，再给每个项目群接上一个 AI 分身。分身就是接在群里的 Agent，能去后台查项目进度、查问题清单、查文档手册，必要时把文件发回群里。这套东西跑了三个月，现在还算稳。

AI 分身能不能替我挡群，要三件事绑在一起：这个群只看见自己那一库，这个群绑死一条Agent上下文会话，这个群的人设只覆盖它该怎么说话。 后台使用什么模型不是最重要的，对模型的约束才是这个事情的关键。to B业务，错误的回复有时候堪称P0级事故。

01 群里问的，后台得先有

客户在群里问计划进度，分身去我那套小系统里取。系统里就这些：项目文档、项目计划、项目进度、缺陷和问题清单，再加产品标准手册和这个项目自己的定制说明。没有这些记录，分身也就没有说话的依据。

客户要以前某份过程资料，分身会从对应项目的库里把文件发回去。发的只能是这个项目库里的东西，别的项目碰不到。群里也会问操作路径，比如上传几篇文档之后想做 FAQ，该点哪里。这类问题去手册里找现成步骤，比让我再截一遍图省事。

问题清单同样要能被查到。群里问“上周文档问答不准确，最后定位到问题了吗”，分身得看见当时的场景、当前状态、已经试过的办法，再组织成一段能对上的解释。如果后台清单是空的，AI分身就只能一头雾水。

群里的 AI 分身，查的是项目经理已经维护过的记录，不是凭空生成进度。 计划没更新、缺陷没登记、手册是旧的，它回得再快也是错的。

分身在群里有两种开口方式。一种是被@才说话，一种是自己认出群里在问事，再插话。用哪一种，看项目走到哪一步。

中早期文档少，待办也薄，客户还没把“群里有个能问的分身”当回事。这个阶段我只让它被@才答。我会主动@它，让客户看见它能查什么、不能查什么。习惯要先养起来，资料够了再放开。

到了中后期，手册、问题清单、计划都在库里了，客户提问也更冲着具体事项来。这时候可以交给它自己判断：这句话是在问进度、问缺陷，还是问操作。认准了再回，认不准就闭嘴。

如果一上来就让它在群里自由插话，早期最常见的结果是抢话、答浅、把还没定的事说死。@是开关，也是给客户的提示：这个分身在，但你得把它当一个会查后台的助理，别当群里的第二个人。

每个项目单独一库，库和库的权限是隔离的。每个群绑自己的库，每个用户也可以绑到对应的库。这一步做完，它就看不到隔壁项目的手册和缺陷。

真出事往往出在会话上。同一个 AI 会话里如果回过两个项目的事，上下文里就会带着两套计划、两套问题。下一句问进度，它可能把这个项目的节点接到另一个项目的群里。我后来改成一个群一条会话，这个群的上下文就一直是这个群的。

每次回答前，我还会把这个群最近三十条到五十条记录喂给模型。会话太长了，Agent 会把旧上下文收一层，不另开一条新会话。压缩这件事现在跑得比较稳，省掉的是“另开窗口结果把两个项目聊到一起”。

一库一群还不够，还要一群一条会话。 库负责它能看见什么，会话负责它此刻还记着什么。两处有一处共用，串项目的风险就还在。

人设写进上下文的，主要是身份背景、说话方式、禁忌事项。不同项目群里坐着的人不一样，同一套活泼语气不能到处套。

有的项目除了我们公司，还有伙伴公司和客户。这种三方群里，哪些能当众说、哪些要先内部对一下，项目经理自己都要留神。分身没有这层禁忌，就可能在群里把还没对齐的口径说出去。人设要写死的，就是这类边界：只答本项目，不确定就标明查过哪类记录，不替人承诺工期，不替伙伴表态。

敏感资料也一样。分身能发文件、能读缺陷，不代表群里每一句都该自动回、每一份都该自动发。拿不准的，留给人。

在开发过程中，群里有时会丢来一段入参，说按手册调接口没成功。客户说的“有问题”，多半指他们的测试环境或生产环境。我们做定制功能时，会在公司内部服务器上搭开发环境，产品标准接口和项目定制接口，这里都能调。

分身能做的，是拿客户给的入参和地址，在自己公司的开发环境走一遍。这里过了，就把整段调用结果，连同 JSON，发回给客户对照。客户那边仍对不上，交给开发人员去看对应的测试环境或生产环境。

客户系统的网络一般都有堡垒机网络隔离，也有安全合规要求，Agent的手伸不了那么长，它能验的是入参和地址在我们自己的开发环境里站不站得住。环境差异、权限、现场网络，还是人接着看。

AI 分身在这里是查记录、对入参、把文件从本项目库里递出去的助理。对外承诺、三方口径、测试和生产上的最终结论，还是项目经理和开发的事。

如果你也同时对接了好几波客户，想给自己搭一套管理用的后台，欢迎加我微信我们一起交流，我是张坤，一个用AI“偷”时间的实践者。