简历初筛AI助手上线翻车记 - 三个错误决策和它们的修正方案
先说结论：这个场景能做，但大多数团队死在第一步
「简历初筛」是招聘场景里最容易被AI化的环节：HR每天看几百份简历，其中八成与岗位无关。让AI先过一遍，把明显不匹配的过滤掉，听起来是一个周末就能做完的小项目。
实际做下来，我见过的小团队 Demo，十有八九活不过两周。问题不在 AI 能力不够，而在几个看起来无关紧要的早期决策。下面按时间顺序复盘三个典型的失败做法，再给出对应的正确路径——如果你的团队正准备做类似项目，可以直接对照检查。
失败做法一：把「筛选」当成「对话」
翻车现场
最常见的做法是直接把简历文本塞进 prompt，然后问模型：「这份简历符合这个岗位吗？」模型回答：「基本符合，候选人具备相关经验。」
HR 拿到这个结果完全没法用。「基本符合」是什么意思？符合哪几条？为什么符合？更糟的是，同一份简历跑三次，两次说符合一次说不符合——HR 对系统的信任直接归零。
问题根源
初筛本质上是一个结构化评估任务，而不是开放问答。用对话式 prompt 做结构化任务，等于把判卷工作交给出题人自己。
正确路径
把 JD 拆成显式的硬性条件和软性条件，让模型逐条打分并给出依据：
- 硬性条件（学历、工作年限、必备技能、城市）→ 输出
true/false+ 证据原文位置 - 软性条件（行业经验、项目复杂度）→ 输出 0-5 分 + 一句话理由
- 最终输出必须是 JSON，由代码做汇总决策，而不是让模型给结论
关键原则：模型只做证据提取和评分，最终「通过/不通过」的规则由代码写死。这样既稳定，又能在 HR 质疑时给出可追溯的判定链路。
失败做法二：简历解析这一步，直接喂原始 PDF
翻车现场
第二个常见坑：开发者用 PDF 库把简历提取成纯文本，直接送进模型。结果双列排版的简历提取出来文字顺序错乱，表格型简历变成一堆碎片，图片型简历（设计师岗位很常见）提取出来是空字符串。模型对着乱码一本正经地打分，筛出来的结果惨不忍睹，而开发者还以为是 prompt 写得不好，反复调了一个月。
问题根源
简历初筛的准确率上限，在模型调用之前就被文档解析质量锁死了。垃圾进，垃圾出，换什么模型都救不回来。
正确路径
把解析做成独立的、可单独测试的流水线阶段：
# 简历初筛流水线（伪代码示意）
def process_resume(file, jd_criteria):
# 1. 格式归一：PDF/Word/图片 统一处理
text = extract_text(file) # 图片走 OCR，PDF 保留排版信息
if len(text.strip()) < 200:
return {"status": "parse_failed", "need_manual": True}
# 2. 结构化抽取：切成固定字段，失败不阻塞
fields = llm_extract_fields(text) # 姓名/年限/技能/最近职位
# 3. 逐条评分：硬性条件由代码判断，软性条件由模型打分
hard = check_hard_rules(fields, jd_criteria)
soft = llm_score_soft(text, jd_criteria)
# 4. 汇总决策：规则在代码里，可审计
return decide(hard, soft)两个细节值得强调：解析失败的简历不要硬筛，标记为转人工，宁可漏不可错；所有涉及候选人个人信息的字段要脱敏后再进入日志，这是合规底线。
失败做法三：模型选型上「一条路走到黑」
翻车现场
项目启动时选了某个模型，把 prompt 和评分逻辑都围绕它的输出风格调死了。三个月后该模型价格上涨、或在国内访问不稳定、或出了更适合的新模型——团队想换，发现 prompt 强依赖特定模型的输出习惯，一换全崩。于是只能继续用又贵又不稳的方案，或者推倒重来。
问题根源
直接对接单一模型厂商的 API，等于把业务逻辑和供应商焊死在一起。模型市场现在每季度都在变，初筛这种对成本敏感、量又大的场景，供应商锁定是慢性毒药。
正确路径：统一 AI API 网关
正确的做法是让所有模型调用走统一的 AI API 网关层。它能降低维护成本的原因很具体：
- 一套接口适配多家模型。换模型只改网关配置里的模型名，业务代码零改动。上例中 prompt 兼容性问题，可以在网关层做输出格式兜底，而不是在每个调用点各写一份。
- 统一的密钥与用量管理。HR SaaS 场景往往要多租户计费，网关层的统一计费和配额能力，省掉了自己搭一套用量统计系统的成本。
- 统一的重试、降级和监控。初筛是批处理任务，某个模型超时自动切换备用模型，这种逻辑在网关层配置一次即可，不用在每个脚本里重复写。
- 成本可控。硬性条件判断这类简单任务路由到便宜的小模型，软性评分路由到能力强的模型，按任务分级用模型，账单能差出一个量级。
如果你的项目已经在用此类网关服务（比如 https://api.thistoken.ai/register 提供的这类统一接入能力），上述迁移成本几乎为零；如果没有，建议在写第一行业务代码之前就把它加上——这是我复盘三个翻车案例后最想提前告诉你的一条。
落地步骤清单
- 和 HR 一起把 JD 拆成硬性/软性条件清单，明确「可解释」是验收标准
- 搭解析层，准备 20 份格式各异的测试简历（含图片版、双栏版、空简历）
- 接入统一 AI API 网关，配置主模型与备用模型
- 实现 JSON 化评分 + 代码规则汇总，解析失败转人工
- 灰度运行：AI 结果先作为「建议排序」给 HR 参考，不直接淘汰
- 每周复盘误判案例，调整条件清单而不是盲目调 prompt
简历初筛这个场景，AI 不该替 HR 做决定，但完全可以让 HR 每天少看两百份无关简历——前提是，避开上面这三个坑。
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。