抓住代码审查漏掉的 Bug｜Killian Carlsen-Phelan 与 Taylor Luttrell-Williams，Sonar

趁大家配置的时候，我想问问现场：有多少人已经在 CI 流程里使用 AI 代码审查工具？看起来不少，这正是我们想看到的。无论你现在有没有用，希望今天的内容都能给你一些帮助。大家登录并开通试用时，我们再多留一分钟。

接下来还有一个二维码。我保证今天的演示不全是二维码，不过这个很重要：它会带你们进入我们专门准备的 GitHub 工作坊仓库，让大家能运行 Gitar。这个项目会用来展示 Gitar 的一些强大能力，稍后 Killian 会带大家走一遍。先说明一下，今天所有操作都在浏览器里完成，不需要配置本地工具或安装开发环境；只要有 GitHub 账号，并能访问 Gitar，就可以跟着做。

简单说一下今天的安排：我们会把 Gitar 安装为 GitHub 应用，然后用它处理几个不同的 Pull Request 场景。演示准备了三个案例，展示 Gitar 的验证能力如何超越单纯的代码审查。即使你不太懂技术也没关系，工作坊对初学者很友好。我们先从开箱即用的验证功能开始，再逐步介绍进阶能力；还会创建项目专属配置，让 Gitar 学会遵守你们项目的惯例。最后会诊断 CI 失败，并演示如何直接在 PR 上自动修复。

跟着 Gitar 和这个仓库完成工作坊后，你会安装好 Gitar，完成三个经过验证的 PR，也会实际了解验证指令、仓库规则、CI 故障分析等内容。希望大家现在都已经登录 GitHub 并设置好 Gitar 了。先别急着 fork 仓库，Killian 接下来会带大家按这次演示的配置步骤来操作。

智能体生成代码的速度已经快到人很难逐一检查，随之出现了几个严重问题。第一，代码审查成了明显的瓶颈。团队人数固定，AI 智能体提交的改动却越来越多；审查队列不断变长，PR 等着合并却无人处理。审查几乎成了一份没人想做、也没有时间和资源去做的苦差事。

第二，生产事故也在增加。变化越快，事故越多。编程智能体不一定遵守团队花了很多时间设计的项目架构、公司或组织的编码规范，也不了解你们定下的各种准则。它们缺少这些背景信息。要是不解决这些问题，编程智能体带来的进步可能反而会被抵消。我们需要一种比人手操作更快、审查质量也胜过人工审查的方式，才能跟上智能体引入改动的速度。接下来我们要介绍的就是……

Gitar 会持续迭代，直到所有改动都通过 CI，确保你能放心发布智能体生成的代码。它还提供专门的分析仪表盘，让你清楚看到审查过程和 CI 情况，从而持续提升代码交付的速度、质量和效率。概括来说，Gitar 面向平台和工程团队，帮助他们以智能体的产量和速度自信地交付代码。它还能理解每次代码变更的上下文和意图，与 SonarQube 相辅相成。

为做到这一点，Gitar 会利用多种上下文来源，给出有根据的修复建议，例如 PR 差异、PR 详情和评论、CI 日志，以及项目专属指令。你也可以在仓库规则里自行编写配置。今天我们会深入介绍其中一些能力。

如果你担心误报带来的噪声，Gitar 的设计重点就是提高信号质量。每个误报都要消耗 token，还可能触发一次带来意外改动的修复尝试。Gitar 不会在已经复杂的审查流程里再添噪声和决策负担，而是会设法把改动推进完成，同时验证并修复问题，尽量不让你亲自处理这些琐事。

大体上，PR 一旦创建，Gitar 的审查引擎就会启动，调用刚才提到的各种上下文，生成发现和修复建议，并直接贴到 PR 上，作为可操作的指导供你评论互动；如果启用了自动化，也可以自动修复并合并。接下来我把时间交给 Killian，由他带大家进入动手环节。有问题或遇到阻碍，随时举手叫我；我会在房间里走动，可以帮大家解决问题。谢谢。

第二步是打开工作坊仓库：github.com/sonarsamples/aie-new-york-workshop-guitar，也可以在 Repositories 标签里找到。先 fork 这个仓库，并确保仓库所有者是你安装了 Gitar 应用的那个组织。仓库名称可以沿用原名，也可以随便起，比如 test run。最重要的是不要勾选“只复制 main 分支”：不同练习放在不同分支里，只复制 main 就拿不到那些练习。然后点击创建 fork。

完成后打开 Actions。GitHub 默认会禁用 fork 仓库里的工作流，为了进行后面的自动合并和审批等操作，需要启用它们。最后，如果要让 Gitar 读取这个 fork，可以打开 Gitar 控制台，进入 Settings、Configurations、Repositories，应该就能看到你的仓库。

