# 批量简历筛选纪律

用户一次性发送多份简历时**不要直接逐份硬读原始提取结果**，否则容易被低质量抽取文本拖住整批交付。

## 推荐流程

1. **按人群拆批次**：如果同一轮里混有不同口径（社招 / 校招、算法 / 产品），先拆成独立批次，不要混在一张筛选表里。
2. **批量提取 PDF 文本**：用 [scripts/resume_pdf_extract.py](scripts/resume_pdf_extract.py) 跑多后端 triage，不要只保留第一种提取结果。
3. **生成清洗索引**：统计每份 txt 的 `backend / score / chars / lines / quality`，必要时附前几行预览。
4. **优先筛 high / medium**：先完成可判断候选人的正式筛选并交付，不要等 low 质量文本全部补完。
5. **low 单独列为待补核**：明确告诉用户该候选人需要回看原 PDF，或暂列"待补材料"。
6. **清洗索引只作为内部执行产物**：除非用户明确要求查看提取质量 / 清洗过程，否则最终交付报告中**不要加入**文本提取质量索引、backend/score/chars/lines 表、抽取质量说明等版块。

## 文本质量分层

- `high`：`chars >= 2600` 且 `lines >= 55` 且 `score >= 65`
- `medium`：`chars >= 1600` 且 `lines >= 35` 且 `score >= 35`
- `low`：低于上述阈值，先标记"待补核"，避免阻塞整批交付

## 根因判断提示

如果原始文本出现以下模式，优先怀疑是 PDF 结构问题，**不要**误判成候选人简历本身差：

- 大量 `n n / B B / x x / X X` 之类的单字符碎片。
- 页首或页尾反复出现一长串字母数字混合 ID。
- 正文中间穿插竖排页边字符或装饰层文字。
- 同一段正文可读，但夹杂少量莫名英文 / 数字碎片。

## 批量任务执行纪律

- **只处理本轮明确提供的文件**：本机缓存目录可能混有历史附件。批量提取前应把本轮附件路径复制 / 链接到独立临时目录，或显式传入文件清单，避免把无关简历 / JD 混入本次评估。
- **先交付一批，再开下一批**：例如社招和校招分开发文件，不要等所有人都看完才第一次交付。
- **不要让坏文本阻塞整批**：单个候选人的抽取失败，不影响其他候选人先出正式结论。
- **必须有状态面板**：至少明确哪些候选人已提取、已评估、待补核、已交付。
- **大批量可并行评估**：10 份以上简历可按 3-5 人一组拆分并行产出分组评估卡，再由主线程统一校准分数、排序和措辞；最终报告必须保持同一评价口径。
- **索引文件可落盘复用**：建议生成一份 Markdown 清洗索引，后续筛选直接按索引优先级推进。

## 重新评估之前批次的纪律

用户说"重新评估之前的某批简历"时，**不要**直接沿用旧结论，也不要先让用户重传。按下面顺序恢复材料：

1. 用会话搜索（或本地笔记）找回上次筛选时的岗位名称、JD 文件名、候选人名单。
2. 到本机缓存目录优先查找历史附件：
   - `~/Downloads/` 或对话工具的附件缓存目录
   - 用户常用的临时目录（按当前 agent 环境约定）
   - 常见命名形态：`doc_<id>_候选人名.pdf`、`doc_<id>_岗位JD.md`
3. 批量 PDF 优先按岗位关键词过滤，再确认与上次会话中的候选人名单一致。
4. 找回文件后**必须重新提取、重新评估**。允许复用历史"文件定位结果"，**不允许**复用历史"评估结论"。
5. 如果用户要求"把评估 markdown 文件发回会话"，先生成本地 `.md` 报告文件，再通过附件机制发送，而不是只把内容粘到回复里。

## 索引输出字段建议

```markdown
| 候选人 | 文本质量 | 有效行数 | 有效字符数 | 提取文件 |
| --- | --- | ---: | ---: | --- |
| 张三 | high | 78 | 3120 | /tmp/resume_extract/zhang_san.fitz.txt |
| 李四 | low | 22 | 980 | /tmp/resume_extract/li_si.pdfminer.txt（待补核） |
```