项目经历写法：STAR 法则与「技术决策」的价值

项目经历是简历的核心，也是面试的题库。面试官对简历的所有提问，九成指向项目那一栏。写好项目经历，等于提前给面试出题范围划了边界：你写到哪里，他问到哪里；你写得多深，他问得多深。这一篇讲项目经历的两种写法工具：经典的 STAR 法则，以及更重要的“技术决策”表达。

先看一个场景。小李的订单项目，第一版写法是：“参与订单系统开发，使用 Spring Boot、MySQL、Redis，负责订单创建、查询、取消等接口，配合前端联调，参与大促保障。”这段话有任何问题吗？字字属实，但面试官读完记不住任何东西，也找不到提问的抓手，最后只能问“你们用什么数据库”，把一场本可以展示深度的面试，聊成了查户口。问题不在于不努力，在于这段文字是“职责清单”，不是“证据链”。

一、STAR 法则的工程师版变形

STAR 是情境、任务、行动、结果的缩写，原是行为面试的答题框架，搬到简历里要做工程师化的变形：

变形要点有两个。第一，情境要带约束：没有约束的项目看不出难度，“日均百万单”和“内部小工具”是同一种技术、完全不同的含金量。第二，行动要写决策不写流程：不是“先调研再开发再上线”，而是“为什么选方案 A 不选方案 B”。

还要提醒一句：STAR 是思维框架，不是填空模板。不必在简历里标出 S、T、A、R，四个要素融进三五行文字里即可，标了字母反而显得像培训班教材。它的真正用途是自查：写完一段，逐项检查四要素是否齐全，缺哪项补哪项。

二、技术决策的价值

普通经历写“我用了什么”，优秀经历写“我为什么这么用、代价是什么”。后者就是技术决策，它是区分“干活的人”和“思考的人”的分水岭。一个技术决策句通常包含三个零件：问题约束、候选方案、选择理由。

比如同样写缓存：“引入 Redis 缓存热点数据”是流水账；“商品详情读多写少，本地缓存会导致多节点不一致，最终选择 Redis 集中缓存，接受一次网络往返的代价”就是决策句。后者给了面试官三个提问入口：为什么读多写少、本地缓存怎么不一致、为什么能接受网络代价。这就是你展示深度的机会。

常见的技术决策场景包括：数据库选型（关系型还是文档型）、一致性方案（强一致还是最终一致）、同步还是异步、缓存策略（旁路还是读写穿）、拆分维度（按用户还是按订单）、技术选型（自研还是开源）。写简历时不必每个都展开，挑和岗位最相关的一两个写透。

决策句的素材从哪来？日常工作中每一次技术方案评审、每一次线上问题复盘，都是一次决策记录。养成习惯：重要决策在当天用三句话记下（问题、选择、理由），攒一个季度，简历和面试弹药都有了。这也是把日常工作变成简历资产的核心方法，比临时回忆可靠十倍。

技术决策还有一个隐性作用：它是团队角色的信号。只写“我实现了什么”的是执行者叙事，写“我们为什么选择什么”的是参与者叙事，后者天然暗示你在方案讨论中有位置。三年以上经验投中高级岗，叙事角度要有意识地从前者切到后者。

三、完整示例对照

下面用两个真实感场景展示改造前后的差别。

反面示范（Java 社招，订单项目）：“参与订单系统开发与维护，负责订单相关接口，使用 Spring Boot、MySQL、Redis 等技术，保障系统稳定运行。”三个毛病：参与（不知道你干了啥）、接口（没有范围和结果）、等技术（罗列不等于会用）。

正面示范（Java 社招，订单项目）：“主导订单核心链路重构：原单体服务大促期间频繁超时，按用户维度将订单库拆分为四库十六表，引入消息队列实现库存扣减的最终一致；重构后大促峰值 QPS 从 500 提升至 5000，超卖投诉降为零，接口 P99 从 800ms 降至 120ms。”有约束（大促超时）、有决策（拆分维度、一致性方案取舍）、有结果（三个数字）。

