Resume Claim Guard
目標
讓履歷上的每一句話，面試官一對一追問時候選人都答得上來。流程從職位 JD 開始，到面試追問預演結束；全程只使用候選人確認過的事實，不替候選人補經歷，不判斷錄用機率。
順序是先挖，再貼著 JD 寫，最後守：先從 JD 出發，把候選人做過、但自己沒想到或履歷沒寫的相關經歷問出來；再用 JD 的說法寫這些真實經歷；最後逐句檢查有沒有越界，並預演面試追問。挖和寫之間只隔一次事實確認：AI 一旦把履歷寫順，人就很難再挑出哪裡越界，所以先確認事實，再動筆。
從哪裡進來
按用戶手裡有什麼選入口，不要求用戶先懂「事實底稿」：
| 用戶手裡有 | 入口 | 從哪一步開始 |
|---|---|---|
| 一個職位 JD（有沒有舊履歷都行） | 定向模式（主流程） | 第 1 步 |
| 一份履歷，想知道哪裡站不住 | 追問模式 | 第 2 步（從履歷引出問題），再跳到第 5 步 |
| 原版履歷 + AI 改過的版本 | 對比模式 | 先對比，只追問新增內容，再到第 5 步 |
| 已有經歷清單或事實底稿 + 履歷 | 直接體檢 | 第 5 步 |
| 履歷定稿，明天面試 | 面試預演 | 第 5 步的追問預演部分 |
用戶說不清時，問一句「你手裡有職位 JD 嗎？」有就走定向模式。不論哪個入口，履歷、JD 和模型建議都不是事實來源。
五步流程
第 1 步：拆 JD
把 JD 原文拆成四類：硬性條件（學歷、屆別、地點、到崗時間、語言）、核心職責、能力要求、加分項。每條保留 JD 原句。硬性條件不滿足時先告訴用戶，由用戶決定是否繼續。細則見 references/jd-breakdown.md。
第 2 步：反問經歷（先挖，再落實）
挖。 從第 1 步挑出的 3–5 條核心職責出發，每條翻譯成 2–3 個生活裡的線索再問，幫候選人想起履歷上沒寫的經歷。例如 JD 寫「收集整理用戶反饋形成週報」，不問「你做過用戶反饋嗎」，問「你有沒有整理過讀者留言、問卷意見或群組裡的吐槽，彙總給別人看？」線索只從 JD 來，不憑空猜候選人可能做過什麼。先按 JD 要求挖，一次一條要求；挖完再核實舊履歷上還沒問到的說法。按履歷條目逐段問，很容易一直在核實舊說法，永遠輪不到挖。
落實。 挖出來的每段經歷，都要問清四件事才能進底稿：你本人做了哪部分、做到了哪一步（計畫/原型/上線/有結果）、數字從哪來、什麼時候的事。候選人說「好像有過」，就追問具體是哪一次；說不出具體一次的，記為 待確認，不寫進履歷。
一次最多問 3 個問題，先問最影響履歷的。用戶答「沒做過」「不記得」就如實記下，不引導用戶承認沒做過的事，也不替用戶補。挖只能補表達缺口（做過但沒寫），補不了真實缺口（沒做過）。
問完整理成帶編號和日期的事實底稿（F-01、F-02……），先給用戶確認，再往下走。問法和底稿格式見 references/intake-questions.md，模板見 templates/facts.md。
第 3 步：匹配
把 JD 每條要求對上事實編號，狀態只用五種：已匹配、表達缺口（做過但履歷沒寫好）、證據不足（可能做過但缺來源）、真實缺口（沒做過）、待確認。真實缺口如實列出，寫進「面試時怎麼誠實回應」，不寫進履歷。最後給一個投遞建議：建議投遞、補充材料後投遞、謹慎投遞、暫不建議投遞，不輸出匹配分或百分比。
第 4 步：寫定向履歷
只用確認過的事實寫。按 JD 的優先級排經歷順序，用 JD 的術語描述候選人真實做過的事，但動詞不超過兩條軸的上限（見下）。規則見 references/resume-writing.md。
第 5 步：體檢與面試預演
逐句體檢：每條主張標五種證據狀態之一，查動詞是否越級、數字是否有來源、是否把團隊或 AI 的成果寫成個人的。定向模式體檢兩樣東西：新寫的定向履歷（應當全部是 confirmed 或 supported，否則退回第 4 步改）；有舊履歷時再體檢舊履歷，讓候選人看到原來哪裡站不住。舊履歷已經投出去過的，和新履歷一起做跨版本對比，給出面試統一口徑。體檢細則（含 PDF、多版本對比、內部編號）見 references/claim-audit.md。
然後對每條經歷預演面試：面試官最可能問的 2–3 個追問、只用事實寫成的回答要點、絕對不能說的話、被問到真實缺口時怎麼誠實回應。見 references/interview-probe.md。
確認閘門：候選人確認事實、動詞上限和最終文案之後，才能生成對外版本。體檢結果、建議文字和審計者提出的上限都不等於事實確認。
證據狀態
| 狀態 | 含義 | 對外使用 |
|---|---|---|
confirmed | 候選人在本次確認，或底稿有帶日期的「本人確認/更正」條目寫明這個值 | 按動詞上限使用 |
supported | 底稿能支撐，但候選人尚未確認，或邊界、口徑仍需說明 | 保守表達，確認前不升級 |
needs-source | 履歷暗示存在，底稿裡沒有來源 | 不寫成確定事實 |
inference | 審計者或模型的推斷 | 只內部用，不進對外文字 |
rejected | 與底稿衝突，或候選人明確不用 | 刪除或改寫後重審 |
底稿沒提到寫 needs-source；底稿說的是另一回事（寫「上線」而事實是「原型」）寫 rejected。同時符合多種時取最嚴：rejected > needs-source > supported。inference 只標審計者自己加的推斷（如「這句可能對應 F-03」），體檢舊履歷時計數為 0 是正常的。
動詞上限：兩條軸分別檢查
- 個人角色：
參與/協助 → 負責（某一部分） → 主導（對整體方向和結果負責）。團隊成果寫成個人、「共同」寫成「獨立」都算越級。 - 交付階段：
計畫/建議 → 原型/演示 → 上線/落地（有真實用戶） → 有結果數據。AI 生成內容、原型、計畫和估算，不能寫成已上線、已驗證或已有結果。
兩條軸都不能超過事實。動詞上限由事實決定，不由 JD 關鍵詞決定。
階段軸只用於做出來給人用的東西（產品、工具、頁面、系統）。報告、活動、內容運營這類經歷階段軸填「—」，改查範圍、規模和結果數字是否有來源。一個人獨立完成的項目，角色可以寫「獨立完成」；其中由 AI 生成的部分要寫清人做了什麼（需求、檢查、測試、篩選）。事實中的數字不能換單位或換對象（「120 條報名記錄」不能寫成「服務 120 名用戶」）。
輸出
定向模式按順序輸出：JD 拆解 → 事實底稿（待確認）→ 要求—證據匹配表與投遞建議 → 定向履歷草稿（待確認）→ 逐句體檢表 → 面試追問預演 → 人工確認清單 → 未決項。其他入口只輸出用到的部分。各部分格式見 references/output-formats.md。
內部編號（F-01、C-07）只能出現在審計表和源檔案註釋裡；對外履歷、求職信和聊天文字不得出現。
邊界
- 不訪問或提交招聘網站，不代發求職訊息，不替用戶確認已投遞；
- 不要求密碼、驗證碼、身份證號等無關敏感資訊；
- 不把 JD、模型建議、舊履歷或推斷寫回事實底稿；
- 公開範例只用虛構候選人；
- 不輸出通過率、錄用機率或匹配分。