文章摘要
我厌倦了审查动辄上千行的大型PR，因为AI能一次性完成整个功能。小型PR不是为了方便编写，而是为了让审查者更容易理解和消化代码。请不要再发送大型PR了。
文章总结
标题：别再给我发超大的PR了；吐槽一下
来源：https://getsmall.xyz/post/cmstjfl9l000if70ljmpzr4va
我真是受够了。每次要审查动辄上千行的PR，就因为某个AI能“一次性搞定整个问题”。小PR从来不是为了方便写代码的人，而是为了方便审查者。AI对行业是好事，但对审查者和维护者来说却成了负担。也许我只是个老古董在发牢骚，但拜托，别再给我发超大的PR了。
最近我多次听到“不改整个代码就不行”或“不提交全部改动代码就没用”的说法。可这不正是小PR的意义吗？小PR不一定要是完整的小功能，而是小而精、易于消化、便于审查和理解的工作单元。虽然没有数据支持，但我大胆猜测，理解代码所需的时间与代码行数呈指数级增长。你为了快速交付完整功能，却要消耗我指数级的时间，这真让人不爽。
另外，我也不需要50行的注释。函数文档、jsdoc、rustdoc、javadoc这些好东西当然要有，但千万别给变量is_logged_in写5行注释解释为什么这么命名。变量命名得当，十有八九我一看就懂；命名不好才需要注释，那不如把变量名改好。
最后，那些AI至上主义者说“用AI来理解代码啊”，你们这是在浪费算力重新消化AI自己生成的代码。“我用不同的模型来审查”，那好，为什么还要提交给人审查？不如让你的宝贝AI先把代码拆分成小块，等我们凡人审查完再说。
AI确实是好工具，能加速开发、优化代码。但当年React出现时，我们也没因为“React写得更快、读得更易”就接受更大的PR，为什么现在要这样？
附注：你该不会故意提交超大PR，指望我审到一半就放弃通过吧？如果是，那算你狠。
评论总结
根据评论内容，主要观点和论据总结如下：
观点一：AI生成的大规模PR（拉取请求）给人工审查带来沉重负担 - 评论7（评分None）：“I'm tired of reviewing one, two, three thousand line PRs because some agent was able to 'one shot the whole issue.'” （“我厌倦了审查动辄一两千行的PR，因为某个智能体能‘一次性搞定整个问题’。”） - 评论5（评分None）：“In my experience the models perform substantially worse if asked to create small PRs or commits... they lack the ability to sequence work and understand dependencies efficiently.” （“根据我的经验，如果要求模型创建小PR或小提交，它们的表现会差很多……它们缺乏有效安排工作和理解依赖关系的能力。”）
观点二：应通过技术手段限制PR规模，如CI检查或Git钩子 - 评论1（评分None）：“Maybe make a CI job which checks that a PR has a reasonable size, and auto-reject with a polite message if it's not?” （“也许可以设置一个CI任务，检查PR大小是否合理，如果不合理就自动拒绝并附上礼貌提示。”） - 评论2（评分None）：“A simple solution is to use a git hook that asks for confirmation if it is too big, with a suggestion to ask the user to have the agent split it up.” （“一个简单的解决方案是使用Git钩子，在PR过大时要求确认，并建议用户让智能体将其拆分。”）
观点三：部分人认为大规模PR有时不可避免，应接受或改用AI审查 - 评论14（评分None）：“The large PRs needed to be large because they were adding features that couldn't be half-pregnant... Once you have the whole thing coded and working it makes no sense to artificially split it.” （“大型PR之所以大，是因为它们添加的功能无法半途而废……一旦整个功能编码完成并运行，人为拆分毫无意义。”） - 评论9（评分None）：“There's only one way out of this predicament. AI reviews. It's what we have to do.” （“摆脱困境的唯一办法就是AI审查。我们必须这样做。”）
观点四：核心问题在于审查流程本身，而非PR大小 - 评论4（评分None）：“If the PR author doesn't see the value in review, it's going to be hard to convince them to write reviewable PRs.” （“如果PR作者不认为审查有价值，就很难说服他们写出可审查的PR。”） - 评论21（评分None）：“why do we put it up for human review? I would wager that they don't actually want human feedback, a human has placed themselves as a gatekeeper.” （“我们为什么要提交给人类审查？我打赌他们其实不想要人类反馈，只是有人把自己当成了守门员。”）
观点五：需要更好的工具和方法来辅助审查，如分章节展示或自动生成说明 - 评论20（评分None）：“Y'all need to try PR review tools that split PRs into chapters... You get the full contexts while each piece is still reviewable individually.” （“你们应该试试能把PR分成章节的审查工具……这样既能获得完整上下文，又能单独审查每个部分。”） - 评论23（评分None）：“What I do think we need is probably at least two-fold: 1) better ways to explain these big PRs to human reviewers. 2) better ways to verify the functionality of a piece of code.” （“我认为至少需要两方面：1）更好地向人类审查者解释这些大型PR；2）更好地验证代码功能的方法。”）
观点六：AI生成代码可能导致组织内无人真正理解系统 - 评论24（评分None）：“If you generate PRs too big to review for others, then they are too big to review for yourself... the end result is inevitably that no one in the organization understands the code better than someone who just walked in the door.” （“如果你生成的PR大到别人无法审查，那它们也大到你自己无法审查……最终结果必然是组织内没人比刚进门的新人更懂代码。”）
平衡性总结：评论呈现明显分歧——一方认为AI生成的大规模PR是审查痛点，应通过技术限制或拆分解决；另一方则认为大规模PR有时合理，应改进审查工具或直接采用AI审查。核心争议在于：人类审查的价值是否被高估，以及如何平衡AI效率与代码可理解性。