A 4-Prompt AI Resume Screening System Caught Every Planted Trap in 96 Seconds

1. Pain Point: Resume Screening — Something Everyone Does, But No One Does Well

Next week, our team's data operations position opens for recruitment. Based on last year's experience, we'll receive over a hundred resumes within two weeks — and initial screening is precisely the most counter-human part of the hiring process:

Pitfall 1: Standards drift. For the first resume, you carefully check against "3 years of experience, proficient in SQL"; by the 50th resume, "familiar with SQL" and "understands SQL" look the same to you. Manual screening has no stable scoring standard, only gradually fatiguing attention.

Pitfall 2: Details rely entirely on sharp eyes. A one-month gap between two jobs, a skills section listing "proficient in Python" but the work experience never mentioning it — these details are noticeable when looking at a single resume, but you go nearly blind after thirty in a row. And they are precisely the signals most worth questioning.

Pitfall 3: Output is not reusable. After a round of screening, all you have is an Excel sheet: three columns for name, checkmark, and notes. When the interviewer asks, "Why did this person make it to the interview?", the answer exists only in your memory. If someone else tries to review it, it's a mess.

I did the math: carefully reading one resume takes 3–5 minutes. 137 resumes ≈ two full days. And within those two days, the truly "judgment-worthy" decisions might number only a dozen or so.

So I decided to build the initial screening into a system within TraeWork — but before feeding real resumes to the AI, I first gave it an exam paper with traps.

2. Practice: Building This Screening System in 4 Steps

The system's four steps are interlinked: Scorecard sets the rules → Simulated exam verifies reliability → Batch screening produces a ledger → Interview questions and review wrap things up. Create a new task "AI Resume Screening" in TraeWork, and send the four instructions in order within the same session, sharing context throughout.

Step 1: Turn the JD into a Scorecard First, Instead of Throwing Resumes Directly at It

Saying "help me screen resumes" directly will make the AI use its own imagined standards — and they'll be different each time. The correct first step is to turn vague hiring requirements into a structured scorecard:

For this step, I asked for one extra thing: grading rules for vague phrasing. "Proficient/Skilled + experience corroborates" counts as met; a claim without corroboration is marked "Questionable"; "Can/Understands" is directly judged as not meeting the bar. This rule is key to catching all the traps later.

See Template 1 at the end for the original instruction text.

Step 2: Create a "Mine-laden" Exam Paper

I didn't test with real resumes first — first, real resumes contain private info like names and phone numbers that shouldn't be casually fed to a tool (always de-identify data in real operations); second, real resumes have no standard answer, so I wouldn't know if the AI screened correctly.

So I wrote 6 de-identified simulated resumes based on real resume patterns, each with a specific trap planted:

Resume	Trap Planted
R1 Wang Lei	No trap. All hard requirements met + all preferred items met with corroboration. Standard answer: "Recommend"
R2 Li Qiang	No trap. Education/Years/Skills all unmet. Standard answer: "Do Not Recommend"
R3 Chen Jing	Half-trap. Claims "SQL skilled" but experience only shows report creation, no data extraction corroboration
R4 Liu Yang	Vague word trap. "Can Python" "Understands SQL" — do they meet the hard bar?
R5 Zhao Lei	Timeline trap. Two experiences overlap by 2 months + a 3-month gap
R6 Sun Yue	Inflation trap. Skills list "Proficient Python/Skilled SQL/Tableau", but work content only mentions Excel

Creating the exam paper before using real data — this logic applies to any scenario where you "want AI to take over a judgment task" — when you don't know if the AI is reliable, give it a test where you know the answers.

Step 3: Batch Screening — Full Table in 1 Minute 36 Seconds, All Traps Detonated

I sent the 6 resumes as attachments along with the scoring requirements to TraeWork. The core of the instruction was one sentence: Every conclusion must cite the original resume text; write "Questionable" if unjudgeable; speculation is forbidden.

A judgment table for each resume, with the original resume text cited right next to every conclusion. Taking R1 Wang Lei as an example, 7 criteria scored item by item, with citations and timeline checked:

