用 STAR 法则写工作经历，面试率翻倍

什么是 STAR

Situation（情境）· Task（任务）· Action（行动）· Result（结果）。一条经历要点，尽量覆盖这四层信息：你在什么背景下，承担什么目标，采取了哪些关键动作，最终带来什么可验证变化。

在简历里，STAR 通常被压缩成 1–2 句，而不是四段小作文。面试口述时，再把细节展开。很多人简历写得很「忙」，却过不了初筛，往往是因为只停在 Situation / Task，缺少有力度的 Action 与 Result。

主导商家后台改版（S/T），拆解支付链路并推动跨端联调（A），上线后转化率提升 18%、投诉下降 40%（R）。

为什么简历特别适合 STAR

招聘方扫简历的时间极短。他们需要快速判断三件事：你是否做过类似问题、你是否能独立推进、你的产出是否可信。STAR 正好对应这三点：背景说明相关性，行动说明能力边界，结果说明影响力。

对程序员、产品、运营、设计等岗位同样适用。差别只在「结果指标」不同：研发常写性能、稳定性、交付效率；产品写转化、留存、需求吞吐；运营写增长、成本、活动 ROI。结构不变，换指标即可。

如果你还在纠结版式，建议先把经历按 STAR 写清楚，再选一套清晰排版的 简历模板。内容可信度永远比装饰更重要；导出时尽量用标准模块标题与可选中文本，避免机器解析丢字段。

三条可立刻套用的写法

• 用动词开头：主导、搭建、优化、推动、落地、重构、设计、验证——比「负责」「参与」更能体现贡献度。
• 结果尽量量化：时长、金额、比例、用户量、错误率、交付周期、覆盖范围。有一个数字就写一个；没有百分比，也可以写「支撑 N 个业务线」「覆盖 N 个页面」。
• 一段 2–4 条要点：信息密度够用即可。每条只讲一件事，避免把五件事揉进一句超长复合句。

一句话公式

动词 + 对象 + 方法/范围 + 结果（数字）。例如：「重构订单查询接口，引入缓存与分页策略，P99 延迟从 800ms 降至 220ms。」这里情境被压成「订单查询」，任务与行动合并，结果用延迟指标收尾。

没有「大数字」时的 Result 写法

应届生或内部工具岗常缺业务大盘数据。可用这些替代：按期上线、缺陷数下降、联调周期缩短、文档/自动化节省工时、支持多少人使用、通过多少轮评审、减少多少人工操作。只要真实且可追问，就比空泛的「显著提升效率」更强。

改写对照

通用示例

改前：负责公司官网改版项目，和设计、研发协作，完成了多个页面上线，积累了项目管理经验。

改后：主导官网改版，协调设计与前端 6 人小组，两周内完成 12 个核心页面上线；首月自然搜索流量提升 27%。

程序员示例

改前：参与微服务改造，写过一些接口，熟悉 Spring Cloud。

改后：将会员中心从单体拆为 3 个服务，补齐熔断与超时配置；灰度两周后接口错误率从 1.8% 降至 0.3%，高峰 CPU 占用下降约 25%。

产品 / 运营示例

改前：负责活动策划，和多个部门沟通，活动效果不错。

改后：策划拉新活动并协调投放、内容、客服三方，两周内完成落地；活动期新增注册 1.2 万，次日留存较日常提升 6 个百分点，单注册成本下降 18%。

常见误区

• 只有职责没有结果：「负责后端开发」说明不了你做成了什么。
• 团队成果全算自己的：用「主导 / 独立完成 / 作为核心开发」等措辞划清边界，面试才经得起追问。
• 堆砌形容词：「高效」「深入」「赋能」不如一个具体动作 + 一个数字。
• 与目标岗位无关的 STAR：再漂亮的结果，若和 JD 无关，也建议压缩或删掉，把版面留给匹配经历。
• 数字不可解释：写了「提升 50%」却说不清口径，反而减分。口径简单即可：环比、对比实验、上线前后窗口。

写完后自检

• 是否能回答「所以呢？」——没有结果的行动价值有限。
• 数字是否真实、可被追问——面试官很爱追「这个 18% 怎么算的」。
• 是否与目标岗位相关——无关亮点宁缺毋滥。
• 动词是否具体——把「参与」「负责」尽量替换成可观察的动作。
• 一条要点是否只讲一件事——信息清晰比句子华丽更重要。

写完经历后，建议在导出前核对联系方式、时间线与文件名，并自己预览一遍 PDF；应届生同样可以把课设与实习套进 STAR，重点写角色、模块与结果。

常见问题