每周都要复制粘贴的几张表，你写了个脚本，一次就能合并。
原来总要来回问的材料，你整理成一张清单，提交时就知道该准备什么。
工作确实被你做简单了。可一打开简历，这些改动又缩成了八个字：
优化流程，提升效率。
看起来挺专业，就是看不出你干了什么。
写流程改进，先把“原来怎么做、你改了什么、现在怎么用”说清楚。 有可靠的前后数据，再补上数字；没统计过，也可以从具体变化里找到值得写的内容。
“提效”是你的总结，HR还没看见过程中的变化
你知道原来的表格有多难合，哪个字段每周都有人填错，也知道那段脚本帮你省了多少麻烦。
但HR只看到了“优化流程”。
这句话没有交代：你改的是数据整理、材料提交，还是审批流转？做了一张表、写了一个工具，还是调整了交接方式？改完之后，具体用在了哪里？
这些事实一旦被省略，不同的工作就会长得一模一样。
所以，先别忙着把“提升效率”换成更厉害的词。回到那件让你觉得“终于不用再这么折腾了”的事。
从一项重复工作，找回被省略的事实
假设你做运营，每周都要整理不同来源的数据。简历上原本写的是：
优化周报数据处理流程，提升团队效率。
先顺着这句话往下问。
原来整理周报时，哪些操作每周都要重复做？
把几个来源的表格合在一起，再检查日期、字段格式。不一致的地方要找同事补正。
这时，我们知道了“流程”到底指什么，但还不知道你改了哪一步。
你做了什么，让这件事变得简单？
写了一个脚本，自动合并数据、检查格式，把有问题的记录单独列出来。
现在有了具体产出：数据合并与格式校验脚本，以及它生成的异常清单。再确认一下实际使用情况。
这个脚本现在怎么用？
已经用于每周的周报整理。我运行脚本，同事根据异常清单核对补正，不过没有统计过前后耗时。
这些事实已经能支撑一条清楚的简历表达：
编写数据合并与格式校验脚本，用于每周周报整理，自动输出异常清单供同事核对补正。
这句话没有“效率提升50%”，但HR能看懂：你把原来手工合并、逐项检查的工作，改成了自动处理并集中核对异常。
改进的价值，落在了具体做法的变化和实际用途上。 不必为了补一个百分比，再去猜当时大概省了多少时间。
不会写脚本，也有可以讲清楚的改进
工具只是其中一种做法。把重复确认的内容提前说清，也可能是一项实在的工作。
再假设你负责活动物料对接。过去，各部门发来的需求格式不同，有的缺数量，有的没写到货日期，你得逐个问。后来，你整理了统一的需求表，把这些信息列成提交项，已经用于后续活动的物料需求收集。
可以写成：
整理活动物料需求表，统一收集物料规格、数量和到货日期，用于各部门活动需求汇总。
这条表达交代了你把什么做法改成了什么，也说明了表格的实际用途。如果没有统计返工次数，就先不加“显著减少返工”；如果没有跟踪沟通耗时，也不用补“沟通效率大幅提升”。
具体到这里，已经比“优化跨部门协作流程”更容易理解。
写到实际发生的那一步，就够了
同一个工具，使用情况不同，简历里的说法也应该不同。
只在自己的工作中使用，就写清它帮助自己处理的任务。给同事演示过、还没开始使用，就不能写成“推广至团队”。已经有人持续使用，再据实补上使用范围。
数字也一样。手里有同类任务的前后耗时记录，可以补充对比，并说明必要的统计条件。没有记录，就保留能确认的变化：原来的人工步骤变成了什么，交付了什么，实际用在什么工作中。
还要留意自己的分工。你整理了需求、由研发完成工具，就写自己完成的需求梳理和验收工作；不要把“参与改进”顺手改成“独立开发”。
简历可以精简，事实不能顺便升级。
下次看到“提效”，先补两句话
找出简历里一条“优化流程、提升效率”，在旁边写下：
- 原来，这件事要怎么做？
- 我改完以后，现在怎么做、交付什么？
再核对一下：这个变化已经用在哪里？哪些是自己完成的？
你不必把答案全部塞进简历。留下能让HR看懂改动和用途的关键事实，其他过程可以留到面试展开。
这也是简历喵关注的价值挖掘：从你确实做过的事里，找回被一句概括省略的贡献。
你已经把工作做简单了一点。写简历时，让人看见你改的那一点。