“上传 PDF，系统自己填候选人”听起来很美，但企业版的 hr_recruitment_extract 并没有这么鲁莽。enterprise/hr_recruitment_extract/models/hr_applicant.py 显示，这个模块更像一套受控 digitization 流程：先判断候选人是否处在可抽取阶段，再把主附件送去 OCR，最后只回填一组明确校验过的字段。
一、不是任何阶段都允许抽取
_compute_is_in_extractable_state() 会按职位查默认招聘阶段，只有 applicant 还停留在“首个有效阶段”时，is_in_extractable_state 才为真。源码甚至给了明确错误文案：You cannot send a CV for an applicant who's not in first stage!
这一步是在防止两个问题：
- 候选人已经走到后面阶段，HR 又上传新简历把核心字段覆盖；
- 一条申请被反复 OCR，流程证据和当前信息口径混乱。
换句话说，OCR 被设计成“初筛入口增强”，不是“任意阶段的字段覆盖工具”。
二、回填字段非常克制，只处理最基础的识别项
_get_validation_fields() 只返回 email、name、phone。_fill_document_with_results() 也只优先写入 partner_name、email_from、partner_phone；如果装了 hr_recruitment_skills，再额外从全文里匹配技能词。
这个范围看起来保守，实际上非常合理。简历 OCR 的准确率最能支撑的，就是基础识别和技能提示；如果一上来就试图自动填住址、学历、职位偏好，误识别成本会比省下的录入时间更高。
三、自动送 OCR 是绑定在“主附件设置”上的
_message_set_main_attachment_id() 在完成父类逻辑后会调用 _autosend_for_digitization()。而 _autosend_for_digitization() 又取决于公司级配置 recruitment_extract_show_ocr_option_selection 是否设为 auto_send。
这说明企业版不是“看见附件就 OCR”，而是“当附件被确认为主简历附件，而且公司允许自动送检时，才进入 digitization 流程”。这条边界很重要，因为招聘对话里经常会有补充材料、作品集、证书截图，它们并不都应该拿去当简历解析对象。
四、OCR 结果不是数据库真相，只是候选资料的第一层草稿
_contact_iap_extract() 会把版本号和 IAP token 带去远端 extract.api.odoo.com，说明 OCR 本身是一个外部能力调用；_get_validation()、_get_validation_fields() 则告诉我们，系统知道它需要验证，并非盲信结果。
对业务来说，这意味着 OCR 最适合做三件事：
- 帮 HR 在海量投递里减少手工录入；
- 帮初筛阶段快速拿到联系方式和姓名；
- 帮技能模块做“建议”，而不是替人做最终判断。
五、实战注意事项
- 把 OCR 放在首阶段：越往后阶段越不适合自动覆盖候选基础信息。
- 区分主附件与普通附件：只有真正的简历附件才应该触发 OCR。
- 把 OCR 结果当建议，不当真理：特别是手机号、邮箱格式异常时，要让 HR 复核。
- 技能提取要看词库质量：源码是从全文 token 里匹配
hr.skill，词库质量会直接决定结果质量。
新手误区
- 误以为任何阶段都能重新 OCR。
- 误以为 OCR 结果可以全量覆盖现有候选资料。
- 误以为所有附件都适合送 digitization。
- 误以为技能识别是语义理解，实际上这里更接近关键词匹配。
主要源码参考
enterprise/hr_recruitment_extract/models/hr_applicant.py
DISCUSSION
评论区