项目经历怎么写：从「参与」到「负责」的改法

项目经历怎么写决定了技术岗与产品岗简历的成败。HR 最常见的不满是：「看不出 TA 到底做了什么。」

为什么要改「参与型」描述

弱描述	问题
参与 XX 系统开发	无个人边界
负责部分模块	太模糊
使用 Spring Boot 开发	只有技术栈，无业务与结果

强描述需要：具体职责 + 技术/方法 + 可验证结果。

STAR 法则快速上手

• Situation：项目背景（1 句）
• Task：你的任务
• Action：关键动作（动词开头）
• Result：量化或定性结果

Before： 参与电商后台开发，使用 Vue 和 Java。

After： 电商订单后台（日单 2 万+）：独立负责售后模块前端重构，将页面加载从 3.2s 降至 1.1s；对接 5 个 REST API，减少售后工单处理时长约 25%。

三条 bullet 结构

每个项目建议 2-4 条 bullet，每条遵循：

[动词] + [对象/范围] + [方法/技术] + [结果/影响]

动词示例：设计、实现、优化、主导、落地、分析、推动

不同场景的写法

后端： 强调 QPS、延迟、可用性、数据一致性
前端： 强调性能、体验指标、组件复用、工程化
产品： 强调需求分析、数据验证、上线效果、协作规模
数据： 强调指标提升、模型效果、 pipeline 效率

技术岗对比详见 技术岗简历要点。

没有数据怎么办

• 用范围：「支撑 10+ 活动页」
• 用对比：「由人工整理改为自动报表，每周节省约 8 小时」
• 用质量：「上线 3 个月零 P0 故障」

切忌编造无法解释的数字。

自检清单

• 每个项目是否写明你的角色（独立/主导/协作）？
• 是否至少 1 条含数字或范围？
• 技术栈是否与 JD 有交集？
• 是否删掉了「熟悉」「了解」型空话？

使用 简历诊断 可自动识别「描述过虚」「缺少关键词」等风险。

---

案例结构仅供学习，请替换为你自己的真实项目与数据。