Tessl：75% 的 PR 已无需人工审查即可合并

作者 @Simon Rendon Arango 和 @Colin Hallett

概览

• 团队：Tessl 工程团队，在一个 monorepo 上运行软件工厂
• 规模：每周超过 1,200 个由 agent 编写的 pull request（PR）
• 挑战：审查每一个由 agent 编写的 PR，既不让工程师淹没在噪音中，也不让审查成本攀升
• 解决方案：Tessl Code Review 基于团队自身的标准运行

关键结果

挑战

Tessl 工程师的大部分工作都通过 agent 完成。正因如此，我们每周的 PR 超过 1,200 个，也正因如此，审查开始拖慢一切。

它还成了我们最大的可变成本。从未合并的 PR 和审查-修复循环占我们 agent 支出的超过一半。

我们之前的 AI 审查器本应分担一部分负载，但我们不信任它。它约三分之一的发现并非真实缺陷，于是工程师最终变成了审查审查器，逐一核查每个发现，再核查每个修复。我们也无法按自己的标准来调整它，所以当它漏掉某些东西或标记了我们并不关心的问题时，我们无能为力。

解决方案

我们需要一个足够可信、能让 PR 无需人工即可合并的审查器。借助 Tessl Code Review，我们在标准审查视角之上编码了我们自己的标准，并设定了与我们所愿承担风险相匹配的审查策略。由于我们拥有这些视角和标准，我们可以看清某个发现为何被提出，并更改审查器检查的内容。正是这种控制力建立了我们的信任，任何使用 Tessl Code Review 的团队都能对自己的仓库拥有同样的控制力。

依据我们自己的标准进行审查

Tessl Code Review 依据我们团队已经为其 agent 编写的标准来检查每个 PR，包括我们的编码规范、设计系统和 AI 代码审查策略。我们之前的 AI 审查器对每个仓库都套用相同的通用规则，因此无法判断某项变更何时违反了针对我们代码库的特定规则。

为了确认我们的标准能够解释这一差距，我们在一个带有人工标注缺陷的外部基准上运行了两个审查器。它们打成了平手。在我们自己的仓库上，Tessl Code Review 有我们的标准可依据，它发现了更多真实缺陷，误报也少得多。

这里有一个取舍。我们之前的 AI 审查器在低严重度发现和表面问题上更强，在我们的仓库上，它还捕获了一些 Tessl Code Review 漏掉的缺陷。我们之所以切换，是因为我们可以通过更新审查视角、标准或设置，自行弥补每一个差距。

当审查器反复标记同一模式时，我们会将其转化为一个验证器，即对每次变更运行的通过或失败检查。而使用之前的 AI 审查器时，弥补一个差距意味着等待供应商。

结果

自我们引入 Tessl Code Review 以来，约 75% 的 PR 在无需人工纠正 agent 或讨论工程问题的情况下合并。由于需要驳回的误报少得多，工程师将审查时间花在真正需要人工的 PR 上。

审查质量

在为期一周的并排对比中，Tessl Code Review 和我们之前的 AI 审查器共提出了约 1,850 条发现。Tessl Code Review 的发现中有 91% 是真实缺陷，而我们之前的 AI 审查器为 68%。这意味着工程师每周需要阅读并驳回的误报减少了约 435 条。

对于只有 Tessl Code Review 标记的 PR，工程师每个 PR 修复了 1.56 个 bug，而我们之前的 AI 审查器为 0.75 个，因此在合并前修复的真实 bug 数量翻了一倍。

Tessl Code Review 在我们的 AI 代码审查政策规定始终需要人工检查的全部六种变更类型上也处于领先。差距最大的是隐私（发现 27 个问题 vs 4 个）和访问控制（94 vs 34）。

这对你的账单意味着什么

在默认设置下，每一轮 Tessl Code Review 固定花费 50 个积分。我们的 PR 平均需要 2.2 轮，因此每个 PR 的审查成本比使用我们之前的 AI 审查器低约 35%。

如果你更改模型、投入程度或审查视角的数量，你需要为使用的 AI 积分付费，每轮最低 50 个积分。我们还根据每个已验证结果的成本而非 token 价格来选择模型，这有助于降低每次审查的成本。阅读我们如何选择模型。

下一步

接下来，我们正在利用审查来直接改进上下文。Tessl 将按计划挖掘代码审查数据，并建议更新你的智能体所使用的上下文，这样一次审查中的经验教训就能在下一个智能体编写代码之前传达给它。我们会在结果出来时分享。

在你自己的仓库上试用

Tessl Code Review 可免费开始使用，每月 1,000 个积分。将它指向一个仓库，看看它能发现什么。[免费试用]

我们如何衡量

• 并排审查：我们在单仓库中对每个 PR 同时运行两个审查器，为期一周，总共超过 600 个 PR。[占位符：确认日期。]
• 真实缺陷：只有当一条发现描述了在生产环境中会出问题的情况时，才被计为真实缺陷：错误行为、契约破坏、数据丢失、安全漏洞、崩溃或泄漏。风格、命名和偏好不计入。
• 已修复：作者在合并前更改了代码以解决该发现。
• 基准：一个外部的第三方数据集，带有由人工标注的缺陷，使用它是为了让两个审查器都没有主场优势。
• 未经人工纠正即合并：一个 PR 在合并时没有人工纠正智能体或讨论工程问题。从引入 Tessl Code Review 开始衡量。[占位符：确认开始日期。]
• PR 数量：整个单仓库中每周由智能体编写的 PR 数量，来自工程师在本地运行智能体以及软件工厂。[占位符：确认每周数字和日期。]
• 审查成本：一轮 Tessl Code Review 的默认价格乘以我们每个 PR 平均 2.2 轮，与我们之前的 AI 审查器每个已审查 PR 的成本进行比较。[占位符：确认 2.2 平均值所涵盖的时期。]

我们在查看结果之前定义了每一个术语。

• 在一个 Swift 应用上，有一个项目将其作为必需检查运行，并使用了自定义审查视角。在单个 PR 上，它提出了 12 条必需发现，其中包括两条 API 密钥标头在 HTTP 重定向中被转发的路径。这是一次凭据泄漏，而且是在我们未曾针对调优的语言和领域中发现的。
• 在一个长期存在的气候科学 Python 包中，维护者解决了 219 个发现中的 216 个，有时还注明了哪个提交修复了哪一个。
• 8.5% 的 PR 经历了超过五轮审查。
• 这些 PR 占用了我们审查循环支出的 47.4%。
• 这些 PR 上大约每七轮中就有一轮是由合并冲突触发的，而这些重新运行中有三分之二没有发现任何新问题。