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)

Two details worth emphasizing: resumes that fail to parse should **not be force-screened**—flag them for manual review; false negatives are acceptable, false positives are not. And all fields containing candidate personal information must be anonymized before entering logs—this is a compliance red line.

## Failure Pattern 3: Going "All In" on a Single Model

### The Crash Site

At project kickoff, the team picks a model and tunes all prompts and scoring logic around its output style. Three months later, that model's price goes up, or its access becomes unstable in your region, or a better-suited model is released—the team wants to switch, only to find the prompts are tightly coupled to that specific model's output habits, and everything breaks the moment they switch. So they're stuck with an expensive, unstable solution—or they have to start over.

### Root Cause

Directly integrating a single model vendor's API means your business logic is **welded to the vendor**. The model market changes every quarter now, and for a cost-sensitive, high-volume use case like screening, vendor lock-in is slow poison.

### The Right Path: A Unified AI API Gateway

The correct approach is to route all model calls through a unified AI API gateway layer. The reasons it reduces maintenance cost are concrete:

1. **One interface, multiple models**. Switching models means changing the model name in the gateway config—zero changes to business code. For the prompt compatibility issue above, you can handle output-format fallback at the gateway layer instead of writing it separately at every call site.
2. **Unified key and usage management**. HR SaaS scenarios often need multi-tenant billing. The gateway's unified billing and quota capabilities save you from building your own usage tracking system.
3. **Unified retries, fallbacks, and monitoring**. Screening is a batch job. "Auto-switch to a backup model when one times out" needs to be configured once at the gateway layer, not rewritten in every script.
4. **Controllable costs**. Route simple tasks like hard-criteria checks to cheap small models, and soft scoring to more capable models. Tiering models by task can change your bill by an order of magnitude.

If your project already uses such a gateway service (for example, the unified access capability offered at https://api.thistoken.ai/register), the migration cost described above is nearly zero. If not, I recommend adding it before you write the first line of business code—this is the single most important lesson I want to share after reviewing these three failures.

## Implementation Checklist

1. Work with HR to break the JD into hard/soft criteria lists, and make "explainability" an acceptance criterion
2. Build the parsing layer, and prepare 20 test resumes in diverse formats (including image-based, two-column, and empty ones)
3. Connect to a unified AI API gateway, and configure primary and backup models
4. Implement JSON-based scoring + code-based rule aggregation, with parse failures routed to manual review
5. Run in canary mode: AI results serve only as "suggested ranking" for HR reference, with no automatic rejection
6. Review misjudged cases weekly, and adjust the criteria lists rather than blindly tweaking prompts

For resume screening, AI shouldn't make decisions for HR—but it can absolutely save HR from reading two hundred irrelevant resumes a day. Provided, of course, you avoid the three pitfalls above.

---

Tired of juggling provider integrations? Register at https://api.thistoken.ai/register and call every model through one base_url.