和岗位描述对上，不是把 JD 抄一遍，而是让它的关键要求写进工作经历的使用场景，并尽量靠前出现。技能栏只是补充，代替不了证据。

先说一个数字。据 Jobscan 2026 年 8 月发布的第 6 版 ATS 使用率报告，财富 500 企业里有 97.4% 能被检测到在用招聘系统。换成绝对数，就是 500 家里的 487 家。这不是新趋势：2025 年是 97.8%，2024 年是 98.4%。

所以「机器先看一遍」这件事不用再论证。要解决的是下一问：它看的时候，凭什么决定先看谁的。

对口不是你觉得像，是系统能不能检索到

招聘系统做的是检索，不是理解。它把简历拆成字段，再拿岗位描述里的词去比对：有没有这个词、出现几次、落在哪一版块。你说的「对口」如果只是「我觉得这些事我干过」，那在系统那里等于没写，它只认得文本里的字。

先判断一下：打开你最近投的那份简历，数一数技能栏第一行的词，有几个能在工作经历里原样找到。这一步花不了一分钟，结果多半和你以为的不一样。

有个更容易被忽略的门槛：文件能不能被解析成文本。据 Parseur 2026 年 8 月整理的各家官方文档与指南，Greenhouse 的说法最直白。非标准格式或含嵌入图像的简历，内容是读不出来的，候选人也不会被加进人才库。Lever 的开发者文档同样写明，图像文件无法成功解析。

招聘官那一侧也一样。据 Huntr 2026 年 4 月发布的访谈报告，4 位招聘官分别来自亚马逊、微软、四大和另一家财富 500 企业。他们对关键词过滤的说法很一致：主要用于主动搜人，很少用在某一份具体申请上。微软那位还把这类过滤器形容成「加了好看外观的布尔检索」。

同一份经历，两种写法，评分差了 57 分

为了不靠感觉说话，我做了一组对照。同一份岗位描述、同样一段工作经历，我写成两版简历。A 版的技能栏写满 JD 里的词，经历行是「负责、参与、协助」。B 版技能栏一个字没改，只把经历行改成「用什么工具、做了什么、覆盖多少量」。

两版一起送进匹配度评估接口。先过门槛问题，一共 6 道：学历和年限走规则判断，SQL、Python、A/B 测试与埋点、可视化工具走语义判断。过了门槛，再按关键词命中率和语义相似度排序。

结果差得很远。A 版总分 0.0，档位「差」；B 版 57.42，档位「中」。更值得看的是门槛那一栏：A 版 4 道语义问题全部判「简历未提及」，B 版全部通过。

关键词那一栏更能说明问题。A 版的技能栏明明写着 SQL、Python、Pandas、Tableau，接口返回的必需技能命中数却是 0。B 版把同样的词写进经历行，命中了 3 项必需技能，另外命中 1 项优先项。技能栏是标签，经历行才是证据。

只有一处例外。B 版把 A/B 测试写成了带空格的「A/B 测试」，工具的词表把它当成另一个词，没算命中；但门槛那 4 道语义判断读懂了它。可见词表匹配和语义判断是两套逻辑，别只盯着一个数。

岗位要求片段，该落到简历的哪个位置

回到最实际的问法：一段岗位描述摆在面前，哪些原话要落到简历的哪一行。下表左边是示例 JD 的原话，中间是它该落的位置，右边是写出来以后的样子。

这张表要照抄的是结构，不是词。左边那列换成你手上那份 JD 的原话，中间那列告诉你这类要求通常该放在哪一块，右边那列才是你自己的内容。技能栏负责让关键词被发现，经历行负责让关键词站得住。

顺序也有讲究。最相关的两三条经历要放在第一页靠上的位置，不要藏在第三页。据 Huntr 的访谈，招聘官在一份简历上停留的时间大约 6 到 10 秒。你控制不了那 6 秒里他看什么，但能控制最相关的那几行是不是最先出现。

20 行脚本自查：关键词出现在第几段