反面示范（前端校招，课程项目）：“使用 Vue 完成了课堂管理系统，包含登录、列表、表单功能，熟悉了组件化开发。”问题在于只写了功能清单，没有任何思考和结果。

正面示范（前端校招，课程项目）：“独立完成课堂管理系统前端（Vue3 + TypeScript）：针对列表页卡顿问题，将一次性加载改为虚拟滚动加接口分页，千条数据首屏渲染从 2.1s 降至 0.4s；用 Pinia 重构全局状态，消除了三个组件间的 prop 逐层传递。”有问题（卡顿）、有方案（虚拟滚动加分页）、有结果（数字）。校招项目不要求商业规模，但要求有“发现问题、解决问题”的完整痕迹。

再补一个基础设施方向的示例。反面：“负责 CI/CD 流程搭建与维护，使用 Jenkins、Docker。”正面：“重构发布流程：针对原发布耗时长、回滚困难的问题，将 Jenkins 流水线改为容器化滚动发布，发布时长从 40 分钟压缩到 8 分钟，回滚从十分钟的人工步骤简化为一键；期间引入灰度开关，重大变更支持按百分比放量。”同样是搭流水线，后者有痛点、有方案、有结果，提问点也自然出现：灰度怎么实现的、开关如何热更新。

四、项目数量与详略分配

项目不是越多越好。简历上放两到四个主项目，每个三到五条 bullet；其余项目一句话带过或不写。判断标准是“这个项目能否支撑二十分钟深挖”：能，展开写；不能，合并或删掉。三年经验的简历，两个有深度的项目胜过五个流水账。

每条 bullet 也要有主次：第一条放最硬的（架构或结果），中间放有决策的，最后可以放协作和规范的（一带而过）。面试官的注意力随 bullet 序号递减，把最想被问到的放最前。

什么项目不值得展开：你只待了两周的项目、职责是维护文档和改配置的项目、以及技术栈和岗位完全不搭的项目。这些用一行“参与 XX 系统维护”带过即可，它们的作用是证明经历连续，不是证明能力。

五、项目卡模板

动笔写项目前，先用这张卡把素材攒齐，写简历和准备面试都靠它：

项目卡
项目名：订单核心链路重构
时间：2024.03 - 2024.09｜角色：主力开发（3 人团队）
背景与约束：日均 80 万单，大促峰值 500 QPS，单体架构频繁超时
我的职责：链路拆分方案设计与核心模块开发
关键决策 1：按用户维度分库（备选：按时间归档）
  理由：用户维度查询占比 85%，避免跨库 join
  代价：分片键后续扩展受限，接受
关键决策 2：库存扣减用消息最终一致（备选：分布式事务）
  理由：引入 Seata 会增加 30%  RT，业务可接受秒级延迟
结果：QPS 500→5000，P99 800ms→120ms，超卖投诉归零
可深挖点：分片键热数据问题、消息可靠性保障、灰度方案

卡片里最后一行“可深挖点”要主动填：你预判面试官会问什么，就提前准备什么。这个习惯迁移到日常，就是持续的面试弹药库。项目卡的素材可以来自你的工作笔记，长期沉淀方法参考 Obsidian 知识管理实战；攒好的卡片可以用 Claude Code 完全指南 让它按 STAR 结构帮你改写措辞、删减形容词，但决策和数字必须来自你的真实记录，AI 不会为面试时的追问负责。

还有一层联动：项目卡里的“可深挖点”要同步变成面试准备清单。比如你预判到“分片键热数据”会被问，就把相关的索引设计、热点治理方案提前复习一遍。简历写决策、面试讲决策，两处用同一份思考，面试时就不会出现“简历像高手、聊天像新手”的割裂。

六、常见错误对照

项目经历是简历里唯一能让面试官“还没见面就已经在尊重你”的模块。把每个项目当成一次小型的架构答辩来写：背景、约束、决策、结果，四要素齐全，提问自然而来，而那就是你准备好的战场。最后强调一遍顺序：先攒项目卡，再写简历，最后准备面试，三步都用同一份素材，简历和面试就永远不会互相打架。

本章由 WorkBuddy 原创整理，方法与话术仅供参考，请结合自身情况调整。