用这一个简单技巧让代码审查重新可行

# Noon van der Silk - 一个简单技巧让代码审查重回正轨 来源：https://silky.github.io/posts/reviews-one-simple-trick.html 发布于 2026年7月24日，作者：Noon van der Silk 一堆分支。你可能已经猜到了：它就是堆叠分支。但如果你之前不知道，别担心，我们很快就会讲清楚。 不过，先来聊聊问题。 ### AI 生成的代码难以审查 目前几乎所有使用 AI 的人都面临这个问题；生成一段基本连贯、基本能解决当前问题的代码相当容易，甚至容易到我们常常会有点兴奋过头，一次性做得太多——这使得代码变得难以审查。 这给审查者带来了多方面的压力。光是看着一个巨大的差异（diff）就让人提不起劲：它“可能”确实做了作者说的那件事，“甚至”通过了你的测试套件，但“也”可能包含一些古怪的、不符合你代码库习惯的东西——如果你有动力去质疑的话，你本来会提出挑战。 还有知识流失的问题；大段地阅读这样的工作成果并理解一切，简直是难上加难。尤其是当你不能完全信任每一行代码和注释都源自（人类）作者某种深层次的根本理解时。 当然还有很多其他问题，这个想法并不能解决所有问题；但我们这里要抓住的核心思路是：少即是多。当改动量很小时，审查更容易；而且在进行特定审查时，你可以只专注于思考“一件事”。 ### 常规技巧 应对这个问题有很多种方法，而且还在不断增加： 1. *多加测试*：理论上是这样：如果测试通过，那就说明工作正常。根据你的测试基础设施，这可能很冒险，也可能很棒。但我们都知道，测试并不能覆盖代码所能表达的一切。 2. *少做一点*：只提交更小的拉取请求（PR）。这很难，因为现代 AI 系统似乎有点刻意地让人上瘾/游戏化：它们在完成一项工作时，常常会不断发现新的事情要做。这也与大多数工作压力相悖：要交付更多、更好、更快。 3. *集体审查*：让所有人开个电话会（或者当面？！），一起过一遍代码。这有时有用，但不能什么事都这么干。而且，这对某些团队成员和思考风格并不奏效。 4. *作者与合并者责任*：你可以直接宣布，比如说，如果发现某个（大型）PR 引入了一个大 bug 或某种误解，就直接开除作者和合并者。或者不那么极端，比如在绩效评估中给他们打差评。无论如何，这种方法是惩罚性的、基于压力的。这让作者和审查者*更加*紧张；并没有真正以有意义的方式赋能他们。最终只会拖慢你的速度，让大家不开心。 5. *别管了，让市场来裁决*：你的产品变好了吗？功能正常吗？特性越来越多了吗？那么，到底谁能说什么是“正确”的？最终裁决者不就是用户吗？我们难道不应该尽快把更多东西推给他们吗？显然，这种说法既正确又疯狂。理论上，只有可见的功能才重要；但同样真实的是，某个东西可能在视觉上准确，但在略有不同的情境下却错得离谱。我们还没到可以这样运作的地步。也许随着测试生态的完善，以及定理证明器与代码的结合，我们正在接近这个目标；但归根结底，即使在那个应许之地，我们也永远需要审查我们陈述的意图。所以，我们先达成共识：短期内，我们还需要*某种*人工审查。 6. *实际上不，让 AI 来审查*：自然，我们可以让 AI 进行它自己的审查。务实地看，这可能非常有效，尤其是在捕获遗漏、bug、安全问题等方面。但我认为，为了获得对“你要求的东西确实被正确执行了”的某种确定性，我们仍然需要一些监督。 那么，让我们来看看一个古老的想法，它仍然可以与上述任何方法兼容——只要我们愿意。 ### 一个古老的想法：创建堆叠分支 我并不是在这里发明堆叠分支。很多人喜欢它，有 `jj`（https://docs.jj-vcs.dev/latest/），部分原因就是为了从中获得更多乐趣，还有专注于这个想法的初创公司（https://www.ersc.io/）。 堆叠分支的概念很简单： - 想想你做的那个大块工作， - 把它分解成（连贯的）小块（每个小块可能单独通过 CI）， - 每个小块创建一个分支， - 每个分支依赖于前一个：1 ← 2 ← 3 ← ... - 按顺序将它们作为 PR 提交 现在，每个连贯的改动都可以单独阅读；它们可以按顺序合并，一切都会很好。 你可以在这里（https://gist.github.com/thoughtpolice/9c45287550a56b2047c6311fbadebed2）了解更多。 ### 新的工作流程 手动维护堆叠分支有点烦人。你可以用 `jj`；但那样你就得学会用 `jj`，说服团队里的每个人也学，而且*还是*要手动做一些繁琐的工作。 或者，你可以尝试预测你可能做出的所有改动，创建单独的分支，然后不停地切换。这当然极其不便和烦人。 但幸运的是，*从单个大分支创建*堆叠分支是相当机械的、无聊的、容易描述的……这正是你的 AI 工具的绝佳用例！ 因此，新的工作流程很简单： 1. 创建一个分支（`some-performance-work`）， 2. 随意修改， 3. 向你的 AI 提问，比如：> 你能把这个工作重新组织成一系列堆叠的 PR 吗？尝试把所有改动归成 4-5 个块，然后基于这些块创建分支。请把分支编号为 `some-performance-work-1` 这样的格式。 4. 推送所有分支并创建 PR。 5. 沉浸在简单审查的快乐中。 我稍微实验了一下，效果相当不错！注意，在我的特定工作流程中，我会等到整个工作完成后再进行拆分。在开始之前就拆分需要更多 `jj` 的琐碎操作，目前我还不愿意深入。 ### 未解决的问题和缺点 以下是一些未解决的问题、缺点和小贴士。 - GitHub 的 UI 对于堆叠 PR 很烦人：它们应该像当年 Gmail 的邮件线程一样把 PR 串起来。这样会好得多。其他版本控制公司在这方面有很大的改进空间，能让整个体验愉快得多。 - CI 可能会非常烦人/浪费/缓慢：取决于你做什么，你可能会在这种风格下意外浪费数小时用于重建。应该花点时间考虑这个问题。（广告：实际上，我认为这是一个有趣的开放研究领域，如果你为此困扰或想进一步讨论，欢迎通过 Invariant.Club（https://invariant.club/）联系我！） - 原子化堆叠：也许你不应该让第一个分支直接合并到 `main`，而应该让它指向某个基于 `main` 的 `xxx-stacked` *新*分支，这样你就可以在过程中进行一些最终的重组。否则，你往往需要*基本上同时合并*堆叠分支集合的*每一步*，因为你希望保持连贯性，而这些东西通常只有在*所有步骤都完成*时才连贯；也就是说，如果你在一个 5 步堆叠中合并了第 1-4 步，但拒绝了第 5 步，你*真的需要*前面所有步骤吗？指向一个新分支给了你一些灵活性。这也给了你一个清晰最终的 PR 历史，展示改动前后的好处；这取决于你如何合并，否则可能不会得到。此外，你可能还想保护你的合并堆栈队列，防止在合并堆栈期间被其他不相关的 `main` 分支合并打断。 - 事后拆分更容易：我个人觉得从一开始就做这件事很难。实际上有人可能会说，如果我能从一开始就做，那我早就已经分开提交 PR 了！ - 也许学学 `jj`，也许不学。如果你想更深入地使用这种模式，掌握 `jj` 可能非常有用。但不要因为*没有*掌握它而阻碍你现在就获益。 - 可能还需要一些工作来提升 AI 工具的能力，使其更连贯地管理一组大致独立的分支。例如，通常使用 git worktree 隔离独立修改很容易；但 worktree 是 1:1 对应分支的；现在我们有可能是 1:多，这就需要更多的细心和关注。 ### 结论 总的来说，在 AI 辅助工作分区以实现高效审查和编译这个领域，还有广阔的世界有待探索。期待看到这个领域有更多的工作！