手工数关键词很容易漏。下面这段脚本不到 30 行，只做一件事：把你从 JD 里圈出来的词，逐个在简历里找出来，报出出现几次、落在前中后哪一段、是否只躺在技能栏。

准备两个文本文件，一个放关键词（每行一个），一个放简历的纯文本版本。在同一个目录里执行一行命令：

python3 kw_check.py jd_keywords.txt resume_a.txt

# -*- coding: utf-8 -*-"""检查岗位关键词在简历里出现在哪一段（纯标准库） 用法：python3 kw_check.py jd_keywords.txt resume.txt"""importreimportsys kw_file,res_file=sys.argv[1:]resume=open(res_file,encoding='utf-8').read()kws=[l.strip()forlinopen(kw_file,encoding='utf-8')ifl.strip()]n=len(resume)zones=[('前1/3',0,n//3),('中1/3',n//3,2*n//3),('后1/3',2*n//3,n)]# 「技能」小节范围：从含「技能」的标题行到下一个标题行m=re.search(r'^#{1,3}\s*技能[^\n]*\n(.*?)(?=^#{1,3}\s|\Z)',resume,re.S|re.M)span=(m.start(1),m.end(1))ifmelseNoneprint('%-14s %-6s %-20s %s'%('关键词','次数','命中位置','只在技能栏'))hit_total=only_skill=front_hit=0forkinkws:pos=[iforiinrange(n)ifresume.startswith(k,i)]where=[nameforname,lo,hiinzonesifany(lo<=p<hiforpinpos)]sole=Falseifposandspan:lo,hi=span sole=all(lo<=p<hiforpinpos)ifpos:hit_total+=1only_skill+=1ifsoleelse0front_hit+=1if'前1/3'inwhereelse0print('%-14s %-6d %-20s %s'%(k,len(pos),'/'.join(where)or'未出现','是'ifsoleelse'否'))print('-'*52)print('关键词 %d 个 | 命中 %d 个 | 只在技能栏 %d 个 | 落在前1/3 %d 个'%(len(kws),hit_total,only_skill,front_hit))

拿前面那两版简历各跑一遍，输出是这样的：

关键词 次数 命中位置 只在技能栏 SQL 1 后1/3 是 Python 1 后1/3 是 Pandas 1 后1/3 是 Tableau 1 后1/3 是 A/B 测试 1 后1/3 是 埋点数据口径 1 后1/3 是 用户增长 1 前1/3 否 多表关联 0 未出现 否 数据清洗 0 未出现 否 数据看板 0 未出现 否 ---------------------------------------------------- 关键词 10 个 | 命中 7 个 | 只在技能栏 6 个 | 落在前1/3 1 个

这里有个容易读错的地方。这个脚本数的是「词出现过几次」：A 版命中 7 个，比 B 版的 6 个还多。原因很简单，A 版在技能栏把词抄了一遍，脚本照样数得到。

真正决定排序的判断，算的是词有没有落在经历里。同一个动作，两套口径给出相反的结论，就像分数和老师印象不是一回事。

所以这个脚本只能当索引，不能当判决。它告诉你哪个词该挪位置，不告诉你改完会不会有人回你。说白了，能自己验证的部分就别靠感觉。

匹配度百分比该怎么读，别当成及格线

网上流传的「匹配度要到多少才算过」，版本不止一个，彼此还对不上。

四家说法、四套数字，没有一家给出样本和方法。这类数字的正确读法是看分子分母。举个假设的例子：某个工具说你的匹配度是 62%，它算的是自己维护的那张词表里命中了几项，分母是它挑出来的词数。这跟某家企业实际用的招聘系统没有关系。

Huntr 的报告说得更直接：不存在通用的 ATS 分数，也不会有雇主看到你简历上的 0 到 100 分。给你打分的工具用的是自己的标准，不复制任何真实系统的行为。

前面那组对照，用的就是仙踪问道·简历优化里的匹配度评估接口。同一个接口、同一份岗位描述，只换了简历写法，分数从 0.0 变成 57.42。它不是及格线，只是一个相对值。改前一个数、改后一个数，差的那些就是你补进去的词。至于多少分算够，没有统一答案。

