写项目经历时，容易把项目的来龙去脉交代得很完整，却只用“负责开发”“参与执行”带过自己的工作。
可以先解决两个问题：这个项目为什么值得放进这份简历？读者需要哪些信息，才能理解你在其中做了什么？选好内容后，再决定篇幅和位置。
选项目，看它能说明什么
先看目标岗位的实际要求，再从经历中选择有对应事实的项目。例如，岗位重视交付协作，可以选你实际承担过交接、沟通或验收工作的项目；岗位重视开发能力，可以选能说明实现过程和技术取舍的项目。
项目不一定要规模最大或结果最亮眼。内部工具、课程作品、开源贡献和执行既定方案的工作，都可能提供相关信息。关键是能说清真实职责、工作过程以及目前完成的部分。
如果几个项目证明的是相近能力，可以详写最相关、事实最充分的一个，其他压缩。不要为了凑够固定数量，放入自己讲不清楚的项目。
放在工作经历下面，还是单独成节？
两种方式都可以，取决于哪一种更便于理解。
- 放在工作经历下：适合项目与某段任职关系紧密、展开后篇幅仍然清晰的情况。
- 单列项目经历：适合需要集中展示技术实践、作品或跨多段经历的项目。属于任职期间的项目，仍要写清对应公司或角色与时间。
- 在工作经历中简述，项目节展开：适合确实需要更多细节的情况，但不要重复粘贴相同段落。
课程、个人和志愿项目应如实标明性质，避免让读者误以为是商业交付。结构的目的，是让人看清项目与你的关系。
每个项目，保留足够理解工作的线索
写作时可以从这些信息中选择：
- 项目名称、时间、你的角色。
- 要解决的问题，或交付对象。
- 你负责的范围与具体行动。
- 已完成的交付、实际使用情况或有依据的结果。
这是整理信息的提示，不是每条都必须填满的表格。技术栈、规模和团队人数，只在有助于理解工作时加入。背景已经清楚，就不必写成长篇项目复盘。
一个完整改写示例
以下为演示情境，不代表真实项目成效。
原始表述：参与库存工具开发，负责导入模块，提升库存管理效率。
假设补充确认了这些事实：
- 仓库人员需要把供应商提供的表格导入内部库存工具。
- 你按照已确认的字段规则实现导入校验，提示缺失字段和重复编号，并提供错误行下载。
- 你整理了用于验收的样例文件，配合仓库人员完成验收；模块已经投入使用。
- 没有统计导入耗时、库存准确率或节省的人力。
可以写成：
修改后：为内部库存工具实现表格导入校验，按既定规则检查缺失字段和重复编号，并支持下载错误行；整理验收样例，与仓库人员完成验收，模块已投入使用。
“导入模块”变成了具体的功能和交付，未记录的效率提升则被去掉。没有把执行字段规则改成制定规则，也没有增加不存在的节省比例。
如果投递岗位特别关注某项技术，可以补充实际使用的实现方式；不需要为覆盖岗位关键词而加入没有用过的工具。
几种容易卡住的情况
只参与了很小一部分
就写那一部分。例如负责测试数据准备、实现一个接口或整理用户反馈，都可以写清工作范围与交付。不必把整个系统或项目写成自己完成。更多示例见团队项目中怎么写清个人贡献。
项目还没结束，或者没有上线
标明“进行中”“完成原型”“完成测试”等实际阶段，说明自己已经完成的工作。未上线的原型不能写成已投入生产，也不要把预计收益当作已经实现的成果。
项目没有数字结果
可以写验收通过、交付完成、方案被采用或问题得到解决；这些也需要事实支持。没有测量时，不补百分比。可以参考没有数字时怎么写工作成果。
项目最终取消了
先判断已完成的工作是否仍能证明岗位需要的能力。如果值得保留，如实交代最终状态，写自己已完成的调研、验证或交付；不把取消的项目写成成功上线。
最后做一次取舍
读完一个项目，别人能否说出它解决什么问题、你做了哪部分、最后到了什么阶段？缺的部分补事实，重复的背景删减。
工作经历与项目经历应互相补充。若整份简历仍以职责罗列为主，可以从工作经历怎么写清楚开始梳理，再决定哪些项目需要单独展开。