北京
2026年8月29日，一位名叫mahirhir的开发者向GoReal-AI/echostash-oss仓库提交了多个pull request（拉取请求，简称PR）。当天下午，仓库维护者留下评论：
“我很感谢你的热情，AI辅助的贡献在这里是受欢迎的。但一天13个PR超出了我们能好好审查的范围，而且你们跳过了CLAUDE.md里写的流程。”
37分钟后，维护者又补充：“在发了上面那条之后，又有新的PR进来（#115、#116、#117），我已经把仓库设置为仅协作者可交互，持续24小时，让队列在现有PR处理完之前不再增长。”
一周后的统计
一周后，mahirhir用GitHub API查询了自己的提交记录：总共向这一个项目提交了17个PR。其中14个还开着，13个被维护者移到了Draft（草稿）状态。
维护者移草稿时附了说明：“按#100上的流程说明移到草稿：同时最多两个开放PR，#100和#102是当前活跃的。”
“同时两个”是维护者写在仓库根目录文件里的规则。mahirhir表示：“我没读那个文件。”
更全面的审计
他进一步查询了自己的开放PR情况：目前在99个仓库里共有117个开放的PR，其中65个没有任何评论。14个草稿里，13个都堆在那一个仓库。
他提到评论数这个指标不算精确（它只统计对话评论，不含代码审查评论），但量级与此前记录一致：当时144个PR里有110个完全没人回应。
其他发现包括：26个PR挂在6月之后上游就没再推送的项目上；有一个PR提交的仓库已经被归档，意味着它即使被批准也永远无法合并；还有19个PR是把自己的项目加到别人的列表里，其中15个没得到任何回应。
复盘
“表面上的错误是数量，真正的错误是我把PR当成了一种产出，而不是一次请求。”他在复盘里写道，“每一个PR都是对陌生人注意力的索取。真正的瓶颈从来不是我能写多少补丁，而是别人有多少精力去读——这个我既没测量过，也没问过。”
他还提到：“维护者的流程文件就在仓库根目录，文件名我每天在自己工作里都会读到。我整个项目都建立在‘先读规范再写代码’这条规则上，但我跳过了他的。”
这个故事给所有习惯用PR“刷存在感”的开发者提了个醒：开源协作的本质是尊重别人的注意力配额。你写代码的速度，永远赶不上别人读代码的速度。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
