一叶舟・记

在写贡献指南时卡住#

事情的开端比听起来要平凡得多。

我在给一个项目补贡献指南。写到”如何提交 PR”那一段时，手指悬在键盘上方，突然打不下去了。

常规写法我很熟——“Fork 本仓库 → 创建分支 → 提交代码 → 发起 PR → 等待 Review”。这套话术我写过见过无数次，闭着眼都能敲。但那一刻我卡住了，因为脑子里冒出一个很诚实的念头：如果真有人按这个流程给我提了个野生 PR，我大概率不会按这个流程处理它。 我会读一遍，提取思路，然后打开终端让 agent 按我的上下文重新实现。贡献者花时间写了代码，但我最终合入的那份，是他思路的 agent 转译版，不是他的 diff。

那我在贡献指南里写”欢迎 PR”，是在欢迎什么？欢迎别人花时间产出一份我不会直接用的代码吗？

这个念头一冒出来就压不回去了。

后来几周，我有意地在提 Issue 和逛社区时留意这件事。发现好几个 vibe coding 主导的项目的维护者，聊到这个问题时给出了几乎一致的反馈：野生 PR 的处理成本正在超过它的贡献价值，但大家都不好意思说。 不是因为贡献者不好，而是维护者手里那套”读 spec → agent 修 → 审 diff”的链路太快了，快到让”读陌生 diff → 理解别人的思路 → 写 review → 来回改”那条传统链路显得极度昂贵。

代码本身，正在贬值。保值的，是代码背后的排查过程和架构判断。

消费主体变了#

这里有个一直被忽略的层面：Issue 的消费者不再是纯粹的人类。

在传统模型里，一条 Issue 写得再好，维护者还是得自己动手修。Issue 再漂亮，也只是”省了排查思考时间”，编码时间一分不少。所以 Issue 和 PR 之间，存在一道无法跨越的价值鸿沟——PR 直接给了代码，Issue 只给了方向。哪怕方向再准，甚至完整的修复思路，但从方向到代码那段路，还是要人走。

现在，vibe coding 把”从方向到代码”那段路的成本碾碎了。

一条包含变量名、文件路径、复现步骤、排除项和修复思路的 Issue，本身就可以被 Agent 直接消费。 维护者不需要”把 Issue 翻译成代码”，那是 Agent 的活。维护者只需要做一件事：判断 Agent 产出的 diff 对不对。

这意味着什么？

Issue 和 PR 之间的价值鸿沟，被 Agent 填平了。

一条足够清晰的 Issue，在功能上等价于一份附带完整代码的 PR——因为从 Issue 到代码的转换成本趋近于零。而 Issue 比 PR 多了一个决定性优势：它不包含任何维护者需要逆向工程的陌生决策。 变量命名、文件拆分、错误处理策略——这些在 PR 里需要维护者逐行审查的东西，在 Issue → Agent → diff 的链路里，天然由维护者的 Agent 按项目的既有风格生成。

换句话说：提交 Issue 的人负责”修什么”和”为什么这样修”，Agent 负责”怎么写”，维护者负责”对不对”。

三层分工，各司其职。代码层被彻底自动化了，认知层反而比以往任何时候都更值钱。

贡献指南将会重写#

这是本文最想说的一个预判。

在可预见的未来，许多 vibe coding 项目或个人小项目的贡献指南，大概率会发生根本性的改变。它们可能不再强求传统的 PR 流程，而是会出现类似这样的表述：

欢迎提交包含清晰 Spec 和复现路径的 Issue。 维护者会直接借助 Agent 修复并合入。
对于非核心功能的野生 PR，我们可能不会优先 Review。
如果你愿意做排查而不是写代码——把根因、涉及变量、排除路径理清楚，你的贡献价值将远大于一个附带陌生 diff 的 PR。

这在两年前是不可理喻的。开源社区的核心伦理之一就是”来写代码吧，PR welcome”。拒绝 PR？那是闭源公司才干的事。

但 vibe coding 撕开了一道裂缝：当维护者自己修的成本低于审查陌生人代码的成本时，“欢迎 PR”就不再是善意，而是一种隐性负担的转嫁。 说”欢迎 PR”等于说”欢迎你花时间写一份我大概率不会直接用、但出于礼貌又不得不审的代码”。这对谁都不好。

更诚实的做法，恰恰是那行看起来”冷漠”的声明：把你的排查过程写成 Issue，剩下的交给我的 Agent。 这不是拒绝协作，是重新定义协作的分工。

从”大家一起搬砖”到”野生架构师 + AI 施工队”#

传统开源协作的隐喻是：大家一起来搬砖。 你搬一块，我搬一块，项目就盖起来了。PR 是那块砖——可度量、可审核、可合并。

但 vibe coding 把”搬砖”这个动作自动化之后，砖本身不再是稀缺资源。稀缺的是知道砖应该往哪搬的人。

这就催生了一种新的协作形态：

野生架构师 / QA（提 Issue）+ 拥有全局上下文的 AI 施工队（维护者 + Agent）

