上周帮一个朋友看简历，后端五年经验，Spring Cloud 玩得挺溜，投了 200 多家，面试 3 个。我把他 PDF 丢进一个模拟 ATS 的脚本里跑了一遍，匹配度 31%。问题不在于他能力不行，而在于他这份简历压根没被真人打开过------75% 的简历在 HR 点开邮箱之前，就已经被关键词算法判了死刑。
这不是贩卖焦虑，这是一个可以被逆向的工程问题。
先说 ATS 到底在干什么
很多人以为 ATS（Applicant Tracking System）是个智能筛选系统，其实大部分中小厂和部分大厂用的还是十年前的架构：PDF/Word 解析成纯文本 → 分词 → 词表匹配 → 加权打分 → 低于阈值直接进 trash。整个过程没有语义理解，没有上下文，就是一堆 if (jd.includes(keyword))。
黑盒的地方在于：你不给它分数，它也不告诉你缺什么词。你只能一遍遍改简历，像往自动售货机里塞硬币，塞到某一次掉出来一瓶可乐，但你不知道自己塞对的是哪一枚。
我复现了一遍逻辑，踩到三个坑
坑一：纯字符串匹配会误杀同义词
JD 上写的是 Kubernetes，你简历里写 K8s，匹配失败。JD 写 Golang，你写 Go，匹配失败。更离谱的是 JavaScript 和 JS、持续集成 和 CI/CD，在 naive 的匹配算法里都是两个毫不相干的词。这不是你写错了，是算法太笨。
坑二：JD 里藏在职责段落里的硬性词，权重被吞了
招聘方写 JD 的时候，往往把技术栈埋在「负责 xxx 系统的设计」这种长句里。大部分人的做法是通读一遍，凭感觉抓到几个显眼的词就改简历，结果漏掉的是真正常用的框架名。
坑三：格式才是隐形杀手
双栏排版、图表化的技能条、文本框、页眉里的联系方式、用图片做的公司 logo------这些在 PDF 里看着很舒服，解析出来全是乱码或者直接丢失。见过最惨的一个例子：候选人把联系方式放在页眉，ATS 解析时整段丢弃，HR 收到一份没有电话和邮箱的简历。
所以我自己写了个东西
我做了个 Chrome / Edge 扩展，叫 ResumeRadar。核心思路很简单：既然黑盒不告诉我分数，那我就在浏览器里自己算一遍。
它做的事：
- 网页悬浮雷达实时扫描：在 Boss 直聘、LinkedIn、Indeed、Glassdoor 的岗位详情页上，直接浮出一个雷达按钮，一键抓取当前 JD 全文，不用复制粘贴；
- 0~100% 匹配度实时打分：把你的简历文本和 JD 做分词比对，绿标是命中，红标是缺失，缺什么补什么，一目了然；
- 词界 + 同义词映射 ：这是我觉得最值得说的一点。普通匹配用
includes会出问题------Go会命中Google、Django，Java会命中JavaScript。所以做了 Word-Boundary 词边界校验，同时维护了一张技术同义词表，K8s ↔ Kubernetes、Golang ↔ Go、CI/CD ↔ 持续集成，全部归一到同一个概念节点； - 按 STAR 原则重构经历：可选接入 DeepSeek 或 Claude，把匹配度低的经历条目按「情境-任务-行动-结果」重写，让它读起来像人写的，同时把缺失的关键词自然嵌进去；
- 本地加密存储：简历是很私密的东西，所有数据走浏览器本地存储加密，不上传任何服务器，这点我比较在意。
几个实操建议，比工具本身更重要
- 别为了刷分堆词。把 JD 里出现三次以上的技术词对应到你真实做过的项目里，写成「用 Redis 做了热点缓存，QPS 从 800 提到 4000」，而不是在技能栏罗列二十个名词。
- 投之前先导出纯文本自检。把简历另存为 txt 看一眼，如果结构全乱了，说明 ATS 也会乱。单栏、无表格、无文本框，是最稳的排版。
- 同一家公司别海投多个岗位。很多 ATS 会记录你投递的历史岗位，短时间多次投递反而会降低优先级。
- 匹配度 70% 以上再投，60% 以下基本是给算法当分母。
最后
工具已经上架 Chrome 应用商店，搜 ResumeRadar 就能装，Edge 商店同步。装上之后随便找个岗位页面试一下，看看你现在的简历能打几分------我猜大部分人第一次看到的分数都会有点难受。
评论区聊聊：你遇到过最离谱的简历被筛原因是什么？我先来一个，有朋友因为简历文件名带了下划线 _，被某系统的上传校验直接拒了。