岗位匹配自查表：投递前逐项打勾

把上面的做法固定成一张表，投递前逐项打勾。六项都过了再提交，比投完再回来改省事。

六项里最容易漏的是第 3 项和第 4 项。第 3 项是位置：词都写了，但全在技能栏，经历里一个都没有。第 4 项是口径：JD 里写「A/B 测试」，你写「AB 测」，机器读到的是两个词。

岗位侧的变化也值得放进判断。据前程无忧《2026届校招市场AI人才需求报告》，校招侧大模型算法工程师的月薪中位数是 24,760 元，近六成企业计划扩招 AI 人才。同一份报告里还有一组数字：20.3% 的企业缩减了基础客服这类标准化岗位的应届生编制。入口的形状在变，越是这样，简历里能被检索到的证据越值钱。

三个常见误区与它们的边界

误区一，把 JD 抄进技能栏就等于对上。前面那组对照里，A 版就是这么做的，命中数是 0。词在技能栏里待着，谁也没法从经历里看出你用过它。

误区二，机器会自动把你淘汰。据 Huntr 2026 年 4 月整理的 7 个主流招聘系统对照表，它们都支持按预设门槛自动淘汰，门槛是学历、年限这类可配置项。但表里没有一个是「在没有人参与的情况下、只凭简历内容自动拒绝」。真正挡人的往往是门槛问题，不是关键词。

误区三，有一个万能分数，冲上去就行。这条上一节已经拆过，不再重复。更该记住的是边界：那组对照是我用一个示例简历跑出来的，岗位是数据运营，换成产品经理或财务，词表完全不同，结果未必一样。

还有两条边界要说清楚。第一，不同评估工具给的分数不能互相换算，同一份简历在两个工具里可能算出两个不同的数。第二，让机器读到不等于会被推进。据 Huntr 的访谈，招聘官做的仍是 6 到 10 秒的扫描，最终判断是人做的。检索和门槛这两关能自己过干净，剩下的部分不在这篇文章的范围内。

关于简历和 JD 对不上的 4 个问题

下面四个问题，是这类题材里问得最多的。答案按前面的实测口径写，不扩张。

问：技能栏里明明写了 SQL，为什么系统说没命中？

答：不少系统只在经历段落里提取技能的使用场景。同一个词写在技能栏和写进经历行，被算进去的概率不同。把它挪进你真正用过它的那一条经历，是最省事的改法。

问：JD 要求 10 项技能，我只有 6 项，要不要都写上？

答：不写没有的。写上去的要是能撑住追问的，缺口留到面试里解释更稳。硬凑的词会在追问的第一轮露馅，反而拖累整份简历的可信度。

问：要不要为每个岗位改一版简历？

答：不必整篇重写。改三处就够：技能栏里词的排序、经历行里的工具名和动词、关键词的位置。仙踪问道·简历优化会把没命中的词单列出来，照着补就行。

问：简历用 PDF 还是 Word？

答：两者都行，前提是文字能被选中、能被复制。扫描件、图片导出的 PDF、文本框和复杂分栏，是各家文档里都提到的解析风险点。

今天就能改的一处

今天就能做的一件事。打开你最近投的那个岗位的描述，圈出 5 个最关键的要求词，回到简历里逐个找它出现在哪一行。

只在技能栏出现的词，把它挪进对应的经历行，补上工具、对象和量级。出现在第三页的词，往前挪到第一页。整个过程 15 分钟左右，比再投 20 份简历有用。

不想手工数的话，仙踪问道·简历优化可以把一段岗位描述和一份简历放在一起，给出关键词命中的位置和几道门槛问题的判断，你按结果改。它给的是自查结果，不是录用结论，最后那一关仍然是人来判断的。

关注这个账号，后面我继续把投递这一关拆成能对照的表和清单。你最近投的那个岗位，简历和它对上了吗？差在哪一项？欢迎在评论区留言，出现多的那一项，下一篇就写它。