我在每天投递15–20份工作后构建了一个简历 ATS 工具

发布: (2026年1月2日 GMT+8 13:05)
7 min read
原文: Dev.to

Source: Dev.to

请提供您希望翻译的文章正文内容(除代码块和 URL 之外的文字),我将把它翻译成简体中文并保留原有的格式。谢谢!

Source:

求职耗尽了我的耐心,先于信心

在大四那年,求职成了全职工作。每天的节奏都一样:

  • 打开招聘门户
  • 阅读职位描述
  • 定制简历
  • 投递申请
  • 重复

我每天要向 15–20 家公司 投递,涉及不同的岗位和领域。每份申请都需要一份 稍有不同的简历:修改概述、重新排序技能、改写要点、删除“不符合该岗位”的内容。这工作并不难,却是 精神上极度消耗 的活儿。第 40 次改写后,我意识到出了问题。

真正的问题不在简历

大多数人认为简历失败是因为:

  • 格式糟糕
  • 技能缺失
  • 经验不足

这只是部分原因。更大的问题是 相关性。一份适用于某个岗位的简历,可能在另一岗位上悄然失效,即使候选人资历合格、经验扎实、技能齐全。

为什么?因为 ATS 系统不评估潜力,只匹配文本。如果你的简历没有与职位描述精准对应,它不会被大声拒绝——它会悄无声息地消失。这是最糟糕的拒绝方式。

ATS rejection illustration

所以我出于沮丧而构建了一个东西

我厌倦了手动编辑简历——不是因为做不到,而是因为每天都在解决同样的问题。我写了一个小脚本(没有 UI,也没有产品愿景),在我的 VS Code 终端 中运行,完成三件事:

  1. 接收我的简历
  2. 接收职位描述
  3. 生成与该职位匹配的定制版简历

它并不完美,但节省了时间,更重要的是,它真的起作用了。最终,我被录用了。

显而易见的问题

在我被录用后,我问自己:“如果这对我有帮助,为什么其他人仍然要手动经历这些痛苦?”大多数人要么在各处使用同一份通用简历,要么花数小时重写简历,却不知道到底哪些内容真正重要。这两种做法都无法始终如一地奏效。这也是我决定 将脚本转变为正式工具 的原因。

MVP 实际功能

我有意将 MVP 保持得小而专注。

工具

  • 分析你的简历与职位描述的匹配情况
  • 识别缺失或不足的技能
  • 调整内容以提升 ATS(申请者追踪系统)的兼容性
  • 确保简历对人类阅读友好

工具

  • 承诺一定获得面试
  • 盲目堆砌关键词
  • 将简历重新设计成花哨的模板
  • 假装招聘“靠 AI 就很容易”

目标很简单:让每次提交 相关 简历变得更容易。

为什么 ATS 优化很重要(不管我们喜不喜欢)

ATS 系统并不聪明,也不邪恶——它们只是帮助公司处理大量简历而非质量的 过滤器。这意味着:

  • 优秀的候选人可能会被过滤掉
  • 如果匹配度更高,普通候选人也可能通过

这个工具并不是在玩弄系统,而是 在其限制范围内清晰沟通。最终决定仍由人来做,ATS 只决定谁会被看到。

ATS filter illustration

我在构建和测试时学到的东西

  • 人们在要删除什么上比在要添加什么上更挣扎
  • 过于堆砌的简历表现不如聚焦的简历
  • 试图适配每一个职位会降低清晰度
  • 手动定制会导致不一致和疲劳

找工作最难的不是技能,而是决策疲劳。这正是我想要减少的。

为什么我要公开构建

找工作很孤立。你不知道:

  • 你是否做对了
  • 其他人是否也在同样的困境中
  • 系统是否出了问题,还是只有你

公开构建有助于:

  • 验证真实的痛点
  • 获得诚实的反馈
  • 避免构建想象中的功能

我并不是想“颠覆招聘”。我只是想让其中一步痛苦变得不那么痛苦。

接下来是什么(以及不是)

目前:

  • 使用真实简历进行测试
  • 提升准确性
  • 有意保持范围小

我在抵制添加功能的冲动,除非用户明确提出需求。发布一个乏味但实用的产品胜过打造一个华丽却令人困惑的产品。

最后思考

大多数简历之所以失败,并不是因为人们不够能力,而是因为每天手动保持相关性非常困难。如果你曾在凌晨 2 点重写简历,心想 “这真的有意义吗?”——这个项目正是因为这种感受而诞生。

仍在构建。仍在学习。仍在发布。

Back to Blog

相关文章

阅读更多 »

开启我的 C# .NET 之旅

引言 我还没有掌握 Python,但我决定把学习 C 和 .NET 作为下一步。在大学期间,我探索了几个程序…