技术岗面试的第一轮几乎必然从「针对简历的项目深挖」开始。这决定了项目经历的写作原则：写上去的每一行，都是你邀请面试官提问的范围。写之前先想清楚哪些经得起追问，比堆满关键词重要得多。
项目条目的三行结构
每个项目控制在三到五行，按功能分三层：
- 背景一句话：项目是什么、解决什么问题、你的角色（独立/协作、负责哪个模块）；
- 我做了什么：两到三条，每条动词开头 + 具体技术动作（「用 Redis 缓存热点数据，将接口 P95 延迟从 800ms 降到 120ms」），而不是罗列技术栈；
- 结果与数字：性能提升、覆盖量、上线状态。数字要经得起追问来源——量化写法见《简历经历量化四要素》。
深挖预演：每条描述准备三个追问
写完每一条，站在面试官角度预演三个追问：
- 为什么这么选型？（为什么用消息队列而不是直接调用？为什么选这个框架？）
- 难点在哪，怎么解决的？（说不出难点的条目，面试官会认为是抄的）
- 换个方案会怎样？（有没有考虑过替代方案、各自的取舍）
三个追问里有任何一个答不上来，这条描述就要降级改写或删掉。这个预演最好实际做一遍：用面试鲸对着简历模拟一轮项目深挖，把卡壳的地方录下来复盘，比自己在脑子里过效率高得多。
教程型项目的改造写法
跟教程做的项目（培训班同款商城、外卖、秒杀系统）不是不能写，但直接照抄教程需求等于告诉面试官「我只会跟着做」。改造的关键是加入自己的增量：
- 换掉或扩展一个模块（教程用轮询，你改成 WebSocket，写清楚为什么）；
- 补一个教程没有的工程环节（压测报告、监控告警、CI 部署）；
- 明确标注哪部分是自己的设计决策，深挖时主动往增量上引。
常见减分项
- 技术名词堆砌：一行塞八个框架名，没有任何动作和结果——筛选器可能喜欢，面试官会逐个问，全线崩塌；
- 团队成果不区分个人贡献：「我们实现了……」会被追问「你具体做了哪块」，写的时候就直接写自己那块；
- 结果无法核实：「性能提升 10 倍」说不出测试条件和基线，不如写「压测环境下 QPS 从 X 到 Y」；
- 时间线与网申表冲突：简历和网申系统里的经历必须一致，不一致会在背调环节出问题。
项目经历改完后，整份简历投出去之前还有一轮系统自查——见《投递前简历自查清单》。