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、模型建议、旧简历或推断写回事实底稿；
- 公开示例只用虚构候选人；
- 不输出通过率、录用概率或匹配分。