别再发巨型PR了，求求你
Stop sending me huge PRs; a rant
我受够了。最近因为AI能一次性搞定整个Issue，我不得不审查动辄上千行的巨型PR。小PR从来不是为了方便写作者，而是为了照顾审查者。AI虽是行业福音，却成了维护者的噩梦。代码行数越多，理解它的耗时呈指数级增长，这绝不是为了快速上线功能而该付出的代价。另外，别写50行的注释，变量名起好了根本不需要解释。至于那些AI原教旨主义者，别再用AI去审查AI生成的代码了，既然都用AI，为何还要人类介入？React刚出现时我们没因此接受更大的PR，现在也不该例外。
我受够了审查那些因为某个AI代理能“一次性搞定整个Issue”而导致的成千上万行的PR。
HN 评论区
104- danpalmer
凭我的经验，如果让模型生成小型 PR 或提交，其表现会大打折扣。它们缺乏高效地规划工作顺序和理解依赖关系的能力——这并不是说它们做不了小 PR，而是这样做会消耗多得多的资源，进而触发上下文限制等问题。如果你还想回头去编辑一堆提交或 PR，或者把某些工作 rebase 到中间，那情况会更糟。我认为这其中没有任何一项是随着代码量或提交数量线性增长的。
此外，模型普遍不擅长“讲故事”，因为这需要你对沟通对象具备心理理论（theory of mind）。撰写供审查的代码本质上就是在讲故事，你要以某种方式进行修改，从而建立审查者的信心。我相信目前的 LLM 距离做到这一点还差好几年。
在我看来，如果你做不到这些，那你只是在 cosplay 软件工程。Vibe coding 有其用武之地，LLM 编程也是，我自己就经常这么干！但如果我们认为这就是软件工程，那我们就是在自欺欺人，并且危险地降低了标准。
- gensym
> 那你为什么还要把它提交给人工审查呢？
这似乎才是问题的核心。
我猜大多数时候，答案都是“因为这是将变更部署到生产环境的必经关卡”。如果 PR 作者看不出审查的价值，那就很难说服他们写出适合审查的 PR。
如果他们真的在寻求人工反馈，那么告诉他们如何以适合人工反馈的方式提交 PR，成功率会高得多。
- sackfield
将 PR 拆分成更小的块是合理的，但这也有限度。经常有审查者对此过于狂热，坚持要拆得比合理范围更碎，例如当拆分会破坏原本意图时，或者当那个“千行”PR 其实只是包含大量测试用例时（AI 超爱写测试，我也很喜欢它们这么做）。有些任务就是很长，审查时很有必要结合背景来理解。
不过话说回来，这类审查者最终会像恐龙一样灭绝。文章里其实也提到了，他们认为用 AI 审查大型 PR 很糟糕，理由是“这会浪费你的 token 去重新摄入那些原本就是由 AI 生成的代码”。这根本说不通，AI 经常需要重新摄入 AI 生成的内容，evals（评估）就是个很好的例子。
紧接着，文章触及了真正的问题：“好吧，很好，那你为什么还要把它提交给人工审查呢？”确实，这是个值得问的好问题：我们为什么要把它提交给人工审查？我敢打赌，他们其实并不想要人工反馈，而是有人把自己摆在了守门人的位置上，因此必须被安抚，而且他们很可能选择了最高效的方式，来维持这道关卡，拖慢那些已经跟上时代技术步伐的人。
- bawolff
> 老板，我累了。我受够了审查那些一两千行的 PR，就因为某个 agent 能够“一次搞定整个问题”。从来没人要求写小 PR 是因为它们更容易写，一直以来这都是为了审查者的利益。
100% 同意。
但话说回来，“不”只有两个字母，而这却是作为维护者最重要、也最难做到的部分之一。
- ulrikrasmussen
如果你生成的 PR 大到别人无法审查，那对你自己来说也大到无法审查。这意味着你把理解代码的任务委托给了 LLM，最终结果必然是：组织里没人比刚进门的新人更懂这套代码。新人也能像你一样写出下一个 LLM 提示词，因为他们对系统的了解程度和你一样少。
在这种情况下，我想问你：作为一家软件公司，你的护城河是什么？当像 Anthropic 这样的公司可以直接提供“你的软件公司即服务”，砍掉中间商并省下六位数的薪资时，你的客户为什么要继续付钱给你？