第 17 章・應用場景篇

人資招募：履歷初篩評分

一個熱門職缺湧進上百封履歷，HR 光是初篩就要熬夜。這一章我們做一個履歷初篩助手：貼上職缺 JD 與履歷，它給出適配評分、逐項比對、面試建議。這是把第 13 章「抽取＋判斷」的思路，用在最需要一致標準的招募場景。

業界痛點
招募初篩是又累又難一致的工作：履歷格式五花八門、必備條件要逐條核對、量一大就疲勞誤判；不同 HR 的標準也不一，同一份履歷換人看結果可能天差地遠。更麻煩的是要快——好的候選人往往被慢半拍的流程流失。這種「大量、要客觀、要快」的比對工作，讓 AI 先做一輪結構化初篩最合適。

本章目標

解決什麼: 依職缺 JD 對履歷做客觀初篩，輸出評分、條件比對、疑慮與面試建議
用到的技術: 工作流＋結構化評估提示詞（打分、逐項比對、給建議）
難度: ★★★☆☆　重點在把「評分規則」與「公平性約束」寫進提示詞

✨ 成果搶先看

先看做完長什麼樣——這樣你就知道自己在往哪裡前進。跟著本章做，你也能生出下面這個結果：

① 使用者填寫的欄位
職缺 JD：徵資深後端工程師：5年以上Python、熟FastAPI/PostgreSQL/Docker/AWS…
應徵者履歷：陳大文，後端7年。精通Python、FastAPI，主導日活百萬系統，熟PostgreSQL/K8s/AWS，曾將API延遲降低60%。

↓　AI 處理，產出 ↓

綜合評分：78 / 100

履歷關鍵字與 JD 要求高度吻合，且具備大流量系統經驗，但內容過於簡略，缺乏具體佐證細節。

必備條件比對

條件	是否符合	依據
5年以上Python經驗	符合	「後端7年」，「精通Python」
熟FastAPI	符合	「精通...FastAPI」
熟PostgreSQL	符合	「熟PostgreSQL調校」
熟Docker	符合	「熟...Docker/K8s」
熟AWS	符合	「AWS」（僅提及，未說明熟悉程度）
大流量系統經驗（加分項）	符合	「主導日活百萬用戶系統」

亮點

大流量系統主導經驗：日活百萬用戶系統，直接對應JD「大流量系統經驗尤佳」的加分要求。
具體量化成果：API延遲降低60%，顯示有實際優化能力與數據佐證意識。
技術棧完全匹配：Python、FastAPI、PostgreSQL、Docker/K8s、AWS 全部命中JD要求，且額外具備K8s經驗（JD未要求但屬加分）。

疑慮與待確認

履歷內容過於簡略：僅一段文字，缺乏公司名稱、任職期間、專案規模等細節，履歷未提及具體年資分布（如7年是否連續、是否有空窗期）。需面試釐清。
AWS熟悉程度不明：僅提及「AWS」，未說明具體使用的服務（如EC2、RDS、ECS等）或熟悉深度。需面試釐清。
「主導」角色定義不清：是技術負責人、架構師還是純開發？團隊規模、職責範圍履歷未提及。需面試釐清。
延遲降低60%的技術手法未說明：是資料庫優化、快取策略、程式碼重構或架構調整？履歷未提及具體做法。需面試釐清。

建議面試問題

（完整結果更長，這裡先看重點——下載本章 DSL 自己跑就看得到全部）

👇 在 Dify 裡實際執行、長這樣

成果搶先看 — 成品貼上 JD 與履歷，秒出綜合評分、必備條件比對表、亮點與面試建議。

效益速覽（估算）

省時間

每份 10 分→數秒

不必逐封細讀

省人力

百封初篩一輪跑完

HR 專注面談

創造價值

標準一致

可解釋、減少偏差

⬇ 把這個工作流帶走，直接用
不想從頭做？下載本章的 DSL 檔，到你的 Dify「工作室 → 匯入 DSL 檔案」上傳，就能一鍵複製這個範例、改成自己的。

下載 DSL 檔

17.1設計思路：讓標準寫在提示詞裡

兩個輸入：jd（職缺說明）與 resume（履歷）。提示詞要求模型輸出固定六段：綜合評分、必備條件比對（表格）、亮點、疑慮與待確認、建議面試問題、初篩建議。關鍵在兩條約束：只依 JD 與履歷內容判斷、不臆測與職務無關的性別年齡背景，以及資訊不足處明說「履歷未提及」、不腦補——這讓評估既客觀又可解釋。

