一个课题组要找人，通常是几个人在忙：导师心里有个大致范围，师兄手里有一串可能合适的人名，负责外联的同学在想这封邀约该怎么发。麻烦在于，这些人的信息很少在同一处——范围在会上说过一遍，名单在某人的笔记里，要用的简介还得再问一遍。等到汇总时，往往谁也拿不出一份完整的。
这件事的本质不是人不够勤快，而是没有共同的工作台面。人才画像解决的是「一条记录凭什么可信」，共研工作坊解决的是「这份可信的记录放在哪儿、由谁共同维护」。这篇拆的就是两者接上的那一截。
01 名单散在聊天里，和沉淀在项目组里
▲ 图 1｜差别不在谁记得多，而在能不能被下一个人接着用
先说最直观的差别。 名单散在聊天与邮件里时，每个人都在自己的文档上加几笔，汇总时版本对不上是常态：同名的人被写成两条，同一个人出现两种写法，事后很难追出是哪一版。放进项目组之后，事情变成只有一份——谁加的、什么时候加的、当时依据什么，都留在同一个空间里。
存疑的处理方式也跟着变了。分散整理时，拿不准的那条往往含糊带过去就算了；在共享底稿里，对不上的人名可以单列一档，明明白白地告诉后来者「这条没核实」。宁可留着待核验，也好过把来源不清的记录混进正式名单。
交接成本是第三个差别。换个人接手课题，散在聊天里的上下文要重讲一遍；项目组里的对话、智能体与文件都在，下一个人打开就能接着干。
02 三个标签，各接住一截
▲ 图 2｜成员、智能体、文件三类对象，共享同一份上下文
成员这一层回答「谁在参与」。项目创建人与普通成员在列表里被区分开，分工是显式的：导师定范围，师兄补人选，外联负责把材料发出去。角色清楚了，谁该补哪一段就不用反复商量。
智能体这一层回答「谁来整理」。项目组可以绑定智能体，成员在输入框打 `@` 就能唤起。对找人这件事来说，用处在于把各自补来的一堆名字按同一套字段整理一遍——基本情况、受教育情况、任职履历、主要科研成果，逐项对齐成列，而不是各写各的一段。在 MuchSci 的项目组里，这一步发生在讨论的同一个地方，不需要把名单搬进搬出。
文件这一层回答「成果落在哪」。候选名单、整理好的档案、成稿的邀约材料，都随项目留存，不会被新的聊天消息冲走。讨论时可以直接引用材料，而不是抛一个链接让大家自己找。
03 一份共享底稿，是这样长出来的
▲ 图 3｜从建组定范围到成稿进文件区，六步都在同一个空间里
流程大致是六步： 为一个招人课题开一个项目组，先把范围说清楚；成员各自往里补人，先不急着整理；在聊天里 `@` 绑定的智能体，让它按四类字段批量补档；对拿不准的记录单列一档，标待核验，不进正式名单；整理好的档案放进文件区，成员共用同一份；由熟悉情况的人再过一遍。
其中值钱的是「不完整也被允许」。待核验这一档的存在，说明整理过程承认自己会不确定。共享底稿如果只允许写确定的内容，成员就会把存疑的干脆删掉，反而丢掉线索。
可追溯是另一个好处。 一条记录是谁补的、依据是什么、有没有核实过，都留在项目空间里。等到要正式发出邀约时，回头查一遍的成本低得多。
04 功能界面：成员、智能体、文件在同一屏
▲ 图 4｜各自为战的三类麻烦，恰好都能被同一份底稿接住
进入项目组后，界面像一个课题工作台：右侧分「成员」「智能体」「文件」三个标签，底部输入框提示输入 `@` 可唤起绑定的项目组智能体。
▲ 图 5｜项目组内部：三个标签并列，聊天里可直接 `@` 智能体派活
这里的关键是 `@` 机制。 在普通聊天里，@ 一个人是叫他来看消息；在项目组的聊天里，@ 一个智能体是调用它的能力。同一个输入框，既能发消息给成员，也能给智能体派活，智能体因此成了协作流程的一部分。MuchSci 把人才画像放在个人智能体助手的页签下，与这套机制配合，档案的整理与讨论可以发生在同一处。
05 边界
① 本篇讲功能机制与应用方式，不构成效果承诺。项目组能集中上下文，不代表找人这件事一定更顺利，实际还取决于成员使用习惯与任务清晰度。
② 结构化不等于评估。 档案是公开资料的整理，不构成对任何人的能力评价、推荐或背书；涉及具体个人的判断须由使用者自行核实并负责。
③ 只使用公开资料。 不涉及个人隐私数据；用于评审、招聘、尽调等正式用途时，以相关单位现行规定与程序为准。