北京
一个工程团队每周要处理超过1200个由智能体写出的PR。这个数字本身就够吓人了，但真正让团队头疼的不是写代码，而是审代码。
Tessl的工程团队在一个单体仓库里跑着一套"软件工厂"模式，工程师主要通过智能体完成工作。PR量冲到每周1200个以上之后，评审成了瓶颈，也成了最大的变动成本。那些最终没能合并的PR，加上评审后反复修改的轮次，吃掉了团队智能体开销的一半以上。
他们之前也用过AI评审工具，但不敢信。大约三分之一的发现不是真正的缺陷，工程师最后变成了"评审那个评审者"——先看每条发现，再看每个修复。更麻烦的是，这个工具没法按团队自己的标准来调，漏了什么、误报了什么，都改不了。
于是他们换了个思路：要一个能信任到让PR直接合并、不需要人工介入的评审器。
把团队标准写进评审器
Tessl Code Review的做法是，在通用评审视角之上，把团队自己的标准编码进去，再根据愿意承担的风险设定评审策略。因为团队拥有这些视角和标准，所以能看清一条发现为什么被提出，也能改掉评审器检查什么。这种控制权，是信任的来源。
评审器会对照团队为智能体写的标准来检查每个PR，包括编码规范、设计系统和AI代码评审策略。之前的AI评审器对所有仓库套用同一套通用规则，识别不出某个改动是否违反了团队代码库特有的规则。
为了确认差距确实来自标准，他们在一个带人工标注缺陷的外部基准上跑了两个评审器，结果打平。但在自己的仓库里，有了团队标准的Tessl Code Review找到了更多真实缺陷，误报也少得多。
当然也有取舍。之前的AI评审器在低严重度发现和外观问题上更强，在自己的仓库里也抓到了一些Tessl Code Review漏掉的缺陷。他们选择切换，是因为这些差距可以自己通过更新评审视角、标准或设置来补上。当某个模式被反复标记，团队就把它变成一个验证器——一个每次改动都跑的通过/失败检查。而用之前的工具，补一个缺口得等供应商。
结果：75%的PR无需人工纠正
引入Tessl Code Review之后，大约75%的PR在合并时没有经过人工纠正智能体，也没有人工讨论工程问题。误报大幅减少，工程师把评审时间花在真正需要人看的PR上。
在并排对比的那一周里，两个评审器一共提出了大约1850条发现。Tessl Code Review的发现中91%是真实缺陷，之前的AI评审器是68%。这意味着工程师每周少读、少驳回大约435条误报。
工程师修复了1.56个只有Tessl Code Review标记出的bug（每个PR），之前的AI评审器是0.75个，也就是说合并前修掉的真实bug翻了一倍。
在AI代码评审策略规定"必须人工检查"的全部六类变更上，Tessl Code Review也都领先。差距最大的是隐私（发现27个问题对4个）和访问控制（94对34）。
账单上的变化
默认设置下，每一轮Tessl Code Review花费固定50个积分。他们的PR平均要跑2.2轮，所以每个PR的评审成本比之前用AI评审器时低了大约35%。
如果更换模型、调整投入或评审视角数量，就按实际使用的AI积分付费，每轮最低50积分。他们按"每个已验证结果的成本"来选模型，而不是按token价格，这样能把每次评审的成本压下来。
几个实际案例：在一个Swift应用上，某个项目把它设为必需检查并配了自定义评审视角。在单个PR上，它提出了12条必需修复的发现，其中包括两条API密钥请求头在HTTP重定向中被转发的路径——这是凭证泄露，而且是在团队没有专门调过的语言和领域里抓到的。在一个长期维护的气候科学Python包上，维护者解决了219条发现中的216条，有时还会注明哪个提交修了哪一条。
另外，8.5%的PR经历了超过五轮评审，这些PR占用了评审循环开销的47.4%。这些PR上大约每七轮就有一次是由合并冲突触发的，其中三分之二的重新运行没有发现任何新问题。
下一步，他们打算用评审来直接改进上下文：Tessl会定期挖掘代码评审数据，并建议更新智能体使用的上下文，让一次评审的教训在下一个智能体写代码之前就传达到位。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
