用AI一起开发之后,GitHub上的活动量怎么变了。2024年下半年每月约20~40件,2025年5月约300件
GitHub的贡献数在2024年下半年每月约20~40件,2025年5月约300件。这是包含Issue、PR和评审的GitHub标准合计,依据是2025年5月30日发布的图。它不是开发速度或交付量的倍率。
GitHub的贡献数(包含Issue、PR和评审的GitHub标准合计)在2024年下半年每月约20~40件。2025年5月约300件(依据2025年5月30日发布的图)。
初版的「7倍」是把使用AI之前按每月大约50件来放时的四舍五入。
这个件数并不表示开发速度或交付量变成了多少倍。
本文回顾当时把哪些工作交给AI、什么变得更容易推进。质量、返工和实际作业时间没有在相同条件下比较。那些改善率并不主张。
比较的是2024年下半年的每月件数和2025年5月的件数。非公开仓库的件数是否计入,从公开信息看不出来。没有为了配合过去的数字而新做分母或质量指标。
当时的工作怎么分
写代码的工作
代码由Claude Code来写。先和Claude Desktop对话,把指示书写好,再在终端交给Claude Code。几分钟就能得到成为基本骨架的代码。之后再叠上具体指示,例如「给这个类加方法,并写单元测试」。
评审
做出PR后,CodeRabbit开始评审,把可能的缺陷、安全上的指出、与编码规范的差异评论到PR上。被指出的地方用Cursor的Agent功能修改。这并不表示指出能找到全部问题。
数的是什么
数的是GitHub的贡献数。2024年下半年每月约20~40件。2025年5月约300件。两者都在2025年5月30日发布的图的范围内。
贡献不是提交数。按GitHub的定义,除了提交,Issue、Pull Request和评审也算进去。
当时用的工具
- Cursor:内置AI的编辑器。被指出的地方用Agent功能修改
- Claude Desktop:一边对话一边写指示书
- Claude Code:按指示书写代码
- CodeRabbit:对PR的自动评审
当时的感觉更接近一边和AI对话一边解决问题,而不是一行一行写代码。这是感觉,不是作业时间或交付量的测量结果。
参考资料
2025年6月1日的note文章标题里写着开发速度7倍。公司这篇文章的数字对齐2025年5月30日的图。不把它当作速度或交付量的倍率。
2025年5月30日的帖子里有按月的贡献图。
- GitHub Docs: Profile contributions - 官方对贡献计入对象的说明
想在贵公司推进本文的内容?
AI 受托开发的咨询,由 AI 接待「Cloudia」受理。
详细了解AI 基础设施与受托开发Support this article
If this article was helpful, please support us with a tip. You can choose any amount.
相关文章

添加示例反而变差的问题亦有存在。通过小型LLM验证的生成式AI测试方法
2026年10月29日,在代表寺田 康佑担任讲师的某企业内部学习会上,针对小型语言模型(Qwen2.5-3B-Instruct)尝试了“附带示例”和“要求复核”这两种改进方式。本文将根据回答变好的问题、变差的问题,以及将错误断定为正确的问题,为您阐述在业务中测试生成式AI时的对比方法。

从修复版本发布到完成应用:以LiteLLM为例探讨更新的负责人、期限与记录
以LiteLLM在非公开镜像仓库中分发修复补丁为契机,探讨本地LLM的更新负责人、应用期限与记录方式。本文是面向企业提供的专业解析,旨在帮助企业明确区分补丁发布与在自社环境中的实际应用。
在公司里使用本地推理API之前。认证、许可列表和终端退役的设计
在公司里使用本地推理API之前,把认证、许可列表和终端退役分开设计。许可列表表明的是通信可以通到的对方。谁可以把它们用于哪项业务,要另外决定。



