我不再需要你的 PR

# 我不再需要你的 PR 来源：https://dpc.pw/posts/i-dont-want-your-prs-anymore 我很感激你喜欢我维护的软件，并愿意伸出援手。但我们需要重新思考这种协作方式，因为我觉得我们越来越在彼此浪费时间。 ### 为什么我不想合并你的 PR 由于我根本不了解你，我必须默认你可能会在改动里夹带恶意，这使得审查和合并的风险高于我自己动手实现。 除此之外，代码还有很多主观和个人化的层面：格式、风格、结构、依赖、思路，你有一套偏好，我也有一套。 然后我们还要就 review、CI、冲突解决等来回同步。 再加上贡献者与维护者之间常见的多轮往返，只会把事情越拖越久。 早在 LLM 出现之前，写代码就不是我的主要瓶颈，但写代码确实要花时间，因此一份扎实、能跑、易审的 PR 通常值得冒那点风险、忍受那点不便。 如今 LLM 已经能很好地实现功能，这种权衡几乎不再成立。 虽然我还是得审 LLM 生成的代码，但起码不用担心它暗藏恶意；我已经把自己的编码偏好和风格指南固化给了 LLM；我可以按自己的节奏快速迭代，无需跟身处不同时区的人类同步。 因此，干脆我自己（在 LLM 协助下）改代码，对大家都更轻松。 ### 软件开发的本性正在转移 越来越明显的是，“源代码”里的“源”字正失去意义，它更像是一份“代码”——开发者脑海里的想法与计算机可执行指令之间的中间形式。向来如此，只是现在代码可以自动生成，这层关系才变得更显眼。 外界对“编码智能体”的反应两极：有人彻底封杀，有人宣布编码已死、“vibecoding”才是未来。就当下而言，我处在中间：我先做设计，再让智能体写大部分代码，最后我来审阅、打磨。 我能让海量代码瞬间生成，但真正的瓶颈是： - 理解——读懂既有代码以便推理； - 设计——构思正确的改动与架构； - 审查——确保代码确实符合我的意图。 你的 PR 对这三点几乎毫无帮助。所以咱们跳过这一步——别再抱着“合入主干”的目标去写代码了。 ### 那你能怎么帮 当“写代码”这部分价值下降，其他帮助维护者的方式就相对更值钱了。 #### 给反馈 我忙于实现功能，往往没空深度使用，也缺乏调研改进方向的时间。用户告诉我哪里好用、哪里卡手，价值巨大。 #### 讨论思路 我并非全知，与不同背景的人交流，能帮我想清楚该做什么、怎么做。 #### 报告并排查 bug 一份好的 bug 报告等于修 bug 完成了四分之三。 如果你发现问题，请描述清楚，最好再进一步定位复现路径和出错位置，然后一起探讨解决方案。 #### 用原型说明改动 给我一份参考 PR 和/或你用来生成它的 prompt。 没错，我刚说“别给 PR”，先解释下：有 LLM 后，我更愿意让自家 LLM 按我的风格改，然后自己审。 但——用代码“示意”仍然有用，扫一眼实现方案能帮我快速理解。 如果你把真正的“源”（prompt）也贴出来，我还能继续打磨复用，省时间。 #### 审代码、挑毛病 我卡在 review 环节，多一双眼睛总是好事。 #### 自己分叉，回头汇报 别怕分叉，想怎么改就怎么改。 要设计兼容多种场景、寻求共识、权衡折中，这些都非常耗时。 LLM 让软件可定制化变得前所未有的简单。你可以自己搞定需求，再按自己的节奏跟上游合并（或不合并）。 直接分叉，为你的场景加功能，按你的方式来，无需请示，也无需抱歉。 作为维护者，我也省心。最终，也许你的分支走出另一条路，我们还能互相学到东西。