简历上「开源贡献」这一栏两个极端都常见。一种是一句「参与多个知名开源项目贡献」下面什么都没有另一种是把三年前改过的一处文档拼写也列成一条和别的经历并排。两种写法在面试官那里的处理方式是一样的打开链接十秒钟判断这条贡献是什么量级然后决定要不要问。所以问题不在于写不写在于你有没有替对方先把量级标清楚。PR 是分档的对方一眼就能分出来按含金量从低到高大致三档一、文档、拼写、注释、依赖版本升级、CI 配置微调。这类 PR 说明你会走一遍开源协作流程fork、分支、提交、签 CLA、等 review说明不了别的。二、bug 修复。有 issue 对应、有复现步骤、改动带测试用例、被维护者 review 过至少一轮。这一档开始能体现排查能力因为你得先读懂别人的代码才能改。三、功能或设计层面的改动。涉及接口设计、和维护者讨论过方案、可能被要求改过设计再合入。这一档能问出很多东西为什么这样设计、维护者提了什么反对意见、你怎么说服的或者怎么妥协的。面试官打开 PR 页面看的就是这几个信号改动行数和文件分布、有没有测试、review 对话有几轮、最终是 merged 还是 closed。这些都在页面上藏不住。第一档能不能写能但要写对位置。它不该出现在项目经历里放在技能栏或者「其他」里一句话带过更合适向 Vitest、pnpm 提交过文档与类型定义修正已合入这一行的作用是告诉对方你熟悉开源协作流程、英文沟通没障碍仅此而已。把它单独列成一段、配上项目介绍和 star 数反而让人觉得你在拿别人的项目垫高自己。第二、三档才值得写成条目对比一下参与 Apache ShardingSphere 开源项目提交多个 PR 并被合入Apache ShardingSphere · 贡献者PR #28341、#28902均已合入 5.4.1 - 修复分片键为 Date 类型时时间区间查询漏路由的问题定位到区间边界计算未处理时区偏移 补充边界用例 4 个经 2 轮 review 合入 - 为读写分离插件增加权重路由策略与维护者讨论后放弃在配置层做动态权重 改为静态权重 健康检查剔除第二种写法多出来的信息PR 编号可查、合入版本说明不是挂着的草稿、问题的技术定性、review 轮数、和维护者的分歧点。每一项都能往下聊而且每一项都能在 GitHub 上核对。第一种写法里的「多个」和「知名」是两个最没用的词。多个是几个知名到什么程度对方点开就知道了你自己先写清楚更好。面试会问什么第二档的追问通常是这个 bug 你是怎么发现的是自己踩到的还是看 issue 列表挑的复现花了多久改动为什么是这样而不是另一种。第三档会多一层维护者最初的意见是什么你的方案和最终合入的版本差别在哪这个模块的整体设计你看明白了多少。「看 issue 列表挑的」不是坏答案挑一个 good first issue 之外的问题并解决掉本身就是能力。坏的答案是说不清改动为什么这样做那说明改动是照着维护者的评论一步步改出来的你只是执行了。几种会被当场识破的写法把 fork 当成贡献。自己 fork 了一份改了配置没有提回上游这不是开源贡献是个人仓库按个人项目写进项目经历可以别标「贡献者」。把 issue 里的一条评论写成参与讨论。除非那条评论确实推动了设计变更否则不要写。把 open 状态的 PR 写成已合入。这条最伤因为核对成本是零。没合入的 PR 可以写但要写「未合入」并给一句原因比如维护者认为该功能不在路线图内。写清楚了反而显得坦荡而且讨论过程本身有时比合入更有价值。写 star 数不写 PR 号。star 数是项目的PR 号是你的。只写前者会让人觉得你想借光。贡献量不够时的处理只有一两条第一档的贡献不用硬撑一个「开源贡献」板块。合并到技能栏一行带过把版面留给能撑得住追问的经历。板块的存在本身会抬高期待期待抬高了又撑不住比没有这个板块更糟。写完自查每条贡献有没有 PR 编号或链接状态是不是写对了改动的技术定性有没有一句话说清你能不能讲出维护者的意见。四个问题过一遍档位就清楚了。表述层面还可以借工具扫一遍棱镜简历prismresume.cn/check免费体检不用注册粘贴文本或上传 PDF几十秒列出表述缺失、格式不一致这类问题。开源条目带编号、带英文项目名写法不统一的情况尤其多自己先对一遍。最后开源贡献的可信度来自它可以被核对。写的时候就按会被核对的标准写对方核对完信任度会比任何形容词都高。