我们把 6 份流行的开源简历模板喂给 ATS 解析器：有一份丢光了所有数字

几乎每篇简历指南都会讲同样两件事：别用双栏、别让解析器看到花哨的东西。这两句话被转述的次数远多于被验证的次数。所以我们找了六份开源简历模板——程序员真的会去 GitHub 上 fork 的那几份——挨个走一遍和用户上传简历时完全相同的 PDF 文本提取。

结果和那句忠告相反：双栏解析得好好的，真正毁掉一份简历的是字符编码。

测了什么，怎么测的

六份 PDF，全部来自有明确开源许可的仓库。文本提取用的是站内上传流程同一个库、同一段调用——不另外挑一个「效果更好的」解析器，那样测出来的是解析器不是模板。提取出的文本再走我们免费 ATS 检测背后那套规则。

发现一：有一份模板丢光了每一个数字

Deedy 中文版提取出 1709 个字符，其中阿拉伯数字为 0 个。不是偏少，是一个都没有。同一批里其它文件都在 69 到 453 之间。

这在实际投递里意味着：解析器读这份简历时，看不到毕业年份、看不到任职时间、看不到任何业绩数字。提取出来的文本长这样：

打开 PDF 用眼睛看，数字明明都在。它们只是不在文本层里，所以任何按程序读这个文件的东西都收不到。这份简历里每一条量化成果——恰恰是所有指南都让你写的那个东西——对机器完全不可见。

发现二：同一份文件连自己的汉字都错了

同一次提取里有 69 个字符并不是它们看上去的那个字。它们是康熙部首——一个渲染出来几乎一模一样、但码位完全不同的 Unicode 区块。候选人的姓提取出来是 ⾼（U+2F98，部首）而不是 高（U+9AD8，汉字）；工程 提取出来是 ⼯程。

发现三：双栏什么问题都没出

这条和流行说法正好相反。英文版 Deedy 是左窄右宽的双栏布局，它通过了全部排版相关的检查：邮箱抓到了、电话抓到了、联系方式在开头几行找到了，被判定为「串栏」的行数是 0。

「双栏危险」这个说法不是空穴来风——用无标签表格或文本框实现的分栏，压平成文本时确实会串行。但双栏布局不等于那种实现。我们实测到的是：失效点在文件怎么编码文本，不在你看到几栏。

有一条结果我们扔掉了

这次运行一开始把 zheyuye 那份标成了「抓不到电话」。那不是缺陷。那份模板的示例内容里写的就是 13xxx-xxx-xxx，是作者故意留的占位符——根本没有号码可抓。把它当成模板缺陷写进去，等于拿别人的占位符充数，所以它不进结论。

特意提一句被扔掉的结果：一个只让你看到成功那一半的测量，不算测量。

那该做什么

1. 打开你自己的 PDF，用鼠标把正文选中复制，粘到一个纯文本的地方。剪贴板里出现的东西，和解析器收到的差不多。
2. 专门看数字。日期和业绩数据是最先消失的，也是最不容易发现少了的。
3. 如果汉字或数字消失了，要修的是字体嵌入，不是版式。重新导出时把字体完整嵌入，或者干脆换一条导出路径。
4. 不要仅仅因为「它是双栏」就把简历重排成单栏。先测一下——它可能本来就没问题。

怎么复现

测量脚本在仓库里，路径是 scripts/ats-template-audit.ts，每份模板的来源、许可和 commit 都记录在文件旁边。跑一遍应该得到同一张表。如果对不上，那是这篇文章过期了，以脚本为准。