STAR 法则：如何描述项目经历
STAR 法则不只是面试答题框架，更是写简历项目描述的最佳武器。
什么是 STAR 法则
STAR 是四个英文单词的首字母缩写：
| 字母 | 含义 | 说明 |
|---|---|---|
| S | Situation | 背景：项目在什么场景下启动 |
| T | Task | 任务：你的职责是什么，负责什么模块 |
| A | Action | 行动：你具体做了什么，采用什么技术方案 |
| R | Result | 结果：最终带来了什么效果（最好量化） |
核心逻辑：先让人理解「为什么做」，再说明「做了什么」，最后展示「做成了什么」。
简历 vs 面试：用法的微妙区别
| 场景 | 用法重点 |
|---|---|
| 简历 | 重点在 A（行动） 和 R（结果），S 和 T 压缩到一句话 |
| 面试 | 四步完整展开，尤其是 T 和 A，要引导到自己的核心贡献 |
简历写法：精简版 STAR
简历空间有限，要用最少的字传达最多的信息。
对比：不用 STAR vs 用 STAR
不用 STAR（流水账）：
在项目中负责用户模块的开发，使用 Redis 做缓存，使用 MQ 做消息通知。
用 STAR（精简版）：
针对高并发场景下用户查询热点问题，设计并实现了多级缓存方案（本地缓存 + Redis 分布式缓存）， 配合缓存预热与异步刷新机制，使接口 QPS 从 1200 提升至 8500，P99 延迟从 180ms 降至 28ms。
对比非常明显：第二个版本不仅说清楚了做什么，还量化了价值。
模板
【动词】+ 【具体工作内容】+ 【用了什么技术/方案】+ 【带来了什么量化结果】常见动词：
- 设计：
设计了 XX 方案，解决了 XX 问题 - 实现：
实现了 XX 功能，支持 XX 规模 - 优化：
优化了 XX 指标，从 XX 降低/提升到 XX - 重构：
重构了 XX 模块，代码行数减少 XX%，可维护性提升 - 引入：
引入了 XX 技术栈，解决了 XX 痛点 - 主导：
主导了 XX 项目，跨团队协调 XX 人
面试口头表达：完整版 STAR
面试中回答项目问题时，STAR 四个维度都要展开。
范例：如何回答「介绍一个你做过的有挑战的项目」
S（背景）：
我们公司当时日均订单量大概 30 万，峰值 QPS 能到 5000 左右。但订单确认接口的平均响应时间是 200ms，99 线更是到了 800ms，用户投诉比较多。
T（任务）：
我作为后端负责人，承接了这个接口性能优化的任务，目标是把它优化到 50ms 以内。
A（行动）：
我首先做了性能分析，用 Arthas 定位到瓶颈在数据库查询，单次请求平均触发了 8 次数据库 IO，其中有个关联查询耗了 100ms。
确定了瓶颈之后，我做了三件事：
第一，对高频查询加了 Redis 缓存，设置 5 分钟 TTL，预热了 Top 100 热数据；
第二，把那个慢查询拆成了两步简单的查询，用并行请求合并结果；
第三，对非核心的库存校验消息做了异步化，用 RocketMQ 解耦。
改完之后又做了一轮全链路压测，在 8000 QPS 的情况下验证了稳定性。
R（结果）：
最终接口 P50 降到了 18ms，P99 降到了 45ms，达到了目标。另外这个缓存方案后来被推广到了用户模块和商品模块，整体接口 RT 降低了 60%。
常见问题与注意事项
Q：项目经历太多了，怎么选？
选择标准按这个优先级：
- 技术有深度：涉及原理、源码、设计模式
- 规模有量级：数据量大、高并发、分布式
- 结果有量化：性能提升、成本降低、效率提升
- 个人有贡献：是你主导或核心参与，而不是打酱油
Q：结果不好怎么办？
很多项目的结果可能不理想，比如系统最终没做起来。这种情况：
- 可以换角度讲：「虽然项目因为 XX 原因暂停了，但我在 XX 方面的设计经验对后续项目很有帮助」
- 或者讲过程中的学习：「通过这个项目我深入理解了 XX，为后续 XX 项目打下了基础」
Q：团队合作的项目怎么写？
明确区分「我做了什么」和「团队做了什么」：
- 负责用户下单模块，基于 Spring Cloud 实现，QPS 支撑 5000+
- 团队其他同学负责商品模块和支付模块
不要把团队成果全归功于自己，也不要完全不提自己的贡献。
总结
STAR 法则的核心心法：
好的项目描述 = S（让人相信这件事值得做）+ A（让人看到你的能力）+ R（让人记住你的价值）写简历时，重点练三个动作：
- 每个项目总结出 1-2 个量化数据
- 每个数据背后有 1 句话的技术方案说明
- 准备 2-3 个深度追问的答案（面试时会问）