Results compared to the standard answers: All 6 judged correctly. 1 Recommend, 3 Pending, 2 Do Not Recommend. More crucially, the details of catching the three planted traps:

• R3's SQL claim caught as Questionable: Claims "SQL (Skilled)", but experience only shows "data report creation" and "tag data verification" — per the grading rules, no application corroboration means it cannot be judged as met; simultaneously caught that her last experience ended in 2024.08, a gap of nearly 2 years;
• R5's timeline anomaly caught (image below): 2022.01–02 two experiences overlap, 2023.05–08 a 3-month gap, directly marked Pending;
• R6's skill inflation caught: Three high-level claims vs. only Excel throughout the work content, all marked Questionable, bonus points forbidden.

Unplanned bonus: R3 and R4's last experiences on their resumes ended in 2024.08 and 2024.09 respectively — a nearly 2-year career gap. This was something I hadn't deliberately planted when designing the simulated resumes. The "experience end date," which human eyes are most numb to, was checked resume by resume. Once the rules are clear, a machine is far more stable than fatigued human eyes.

Finally, a summary ranking table, sorted by total score descending, ready to paste into the recruitment ledger:

Step 4: Interview Question Generation + Pending Review, Wrapping Up in One Go

The endpoint of initial screening isn't just a table. For the sole "Recommend" candidate R1, I had TraeWork generate 8 customized interview questions based on his resume text — not generic questions from a bank, each one targeting a specific sentence in the resume:

For the 3 "Pending" candidates, I asked it to give handling suggestions based on "Value after Clarification × Clarifiability of Doubts," directly attaching phone review scripts:

The most interesting suggestion: For R6, the recommendation was to change the phone screening to a practical verification — "You can't get the truth from verbal questions; anyone who memorized answers can respond. Have him verbally describe the logic for an SQL query aggregating sales by date, and listen for details, not concepts." At this step, the AI wasn't giving a neatly formatted answer; it was genuinely designing a review strategy for you.

3. Results: A Verified System + An Auditable Scoring Ledger

The four-step system ran with a total of 4 instructions in one session. The batch screening step took 1 minute 36 seconds (checkable in the TraeWork taskbar), the interview question and review steps each took just over 1 minute. Including the time to design the simulated resumes, the entire process took under 20 minutes. Three outputs were produced:

1. An auditable scoring ledger: For 6 resumes, each item's score, a three-tier conclusion, original text citations, and a list of doubts. Anyone can review my judgment — "Why did this person get an interview?" now has documented evidence;
2. 8 customized interview questions: Directly entered into the interviewer's question board, each marked with its assessment point, along with usage suggestions divided by interviewer role;
3. A set of verified instruction templates: After the mine-laden exam was aced, this process is qualified for use on real resumes.

The efficiency calculation is straightforward: Manually screening 6 resumes carefully and writing doubt notes takes about 40 minutes. TraeWork produced the table in 1 minute 36 seconds and caught gap details I might not have noticed even after three human reviews. Extrapolating this ratio to the real 137 resumes: ~2 days manually → AI batch output + 1 hour of manual review for the "Pending" tier.

But more important than the time saved is the quality change: the scoring standard went from "in my head" to "in the scorecard" — consistent throughout and auditable item by item.

4. Reuse: 4 Instruction Templates, Ready to Copy

Below are the 4 instructions used throughout this article. Just replace the content in 【】 with your own. The order cannot be changed: Scorecard first, then batch screening, and finally interview questions and review.

Template 1: JD → Scorecard (Calibrate First, Then Screen People)

You are a senior recruitment expert. I am sending you a job JD. Please convert it into a structured initial screening scorecard:
1. Extract 5-8 hard criteria (education/years/skills/industry), divided into "Must-have/Priority" tiers. Candidates failing hard criteria are directly eliminated;
2. Provide clear judgment standards and scores for each criterion;
3. Differentiate vague phrasing: e.g., how to grade "Can Python" vs. "Familiar with Python," providing executable rules. Skill claims must be corroborated by experience to count as met; claims without corroboration are marked "Questionable";
4. Add a separate "Questionable Items" column: which phrasings in the resume cannot be judged and require manual confirmation;
5. Output a three-tier conclusion standard: Recommend/Pending/Do Not Recommend (Timeline anomalies like overlapping experiences or gaps over 2 months automatically go into "Pending").

