STAR法则一旦被机械套用，简历很容易变成长作文：Situation一段、Task一段、Action一段、Result一段。招聘方并不需要看到四个标签，他只需要快速看懂：当时是什么问题，你负责什么，你具体做了什么，最后发生了什么。
简历里的STAR应该“压缩”使用：S和T只保留足够理解场景的背景，A写得最具体，R只写你真正有依据的结果。没有可靠结果数字时，可以写流程完成、问题关闭、交付通过或后续使用情况，不能为了结构完整硬编百分比。
需要先用简历版式承接经历：
查看可编辑Word简历模板 →
案例一：运营岗位，不要把STAR写成四段话
模拟场景：一次线上活动报名量不稳定，运营实习生负责报名页和渠道信息核对。
原始素材：活动上线前发现不同渠道使用的时间和报名规则不一致。我需要把信息统一。先逐个核对公众号、社群和报名页的文案，把冲突处列出来，与负责人确认最终口径，再通知设计和渠道替换旧版本。活动正式开始前完成全部页面复查。
压缩到简历：
- 活动上线前核对公众号、社群和报名页规则，整理时间、权益和报名条件冲突项，提交负责人统一口径；
- 跟进设计与渠道替换旧版本，并在正式上线前完成页面复查，避免不同入口继续使用过期信息。
背景和任务只占一句，主要篇幅都给了行动。结果也没有虚构“转化提升30%”，而是写到实际完成的状态。
案例二：研发岗位，R不一定是业务增长
模拟场景：内部系统导出文件经常因为空字段报错。
不推荐：运用STAR法则解决系统问题，提升用户体验。
更像工程经历：排查批量导出接口空字段导致的异常，补充参数校验和默认值处理；与测试复现历史问题并补充边界用例，修复后完成回归验证。
对于工程岗位，结果可以是“修复并通过回归”“减少某类重复故障”，不一定强行转换成营收数字。
案例三：行政岗位，没有数字也可以完整
模拟场景：会议材料经常在开会前才发现版本不一致。
STAR压缩后：重要会议前按议题收集材料并统一文件命名，发现部门版本冲突时退回确认；会前锁定最终版并建立材料清单，会议结束后将纪要和待办事项归档到同一目录。
这里的R更接近“建立可追溯的最终版本”，不是虚构一个无法验证的效率提升。
把自己的经历套进这个简历版STAR骨架
场景：发生了什么，为什么需要处理？
任务：你在其中负责哪一部分？
行动：你先做什么、再做什么、用了什么工具、和谁协作？
结果：事情最终完成到什么程度，有没有真实数据、交付物或后续使用？
写完后，把前两项压缩，把“行动”保留下来，再删掉无法证明的结果。最终简历里通常只需要2—3条bullet，而不是把四段原始素材全部复制进去。
哪些经历不适合硬用STAR
纯技能列表、证书、教育背景不需要STAR；重复性很高的日常职责也不必每条都讲一个完整故事。STAR更适合项目、问题处理、改进、跨部门协作和阶段性交付。如果每一条工作经历都写成“背景—任务—行动—结果”，反而会有强烈模板感。
你可以先按上面的骨架把经历拆出来，再用目标JD判断哪几段最值得留下。如果不知道自己的行动是否真的对应岗位要求，可以用星衡简历诊断先看免费匹配结果。