别再给我发巨大 PR 了；一篇吐槽

原文 ↗ Hacker News 讨论 ↗

大型、AI 生成的拉取请求正在压垮人工代码审查者，并暴露出现有开发工作流的局限。评论者争论是应当严格限制 PR 大小、更多依赖自动化和 AI 辅助审查，还是重新规划功能开发，让变更以更小、更有叙事性的块逐步引入，从而更易理解和测试。在工具争论的背后，是对责任、软件质量，以及大型语言模型究竟能安全承担多少责任的更深层担忧。

AI 生成的大 PR 与审查瓶颈

  • 许多维护者反映，面对由代理“一次性”生成的 1,000–4,000 行 PR，会感到疲惫；人工审查成了瓶颈。
  • 有人说，如果一个 PR 大到人类无法审查，团队可能会倾向于取消审批，只依赖 CI；而另一些人认为这很危险。
  • 还有人担心，如果没有人能完整审查代码，就再也没人真正理解系统了，这会削弱公司的“护城河”。

限制、工具与工作流策略

  • 提出的缓解办法包括：用 CI 检查或 git hook 拒绝超过 N 行的 PR，并附上一条礼貌提示；但也有人认为这只是在把不可理解的工作进一步碎片化。
  • GitHub 的 stacked PR、将 PR 审查“分章节”的工具，以及浏览器扩展，都被提及为让大改动更易消化的方法。
  • 有人描述了自定义“技能”或工作流，用来强制原子化提交或拆分分支；另一些人则发现，在没有大量提示的情况下，LLM 在良好的 git 习惯方面顽固地表现很差。

小 PR 与大 PR 的理念之争

  • 一派坚持小而有叙事性的 PR：先引入基础，再加胶水层，最后实现功能；大包提交或一次性多个大 PR 都不被接受。
  • 另一派认为某些功能“不能半吊子”；拆分只是额外且无意义的工作，尤其当所有内容必须一起发布时更是如此。
  • 反驳观点是：大多数大型功能都可以通过功能开关或前置重构来分阶段推进；“只要有意愿，总能找到办法”。

测试与代码质量的作用

  • 一些评论者强调，LLM 写出来的测试可能空洞无物，或者把错误行为编码成规格；测试往往应该由人类编写，或者至少由人类仔细审查。
  • 干净的提交历史和小而聚焦的变更，被视为良好审查的核心，而不是可有可无的修饰。

审查与责任中的人类 vs AI

  • 有人主张 AI 审查是唯一可扩展的路径；批评者则问：谁来审计 AI，并警告“劣质产物会滋生更多劣质产物”。
  • 另一种相反的观点是：减少或取消人工审查者，并提高“提示者”的个人责任。
  • 还有人坚持认为，真正的人类审查至关重要，尤其是在受监管或安全关键的场景中。

组织与 OSS 动态

  • 在 OSS 中，维护者可以直接关闭巨大的/AI 生成的 PR，且通常会考虑彻底阻止匿名 AI 贡献。
  • 在公司里，合规、截止日期、领导层态度以及审查者与作者之间的权力关系，使得“直接拒绝”要困难得多。