把 GitHub 项目写进简历：HR 和技术面试官看的根本不是同一件事
“我 GitHub 上有几个项目，简历上贴个链接就行了吧？”
不行。因为这份简历要过两双眼睛，而这两双眼睛的关注点几乎不重叠。
HR 或者简历筛选系统先看：这个人做过什么方向、技术栈对不对、有没有可量化的产出。它们不会点开你的仓库，更不会读代码。技术面试官后看：这东西到底是自己写的还是照着教程敲的、有没有真正的技术决策、能不能问出深度。
只贴链接，等于第一关直接放弃，第二关全靠对方主动。
贴链接之前先确认三件事
- 仓库是 public，README 是完整的。面试官打开一个只有代码没有说明的仓库，通常十秒就关掉；
- commit 记录看得过去。三个 commit 全叫 update、时间戳集中在同一晚上，比没有链接还伤；
- 代码是你自己的。fork 来改了配置文件的项目不要写进项目经历，这个太容易查了。
这三条不满足，先花一个下午补 README 和整理提交记录，再考虑往简历上写。
简历上的项目经历该长什么样
对照着看最直观。常见写法：
个人博客系统
使用 Spring Boot + Vue + MySQL 开发的博客系统，实现了文章发布、评论、用户登录等功能。
GitHub: github.com/xxx/blog
问题在于，这段话换成任何一个同专业同学都成立。它描述的是"我做了一个大家都做过的东西"，没有任何独属于你的信息。
改写之后：
个人博客系统（github.com/xxx/blog · 后端独立开发）
· 技术栈：Spring Boot 3 / MySQL 8 / Redis / Docker Compose 部署
· 文章列表接口在数据量到 5 万条后响应从 40ms 涨到 800ms，定位为深分页导致的大量回表，改用游标分页 + 覆盖索引后稳定在 50ms 以内
· 评论区高频读写用 Redis 做热点缓存，设计了缓存与数据库的双写一致方案（延迟双删），处理了缓存击穿场景
· 用 GitHub Actions 做了 CI，提交后自动跑测试并构建镜像
差别不在于第二段更长，而在于第二段里每一条都是只有真做过的人才写得出来的。深分页、回表、双写一致、缓存击穿，这些词一出现，面试官立刻知道可以从哪里问起，而你已经准备好了。
没有真实流量，量化数据从哪来
这是校招项目最尴尬的一点：项目只有自己在用，哪来的数据。
三个来源，都是真的：
- 自己压出来的：用 JMeter 或者 wrk 压一遍，记下优化前后的 QPS 和 P99 延迟。这本身就是工程能力的一部分；
- 数据量造出来的：写脚本灌 10 万条测试数据，很多问题只有在这个量级才会暴露，这也是上面那个例子里深分页问题的来源；
- 代码规模本身：接口数量、表数量、测试覆盖率、代码行数（谨慎用，行数多不等于好）。
关键是别编。写"支撑日活 3000 用户"，追问一句"用户从哪来的"就穿帮了，而且是致命的那种穿帮。
三个项目怎么排
优先级只有一条：和目标岗位的相关度，不是技术难度，也不是你花的时间。
投后端就把后端项目放第一个，即使那个前端项目你做得更漂亮。第一个项目会被问得最细，把你最有把握的放在那里。
数量上，两到三个足够。第三个之后的边际收益迅速趋近于零，还会稀释注意力。宁可两个写透，不要五个各写两行。
别忘了排版这层
内容写好之后还有一道容易被忽略的坎：链接在 PDF 里是不是可点、有没有因为过长被折行折断、代码字体和正文混排会不会看起来乱。技术岗简历里出现的英文和符号比其他岗位多，排版翻车的概率也高。
导出前建议整体过一遍检测，棱镜简历的 prismresume.cn/check 免登录，能看出格式和结构层面的问题；如果内容是在编辑器或者 AI 对话里攒的、还没有成型的版式，prismresume.cn/paste 可以把文本直接排成标准简历再导出 PDF。
最后一句实在话：GitHub 链接的作用是让对方愿意点进去，而愿不愿意点，取决于简历正文里那三行有没有写出让人好奇的东西。链接本身不产生说服力。