第 33 章・串接外部服務篇

履歷初篩與自動通知信

把「評分 → 判定 → 分流 → 個人化回信」交給工作流。這一章用 LLM 評分、Code 精確判定、三向條件分歧、變數聚合，最後用 Gmail 寄出個人化通知信——每份履歷自動打分、依 PASS／HOLD／REJECT 寄出對應的邀約、待定或婉拒信，HR 只需覆核。

業界痛點
一個熱門職缺動輒上百封履歷。HR 要逐份讀、憑印象打分（標準還常常飄），再一封封寄邀約或婉拒信——耗時、標準不一，且婉拒信常常拖著沒寄、傷害雇主品牌。能不能讓系統客觀評分、依分數自動寄出個人化又得體的通知信？

本章目標

解決什麼: 履歷自動評分，依分數三向分流，寄出邀約面試／待定／婉拒的個人化通知信
用到的技術: LLM 評分 + Code 判定 + 三向條件分歧 + 變數聚合 + Gmail 寄送，共 10 節點
難度: ★★★★☆　Code 精算 + 多向分流 + 真實寄信

✨ 成果搶先看

先看做完長什麼樣——貼一份履歷與 JD，系統自動評分 88（PASS）、附詳細評估理由，並寄出邀約面試信：

① 使用者填寫的欄位
職缺 JD：徵資深後端工程師：5年以上Python、熟FastAPI/PostgreSQL/Docker/AWS…
應徵者履歷：陳大文，後端7年，精通Python/FastAPI，主導日活百萬系統…
應徵者姓名 / 信箱：陳大文 / applicant@example.com

↓　AI 處理，產出 ↓

評分：SCORE = 88 ｜判定：PASS（自動寄出邀約面試信）

年資與核心技術：具備 7 年後端經驗，超過 JD 要求的 5 年門檻；明確精通 Python／FastAPI，符合核心技術要求。
資料庫與雲端：履歷載明熟悉 PostgreSQL 與 AWS，均符合 JD 需求。
Docker 疑慮：JD 要求熟 Docker，履歷僅提及 K8s，隱含相關經驗但未明寫，建議面談確認。
亮點：主導日活百萬（高併發）系統，且有量化成果（API 延遲降低 60%），顯示大型系統實戰經驗。
整體適配度：核心必備條件皆符合，屬高度適配的候選人。

這是實際跑出來的：LLM 評分＋Code 判定 PASS → 自動寄出對應的「邀約面試信」。

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

執行結果：履歷評分 88 PASS，寄出邀約信 — 成品自動評分（`SCORE=88 / PASS`）＋逐點評估（年資、技術、疑慮、亮點、整體適配），並自動寄出對應通知信（`Email sent successfully!`）。

效益速覽（估算）

省時間

每份 10 分→數秒

評分＋回信一次做

省人力

百封初篩一輪跑完

HR 專注面談

創造價值

標準一致＋不漏回

婉拒信也準時、體貼

⬇ 把這個工作流帶走，直接用
下載本章 DSL 匯入你的 Dify。需先完成 Gmail 授權（見第 31 章），Gmail 節點才能寄信。

下載 DSL 檔

33.1設計思路：讓分數說話，讓 Code 決策

10 個節點：開始 → 適配度評分 → 判定結果(Code) → 依評分三向分流 → 邀約／待定／婉拒信 → 彙整信件 → Gmail 寄送 → 輸出。關鍵設計：LLM 負責「評分＋理由」，但把最終決策交給 Code（用分數門檻精確判 PASS/HOLD/REJECT），避免 LLM 在邊界分數上飄。

履歷初篩工作流全貌，10 節點 — **圖 33-1**工作流全貌。評分後由 Code 產生旗標，三向條件分歧接三種信，最後聚合成一封、由 Gmail 寄出。

33.1.1節點①「開始」：JD、履歷、姓名、信箱

開始節點四欄位 — **圖 33-2　開始節點**四個欄位：`jd`、`resume`、`applicant_name`、`applicant_email`。

33.1.2節點②「適配度評分」：第一行輸出可解析的分數

提示詞要求 LLM 第一行只輸出「SCORE=<0-100>」，換行後再寫評估理由。這個「固定格式」是關鍵——下游 Code 才好解析。並下公平性鐵律：只依 JD 與履歷判斷、不臆測無關因素。

適配度評分 LLM — **圖 33-3　適配度評分**把 JD 與履歷帶進提示詞，輸出「SCORE=NN」＋逐點理由。

33.1.3節點③「判定結果」：Code 精確定生死

Code 節點用正則從評分輸出抓出數字，依門檻判定：≥80=PASS、60–79=HOLD、<60=REJECT，輸出 flag 與 score。用程式判門檻，結果穩定、可稽核，不會因語氣而飄。

Code 判定節點 — **圖 33-4　判定結果（Code）**正則取分數、門檻判旗標——精確計算交給程式，是這章穩定的關鍵。

33.1.4節點④「三向分流」＋三種信

條件分歧依 flag 三向路由：包含 PASS → 邀約面試信（IF）；包含 HOLD → 待定通知信（ELIF）；其餘 → 婉拒信（ELSE）。三個 LLM 各寫對應語氣的信，都以「{{應徵者姓名}} 您好」開頭、個人化又得體。

三向條件分歧 — **圖 33-5　依評分三向分流**IF／ELIF／ELSE 三條路，分別接邀約、待定、婉拒信。

33.1.5節點⑧⑨「彙整信件」＋「Gmail 寄送」

三種信只會產生其中一封，用變數聚合收成一個 output，再交給 Gmail 節點寄給 applicant_email。一個寄送節點服務三種結果，乾淨俐落。

變數聚合節點 — **圖 33-6　彙整信件**把邀約／待定／婉拒三個變數聚合成單一 `output`，餵給 Gmail 寄送。

Gmail 寄送節點 — **圖 33-7　Gmail 寄送通知**To 接 `開始.applicant_email`、Body 接聚合後的信件內容，一鍵寄達應徵者。

33.2延伸與變化

邀約信自動附時段邀約分支可再串行事曆／表單連結，讓通過者直接預約面試。
批次處理接第 9 章的 API，讓 ATS 系統把每封履歷丟進來自動跑，回傳分數與已寄信狀態。
先草稿再寄把 Gmail 換成 draft_message，HR 覆核後再送——尤其婉拒信，避免誤寄。

務必注意
寄的是真實通知信，且涉及應徵者感受與雇主品牌。建議：婉拒／待定信上線初期先走草稿由人覆核；評分僅供初篩參考、最終仍由人決定；提示詞已要求「只依 JD 與履歷、不臆測性別年齡等無關因素」，請保留這條以降低偏誤。

33.3本章回顧

LLM 負責評分與理由，但把「過或不過」的決策交給 Code 用門檻精算，結果穩定可稽核。
讓 LLM 以固定格式（SCORE=NN）輸出，下游程式才好解析——這是 AI 與程式協作的常用技巧。
三向條件分歧（IF/ELIF/ELSE）對應三種結果，各寄個人化通知信。
多分支最後用變數聚合收攏，一個 Gmail 節點服務所有結果。