做研究的人對「檢索」都不陌生：輸入關鍵詞，從文獻庫裡檢出一批論文，再逐條判斷哪些真正相關。但順著文獻往下走一步——這個方向上都有誰在做、各自的團隊負責人是誰——很多人就退回最原始的辦法：開一個記事本，把作者名逐個記下來，再逐個去搜履歷。搜到之後同樣不敢直接用，同名的一大堆，單位對不對得上全憑感覺。
MuchSci 裡恰好有兩個功能對著這件事的兩頭：論文檢索負責「找文獻」，人才畫像負責「找人」。這篇拆的是它們背後共用的那套檢索哲學，以及怎麼用 MuchSci 把兩個功能接成一條流程，交付一份「方向 + 人」的清單。
01 一套哲學，兩個落點
先把兩個功能的分工擺清楚。
▲ 圖 1｜從確定方向到交付清單，檢索與畫像是同一條流水線上的兩段
檢索是拿關鍵詞去學術庫裡命中文獻，畫像是拿姓名、單位、履歷去公開資料裡命中人。輸入不一樣、對象不一樣，但動作結構完全相同：都是先「命中」，再回答「這條命中可靠嗎」。文獻要核對出處與相關性，人要核對姓名、單位與履歷能不能精確對上。想通這一點，兩個功能就不是兩個孤立的工具，而是同一件事在不同對象上的落點。
所以自然的用法不是二選一，而是串起來：先確定研究方向，用檢索摸清這個方向上有哪些活躍團隊，再用畫像把團隊負責人整理成結構化檔案。
02 對照著看，紀律是一樣的
把兩個功能擺進同一張對照表，共同點會看得更清楚。
▲ 圖 2｜對象、輸入、核驗內容各不相同，但「命中之後怎麼確認可靠」是同一道題
最值得對照的是「歧義處理」這一行。檢索面對的相關性不夠的結果，做法是棄用；畫像面對的對不上的記錄，做法是標記「待核驗」，不計入專家。兩者都不走「差不多就收下」的路線。這不是巧合——文獻庫裡混進一篇不相關的論文，引用就錯了；名單裡混進一個對不上號的人，整個盤點的可信度就塌了。寧可少收幾條，也不把來源不清的結果當成可靠結論，這是檢索類工作共有的紀律。
另一處呼應在核驗對象上。檢索核驗的是文獻出處與收錄資訊，畫像核驗的是公開資料裡的履歷與單位——都是能被外部資料驗證的事實，而不是「這篇好不好」「這個人強不強」這類主觀判斷。
再往深處看一步，兩條核驗路徑其實是鏡像的。
▲ 圖 3｜檢索側核驗「這條文獻是真的、相關的」，畫像側核驗「這條記錄說的是同一個人」
檢索側的核驗分三步：出處可查，能回溯到收錄庫與期刊；相關性判斷，內容與研究方向確實相關；不相關的棄用，沾邊的、存疑的不進入引用。畫像側同樣三步：三方匹配，姓名、單位、履歷逐項對上；同名區分，對不上的不合併成一個人；存疑隔離，標記待核驗、不計入專家。兩條路徑共用一個原則：核對不通過的結果，寧可棄用也不硬用。
03 交付的不是名字，是三層咬合的清單
單獨用畫像，得到的是一份份檔案；和檢索接起來，交付物就升級成一份「方向 + 人」的清單。
▲ 圖 4｜方向層、團隊層、檔案層三層各自可核對，清單才立得住
這份清單分三層。方向層回答「看哪個領域」，由檢索階段圈定的研究範圍、活躍程度與代表文獻支撐。團隊層回答「誰在做」，由檢索結果映射出活躍團隊、發表記錄與單位歸屬。檔案層回答「這個人是誰」，由畫像生成的四類欄位承載——基本情況、受教育情況、任職履歷、主要科研成果。
三層的關鍵在於各自可核對：方向有文獻撐著，團隊有發表記錄撐著，檔案有資料來源標識撐著。別人拿到清單，不需要信任整理者本人，只要順著任何一層往回查，都能查到依據。這比一份只有名字和頭銜的名單紮實得多。
04 功能介面：從文獻對話到人物檔案
實際操作時，兩個功能都在智能體助手的頁籤下，介面上是平行的兩個入口。
▲ 圖 5｜論文檢索頁籤：對話式檢索，回答文獻庫規模與單次檢索上限這類事實問題
檢索頁籤是一個對話介面：提問後，系統調用檢索工具，返回帶出處的回答——文獻庫覆蓋範圍、單次檢索返回上限這些事實，都直接給出並可核對。在這個對話裡摸清方向和團隊之後，切到人才畫像頁籤，把團隊負責人的姓名、單位、履歷交給畫像，得到的就是前幾篇拆過的那種結構化檔案。檢索的產出（方向、團隊、線索）正好是畫像的輸入，兩個功能在介面上是分開的，在流程上是接續的。
05 邊界
① 本篇講功能機制與組合用法，不構成效果承諾。檢索與畫像的覆蓋範圍都有限定，清單的完整程度取決於公開資料與文獻庫的可得性。
② 結構化不等於評估。 清單是公開資料的整理與呈現，不構成對任何人的能力評價、推薦或背書；涉及具體個人的判斷，須由使用者自行核實並承擔責任。
③ 只使用公開資料。 不涉及個人隱私數據；用於評審、合作邀約等正式用途時，以相關單位現行規定與程序為準。