AI 代码审查自动化的前置条件与风险分级

最近，关于 pull request 无需人类参与、就能自动完成审查和部署的讨论很多。这周，我试着回答这个想法留给我的一个问题：哪些 PR 可以这么做？

哪些 PR 可以跳过人工审查

答案取决于两件事：项目已经有哪些防护措施，以及它有多关键。在考虑完全自动化审查之前，我认为项目至少应该具备：

• 如果使用动态类型语言，要有类型检查器；
• linter 和 formatter；
• 认知复杂度和圈复杂度检查；
• 完善的测试金字塔：单元测试、集成测试、组件测试、冒烟测试和端到端测试；
• 结合静态工具和 Agent skills，让代码至少保持基本的组织结构；
• 一条能正常运行、速度也足够快的 CI/CD pipeline。

哪些页面仍然需要编辑把关？

即使具备了这些条件，项目之间也有差异。为了思考服务的关键程度，我借用了服务目录平台 OpsLevel 的 service tiers 分级思路：

• Tier 0：业务关键服务。停机可能导致核心运营中断，需要高可用性和快速恢复能力；
• Tier 1：停机会影响重要的业务流程；
• Tier 2：服务降级会影响次要功能，可以容忍较长的恢复时间；
• Tier 3：内部服务、辅助工具或非关键工作负载，对可用性和支持的要求较低。

Tier 0 和 Tier 1 显然不能采用 100% 自动化的审查和部署。Tier 2，尤其是 Tier 3，则可以这样处理，而不会造成严重后果。出了问题？回滚、修复，然后重新发布。不过，OpsLevel 的分级只描述可用性。一个 bug 不必让服务停机，也可能酿成灾难。因此，我又定义了一套分类，用来衡量错误的影响：

• Tier 0：错误可能造成重大财务损失、泄露敏感数据，或违反法规；
• Tier 1：错误会影响重要的业务流程，但影响有限，或可以恢复；
• Tier 2：错误影响较小，可以修复，不会造成实质性后果。

在具备上述基本防护措施的前提下，我认为，同时属于 OpsLevel Tier 2 或 Tier 3，以及 Error Tier 2 的服务，可以完全自动化审查。其他服务不行。

我喜欢这些分类，因为它们会促使我提出具体的问题。比如，要满足什么条件，我才会放心让一个 OpsLevel Tier 1 服务完全自动化审查和发布？性能测试？性能 benchmark？并发测试？对于大型服务或 monolith，这些问题都会变得难得多。当所有服务都拆分到独立 repository 中时，应用这些分级、决定哪些服务可以自动审查和部署，就容易得多。而在 monolith 内部，尤其是那种没有围绕业务组织模块、结构混乱的 monolith 里——这才是常态——情况就完全不同了。

现代 monolith 就像这座纸牌屋：不知怎么，它居然撑住了。

还有一道防护措施，即使是小型服务也需要：检查与本次变更无关的现有测试，确保它们没有被修改。没有这项检查，一次变更可能通过 CI，仅仅是因为本来能发现问题的测试被改了。也许，测试用例的代码应该始终由人来审查。

用并行 Agent 偿还技术债

这周，我把几个服务升级到了 Django 的长期支持版本。其中一个分两步升级，从 3.2 升到 4.2，再升到 5.2。另一个则直接升到了 5.2。在升级过程中，我发现测试套件存在缺口，于是开始为正在修改的服务补充组件测试。借助 tmux、多个 Claude Code 实例和 git worktrees，同时推进这两件事相当顺手。每个 worktree 都是同一个 repository 的独立 checkout，使用自己的 branch，因此每个 Agent 都有独立的工作目录；tmux 则让所有会话在同一个终端里并排保持打开。一个实例负责升级，另一个编写测试，我在它们之间切换，进行审查。对我来说，这很好地说明了 AI 如何成为偿还技术债、维持系统正常运转的出色工具。现在，这些服务的新版本可以依靠新增的测试，缓解了一部分测试瓶颈。顺便说一句，我对其中一些服务原本了解不多，因此，编写测试也是一种非常有效、富有成效的方式，帮助我理解它们底层是如何运作的。

并行投入，共享成果。

要满足什么条件，才能让 Tier 1 服务安全地进行完全自动化审查和发布？性能测试、benchmark、并发测试，还是其他措施？Canary release 加上 feature switches 和／或 feature flags？

对于没有按业务组织模块的 monolith，你会如何在内部应用这些分级？

即使其他一切都已自动化，测试代码的变更是否仍应始终由人来审查？

看看未来会怎样吧。

如果还想采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。