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

你可能正处于这样一个阶段：你有一整套 agent 在拼命写代码，速度之快，人类根本别指望能真正读懂。这些小弟在表现良好时非常出色，但那一堆 PR 里总有可能藏着某个 bug，会在周五下午把生产环境搞垮。这篇博客将展示如何搭建一个自动审查器，它会阅读完整的 pull request，找出并准确告诉你哪里有问题，并且要么礼貌地提醒你，要么直接关上合并的大门，而你可以在大约比煮一杯咖啡还短的时间内让整套东西跑起来。

为什么我需要这个？

你的 agent 交付代码的速度，让你的审查流程显得像是为一个已不复存在的世界悄悄设计的。过去，当一个人对每一行都反复琢磨时，逐 diff 的人工审查运转得很好，但一旦你团队里有一半是硅基的、而且从不疲倦，这套做法就崩了。

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

如果你想知道我们为什么如此倚重上下文，我们在之前的一篇文章里写过。简而言之，你的审查标准以你拥有的 skill 形式存在于你的仓库中，而不是被锁在别人的黑盒里，因此审查器学到的每一课也能回流到你 agent 编写和维护代码的方式中。这使得代码审查成为迈向 Context-Driven Factory 的自然第一步——在那里，同一份上下文引导你 agent 所做的一切，而不仅仅是最后那道检查。

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

第一步，给自己弄一个免费的 Tessl 账户

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

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

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

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

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

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

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

第一个决定是审查何时运行。默认选项 When opened or requested 会在拉取请求被打开或标记为就绪时启动审查，并在有人明确要求审查时再次启动。如果你想要一个持续关注每次变更的审查者，请选择 After every update，它还会审查拉取请求的每次新推送，这对于代码变更速度快到无人能跟上的、以智能体为主的仓库来说非常合适。

第二个决定是审查者可以对其发现采取什么操作。Comment only 是默认选项，也是温和的选项，它会发布发现而不批准或阻止任何内容，因此审查者就像那位留下深思熟虑的备注然后悄然离开的同事。Approve or request changes 则让它有了实权，在满意时批准拉取请求，在不满意时请求更改，这就是我们之前向你承诺的门口保安。

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

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

第五步，打开一个拉取请求，看看会返回什么

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

当你推送修复后，下一轮会进行并解决当前 head 实际已修复其发现的讨论串，先对它们进行回复，因此拉取请求上仍然开放的只有那些仍需要人工查看和思考的内容。被反驳或拒绝的发现会保持开放，由作者关闭，这正是应该的，因为机器不能单方面决定它是错的。而且每一轮发布都会以同样友好的话语结束，即你可以提及 @tessl-code-review 来运行另一次审查。

第六步，修复发现

一旦发现呈现在你面前，有两条路径，两者都完全值得尊重。你可以自己修复、推送，然后看着下一轮悄然关闭你已解决的所有内容。或者你可以将整个审查直接交回给你的智能体，特别是如果你在工厂环境中运行。这些发现结构清晰且足够具体，智能体可以逐一处理、推送修复，并让你重新审查结果。其中一种涉及你打字，另一种涉及你监督，我让你猜我先选哪个。

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

你不必仅仅为了再看一次而苦等新的提交。在拉取请求的任何位置留下一条评论说 @tessl-code-review，它就会立即在那里启动新一轮审查。这在讨论推进了事情之后，或者当你更改了审查者确实应该在任何人合并之前再次查看的内容时，非常方便。

接下来是什么

这篇文章带你从零开始搭建一个可用的审查器，但这其实只是开场。在后续文章中，我们将深入探讨代码审查在就位之后还能做些什么，包括 Tessl Verifiers、安全漏洞修复，以及能够迭代你的上下文、让审查器在每次运行中变得更敏锐的反馈循环。请关注博客，或者更好的是，现在就设置好你的第一个仓库，这样你就能准备好从我们停下的地方继续。

亲自试一试

创建你的免费账户，并在你自己的仓库上运行此流程。拥有 Tessl 账户后，连接一个仓库，让你的 agent 处理设置并打开一个拉取请求，你的咖啡还没凉，你就能拥有一个可用的审查器。如果它在第一个 PR 上就发现了严重问题——而且经常如此——你会想知道没有它你是怎么发布代码的。

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