Tessl Academy 新课：用 Agent 做代码审查循环

代码审查是工作中规模化最难的部分。它需要一位熟悉代码库、有时间、且愿意仔细阅读的人。当 Agent 在编写大部分变更时，那个人在变更耗尽之前早就精疲力竭了。

Simon 昨天在 Tessl Code Review 中介绍了：它是什么、为什么我们选择围绕整个 Pull Request 而不是 Diff 来构建它，以及重新审查如何追踪上一轮已解决的问题。这篇文章回答下一个问题——在安装后大约一小时你就会遇到的问题：你的审查员还不知道你团队的规则，而它有用的版本还不知道。

这就是 Code Review Loops。

npx tessl install tessl-academy/code-review-loops
tessl launch skill --agent tessl-agent -i 01-your-first-code-review

四节课，按顺序，每节课都基于上一节课留下的代码库状态。

第一节代码审查课让你搭建一个小型 TypeScript 服务和一个包含三个故意植入的缺陷的分支，然后对该分支运行三种不同方式的审查，并阅读返回的内容——结果、严重等级、JSON。它还解决了几乎每个人都会遇到的命名冲突：tessl review run 对技能评分，tessl code review 审查你的代码。两条命令都存在，听起来很像，选错一个会浪费五分钟且令人困惑。

这节课植入了三个缺陷；审查员找到了两个。这是故意的——漏掉的那个就是第二节课存在的原因。

编写一个审查镜头从那个缺失的发现开始。Lens 就是一个 Skill：一份 SKILL.md，包含名称、适用场景描述，以及审查指令主体。四个默认 Lens 随 tessl/code-review 插件一起分发，源码是公开的，所以你可以 fork 一个看看它是怎么组织的。你编写一个 Lens 来编码一个只有你们团队才有的规范，让它与默认 Lens 并肩运行，然后在两个方向上测试它——让它在坏案例上触发，在好案例上保持沉默。第二部分正是人们会跳过的部分——那就是 Lens 和噪音生成器的区别。

按路径路由 Lens 将配置从命令行移入仓库中的 YAML 配置文件，用 glob 模式和排除规则让每个 Lens 只在适用规则的地方运行。一个跳过了你文件的审查不是批准了这些文件的审查。

在每个 Pull Request 上运行审查是压轴戏：Token、调用者工作流、锁定到某个提交 SHA 的 Action，先用咨询模式再用门控模式。然后是第二轮，带有一个修复和一个回复，这样你就能看到之前的发现被解决——作为已处理、已解释或已拒绝——而不是再次被提起。

这些是你本来会走弯路才能学到的经验

--skill 会替换配置文件的默认 Lens，而不是添加到它们之中。传入两个就得到两个，不是六个。

一次审查最多接受八个 Lens，它们的顺序会被保留。

Tessl 不会主动寻找你的配置文件。在包含 .tessl-code-review.yml 的仓库中执行裸的 tessl code review 会运行内置的标准配置文件，忽略你的文件。没有什么会因为一个文件出现了就开始用不同方式审查你的代码。

在 CI 中，审查策略来自默认分支，而不是被审查的分支——一个 Pull Request 可以修改仓库中的任何文件，包括决定该 Pull Request 如何被审查的那个文件。

@tessl-code-review 是你工作流匹配的文字，不是某个账号。

第三节课需要比 0.96.0 更新的 CLI，因为 YAML 配置文件在那之后才加入。第一、二、四节课在旧版本上完全正常。

这门课是如何构建的

Academy 的构建方式有些不同寻常，代码审查课程是迄今最清晰的例子。

没有编译课程内容的流水线。课程是由运行一个 Skill 的 Agent 组装起来的，而这些 Skill 才是我们维护的东西。

内容以版本化组件的形式存在：一个用不到 300 词解释的概念、一个实操练习、一个起始代码库状态、一个评分标准。跨越六种类型共有 65 个这些组件，在不同课程和课时中被复用。人类编写决定一个课时使用哪些组件以及按什么顺序的配方。运行 compose-lesson 的 Agent 将那个配方转换成你读到的课时，generate-lesson-skill 将课时转换成可安装的引导式教程，引导你完成它。唯一的确定性步骤是最后一步，那里构建过程将完成的 Markdown 渲染为 HTML。网站本身是静态的，什么都不知道；判断力在上游的 Skill 中。

每个组合的课时都记录了构建它所使用的组件版本。当 CLI 在我们脚下发生变化时，一次维护扫荡会找出受影响的课时而不是我们猜测，并为每个概念写出一份机器可读的判定。只有当课时中的每个概念都有当前的通过状态时，该课时才算通过验证。

这种验证有一个值得说明的局限：通过意味着概念与文档匹配，而不是有人运行过那条命令。一份错误的文档会产生一个自信满满的、正在通过的、错误的课时。我们检查 CLI 漂移，没有别的了，而且扫荡只在人类启动它时才运行。

仓库中的每个 Skill 也必须在发布前以 80% 的分数清除 tessl review run。我们教授这条命令，所以构建教学内容的工具也会被它审查——用审查关闭的状态写一门关于审查的课程会很难看，而且更有用的是，它在我们的 Lens 描述中发现了真正的问题。

课程地址：tessl.io/academy/code-review。去那里阅读，或者安装它并让你的 Agent 引导你完成第一次代码审查，在你自己的仓库中走完整个流程。

如果你学完了，告诉我们你的 Lens 是什么样的——你编码了什么规范，审查员是否捕捉到了它。这是塑造这个项目下一步方向的反馈。在 Discord 找到我们。