The job JD is as follows:
【Paste JD】

Template 2: Main Batch Screening Instruction

According to the scorecard above, score these 6 resumes one by one. Requirements:
1. Output for each resume: Name / Score per item / Total Score / Three-tier Conclusion (Recommend/Pending/Do Not Recommend);
2. Every deduction and bonus point must cite the original resume text as evidence; speculation is forbidden;
3. Write "Questionable" for anything unjudgeable; do not score blindly;
4. Check the work experience timeline for each resume, marking overlaps and gaps exceeding 2 months;
5. Finally, summarize a ranked master table, sorted by total score descending.

【Paste resumes, or upload resume files as attachments】

Template 3: Interview Question Generation (Only for Shortlisted Candidates)

Below is the resume of candidate R1, who was "Recommended" in the initial screening. Please generate 8 interview questions for him:
1. 3 Deep-Dive Questions: Ask for details on the most impressive experiences in the resume (use the STAR method to verify authenticity);
2. 3 Doubt Questions: Follow up on vague phrasing, questionable timelines, and skill-project mismatches;
3. 2 Job-Specific Questions: Create scenario questions based on the JD's core requirements;
4. Mark the assessment point for each question. Questions must cite the original resume text; generic question bank questions are forbidden.

【Paste the shortlisted candidate's resume; can also directly reference above content within the same session】

Template 4: Pending Tier Review (Deciding Where to Spend Time)

For candidates marked "Pending" in the initial screening, please sort them by "Value after Clarification × Clarifiability of Doubts." For each, give a suggestion: Worth a 15-minute phone screening / Can be directly rejected, explaining the reason, and provide specific phone review scripts. For those suspected of skill inflation, provide practical verification questions.

Pitfall Checklist

1. Create the exam paper before using real data: Plant a few traps where you know the answers (overlapping timelines, claims inconsistent with experience). Only use it on real resumes after the AI catches them all. This step also solves the privacy issue — you don't need real resumes at all during the testing phase;
2. Mandatory citation of original text: The phrase "must cite original resume text; speculation is forbidden" in Template 2 is the foundation of the entire process. Remove it, and the AI will start imagining experiences the candidate never wrote;
3. Three tiers, not a binary: The "Pending" tier is a safety valve — sending unjudgeable cases to manual review costs far less than the AI directly eliminating a good candidate or letting an inflated one through;
4. Run all four steps in the same session: Don't start a new session after generating the scorecard. Let the AI maintain context — the latter two steps (interview questions, review) can directly reference the initial screening conclusions without re-pasting resumes;
5. Always de-identify real resumes first: Replace names with aliases, delete phone numbers and ID numbers before feeding them to the tool;
6. AI only does the initial screening: The final interview list is always decided by a human. What AI provides is "ranked sorting with evidence," not a "hiring decision" — keeping the decision-making power with the human is the prerequisite for this process to be usable long-term.

5. Final Thoughts

The biggest takeaway from this real-world test isn't "6 resumes screened in 1 minute 36 seconds," but that for the first time, initial screening has an auditable standard: the scorecard is the rule, the original text citations are the evidence, and the three-tier conclusion is the buffer.

The point of AI screening resumes isn't to replace someone's judgment on whether a candidate is worth interviewing — that's a human's job. What it does is fish humans out of the "attention deficit" that sets in after the 50th resume: the rules watch every resume, and humans only step in at the "Pending" and "Interview" stages, where real judgment is needed.

Recruitment season is coming. It passed this exam. For the next batch of real resumes, it's ready to take the field.

---

The resumes in this article's scenario are all de-identified simulated resumes, used to verify the process and protect privacy; the 4 instruction templates can be directly reused in your real recruitment scenarios.