我们现在要为仓库里的三个分支分别开 PR。Gitar 每次运行可能要几分钟，与其等一个审查完再开下一个，不如一次都开好，然后逐个看。注意把目标仓库设成你自己的 fork。我刚才不小心回到了上游仓库，不过这里可以切回来，再点击 New pull request。

目标要选你自己的运行仓库，然后依次选择 stage one、stage two、stage three，再创建 PR。再检查一遍，确保 PR 是针对你的 fork 发起的，不是上游仓库。现在三个 PR 都应该已经在跑了，Gitar 正在逐一审查；等待期间我们先点进去看看。

趁 Gitar 还在审查，我想指出它的分析方式和传统静态分析工具不一样。像 SonarQube 这样的静态分析非常重要，能发现 SQL 注入之类的安全问题；即使要跨越二十个文件和函数，它也能在数据进入数据库前把问题找出来。但它无法从代码中推断意图。它不会结合你的描述、标题和现有代码，判断新功能的业务逻辑是否合理。所以我们需要把两类能力结合起来，才能把应用验证完整。随着代码数量和速度一起增长，我们必须确保代码得到充分验证，否则服务中断和故障几乎不可避免。

回到 PR，Gitar 已经给出一条发现。它发现问题时，会在相关代码行下评论，也会发布包含全部发现、说明和修复建议的代码审查，并给出整体摘要。这里指出：购票人把票转出去之后，仍然可以退款并作废这张票。也就是说，我买了票并转给别人后，如果取消原来的订单，朋友手里的票也会被取消。这是一个没有考虑到的边界情况。原本有个测试会检查“票已作废时不能转让”，但没有覆盖反过来的情况。

Gitar 还指出问题实际上在原有的 `orders.py` 订单文件里。如果审查者只看 PR 差异，不一定看得出新代码有什么问题；你得了解应用原有的取消流程，才知道这次改动破坏了什么。智能体编程越多，这类问题就越严重：应用的复杂度不断增加，要跟上编码速度、记住每个函数的工作方式几乎不可能。像 Gitar 这样的审查工具就很有必要，因为它会把新功能和现有功能对照，即使问题没有直接出现在 PR 差异里也能发现。

Gitar 正在处理这个额外修复，最后会在 `orders.py` 里增加校验。整个过程只要几分钟，它把故障诊断、再次提交、修复和每次提交后的验证都自动化了。

我非常坚持一点：我们不能发布未经验证的代码。这件事至关重要。每个 PR 都需要结合上下文进行验证，既要有确定性的检查，也要能从逻辑上理解改动到底做了什么。

修复提交落地后，PR 会更新，我们能在文件变更差异里看到它。Gitar 会分析并确认工作流变绿，之后应该就可以合并了。我先快速转到第二个 PR，接下来讲讲上下文。

这个 PR 要给每张票加收 3.50 美元服务费。买一张 50 美元的演出票，最后要付 53.50 美元。但这个虚构公司的规则是：展示给客户的每个价格都必须是含全部费用的总价。不知道你们怎么想，我买票时最受不了的就是先看到 30 美元，最后加上各种费用变成 70 美元。这家公司很重视用户体验，所以他们定了这条规则。那怎么让代码审查智能体也遵守它呢？

可以通过两种方式配置。一种是 `.gitar/review` 目录：你可以把需要的上下文、业务逻辑写进任意数量的 Markdown 文件，Gitar 会据此调整审查。这个能力很强，大家可以自己试着给它提供尽可能多的上下文；Gitar 能高效地读取并应用这些信息。

另一种是 `.gitar/rules` 目录，里面的规则可以在 PR 满足某些条件时触发相应动作。我经常设置这类规则。比如每次定价文件有改动时，就列出所有面向客户的字段，并告知审查者这些价格是否都是含全部费用的总价。规则还能做很多事。比如你和另一位工程师在 Slack 讨论了新功能，可以设一条规则：只要 PR 描述里贴了 Slack 链接，就去读那段对话，再根据讨论内容检查代码。每次都能自动触发，我很喜欢这个能力。

往下看，差点提前给大家剧透 Gitar 找到的问题了。这里新增了服务费和一些测试。回到 PR 讨论，Gitar 已经发了代码审查，并应用了规则。它检查这些定价字段，告诉你哪些价格是总价、哪些不是，并发现了问题。这并不一定是狭义的工程错误：如果你只是一个脱离业务背景、技术能力顶尖的程序员，这么写未必错；但对于具体业务和使用场景来说，这未必符合预期。Gitar 可以按照业务规则检查代码，这很有用。这个 PR 我们暂时不会合并，先留着，再进入第三个练习。

