一个维护者的"叛逆"宣言
2026年4月6日，一位开源开发者DPC（dpc.pw）发了一篇文章，标题简单粗暴——"I don't want your PRs anymore"。
翻译过来就是：你们的PR，我不收了。
这年头，敢这么说的人不多。开源社区的信条是什么？开放、协作、众人拾柴火焰高。结果这位老哥直接掀桌子：不约。
但仔细看完他的论证，你会发现他不是耍脾气，而是算了一笔账后发现——接受你的PR，对我来说是个亏本买卖。
这笔账是怎么算的
DPC列了几个理由，每个都挺扎心。
首先是信任成本。你一个陌生人给我发PR，我哪知道你是不是在代码里藏了什么恶意的东西？与其花时间审核你的代码，不如我自己写——至少我知道自己没使坏。
其次是沟通成本。代码风格偏好、依赖选择、实现方案……咱俩想法不一样，就得来回拉扯。时区不同就更惨了，一条消息发出去，等对方回复可能得第二天。
最后是最核心的变量：LLM来了。
DPC说了一句大实话：以前吧，帮忙写代码的人确实能帮我省时间，所以哪怕审核麻烦点，值。现在不一样了，我自己开个AI，代码分分钟写完，审核也不费劲——因为AI不会跟我耍心眼，不会跟我扯皮，更不会因为时差让我等一天。
"让AI写，我审" vs "你写，我审"——这笔账，维护者心里门儿清。
软件开发正在"去源化"
文章里有个观点挺有意思：DPC说，源代码这玩意儿，正在从"source"变成"code"。
啥意思？
以前我们觉得代码是"源头"，是程序员思想的结晶。现在呢？代码不过是"想法"和"机器指令"之间的一个中间层。AI可以跳过这个中间层，直接把想法变成可执行的指令。
那这个中间层还有多重要？
DPC的定位很清醒：设计我来搞，代码让AI写，我负责审和改。至于你——亲爱的贡献者——你直接给我代码，反而帮不上忙。
审核代码的人，真正卡壳的不是"写代码"，而是"读懂现有的代码"和"想清楚该怎么改"。你发来的那一坨代码，对我的理解、设计、审核，没有任何加成。
所以他建议：别给我发PR了，来点有用的。
什么才算"有用的"
DPC列了几种贡献方式，按价值排序：
反馈——告诉我这东西好不好用，哪里卡bug了。维护者自己往往没时间深度使用自己的产品，用户视角极其稀缺。
讨论——帮我理清楚应该做什么、怎么做。不同背景的人能碰撞出维护者自己想不到的角度。
高质量bug报告——说清楚怎么复现、问题在哪。一个好bug报告，顶修复工作的四分之三。
代码审查——这倒是DPC需要的，他自己也被审核瓶颈卡着。
最后一条最激进：fork它，然后自己改。
别等上游批准了。AI时代，改代码的门槛低到尘埃里。你自己fork，自己让AI改，自己用得爽歪歪。什么时候觉得上游可能也需要这个功能了，再去提个issue问一句——不是求合并，而是告知。
DPC说，这反而替他省了时间。不用协调各方需求，不用说服谁，不用找共识。你改你的，我写我的，世界和平。
行业正在分叉
评论区比文章还精彩。
有人提到了那个让人后背发凉的隐患：安全补丁怎么办？
以前漏洞一出来，开源社区集体升级，PR如雪片飞向各项目。现在如果大家都不发PR了，等维护者自己用AI发现、自己改——这个链条得多长？LLM还不一定知道要改哪。
更有人直接点破：这是中心化的苗头。
开源之所以香，是因为全球开发者一起debug、一起优化，集体智慧碾压个体。但现在维护者说"我自己来就行"，那跟闭源有啥区别？
当然也有人持不同意见：fork之后自己用，不强求合并，这叫"Take it home OSS"——把开源当原材料，自己加工成产品。这模式，有问题吗？
还有一位网友提出了一个灵魂拷问：你会在commit里加Co-authored-by吗？
你让AI写代码，然后署自己的名。跟贡献者把AI生成的代码发给你，本质有啥不同？
说白了，AI把"谁写了代码"这件事，彻底模糊了。
尾声
DPC这篇文章之所以火，是因为他说了很多人不敢说的话、或者说了很多人隐约感觉到但没想明白的话。
开源的协作模型，正在经历一次范式转移。
以前：众人贡献代码，融合成一个大项目。
以后：fork成无数个定制版本，维护者变成"首席架构师+AI监工"。
是进化还是退化？我没有答案。
但有一点是确定的："提交PR"这个动作所代表的善意和价值，需要被重新评估了。
【锐评】：当维护者发现"自己开AI写代码比审你的PR更高效"时，开源社区那套"众人拾柴"的叙事就碎了一地。这不是谁对谁错的问题，这是AI把软件开发的价值链重新洗牌了——只是有些人还攥着旧船票，想登新船。
参考链接：
https://dpc.pw/posts/i-dont-want-your-prs-anymore/