履歷評分（三道關卡漏斗）
一份履歷必須通過獨立的三道關卡漏斗並記錄評分卡，才算完成。
關卡流程比照招聘流程：招募專員 → 資深工程師 → hiring manager。每個關卡代表不同視角，
只評斷其能感知的內容。所有角色、評分標準、權重與門檻皆位於
config/scoring_panel.yaml — 請逐字使用，勿在此處寫死。
原則
- 每次從頭開始。 每個關卡使用一個子 agent，且每次都在全新的上下文：它從未見過這位候選人，
僅透過履歷初次接觸。只給予 JD、履歷文字，以及該關卡自己的
read_mode/評分標準。 絕對不要傳遞我們的分析、決策備註或先前的分數（避免錨定效應）。 - 不同視角，不同評分標準。 不要讓三個關卡共用同一套評分標準。
- 不取平均。 最終結果是最差的等級，標記於最早失敗的關卡； 追蹤編號為所有關卡分數中的最小值。招募專員的 65 分加上 hiring manager 的 82 分， 平均後看似舒適的 73.5 分 — 但履歷在第一關就已淘汰，hiring manager 根本看不到。
- 評斷可讀性，而非真實性。 審閱者初次見到陌生人的履歷時，沒有真實資訊可對照， 因此評分的是文件的說服力 — 誇大的陳述只會顯得不夠說服。真實性屬於作者的責任： 這就是為何此 repo 從不虛構經歷（參見建置技能）。
- 評分實際文件。 從建置好的
.docx中提取一次文字，確認非空，然後直接內聯傳遞給三個關卡 （若給予空白內容，關卡會產生幻覺並評出垃圾分數）。 - 發現不等於編輯。 根據發現採取行動時，絕對不能虛構。JD 中的關鍵字需要有實際經驗的支持； 否則就是誠實的落差。
流程
- 載入
config/scoring_panel.yaml。 - 收集輸入：JD（來自記錄）、提取的履歷文字，確認其為一頁。
- 在同一個訊息中（平行） 分派三個關卡，每個關卡從
reviewer-prompt-template.md建立。 - 彙整：根據各關卡的
pass/borderline評定等級；最終結果 = 最早關卡的最差等級 （NO@recruiter、BORDERLINE@hiring_manager或PASS）；追蹤編號 =min(gate totals)； 共識 = 至少有 2 個關卡獨立標記的項目；將每項扣分分類為可修正 vs 本質。 - 在申請記錄中寫入
## Scorecard區段（格式如下），並在其日誌中寫入一行。
評分卡格式
## Scorecard — YYYY-MM-DD (resume: <output>.pdf)
**Funnel: Recruiter ✅ NN → Staff ⚠️ NN → HM ❌ NN → NO@hiring_manager**
**Weakest gate: NN/100**
| Gate | Score | Sub-scores | Verdict |
|---|---|---|---|
| Recruiter | NN/100 | stack NN/45, seniority NN/30, scan NN/25 | ✅ |
| Staff eng | NN/100 | tech NN/35, projects NN/30, jd NN/35 | ⚠️ |
| HM | NN/100 | job NN/65, level NN/35 | ❌ |
**Probe list (staff):** 1) … 2) … 3) … **Risk memo (HM):** …
**Consensus (>=2 gates):** …
**Deductions:** fixable: … · inherent (interview narrative): …
**Ranked next edits:** 1) … 2) … 3) …
常見錯誤
- 用我們自己的分析或先前的分數錨定關卡。
- 將三個分數平均。
- 要求審閱者評分真實性（它只能評分說服力）。
- 讓關卡因申請表單中另行列出的項目扣分（參見 config 中的
out_of_scope）。 - 將本質落差視為可透過改寫修正。
- 透過虛構來提高分數。