Tessl把代码审查标准写进自家仓库：每周1200个智能体PR，约75%不再经人工合并

Tessl工程团队让大部分由智能体编写的拉取请求不再需要人工介入即可合并，审查环节从瓶颈变成可自行调节的流程。 此前团队使用另一个AI审查器，其约三分之一的问题并非真实缺陷，工程师不得不反过来审查审查器，逐条核对问题与修复，而且无法按自家标准调整它。 在单一仓库上为期一周的并排对比中，两个审查器共提出约1850条问题，Tessl Code Review的问题有91%是真实缺陷，此前审查器为68%，每周因此少掉约435条需要人工阅读并驳回的误报。

审查器按团队自己写给智能体的标准检查每个PR，包括编码约定、设计系统和AI代码审查策略，团队因此能看清某条问题为何被提出并修改检查内容。 此前的AI审查器对所有仓库套用同一套通用规则，无法判断某处改动是否违反了本仓库特有的规则。 在带人工标注缺陷的外部第三方基准上，两个审查器打平；在本仓库上，拥有自家标准的Tessl Code Review找到更多真实缺陷、误报远少，并在AI代码审查策略要求必须人工检查的全部六类改动上领先，隐私类问题为27对4，访问控制类为94对34。

团队把反复出现的同类问题固化成验证器，即每次改动都运行的通过或失败检查，从而自行补齐审查器的短板。 使用此前的AI审查器时，补齐这类缺口需要等待供应商。 默认设置下每轮审查固定50 credits，团队PR平均2.2轮，因此每个PR的审查成本比此前低约35%；若更换模型、投入程度或审查透镜数量，则按实际使用的AI credits付费，每轮最低50 credits。

报告面向在自有仓库上运行智能体、且审查成本随PR数量上升的工程团队。所展示的范围是Tessl单一仓库上为期一周、超过600个PR的并排对比，以及一个带人工标注缺陷的外部第三方基准；真实缺陷被限定为会在生产中出错的问题，如错误行为、契约破坏、数据丢失、安全漏洞、崩溃或泄漏，风格、命名和偏好不计入。团队表示下一步将按计划挖掘代码审查数据，向智能体使用的上下文提出更新建议，使一次审查的经验在下一个智能体写代码前到达，并称结果出来后会分享。

作者说明存在取舍：此前的AI审查器在低严重度问题和外观类问题上更强，并且在本仓库上抓到了一些Tessl Code Review漏掉的缺陷，团队之所以切换，是因为这些缺口可以自己通过更新审查透镜、标准或设置来补上。报告还提到8.5%的PR经过五轮以上审查，这些PR占用了47.4%的审查循环支出，其中约七分之一的重跑由合并冲突触发，而这些重跑有三分之二没有发现新问题。文中若干测量口径仍标注为待确认，包括并排对比的日期、约75%这一比例的起始日期、每周PR数量以及2.2轮平均值所覆盖的时段。