履歷初篩工作流畫布，開始收 jd 與 resume — **圖 17-1**結構單純：開始收下職缺 JD 與履歷兩份長文，LLM 依規則評估，輸出一份結構化的初篩報告。招募的一致性，就靠這段提示詞把標準固定下來。

17.1.1節點①「開始」：設計使用者要填的表單

履歷初篩有兩個輸入，都是長文字：一段貼職缺 JD、一段貼履歷。點畫布上的「開始」節點，在右側「輸入字段」按「＋」新增欄位；每個欄位設三件事：變數名稱（流程內引用用）、顯示標籤（使用者看到的中文）、欄位型別。本例加：

jd「職缺說明 JD」——型別選「段落」（貼上職缺名稱、必備條件、加分條件、工作內容）。
resume「應徵者履歷」——型別選「段落」（貼上履歷全文）。

開始節點輸入字段設定 — **圖 17-1a　開始節點**「輸入字段」裡的每一欄，就是使用者執行時要填的一格；你設定的變數名，下游才能用 `{{#開始.變數#}}` 引用。面板下方「下一步」顯示它接到 LLM 節點。

17.1.2節點②「LLM」：把規範寫進提示詞

LLM 節點的提示詞把評估的六個固定段落（綜合評分／必備條件比對表／亮點／疑慮／面試問題／初篩建議）寫死，並用 {{#開始.jd#}}、{{#開始.resume#}} 帶入。關鍵是兩條公平性鐵律：只依 JD 與履歷判斷、不臆測與職務無關因素；資訊不足就明說『履歷未提及』、不腦補。

LLM 節點系統提示詞設定 — **圖 17-1b　LLM 節點**LLM 節點設定。系統提示詞把六段評估版型與公平性約束寫清楚，並引用開始節點的 JD 與履歷——招募的一致性，就靠這段把標準固定下來。

17.2測試運行：一位後端工程師應徵者

貼上一份 Python 後端職缺 JD 與一位有電商經驗的應徵者履歷，按執行。

評估結果：綜合評分 85、必備條件比對表、亮點 — **圖 17-2**助手給出**綜合評分 85/100**，用表格逐條比對必備條件（Python 開發、Django、PostgreSQL…全部 ✅ 並附履歷依據），再點出三個與職缺高度相關的亮點（電商核心系統實戰、Docker 落地、全端背景助溝通）。捲下去還有疑慮、建議面試問題與初篩建議。

務必注意
AI 初篩是輔助排序，不是自動錄取或淘汰。最終決策必須由 HR 與用人主管把關；也要留意提示詞已明令排除與職務無關因素，避免把資料裡的偏差帶進評分。把它當成「幫你先讀完一百封、標好重點」的助理。

17.3延伸與變化

批次篩選把整批履歷用批次執行跑一輪，依評分排序，HR 只需細看前段名單。
接檔案上傳用第 8 章文件提取或第 15 章多模態，讓 HR 直接上傳 PDF 履歷，不必貼文字。
結構化輸出接 ATS把輸出改成第 6 章 JSON 結構化，直接寫回招募系統的候選人評分欄位。

帶來的改變
初篩從「熬夜逐封讀」變成「幾秒一份、依分排序」；評分標準一致、可解釋、可稽核；好候選人不再因流程慢而流失。HR 把時間留給真正需要人味判斷的面談。

輸出、發布與使用：把成果交付出去

做好的應用要能發布、分享給別人用才有價值。以下是這個應用的輸出設定與發布／使用畫面：

**輸出節點**工作流的最後一站。「輸出變數」把某個節點的輸出（例如 LLM 的 `text`）對應成整條流程的最終結果——決定使用者最後拿到什麼。

**發佈選單**做好後按右上「發佈 → 發布更新」即上線；選單還提供『運行』獨立網頁、『訪問 API』、『嵌入網站』與『工作流程作為工具』等交付方式——這就是把應用分享給別人使用的入口。

17.4本章回顧

「大量、要客觀、要快」的比對，讓 AI 先做結構化初篩最划算。
把評分規則與公平性約束寫進提示詞，是招募一致性的關鍵。
AI 負責初篩排序與標重點，錄取與否仍由人把關。