如何在 5 分钟内为仓库添加 Tessl 智能体代码审查

文章

5 分钟内为你的仓库添加智能体代码审查

用 5 分钟学会为你的仓库添加智能体代码审查。通过自动审查在合并前发现问题，提升代码质量。

Simon Maple

·2026 年 10 月 18 日·9 分钟阅读

你可能正处于这样的阶段：你有一整套智能体在拼命写代码，速度之快，任何人类都别指望能真正读懂。这些小家伙在状态好的时候很棒，但那一堆 PR 里总有可能藏着某个 bug，会在周五下午把生产环境搞垮。这篇博客将展示如何搭建一个自动审查器：它会读取完整的 pull request，准确找出并告诉你哪里有问题，然后要么礼貌地提醒你，要么直接关上合并的大门——而整个流程跑起来的时间，大概比你冲一杯咖啡还短。

为什么我需要这个？

你的智能体交付代码的速度，已经远远超出了你那套审查流程当初被悄悄设计时所面对的那个世界。过去，当每个人都会对每一行代码反复斟酌时，逐 diff 的人工审查效果极佳；但一旦你的团队有一半是硅基的、而且从不疲倦，这套做法就立刻崩盘了。

Tessl Code Review 会读取整个 pull request，而不是孤立地盯着 diff 眯眼看，它会按照你们团队定义并真正在意的标准打分，然后发布一份干净的审查结果。你可以决定它是扮演那个留下评论的热心同事，还是扮演拒绝入内的门卫。

如果你想知道我们为什么如此倚重上下文，我们已经在之前的一篇文章中写过。简而言之，你的审查标准以你拥有的技能形式存放在你的仓库里，而不是被锁在别人的黑盒里，因此审查器学到的每一条经验也能反过来影响你的智能体编写和维护代码的方式。这使得代码审查成为迈向上下文驱动工厂（Context-Driven Factory）的自然第一步——在那里，同一份上下文引导着智能体所做的一切，而不仅仅是最后那道检查。

这是一篇真正的从零到精通实战指南，也就是说，当你读到底部时，你已经让它在真实仓库上运行起来，并对一个真实的 pull request 进行把关，而不只是对着示意图点头。

第一步，注册一个免费的 Tessl 账户

前往 Tessl 并登录。进入后，在左侧边栏选择正确的组织，点击 Reviewer，然后点击右侧的 Manage installation。

第二步，安装应用并授予 GitHub 访问权限

这大概就是你做过上百次的熟悉的 GitHub App 授权流程。你授予 Tessl 对组织的访问权限，并选择允许它查看哪些仓库。一开始只授权一个仓库是合理的，因为之后你随时可以扩大范围。

第三步，为某个仓库开启代码审查

在你组织的 Reviewer 页面中，你会看到一张已授权仓库的表格，你可以在这里为每个仓库启用代码审查。点击你新添加仓库的 Turn on 即可开启。

第四步，告诉它你希望如何被审查

你一点击 Turn on，Tessl 就会打开该仓库的 Code Review 设置，你可以在这里决定审查器拥有多大的话语权。只有两个决定要做，对一个设置页面来说这很清爽，而且你随时可以回来改变主意。

第一个决定是审查何时运行。默认选项 When opened or requested会在 pull request 被打开或标记为就绪时启动审查，并在有人明确请求审查时再次启动。如果你想要一个持续监视每次变更的审查器，就改选 After every update ，它还会审查每次推送到 pull request 的新提交，这对于代码变化快到没人跟得上的、智能体密集的仓库来说非常合适。

第二个决定是审查器可以对其发现做什么。 Comment only 是默认选项，也是温和的选项，它只发布发现，不批准也不阻止任何操作，因此审查器就是那位留下一条深思熟虑的备注然后走开的同事。 Approve or request changes 则让它有了牙齿：满意时批准 pull request，不满意时请求修改，这就是我们之前承诺的门卫。

底部还有一个小巧的复选框 Auto-approve after all Tessl threads are resolved，它的作用正如其名。一旦审查器开启的每个讨论串都得到处理，它就会替你批准 pull request，这样就不必有人记得回来给它放行。

如果你修改了默认设置，请务必点击 Save settings ，然后就完成了。值得知道的是，更改只适用于新的审查运行，因此已经审查过的内容会保持原样，而不会被追溯性地改写。

第五步，打开一个 pull request，看看会返回什么

针对该仓库打开一个 PR，Action 就会开始工作。它会解析 pull request，检出确切的 head，运行审查，并发布一份包含发现和严重程度的审查结果，全程无需你盯着。

当你推送修复后，下一轮会运行，并解决当前 head 确实已修复其发现的问题的讨论串，先在这些讨论串上回复，因此 pull request 上仍然未关闭的只有那些仍需要人工查看和思考的内容。被反驳或拒绝的发现会保持开启，由作者来关闭，这正是应该的，因为机器不能单方面决定自己错了。而且每一轮发布的审查都会以同一句友好的话结尾：你可以提及 @tessl-code-review 来再运行一次审查。

第六步，修复发现的问题

当审查结果摆在你面前时，有两条路可走，而且两条都完全值得尊重。你可以自己修复、推送，然后看着下一轮审查悄悄关闭你已解决的所有问题。或者，你可以把整个审查直接交回给你的智能体，尤其是在工厂化流水线中运行时。这些发现结构清晰、足够具体，智能体可以逐条处理、推送修复，然后由你重新审查结果。其中一条需要你动手打字，另一条需要你监督，至于我先选哪条，就留给你猜了。

第七步，按需再次运行审查

你不必干等着新提交才能再看一次。在 pull request 的任何位置留下一条评论，写上 @tessl-code-review ，它就会立刻在那里启动新一轮审查。当讨论已经推进了事情，或者你改动了某些审查者确实应该在任何人合并之前再看一眼的内容时，这非常方便。

接下来是什么

这篇文章带你从零走到一个可用的审查器，但这真的只是开场。在后续文章中，我们会深入探讨代码审查就位后还能做什么，包括 Tessl Verifiers、安全漏洞修复，以及能迭代你的上下文、让审查器每运行一次都更敏锐的反馈循环。请关注博客，或者更好的是，现在就设置好你的第一个仓库，这样我们讲完时你就能直接接着往下做。

自己试一试

创建你的免费账户，并在你自己的仓库上运行这个流程。 一旦你有了 Tessl 账户，连接一个仓库，让你的智能体处理设置并打开一个 pull request，你的咖啡还没凉，一个可用的审查器就已经就绪了。如果它在第一个 PR 上就发现了严重问题——而且经常如此——你会纳闷自己以前没有它时是怎么发布代码的。

查看 Set up Tessl Code Review 文档了解更多信息。

复制并分享

Simon Maple

Simon Maple 是 Tessl 的开发者关系负责人，也是 AI Native Dev 的联合主持人。此前，Simon 曾在 Snyk、ZeroTurnaround 和 IBM 担任 Field CTO 和开发者关系副总裁。他于 2014 年成为 Java Champion，2014 年和 2017 年成为 JavaOne Rockstar 演讲者，获得 Duke's Choice 奖，是 Virtual JUG 的创始人和组织者，以及 London Java Community 的联合负责人。

35 篇文章

阅读

本文内容

为什么我需要这个？第一步，获取一个免费的 Tessl 账户第二步，安装应用并授予 GitHub 访问权限第三步，为某个仓库开启代码审查第四步，告诉它你希望如何被审查第五步，打开一个 pull request，看看会返回什么第六步，修复发现的问题第七步，按需再次运行审查接下来是什么自己试一试

复制并分享

Simon Maple

35 篇文章

你的下一篇阅读