先到 Rules 页面往下滚，点击 Allow auto merge，这会启用 GitHub 的自动合并设置。然后进入 Rule sets，创建新的分支规则集。名称随意，比如“workshop rule”，确保规则集处于启用状态，并且目标是默认分支。需要添加的规则是“要求状态检查通过”。在这里输入 `test`，就会要求 CI 变绿、测试通过之后才允许自动合并。如果刚才漏了步骤，README 里也列出了所有要求。现在创建规则集。像我所在的公司那样配置了 SSO 的话，可能还会要求输入验证码；我这里已经准备好了。

好，规则集建好了。你可能已经看到这个 PR 被挡住了，因为有个测试失败。这个改动重构了门票扫码流程：现在要把票据更新到票务页面 URL，并调整应用里原有的一部分逻辑。但测试没过。点进去看，失败信息是“票不能被重复扫描”。重构漏掉了这项检查。我的票扫一次就应该用完，不能反复扫描、让后面一群朋友都拿同一张票进场。这条规则很基本，但从逻辑上确实容易漏掉。

Gitar 的审查能检查 CI。它指出 CI 失败，并说明有一项测试在检票环节失败：已经使用过的票第二次扫描时却返回了 200。流水线里任何检查失败，Gitar 都能读取日志并尝试修复。

工程师生涯里最烦人的事情之一，就是反复检查测试日志：找出哪里失败、诊断原因、本地修好、推送，然后等流水线重跑。有些流水线很长，等半天又失败，整个过程耗时又烧钱。你可能还得不断催另一位工程师来审查。光想想我就头疼。Gitar 可以把整个过程自动化，持续处理。操作很简单，只要输入……

好，我把它们加上。刷新一下……Gitar 已经动手了，给它点个赞，谢谢。Gitar 会持续迭代、推送修复、验证和检查，最后合并进去，整个过程只要几分钟。

这确实很强大。顺便说一下，刚才我们用评论来设置，是因为在工作坊里我不想让另外两个 PR 自动合并。你也可以在 Gitar 控制台里，为任意仓库单独打开自动批准和自动合并。每个仓库的自动化和审批级别都可以选择。如果你的智能体工作流本身已经有很多防护措施、测试和成熟的流水线，再叠加 Gitar，就可以一开始就让它们自行运转。

我刷新看看。Gitar 还在工作，会继续推送，直到所有内容都完全合并。也鼓励大家回家后继续用这个仓库练习，README 末尾还有一些进阶功能。你们有 14 天专业版试用，可以用在这个仓库，也可以用在自己的仓库，我觉得会很有收获。我们就不让大家一直等着看 Gitar 迭代并自动合并了；接下来交给 Taylor 介绍更多功能。

Gitar 还有更多功能，包括功能验证。正如 Killian 提到的，它会把每个 PR 和对应的工单（例如 Jira 工单）对照，确认改动正确且完整，而不只是代码整洁。目前它可以接入 Jira、Linear，也支持 Slack；可以在 Gitar 控制台的 Settings、Integrations 里连接。比如，你可以引用一条 Slack 消息或 Jira 工单，让 Gitar 更准确地理解并组织审查。

Gitar 还有一个叫 Knowledge 的功能，会从收到的反馈以及你提供的反馈中学习项目惯例和哪些发现属于误报。它甚至会按照审查者的资历给反馈加权，这挺有意思。界面会展示每条审查背后的规则、来源，以及它为什么会被触发。

今天想重点展示两项能力：跨仓库分析和跨 PR 分析。跨仓库分析能发现某个 PR 单独合并看起来没问题，实际上却可能破坏另一个仓库里的代码；它分析的仓库数量没有上限。跨 PR 分析则会把正在进行中的 PR 相互对照。你们可能也遇到过，我肯定遇到过：两个 PR 单独都能通过检查，合在一起却会把生产环境弄坏。随着工作流里增加的智能体越来越多，这种风险也会随之增加。

Killian 正在带大家看控制台，我简单说明一下这两类发现。点开其中一条，你会看到它指出修复方案和问题发生的位置，也会解释这个问题为什么重要，以及为什么可以让 Gitar 来处理。以上就是 Gitar 的概况。希望这些内容对大家有帮助。大家可以回去继续熟悉工具，尝试提供各种上下文，让审查更有依据。部分功能属于企业版；这些功能都会随专业版推出。现在开放提问，谢谢大家。

这是个好问题。Knowledge 到底如何摄取信息，我得再向你确认一下。不过我确实知道，有办法把这些内容接进来；至于能不能直接连到 Knowledge 功能里，我得再跟你核实。