贡献者的角色从”搬砖工”变成了”建筑师”或”质检员”。他们不再直接生产代码，而是生产架构判断、边界定义、问题定位——这些是 Agent 无法从零产出的东西。Agent 可以在已有认知框架内高效执行，但”这个 bug 的根因在模块 A 和模块 B 的交互边界上”这种判断，它无法凭空生成。

能把问题说清楚、写出高质量 Issue 的人，实际上已经承担了项目中最核心的两件事：

• 架构思考：问题出在哪个模块？为什么会出在这里而不是别处？修这里会不会炸别处？
• 边界定义：什么算 bug 什么算 feature？预期行为是什么？排除项有哪些？

这两件事，在过去是分散在 PR review 的来回对话中的，隐性的，不可见的。但在新模型里，它们被提前到了 Issue 阶段，显性化，结构化，变成了可被 Agent 直接消费的输入。

这不代表贡献降级了，反而可以说是升维。从”写代码”升维到”定义问题和设计解决方案”，这才是开源协作在 AI 时代最珍贵的通货。

长期贡献者与野生 PR 的边界#

这里必须再画一条线——因为很容易被误读为”所有 PR 都贬值了”。

长期贡献者的 PR，从不贬值。一个跟了项目两年的人，他跟维护者之间的认知对齐成本趋近于零。他的 diff，维护者扫一眼就懂——因为那些变量命名习惯、模块组织方式、边界处理策略，本身就是他们一起养出来的。这种 PR 不同于”陌生 diff”，是”自己人写的 diff”。 Agent 生成的代码反而没有这种信任溢价。

贬值的是野生 PR：贡献者怀着善意，基于局部理解写的代码。在过去，“善意 + 可运行的代码”足以构成一次有价值的贡献。但在 vibe coding 项目里，“可运行的代码”不再稀缺——Agent 三分钟就能产出一份更符合项目风格的。

这里不是要否定 LLM 在 PR 审查中的作用，事实上许多仓库的 PR 工作流已经接入了 LLM 预审核和变更总结，这部分可以被代劳一部分。真正的问题是：PR 会遇到那些在 LLM 还没有侵入 coding 时就存在的、最麻烦的老问题——风格冲突、没写出来的假设、命名习惯不一致、你来我往的修改迭代。LLM 预审可以帮你标出”这个变量命名不统一”，但它抹不掉维护者真正的心力开销：跟陌生人反复沟通、等待回复、在一个不熟悉的思路上来回拉扯。而 Issue 呢？最多只需要确认一下方向有没有跑偏，然后就能丢给 agent 修了。

所以野生贡献者的最优策略不是”别来了”，而是”换个姿势来”。 把同样的善意和精力，从”写一份我猜是对的修复”转向”跑一遍完整的排查、把根因压缩到变量名级别、写成 Issue”。后者的价值，在 vibe coding 项目里，是前者的十倍。

写在最后#

写到这里，忽然意识到这篇文章最先该说服的，其实是我自己。

过去总有一种说不清的愧疚，总觉得光提 Issue 不修，跟甩锅有什么区别？我见过不止一次，可能是抱有和我同样想法的人，硬着头皮写了个 PR，明明对那个代码库并不熟。结果维护者在 review 里反复追问他的思路，来回改了三四版才合进去。当时觉得自己”尽了贡献者的本分”，现在回头看，只是把维护者本该十分钟搞定的排查 + agent 修复，硬生生拉成了一场拉锯战。

我以为我在帮他省时间，实际上我是在让他为我的善意买单。

这就是为什么这篇文章不是在说”高质量 Issue 很重要”——那个从来没有人否认过。

它想说的是：在 vibe coding 的侵蚀下，Issue 的生态位正在从”求助”进化为”交付”。 它的消费主体从纯人类变成了人类 + Agent 的组合体。它的竞争对象不再是”另一条 Issue”，而是”另一份 PR”——而且它正在赢。

当代码层的生产力被彻底释放之后，人类贡献者终于可以从”怎么写”里抽身，回到他们最不可替代的位置上：知道该修什么、知道为什么修这里而不是那里、知道修了之后什么不会炸。这些，才是开源协作在 AI 时代最珍贵的通货。

一个随之而来的变化是：未来衡量一个贡献者的维度，会变。 过去翻一个人的 GitHub 主页，看的是 contribution 绿点、PR 数量、star 数。这些信号衡量的，本质上都是”这个人写了多少代码”。但在 vibe coding 项目里，一个把问题排查到变量名级别、把排查路径写成可执行 spec 的人，对项目的实际推动力可能远超十个边缘修 bug 的 PR。他的 GitHub 主页上未必有多少绿点，但他的 Issue 列表读起来像一本代码审计报告。

也许再过两年，技术面试里除了”你做过什么项目”，还会多一个问题：“给我看看你提过的最好的几条 Issue。”

而那张重写过的贡献指南，会成为这个时代的第一份”新契约”。