一個課題組要找人，通常係幾個人喺忙：導師心裡有個大致範圍，師兄手裡有一串可能合適的人名，負責外聯的同學在想這封邀約該怎麼發。麻煩在於，這些人的信息很少在同一處——範圍在會上說過一遍，名單在某人的筆記裡，要用的簡介還得再問一遍。等到彙總時，往往誰也拿不出一份完整的。
這件事的本質不是人不夠勤快，而是沒有共同的工作台面。人才畫像解決的是「一條記錄憑什麼可信」，共研工作坊解決的是「這份可信的記錄放在哪裡、由誰共同維護」。這篇拆的就是兩者接上的那一截。
01 名單散在聊天裡，和沉澱在項目組裡
▲ 圖 1｜差別不在誰記得多，而在能不能被下一個人接著用
先說最直觀的差別。 名單散在聊天與郵件裡時，每個人都在自己的文檔上加幾筆，彙總時版本對不上是常態：同名的人被寫成兩條，同一個人出現兩種寫法，事後很難追出是哪一版。放進項目組之後，事情變成只有一份——誰加的、什麼時候加的、當時依據什麼，都留在同一個空間裡。
存疑的處理方式也跟著變了。分散整理時，拿不準的那條往往含糊帶過去就算了；在共享底稿裡，對不上的人名可以單列一檔，明明白白地告訴後來者「這條沒核實」。寧可留著待核驗，也好過把來源不清的記錄混進正式名單。
交接成本是第三個差別。換個人接手課題，散在聊天裡的上下文要重講一遍；項目組裡的對話、智能體與文件都在，下一個人打開就能接著幹。
02 三個標籤，各接住一截
▲ 圖 2｜成員、智能體、文件三類對象，共享同一份上下文
成員這一層回答「誰在參與」。項目創建人與普通成員在列表裡被區分開，分工是顯式的：導師定範圍，師兄補人選，外聯負責把材料發出去。角色清楚了，誰該補哪一段就不用反覆商量。
智能體這一層回答「誰來整理」。項目組可以綁定智能體，成員在輸入框打 `@` 就能喚起。對找人這件事來說，用處在於把各自補來的一堆名字按同一套字段整理一遍——基本情況、受教育情況、任職履歷、主要科研成果，逐項對齊成列，而不是各寫各的一段。在 MuchSci 的項目組裡，這一步發生在討論的同一個地方，不需要把名單搬進搬出。
文件這一層回答「成果落在哪」。候選名單、整理好的檔案、成稿的邀約材料，都隨項目留存，不會被新的聊天消息沖走。討論時可以直接引用材料，而不是拋一個連結讓大家自己找。
03 一份共享底稿，是這樣長出來的
▲ 圖 3｜從建組定範圍到成稿進文件區，六步都在同一個空間裡
流程大致是六步： 為一個招人課題開一個項目組，先把範圍說清楚；成員各自往裡補人，先不急着整理；在聊天裡 `@` 綁定的智能體，讓它按四類字段批量補檔；對拿不準的記錄單列一檔，標待核驗，不進正式名單；整理好的檔案放進文件區，成員共用同一份；由熟悉情況的人再過一遍。
其中值錢的是「不完整也被允許」。待核驗這一檔的存在，說明整理過程承認自己會不確定。共享底稿如果只允許寫確定的內容，成員就會把存疑的乾脆刪掉，反而丟掉線索。
可追溯是另一個好處。 一條記錄是誰補的、依據是什麼、有沒有核實過，都留在項目空間裡。等到要正式發出邀約時，回頭查一遍的成本低得多。
04 功能介面：成員、智能體、文件在同一屏
▲ 圖 4｜各自為戰的三類麻煩，恰好都能被同一份底稿接住
進入項目組後，介面像一個課題工作台：右側分「成員」「智能體」「文件」三個標籤，底部輸入框提示輸入 `@` 可喚起綁定的項目組智能體。
▲ 圖 5｜項目組內部：三個標籤並列，聊天裡可直接 `@` 智能體派工作
這裡的關鍵是 `@` 機制。 在普通聊天裡，@ 一個人是叫他來看消息；在項目組的聊天裡，@ 一個智能體是調用它的能力。同一個輸入框，既能發消息給成員，也能給智能體派工作，智能體因此成了協作流程的一部分。MuchSci 把人才畫像放在個人智能體助手的頁籤下，與這套機制配合，檔案的整理與討論可以發生在同一處。
05 邊界
① 本篇講功能機制與應用方式，不構成效果承諾。項目組能集中上下文，不代表找人這件事一定更順利，實際還取決於成員使用習慣與任務清晰度。
② 結構化不等於評估。 檔案是公開資料的整理，不構成對任何人的能力評價、推薦或背書；涉及具體個人的判斷須由使用者自行核實並負責。
③ 只使用公開資料。 不涉及個人隱私數據；用於評審、招聘、盡調等正式用途時，以相關單位現行規定與程序為準。