项目经验是简历里权重最高的一块，也是被写坏得最彻底的一块。典型的坏写法：
「项目名称：XX 电商管理系统。项目描述：本项目是一个基于 Vue + Spring Boot 的电商后台管理系统，包含商品管理、订单管理、用户管理等模块。个人职责：负责前端页面开发。」
问题在哪？这段话介绍的是项目，不是你。换个人来写，一模一样。招聘方读完，不知道你干了什么、干得怎么样、有多难。
项目经验的唯一目标：让人相信你有能力做成同类的事。围绕这个目标，下面每一条都好判断了。
STAR 落到简历上是什么样
STAR（Situation 背景 / Task 任务 / Action 行动 / Result 结果）在面试里是回答框架，搬到简历上要压缩——简历没篇幅让你讲故事，但四个要素一个都不能少。简历版的 STAR 长这样：
- S+T 合并成一句：什么背景下、要解决什么问题。（1 行）
- A 是主体：你具体做了什么，尤其是你做了什么，而不是团队做了什么。（2—4 条）
- R 收尾：做完之后发生了什么变化。（跟在对应的 A 后面，或单独一句）
看对照。改写前（只有项目描述，没有 A 和 R）：
「XX 电商管理系统：基于 Vue 的后台系统，包含商品、订单、用户模块。负责前端开发。」
改写后：
- 背景：公司原有后台由三套老页面拼成，运营每天要在三个系统间来回切换录单。
- 我负责：独立完成商品与订单两个模块的前端重构（约 20 个页面），统一了交互和组件；把原本分散的录单流程合并成一个页面。
- 结果：运营录一单的操作从 3 个系统减到 1 个；我封装的 8 个通用组件后来被其他两个模块复用。
同一个项目，第二种写法里能看到：问题是什么、你的工作范围有多大、你的产出被别人用上了。这就是可信度的来源。
把一个平庸项目写出价值
「我的项目很水，就是个课程作业/内部小工具，没什么可写的。」——大部分项目都是平庸的，区别在于挖没挖。按下面四个方向挖，多数项目都能挖出东西。
1. 找出真正的难点
任何做完的项目都有卡过你的地方。卡过你的地方就是你的能力证明。
改写前：「实现了商品列表页的展示与筛选功能。」
改写后：「商品列表最多要同时渲染 2000 条数据，初版滚动明显卡顿；改用虚拟列表只渲染可视区域后，滚动恢复流畅。」
后者说明你遇到过问题、定位到了原因、并且解决了。这比「实现了 XX 功能」有价值得多。
2. 说清你的边界
团队项目里最忌讳含糊。「参与了 XX 系统的开发」——参与是多少？明确写出你负责的模块、你写的部分、团队规模。写清楚边界不会让你显得贡献小，只会让你显得可信；含糊其辞才是减分的，因为面试时一问就穿。
改写前：「参与公司 CRM 系统的开发与维护。」
改写后：「4 人前端小组，我负责客户档案与跟进记录两个模块（约占系统前端工作量的 1/3），并维护团队的公共组件库。」
3. 补上「为什么」
技术选型、方案取舍，是区分「执行者」和「能思考的人」的地方。
改写前：「使用 Redis 做缓存。」
改写后：「商品详情接口的读多写少特征明显，加了 Redis 缓存并设置 5 分钟过期，数据库这一接口的查询压力明显下降。」
4. 交代结果，哪怕结果不大
项目做完总有点变化：省了时间、少了出错、别人在用、被评优、上线了并且还活着。这些都算结果。没有惊人结果不丢人，没有结果才丢人——它会让人怀疑这个项目是不是根本没做完。
量化：有说服力，但不能编
先把底线说清楚：简历上的每个数字，面试时都可能被追问到细节——基数多少、怎么统计的、你负责哪一段、提升前是什么水平。编出来的数字撑不过三个问题，一旦被发现，整份简历的可信度一起归零。量化是把你真实做的事讲清楚，不是把它讲大。所以做法是：先找真实的数，找不到就换一种讲法。
去哪找真实的数：
- 范围类：多少个页面、多少张表、多少个接口、多少人的团队、多长周期、多少条数据、服务多少用户；
- 过程类：迭代多少个版本、处理多少条反馈、覆盖多少个场景；
- 你亲手改变的量：从 3 步变 1 步、从周更变日更、从人工核对变脚本核对。
这些数你自己就知道，不用编。
实在没有数怎么办？用「变化」代替「数字」，一样成立：「原本每周需要人工从三个表里手工汇总一次日报，我写了脚本自动生成，现在只需要核对。」——一个百分比都没有，但任何人读完都知道你干了什么、值不值。说不清的数字不如不写；讲得清的过程永远有效。
反面示范：「优化性能，提升 300%」——没有前提、没有口径、没有测量方式。这种数字的说服力是负的。
技术岗 vs 非技术岗
| 技术岗要写的 | 非技术岗要写的 | |
|---|---|---|
| 重点 | 你解决了什么技术问题、怎么解决的 | 你推动了什么事、结果如何 |
| 必须出现 | 技术栈、你负责的模块、难点与方案 | 目标、你的动作、影响范围、结果 |
| 常见误区 | 只列技术名词，不写自己做了什么 | 只写「负责统筹协调」，看不出具体动作 |
| 结果长什么样 | 性能/稳定性/复用/上线情况 | 效率、成本、转化、复购、满意度、流程改进 |
非技术岗（运营、市场、产品、行政、HR）尤其容易写空。看对照——
改写前：「负责公众号日常运营，统筹内容发布，配合完成各项活动。」
改写后：「独立运营公司公众号（约 2 万粉），一人负责选题、约稿、排版、发布全流程，从每周 1 篇提到每周 3 篇并稳定执行了 8 个月；策划过 2 次线下沙龙，从招募到现场执行全程跟进，两场共到场约 120 人。」
「统筹」「配合」这类词一律要警惕：它们通常意味着你没说清自己到底做了什么。
格式与顺序
- 倒序排列，最近的、最相关的放最前。不相关的项目宁可删掉——简历不是履历全集。
- 每个项目 3—5 条，不超过 6 条。写太多等于没有重点。
- 每条以动词开头：设计、重构、独立完成、推动、定位并修复。不要以「负责」开头写满全篇——「负责」只说明你在场，不说明你做了什么。
- 按 JD 调顺序。投什么岗，就把最相关的项目和最相关的那几条提到前面。这一步花五分钟，效果比重写一遍强。
- 只写你敢被追问的。写在简历上的每一条，都是你在邀请对方提问。
项目经验写扎实了，简历顶部的自我评价才有东西可提炼——那部分怎么写，见《简历自我评价怎么写（附可套用模板）》。