績效審核人推薦 (Performance Reviewer Recommendation)

績效審核人推薦

單一任務

根據指定期間內對員工工作的直接觀察，推薦合適的 360 度審核人，並說明每位人選的推薦理由。使用 Lark CLI 作為資料存取層。使用目前的主機（Doubao Enterprise、Codex 或 Claude Code）作為推理層。

此技能不會評分員工績效、指派審核人、發送邀請、撰寫績效紀錄，或推斷私人特質。

預設使用者體驗

接受類似以下請求：

推薦本週期 10 位 360 度審核人給張三，並說明每位人選的推薦原因。

解析員工、審核期間、要求人數與角色組合。若提供明確的審核週期或日期範圍則使用該資訊。若無法從授權的 Lark 證據確定當前週期，對於直接的推薦請求則使用公開的六個月觀察期；只有在該期間會實質改變候選人群或使用者要求正式週期結果時，才詢問期間。若未指定人數，預設為十位候選人。若請求未指定組合，則包含主管、同事與跨職能觀點；若員工是主管且審核設計需要下行回饋，則包含直屬下屬。

當歧義會實質改變候選人群時，提出一個簡潔的釐清問題。不要因為可以回報為假設的偏好而延遲任務。

主機與存取閘道

在進行任何飛書檢索之前，請先閱讀 host-bootstrap.md。

• Doubao Enterprise：使用其內建的飛書工具或經批准的 Lark CLI 橋接器。若兩者皆不可用，則以 blocked 停止。
• Codex / Claude Code：需要本機 lark-cli。若缺少該工具，請告知使用者安裝或啟用它，然後停止。
• 優先使用 lark-cli auth status --json --verify 驗證預期租戶、設定檔與使用者身分。若目前 CLI 版本未提供 auth 子命令，則退而使用 contact +get-user --as user，必要時使用 task +get-my-tasks --as user 作為唯讀相容性探測。將 contact 視為已解析的當前使用者，將 task 視為僅限使用者上下文，且不要將相容性模式轉變為可寫入或綁定主體的聲明。
• 絕不暗中使用機器人身分、不同的飛書設定檔、瀏覽器搜尋或手動猜測的紀錄作為替代方案。

記錄主機、Lark 設定檔、身分類型、令牌狀態、範圍與檢查時間，但不記錄憑證。

檢索順序

使用 data-source-map.md 作為資料來源路徑。優先使用能回答請求的最狹義唯讀查詢，然後完整分頁。

1. 解析目標：識別員工並確認組織上下文。
2. 解析期間：使用明確的週期或觀察日期；若使用預設值則保留該假設。
3. 尋找共同工作：在授權範圍內，搜尋目標在會議、逐字稿、訊息與討論串、任務、文件、OKR、專案、審批、行事曆與郵件等中的實質協作。
4. 建立候選人關聯：連結員工與共同交付工作、做出決策、負責後續追蹤、審查產出或參與可歸因業務討論的人員。
5. 保留邊界：記錄來源、日期、存取狀態、分頁、截斷、已刪除材料與不可讀的產出。僅有會議標題、與會者清單、訊息提及或文件檢視不足以證明觀察。

依此順序優先使用主要證據：

1. 共同交付成果、任務所有權、決策、行動項目、里程碑、實質編輯/評論、OKR、審批與正式回饋；
2. 附有上下文的可歸因訊息或逐字稿內容；
3. 經主要材料佐證的 AI 產出會議摘要；
4. 共同出席、群組成員、提及、檢視與行政副本僅作為輔助上下文。

候選人規則

排除或標記員工本人、重複身分、非活躍或已離職的使用者、允許群體以外的人員、政策定義的衝突，以及在期間內無實質證據的人員。

將跨租戶合作者視為資格標記的候選人，即使他們的直接證據很強。在將其放入可提交的候選清單前，請確認目標審核系統接受他們。

不要將訊息量、會議次數、出席率、反應、請假、薪酬、健康、年齡、性別、種族、殘疾、私人關係或推斷的個性作為正面證據。

在可用時要求兩個獨立證據項目，其中至少一個是實質主要項目。將信心度與排名分開：排名高但證據不完整的候選人仍是低信心度。

選擇觀點覆蓋，而非人氣。避免集中在單一團隊或單一關係類型。當證據不支持某個角色時，則保留該角色空缺。

證據表示

將每個可用的觀察正規化為 evidence.schema.json 中的合約。將原始快照和候選人名稱對應表保留在本機。提供主機模型不透明的候選人別名，以及附有來源參考的最小事實。

每個證據關聯必須回答：

• 誰觀察了誰？
• 觀察到什麼工作事實？
• 支援哪個維度？
• 何時發生？
• 審核人可以檢查哪個來源？
• 該事實是主要、衍生、行政、受限或未知？

推薦邏輯

在未提供組織政策時，使用透明且暫定的評分量表：

工作相關性       30
觀察深度         25
時效性           15
證據廣度         10
角色互補性       10
審核可靠性       10

將評分量表版本儲存在稽核記錄中。根據證據關聯計算各項分數，而非原始事件數量。對證據稀疏、衝突、重複觀點與歷史集中度套用明確標記。不要讓模型覆蓋存取封鎖或證據不足的狀態。

預設輸出

以簡潔易讀的候選清單開頭：

候選人	角色	推薦原因	證據範圍	信心度
某人	跨團隊協作	基於共同交付、關鍵決策與後續驗收，對目標員工的交付與協作有直接觀察	會議、任務、文件	中

每個原因必須說明觀察到的工作關係、支援的維度以及重大限制。不要複製私人訊息或將模型生成的聲明呈現為來源事實。

當需要機器可讀輸出時，回傳符合 output.schema.json 的 JSON，並使用以下指令驗證：

python3 scripts/validate_output.py path/to/result.json

務必包含來源覆蓋範圍、證據參考、排除的候選人、資料缺口、信心度、主機稽核元資料，以及 human_review_required: true。

完成邊界

正常終點是提供推薦草案給 HR 或負責主管。不要指派審核人或寫回績效系統。若使用者後續明確要求寫入，則需要預覽、確認、冪等保護與精確回讀；將推薦與人類決定分開記錄。

品質檢查

使用合成或經過編輯的測試案例，測試缺少 Lark CLI、使用者身分過期、僅機器人存取、不完整分頁、不可讀的逐字稿、僅出席的候選人、重複身分、衝突標記、角色缺口、矛盾證據、稀疏證據與無效模型 JSON。明確回報 blocked 或 insufficient_evidence，而非填滿配額。