把一个从未被实际衡量过的工程工作硬套上一个百分比，并没有可靠的办法；为了满足"请量化你的影响"这类笼统建议而编造一个数字，比干脆不写数字更糟糕，因为一个编造的统计数字要么是错的，要么在别人追问它从哪里来时根本无法自圆其说。即便没有被追踪的指标，也可以诚实地描述范围：系统有多大、有多少人或服务依赖它、它运行的频率如何，以及在"之前"和"之后"之间实际发生了什么变化。这些事实通常可以从记忆、工单历史或一次事后复盘中重新还原出来，读起来也比一个凭空冒出来的数字可信得多。
为什么"随便加个数字"的建议在没有指标时站不住脚
大多数简历建议都告诉工程师要量化每一条要点，这个建议本身并没有错：一个正在快速浏览几十份简历的读者，确实会对具体的内容反应更好，而不是一句含糊的主张。问题在于，很多真实的工程工作从来没有被以能产生一个干净百分比的方式追踪过。很多团队并不会为每一次改动运行仪表盘，很多影响是被感受到而非被测量的，很多工程师在有人回头检查上个季度的改动到底有没有帮助之前，就已经换了新岗位。面对这种空白，诱人的捷径是写一个"感觉差不多对"的数字，希望没人追问它是怎么来的。这正是这篇文章想帮你避开的陷阱，因为一个面试官只需一个追问就能拆穿的数字，比完全不写数字造成的伤害更大。
即便没有被追踪的指标，也存在诚实的衡量方式
几乎任何一项工程工作，无论是否曾经记录过某个指标，都存在几类具体的细节可用。范围描述的是你所触及内容的大小：一次改动涉及多少个服务、代码库有多大、影响了多少个接口或数据表。规模描述的是系统承载了多少：它服务了多少请求、存储了多少条记录、有多少团队构建在它之上，用你能自信陈述的说法来表达，而不是一个你在猜测的数字。频率描述的是某件事运行或被使用的频繁程度：一个每晚运行的批处理任务、一个团队里每位工程师都在用的部署流水线、一份在每个季度结束时生成的报表。前后状态描述的是你的改动之前是真实的、改动之后又变成了真实的事情，用平实的语言而不是百分比来说明：以前什么会失败、以前需要哪一步人工操作、以前需要谁值班盯着，以及在工作上线之后哪些事情不再成立。谁依赖它，则点明了实际的受众：使用你所构建工具的团队、调用你所维护接口的服务、因为你修复的问题而不再被呼叫的值班轮班。以上每一项都是你亲身经历过、能够凭第一手知识描述出来的东西，这正是它比一个四舍五入的百分比更经得起推敲的原因。
示例说明：把一条要点围绕范围而不是百分比重写
之前，含糊且没有量化："负责结账服务的性能。"之后，围绕范围和一段被描述出来的前后状态重写，而不是一个编造的数字："负责结账服务的数据库查询层，也就是网站上每一笔购买都要经过的唯一路径；重写之前，缓慢的查询是客服团队最常上报的结账卡顿原因，重写上线之后，这类投诉就再也没有出现在每周的排查会里。"重写后的版本里没有任何一处是猜出来的统计数字。它说明了候选人负责的是什么、这部分对系统有多核心、问题在此之前是什么样子、以及之后发生了什么变化，全部来自候选人亲眼所见，而不是事后拼凑出来的一个数字。
重写时应该省略什么
需要坚守的分界线，在于一个你现在能拿出来的数字，比如来自仪表盘、事后复盘，或者你当时确实追踪过的指标，和一个你从"感觉当时速度快了很多"这种模糊记忆中重新拼出来的数字之间。前者可以直接引用。后者恰恰是应该改用范围和前后对比的语言重写的那一种，因为一个被记住的印象四舍五入成一个听起来很漂亮的数字，正是那种在面试里被一个具体追问戳破的说法。上面基于范围写出的版本能经得住这个追问，因为其中每一部分都是你能用自己的话说清楚的，而不用依赖一个你从未真正记录过的数字。
这与更广泛的"把职责变成成就"模式有何关联
围绕范围而不是编造的统计数字重写，是一种更广泛转变的具体应用，这种转变远不止适用于工程领域：把"你负责什么"的描述，变成"因此实际发生了什么变化"的描述。把职责写成简历上的成就一文介绍了这种更广泛的重写模式，并给出了工程以外角色的例子，适合任何一位要点目前读起来像是被分配任务清单、而不是成果的人。
撰写这条内容
如何写简历介绍了让这种重写方式贯穿简历其余部分所需的措辞选择，CVBuilderKit的developer模板正是围绕这种以范围、以项目为主导的条目设计的。在构建器中从一份已有文档或一份空白文档开始，先用范围和一段被描述出来的前后状态重写每一条要点，再考虑要不要用一个你实际上无法自圆其说的数字。