作者表示不再愿意接受他人的PR（Pull Request），因为软件开发的性质已发生变化。他建议贡献者通过提供反馈、讨论想法、报告和调查bug、创建原型变更以及代码审查等方式来帮助项目，而非直接提交PR。

我不再需要你的PR了

为什么我不愿合并你的PR

作为一个开源项目维护者，我确实很感激你喜欢我维护的软件并愿意提供帮助。但我们需要重新思考这种协作方式，因为目前的PR流程正在浪费彼此的时间。

首先，由于我不了解你，必须假设你的代码可能包含恶意内容，这使得审查和合并PR的风险比自己实现更高。此外，代码风格、格式、依赖选择等主观因素常导致分歧。再加上需要协调审查、CI运行、合并冲突等问题，以及与贡献者来回沟通的时间成本，整个过程效率低下。

随着LLM技术的发展，编写代码已不再是主要瓶颈。虽然仍需审查AI生成的代码，但我不必担心其恶意性，且可以按照自己的节奏迭代，无需与不同时区的人类协调。因此，借助LLM自行修改代码反而更高效。

软件开发本质的转变

源代码正逐渐从"源头"转变为"代码"本身——它更像是开发者想法与计算机指令之间的中间层。随着AI自动生成代码的能力提升，这一特性愈发明显。

目前我的工作流程是：先设计架构，然后让AI代理完成大部分编码工作，最后进行审查和优化。真正的瓶颈在于： 1. 理解现有代码以进行推理 2. 设计正确的变更和架构 3. 确保代码符合预期

传统的PR对这些核心环节帮助有限，因此我们应跳过以合并为目的的代码提交。

更有效的贡献方式

随着编码价值降低，其他形式的贡献变得相对更有价值：

1. 提供反馈：用户分享使用体验和改进建议非常有帮助
2. 讨论想法：不同背景的讨论能帮助确定开发方向
3. 报告和排查bug：详细的错误描述和复现方法能解决大部分问题
4. 制作原型：可以分享参考PR或生成代码的提示(prompt)，虽然不会直接合并，但能提供思路
5. 代码审查：帮助发现潜在问题
6. 创建分支：鼓励直接fork代码并按需修改，不必寻求许可

这种"先fork，后报告"的模式能为维护者节省时间，同时让贡献者获得更自主的开发体验。最终，双方都可能从这种平行开发中获益。

[原载于dpc.pw，2026年4月6日]

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

支持拒绝PR的观点

1. 维护者自主权：认为维护者有权决定贡献方式，拒绝PR可减少低质量代码和沟通成本

   • "I think every maintainer should be able to say how they want or don't want others to contribute" (bawolff)
   • "Great example of how to set boundaries. The open source community is slowly healing" (mactavish88)

2. LLM时代的新常态：AI工具使重现代码比审查PR更高效

   • "the observation that he can just re-prompt his own LLM to implement the same feature" (yieldcrv)
   • "reviewing [AI-generated PRs] took longer than just writing it myself" (vicchenai)

3. 质量与信任问题：陌生贡献者的代码可能不符合项目标准

   • "I’d much rather start with a spec, a bug, a failing test... and generate the code myself" (ncruces)
   • "When I see this, I’m not going to insist, I’ll move on to my next Jira task" (boricj)

反对拒绝PR的观点

1. 协作精神丧失：可能阻碍社区发展

   • "we would’ve never had Linux under this mindset" (lou1306)
   • "why do open source at all?" (clutter55561)

2. PR的实际价值：提供具体实现参考

   • "The PR at least has the benefit of offering one possible concrete implementation" (freetime2)
   • "PRs come from your most engaged community members" (tonymet)

3. 安全风险：可能导致代码碎片化

   • "When a new exploit is discovered... the library contributors will likely not know to change their code" (hunterpayne)

中立建议

• 替代方案：提倡提交问题报告或测试用例而非代码

  • "the right unit of contribution is going back to being the detailed bug report / spec" (vicchenai)
  • "submit 'prompt diffs'" (porphyra)

• 明确沟通：应在贡献指南中说明规则

  • "this really shouldn’t be a blogpost, but rather a 'Contributing Guidelines' section" (krick)

关键分歧点在于：维护效率与社区协作的平衡，以及AI工具如何改变开源协作模式。