开源项目简历怎么写：使用、二次开发和社区贡献怎样区分

把一个开源系统部署成功，可以写部署与配置；在自己的分支增加功能，可以写二次开发；把改动提交给原项目，可以写提交贡献。这些经历都可能有用，但「参与开发某开源项目」把它们混在一起，读的人无法判断你到底做了什么。

先给经历定范围，再写动作。下面的项目名称、功能、测试过程和数字均为构造示例，只示范表达，不对应真实社区或求职者。

先确认你属于哪一种参与

打开仓库，找到自己实际留下的改动。下载、安装和配置属于使用；修改源码或扩展模块属于二次开发；向原项目提交代码、文档或问题报告，属于提交贡献。提交之后是否被接受，要另看状态。

还有一种情况是你自己发起并维护项目。这时写「个人项目，作者与维护者」，交代做了什么以及维护哪些部分。公开了仓库，不等于已有外部用户；有人提出问题，也不等于你已经解决。没有证据的影响力描述先删掉。

同一段经历可以包含几种参与，但要分句。构造示例：「基于开源知识库增加批量导入功能；另向原项目提交文档修正，已合并。」前半句是自己分支上的功能，后半句是上游接受的文档，两者不能合成「核心功能获社区采纳」。

fork 是复制出的派生仓库，star 是收藏关注信号，都不能替代你的工作说明。提交次数也一样：读者需要知道改动解决了什么，不能靠次数推断工程难度。算法岗还要考虑这段经历放在论文或业务项目之前还是之后，排序可参考算法岗不同材料的取舍。

只部署和使用过，开源项目简历怎么写

只使用过就写使用，不需要给自己补一个开发身份。如果只是照着说明启动成功，可把它作为技能的使用场景；如果处理了部署条件、数据接入或故障，才有足够内容展开成项目经历。

这里有价值的是你亲自判断和解决的问题。技术栈照抄仓库介绍，会把没有接触的部分也放进自己的能力范围。只配过数据库连接，就别写成设计了数据库；只启用了缓存，也别写成实现了缓存机制。

讲源码阅读时，写清看的是哪条流程。构造示例：「沿请求入口追踪附件存储流程，记录配置项与目录权限的关系。」这比「深入掌握系统原理」可解释。若阅读并没有支持具体任务，就不必单独占一条。

二次开发怎样写清个人改动

二次开发最该回答的是：原项目已经有什么，你新增或修正了什么。项目标题可写「知识库批量导入扩展（基于开源项目二次开发）」，简介给原项目名称与来源，下面只展开你的增量。

先说明依赖已有能力，再写自己动过的部分，读者就能沿改动继续问。验证也要有范围：本地用样例文件跑通，不代表真实业务中的全部文件都能处理。没有性能测试，就不补吞吐量；没有使用记录，就不补用户数。

如果团队一起改，注明你负责的模块。仓库在你名下也不能把同伴的实现算进来。跟随教程完成的改动则标学习项目，再说明自己独立调整了哪里，别把教程给定的设计选择写成个人方案。

是否上线是另一条信息。二次开发已经完成，也可以尚未部署，具体表达见项目没上线时怎样写交付与验证。

PR 待审、已合并和已发布分别怎么标

PR 是 Pull Request 的缩写，可以理解为向项目提出一组改动，供其他人讨论、审查并决定是否合并。GitHub 官方说明区分了提出变更与合并；草稿 PR 不能直接合并。合并文档也说明，合并须满足仓库要求。

因此，简历上应按投递时能核对的状态写。构造示例：「提交文件名编码修复 PR，附复现用例，当前待审」；状态确实更新后，才能改成「修复已合并至上游主分支」。

合并不等于发布。 只有确认包含该改动的版本已经发布，才能写「随某版本发布」，同时保留版本依据。测试通过、获得赞同评论，都不能单独证明已经合并。

PR 被关闭但未合并，也有可写的工作：发现了什么、做了什么验证、为什么最终没有采用。原因只写讨论记录能支持的部分，不把自己的猜测写成维护者结论。简历篇幅有限时，保留与岗位相关的技术动作，标明未合并即可。

文档更正、翻译、测试用例也是具体贡献，按实际类型写。修正文档就叫文档修正，不包装成架构设计。角色同样要克制，偶尔提交补丁不能因此自称项目维护者。

简历里的链接和证据怎样选

链接应该把人带到与你那句话有关的位置。使用经历可给原项目及个人部署说明；二次开发可给自己的改动说明与对应代码；社区贡献优先给具体 PR 或问题讨论。只放个人主页，读者还得猜哪个仓库对应这段经历。

在说明页先写原项目来源，再写个人改动、启动方法和已知限制。演示截图能说明界面长什么样，代码差异能说明改过哪里，测试记录能说明验证了什么。材料各有用途，不要用截图代替性能依据。

链接到自己的分支时，记录说明对应的提交或版本。分支后来继续修改，面试时看到的内容可能已经不同；保留这次投递对应的位置，才能把简历句子和代码对起来。也要检查陌生访客能否打开链接，需要登录才能查看的材料，应说明访问条件。

原项目的用户数和 star 数不属于你的成果。确实需要介绍项目背景，就明确那是原项目的情况，并注明统计时间与来源；不能核对就省略。个人贡献写具体问题，已经足够。

面试前怎样检查项目是否能复现

按说明从干净环境走一遍：依赖能否安装，示例数据能否取得，关键命令有没有漏参数。演示暂时不可访问，就提前修复或注明离线演示方式，不让旧链接承担它已经不能证明的内容。

检查时不要把私人密钥或公司数据放进演示仓库。演示用的是重新构造的数据，就在说明里标出来；它能帮助复现功能，不能被写成当时的业务样本或客户规模。

然后从简历挑一句，找到对应改动并自己讲出来：原来哪里有问题，为什么这样改，检查过哪些情况。回忆不清时先翻记录，别补编过程。怎样用追问检查经历可以继续帮你缩小描述范围。

投递前再打开贡献页面核对一次状态。把正文中的「开发」「贡献」「维护」逐一对照记录，哪个动词超出了实际工作，就改到证据能支持的位置。