STAR 原本是行为面试的答题结构情境、任务、行动、结果。被搬到简历写作上之后出现了一种非常容易识别的句式「为了解决 XX 问题我作为 XX 负责了 XX采用 XX 技术最终实现了 XX得到了好评。」评审者一眼就看出这是套的。不是因为结构本身有问题而是四段的比例放错了。技术简历里 STAR 的比例通用职场写作里 S 和 T 可以占一半篇幅因为在那些场景下背景本身就是差异点你在什么样的困境里接了什么样的任务。技术简历不是这样。背景高度同质电商、SaaS、内部系统做的事也就那几类。真正的差异在 A 和 R也就是你怎么做的决策、结果怎么衡量。所以比例应该是S 和 T 加起来一行A 两行R 一行。四行一条S 和 T 只占四分之一。S 只写影响技术决策的那个约束「公司业务快速发展系统压力增大」不是 S是废话。S 要写的是那个直接决定了你后面技术选择的约束单表 2000 万行、两套库双写、每天早上七点前必须出报表、只有两台 2 核机器。一个判断标准如果把这个 S 去掉读者会不会误解你后面的 A。会误解就留不会就删。T 写边界不写头衔T 的作用是划清「这件事里哪部分是你的」。「作为核心开发」「作为项目负责人」这类头衔没有边界感「其中缓存层由我负责」才有。多数情况下 T 可以直接并进 A 的主语不单独成句。比如「缓存层由我负责选型时…」边界和动作在同一句里读者不用先读完一段头衔再找你做了什么。A 写决策不写动作清单这是最容易写虚的一段。「分析慢查询日志优化 SQL添加索引引入 Redis」是动作清单任何人做性能优化都会说这四句。A 里至少要有一个「选了什么、没选什么、为什么」。「在本地缓存和 Redis 之间选了 Redis因为服务跑两个实例本地缓存会不一致」这一句就把你和「会用 Redis 的人」区分开了。R 要带口径「显著提升」「大幅降低」不是结果。数字才是而且数字要带测量条件P99 从 800ms 到 200ms压测 500 并发告警从每周三到五次到归零发布从 40 分钟到 6 分钟。没有数字的场景写状态变化「同类问题此后没有复现」「该模块交接给两名新同事后没有再需要我介入」。改一条看改前带标签的 STAR情境公司报表系统随着数据量增长查询越来越慢影响业务方使用。 任务作为后端开发我负责对报表系统进行性能优化。 行动分析慢查询日志优化 SQL添加合适的索引并引入 Redis 缓存。 结果报表查询速度显著提升得到了业务方的好评。改后不带标签- 报表明细表过 3000 万行后单次查询超过 20s业务方每天早会前拉数会超时。 慢日志定位到 3 条按日期聚合的 SQL 全表扫描建 (biz_date, shop_id) 联合索引后仍要 4s 最终把 T1 聚合结果预计算进汇总表凌晨定时任务查询走汇总表稳定在 200ms 内慢查询告警归零改后四个要素都在而且多了一层第一次尝试加索引不够第二次预计算才够。这一层在面试里非常好用因为它自然引出「为什么加索引不够」的追问而你已经准备好了。套话的几个特征R 里出现「显著」「良好」「有效」而没有数字A 只有一个动作没有取舍S 写了公司介绍四段各自独立成句像填表。有其中任何一条那一条就是套话。简历和面试的分工简历上压缩掉的 S 和 T在面试口述时要展开。面试官问「讲讲这个报表优化」你要从业务方的痛点讲起讲当时为什么先选了加索引。简历是索引面试是全文两边不该是同一个长度。自查两步把每条的 S 遮住只读 A 和 R还能读懂吗。能说明 S 写对了。把 R 遮住只读 A能推出 R 大概是什么吗。能说明 A 写实了。条目改完之后可以整份扫一遍。最后STAR 不是模板是检查清单。四个要素都在、比例对、不带标签读起来就是一条正常的技术描述而不是一段填出来的表格。