同时申请多份工作而不必到处发送同一份简历，靠的是一套轻量的方法，而不是每份申请都重写一遍：把你实际要申请的职位按相似程度分组，保留一份大致适合整个组的基础简历，把这份基础简历调整成少数几个轻量变体，而不是几十个各自为战的版本，并且保留一份简单的记录，写清楚哪个版本投给了哪里。目标不是为每一个职位都做一份完美定制的文档，因为一旦同时申请的职位超过几个，这种做法很难维持下去；目标是有一套系统，让每一份申请看起来都经过考虑，而不是和上一份一模一样。
把相似的职位归类，而不是把每条招聘信息都当成独一无二
大多数广泛投递的求职者，其实并不是在申请几十个真正不同的职位；他们是在申请数量少得多的几类职位，每一类下面有好几条招聘信息，彼此之间只是公司名称和一些细节不同。在动笔之前，先把打算申请的职位按角色类型、招聘信息强调的技能，或者所在行业，分成几组，就能把一堆看起来各自独立的申请，变成实际上少得多的目标数量。一条招聘信息如果要求和另外三条一样的核心技能，就应该和那三条归在同一组，即使职位名称略有不同，因为处理这条信息所需要做的简历工作，实际上是同一份工作。
一份基础简历加几个轻量变体
一旦把职位归好类，每组用一份基础简历、而不是每条招聘信息用一份，工作量就变得可控了。基础简历涵盖整组职位共有且相关的内容：工作经历、教育背景，以及那一组所有招聘信息都看重的技能。在这份基础简历之上，一个轻量变体只调整针对某一具体职位调整简历里已经讲过的那些内容，个人简介那一行、几条要点的顺序、哪些技能排在靠前的位置，而不必为每一份申请都把文档从头重建一遍。由于CVBuilderKit把每份保存的简历都当作独立的文档，每个账户最多可以保存二十五份，把两三个轻量变体并排放着，每个职位组一份保存的文档，做法就是把每一组的版本各自保存成独立的文档、直接编辑，而不必每次都把整份文档重新做一遍。
记录哪个版本投给了哪里
广泛投递中最容易造成混乱的，不是写这些变体本身，而是在同时有好几份申请在外的情况下，记不清哪个版本到底投给了哪家雇主。一份简单的记录，哪怕只是一条简短的备注，写明公司、职位、投递的是哪个版本、投递日期，都能在两周后招聘方回电、而那份简历具体强调了什么已经记不清楚的时候，省下真正的麻烦。这一点在真正进行跟进对话的那一刻最重要，因为提到的个人简介或要点顺序如果和雇主实际收到的对不上，读起来会比实际情况严重得多，像是一个大得多的矛盾。
让每个变体都如实保持最新
一个轻量变体只有在随着基础简历一起更新时才有用，而不是从它第一次被分出去的那天起就成了一张一次性的快照。一项新成就、一个完成的项目，或者一项发生变化的职责，凡是属于基础简历的内容，通常也应该出现在每一个仍在使用的变体里，因为一个悄悄过时的变体，会开始和它当初赖以建立的基础文档自相矛盾，而某个人以某种方式看到同一位候选人的两个不同版本、细节还对不上，正是上一节里提到那份记录存在的目的所要防止的具体结果。把基础简历当作唯一的事实来源，在每次真正更新之后，把每个变体那一小撮改动重新套用一遍，而不是让变体原封不动地放着，能让这套轻量系统始终保持诚实，而不会在每次有变化时又变回一次完整的重写。
示例说明：为两条招聘信息建立的两个版本
示例说明，一份基础简历拆分成两个轻量变体，分别对应同一大类职位下的两条招聘信息。基础简历涵盖五年后端工程经验、一套一致的核心技能，以及始终如一的工作经历。变体一，为一条强调可靠性和值班责任的招聘信息而建，把个人简介调整为以生产系统的所有权开头，并调整两条经历要点的顺序，把一个事件响应的例子放在最前面。变体二，为一条强调面向外部合作伙伴的API设计的招聘信息而建，保留相同的基础内容，但改为以集成和API相关工作开头个人简介，并调整另外一对要点的顺序以作呼应。两个变体都没有编造任何基础简历里原本没有的内容；每一个都只是重新排序、重新强调了同样的底层事实，以匹配各自那条招聘信息最看重的东西。
这与针对单一职位的调整有何关联
这里描述的轻量变体工作，和针对某一具体职位调整你的简历里针对一次申请所讲的调整，本质上是同一种改动；广泛投递只是把同样的轻量调整合理分组后，做上好几遍，而不是把每一份申请都当作孤立的一次性事件。同时值得维护多少个独立版本，是另一个问题，在这套基础简历加变体的系统已经就绪之后，决定该保留多少个简历版本会讲到这一点。
立即开始撰写
一份基础简历加上两三个轻量变体，基本能满足同时申请几个相似职位的大部分需求。开始搭建你的基础简历，等你看清楚哪些招聘信息真正属于同一组，再把一两个变体各自保存为独立的文档。