---
name: resume-claim-guard
description: 从岗位 JD 出发写一份经得起面试追问的简历：拆解 JD 要求，把要求翻译成生活里的线索反问候选人，挖出简历上没写的相关真实经历，只用候选人确认过的事实贴着 JD 写定向简历，最后逐句做事实体检并预演面试官会怎么追问、该怎么答。也可单独体检已有简历，识别 AI 改写造成的动词升级、无依据数字和把计划或团队成果写成个人成果。用户要求按 JD 写或改简历、定向简历、岗位匹配、简历事实核查、反注水审查、准备面试时讲清每段经历时使用。
---

# 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](references/jd-breakdown.md)。

### 第 2 步：反问经历（先挖，再落实）

**挖。** 从第 1 步挑出的 3–5 条核心职责出发，每条翻译成 2–3 个生活里的线索再问，帮候选人想起简历上没写的经历。例如 JD 写“收集整理用户反馈形成周报”，不问“你做过用户反馈吗”，问“你有没有整理过读者留言、问卷意见或群里的吐槽，汇总给别人看？”线索只从 JD 来，不凭空猜候选人可能做过什么。先按 JD 要求挖，一次一条要求；挖完再核实旧简历上还没问到的说法。按简历条目逐段问，很容易一直在核实旧说法，永远轮不到挖。

**落实。** 挖出来的每段经历，都要问清四件事才能进底稿：**你本人做了哪部分、做到了哪一步（计划/原型/上线/有结果）、数字从哪来、什么时候的事**。候选人说“好像有过”，就追问具体是哪一次；说不出具体一次的，记为 `待确认`，不写进简历。

一次最多问 3 个问题，先问最影响简历的。用户答“没做过”“不记得”就如实记下，不引导用户承认没做过的事，也不替用户补。挖只能补**表达缺口**（做过但没写），补不了**真实缺口**（没做过）。

问完整理成带编号和日期的事实底稿（`F-01`、`F-02`……），**先给用户确认，再往下走**。问法和底稿格式见 [references/intake-questions.md](references/intake-questions.md)，模板见 [templates/facts.md](templates/facts.md)。

### 第 3 步：匹配

把 JD 每条要求对上事实编号，状态只用五种：`已匹配`、`表达缺口`（做过但简历没写好）、`证据不足`（可能做过但缺来源）、`真实缺口`（没做过）、`待确认`。真实缺口如实列出，写进“面试时怎么诚实回应”，不写进简历。最后给一个投递建议：`建议投递`、`补充材料后投递`、`谨慎投递`、`暂不建议投递`，不输出匹配分或百分比。

### 第 4 步：写定向简历

只用确认过的事实写。按 JD 的优先级排经历顺序，用 JD 的术语描述候选人**真实做过的事**，但动词不超过两条轴的上限（见下）。规则见 [references/resume-writing.md](references/resume-writing.md)。

### 第 5 步：体检与面试预演

逐句体检：每条主张标五种证据状态之一，查动词是否越级、数字是否有来源、是否把团队或 AI 的成果写成个人的。定向模式体检两样东西：新写的定向简历（应当全部是 `confirmed` 或 `supported`，否则退回第 4 步改）；有旧简历时再体检旧简历，让候选人看到原来哪里站不住。旧简历已经投出去过的，和新简历一起做跨版本对比，给出面试统一口径。体检细则（含 PDF、多版本对比、内部编号）见 [references/claim-audit.md](references/claim-audit.md)。

然后对每条经历预演面试：面试官最可能问的 2–3 个追问、只用事实写成的回答要点、绝对不能说的话、被问到真实缺口时怎么诚实回应。见 [references/interview-probe.md](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](references/output-formats.md)。

内部编号（`F-01`、`C-07`）只能出现在审计表和源文件注释里；对外简历、求职信和聊天文本不得出现。

## 边界

- 不访问或提交招聘网站，不代发求职消息，不替用户确认已投递；
- 不要求密码、验证码、身份证号等无关敏感信息；
- 不把 JD、模型建议、旧简历或推断写回事实底稿；
- 公开示例只用虚构候选人；
- 不输出通过率、录用概率或匹配分。