## A Manager's Real Situation

A Manager's Real Situation

In the third quarter of last year, my ten-person team took on a task: launching a "smart JD-to-resume matching" feature for the company's recruitment platform. As the project lead, my biggest worry wasn't whether we could pull off the technology, but three other things:

1. Schedule risk: Our two algorithm engineers each had their own preferences—one wanted to build in-house with open-source models, the other wanted to call APIs directly. Leaving the decision hanging would drag down the timeline.
2. Quality and compliance risk: Resumes contain sensitive personal information. If the matching logic showed bias (e.g., implicit discrimination against certain groups), that's not just a product problem—it's a legal problem.
3. Maintenance cost risk: The biggest fear for a small team isn't the launch itself, but that after launch, every model price change and every API change requires dedicated follow-up, tying up people long-term.

This article reviews our decision-making process and implementation approach at the time. It's intended as a reference for leaders of small teams planning similar AI features.

The Business Pain Point: Why Matching Is Worth Redoing with AI

For recruitment platforms, traditional JD-to-resume matching uses keyword matching with weighted scoring. The pain points are clear:

• Semantic gap: A JD says "responsible for high-concurrency backend architecture," and a resume says "led service decomposition for a system with millions of daily active users." Keyword matching scores near zero, yet both descriptions refer to the same thing.
• Inconsistent JD quality: JDs written by HR vary from detailed to sloppy, and structured parsing results in significant information loss.
• Labor cost: Mid-to-large platforms receive tens of thousands of new resumes daily. Purely manual screening is unrealistic, and poor manual rules lead to massive mis-screening and constant candidate complaints.

Our goal was restrained: not to replace HR decision-making, but only to do initial screening, ranking, and matching-reason summaries, compressing HR's screening time while keeping a human review step. This positioning determined all subsequent architecture choices.

Architecture Design: Layered Decoupling to Contain Risk

The final architecture has four layers:

┌─────────────────────────────────────┐
│  应用层：匹配分页 / 匹配理由展示 / HR复核台  │
├─────────────────────────────────────┤
│  业务编排层：JD解析 → 简历解析 →        │
│  匹配打分 → 摘要生成 → 审计日志        │
├─────────────────────────────────────┤
│  AI能力层：结构化抽取 / 语义匹配 / 摘要    │
│  （经由统一AI API网关调用）             │
├─────────────────────────────────────┤
│  数据层：简历脱敏存储 / 缓存 / 审计库     │
└─────────────────────────────────────┘

(A few key decisions:)

1. Separate parsing from matching. JDs and resumes first go through structured extraction (the model outputs JSON), get stored, and then matching runs. This way, iterating on matching logic doesn't require re-parsing existing data—saving a considerable amount in token costs.

2. Match in two steps: coarse ranking first, then fine ranking. Coarse ranking uses embedding vectors for recall; fine ranking uses an LLM to score each of the Top N results and output reasons. This avoids sending the full resume pool through the LLM, cutting costs by an order of magnitude.

3. All model calls go through a unified gateway. This was something I insisted on as a manager, for reasons explained later.

Key Implementation Steps and Checklist

Before launch, we put together an execution checklist, advancing week by week:

• [ ] Week 1: Data compliance assessment. Confirm the resume data anonymization plan (names, phone numbers, and ID numbers stripped before being sent to the model), and establish the "minimize what goes into the model" principle.
• [ ] Week 1: Finalize technology selection. One review meeting settled it: the in-house model plan was shelved; we adopted API calls instead; all calls go through the unified gateway, with individual services forbidden from connecting directly to any model vendor.
• [ ] Week 2: Prompts and output contracts. Define three prompt templates (JD extraction, resume extraction, match scoring), require models to output a fixed JSON Schema structure; frontend and backend develop against the contract without blocking each other.
• [ ] Weeks 2-3: Parallel development. Frontend builds the HR review console, backend builds the orchestration service, algorithms tune prompts. The foundation for running three tracks in parallel was the contract frozen in Week 2.
• [ ] Week 3: Bias testing. Build a test set specifically to verify whether the model implicitly weights fields like age and gender. Issues found are explicitly excluded in prompts, and physically removed before sending to the model.
• [ ] Week 4: Grayscale launch. Open to 5% of job traffic first, with 100% HR review rate; if the manual rejection rate exceeds a threshold, an automatic alert triggers rollback.
• [ ] Ongoing: Auditing and monitoring. Every match records an input summary, model version, and output for post-hoc traceability.

The rough shape of the core matching call (illustrative):

async def match_resume_to_jd(jd_text: str, resume_text: str) -> MatchResult:
    jd_struct = await gateway.chat(
        model="structured-extract",
        prompt=JD_EXTRACT_PROMPT,
        content=sanitize(jd_text),
        response_format="json"
    )
    resume_struct = await gateway.chat(
        model="structured-extract",
        prompt=RESUME_EXTRACT_PROMPT,
        content=sanitize(resume_text),  # 脱敏后送入
        response_format="json"
    )
    result = await gateway.chat(
        model="match-scorer",
        prompt=build_match_prompt(jd_struct, resume_struct),
        response_format="json"
    )
    audit_log.write(jd_id=jd_struct.id, model=gateway.last_model,
                    score=result.score, raw=result.raw)
    return MatchResult.from_json(result)

Note that all calls here point to gateway—no specific vendor SDK appears anywhere in the code.

Why a Unified AI API Gateway Is a Must for Small Teams

This is the part I want to expand on, because it directly addresses the "maintenance cost risk."

First, switching vendors requires no code changes. The LLM market changes every six months, with frequent price and performance fluctuations. If three services each connect directly to different vendor SDKs, switching models means regression testing three services. With a unified gateway, switching models only requires changing gateway configuration—zero code changes. We switched our fine-ranking model once after launch; the change was only in the configuration center and took half a day.

Second, centralized key management. Resume scenarios have high security requirements, and API keys scattered across service configurations are a hazard. The gateway holds keys and handles authentication centrally; engineers never touch production keys, and offboarding handovers are clean.

Third, cost and usage observability. The gateway layer does unified accounting, making token spend per feature clear at a glance. If a prompt's cost suddenly spikes, you discover it that day, not when the monthly bill arrives. Combined with per-feature call quotas, we also avoided a cost incident caused by an infinite loop in a test script.

Fourth, unified fallback and retry strategies. Exception handling for model timeouts, rate limiting, and content safety blocks is written once in the gateway, benefiting all services. What small teams lack most is manpower—this kind of infrastructure shouldn't be written three times over.

Retrospective: The Three Things a Manager Should Actually Manage

The project launched on schedule, and the manual rejection rate during the grayscale period stayed within a reasonable range. Looking back, my real contributions as the lead weren't writing code, but:

1. Locking in contracts early, enabling three workstreams to run in parallel;
2. Making sensitive data handling an upfront, mandatory process, rather than a pre-launch patch-up;
3. Using a unified gateway to turn the certainty of "models will change" into a configuration problem.

If you're planning a similar AI feature, choosing a reliable unified AI API gateway is the highest-ROI first step. The gateway we're currently using supports multiple mainstream models, pay-as-you-go billing, and unified key management—sign up and start using it immediately. It's ideal for small teams getting started quickly: https://api.thistoken.ai/register

---

Every example in this post runs with a single API key — get yours at https://api.thistoken.ai/register and start in minutes.