--- id: "wP3P89YB9fA" title: "抓住代码审查漏掉的 Bug｜Killian Carlsen-Phelan 与 Taylor Luttrell-Williams，Sonar" channel: "AI Engineer" host: ["Taylor Luttrell-Williams"] guests: ["Killian Carlsen-Phelan"] date: "2026-10-29" updated: "2026-10-30" duration: "38:07" duration_seconds: 2287 source_type: "youtube" youtube: "https://www.youtube.com/watch?v=wP3P89YB9fA" canonical: "https://pod-exp.pages.dev/wP3P89YB9fA/" transcript_jsonl: "https://pod-exp.pages.dev/wP3P89YB9fA/transcript.jsonl" language: "zh-CN" translation: true translated_from: "en" timestamp_precision: "block" topics: ["AI 编程","AI 智能体","企业软件"] series: ["AI 软件工程师"] --- # 抓住代码审查漏掉的 Bug｜Killian Carlsen-Phelan 与 Taylor Luttrell-Williams，Sonar > 中文译文，由英文原音字幕翻译整理，不是官方逐字稿；引用原话请核对英文原视频。说话人标签由整理者依上下文标注，带「未确认 / 未标注 / 不确定」等字样的标签不可靠。时间戳一般为块级（所在时间块的起点），不是逐句时间；正文自带 [hh:mm:ss] 的段落除外。 **内容提要：** Sonar 的 Taylor Luttrell-Williams 与 Killian Carlsen-Phelan 通过售票应用 Box Office 演示 Gitar 如何验证 AI 智能体生成的代码。他们先展示一个藏在 PR 差异之外的业务逻辑漏洞：买家把票转给朋友后仍能退款，导致朋友的票也被作废；随后演示如何用项目级业务规则要求页面展示含全部费用的价格。第三个 PR 重构扫码流程时漏掉重复检票限制，CI 测试因此失败，Gitar 能读取日志、修复并重新验证，直至通过后自动合并。两位还介绍工单功能验证、从反馈学习团队惯例，以及跨仓库和跨 PR 分析。核心观点是，静态分析与理解上下文和业务意图的验证能力互为补充，团队应按仓库配置自动化与审批程度。 ## [0:14] 开场 · YouTube **Taylor Luttrell-Williams：** 我叫 Taylor Luttrell，今天和我一起的是 Killian Carlsen-Phelan。我们在 Sonar 做开发者内容，Sonar 也是 SonarQube 的开发方。今天特别高兴能带大家上手 Gitar，帮你们找出 AI 生成代码里的问题，并在问题进入生产之前把它们真正修好。 ## [0:39] 设置免费试用与工作坊仓库 · YouTube **Taylor Luttrell-Williams：** 开始动手演示前，请看一下房间两侧的屏幕。我们放了二维码和链接，点进去就能开通 Gitar 的专业版 14 天免费试用——强调一下，确实是免费的。如果想跟着工作坊一步步操作，就需要先用上 Gitar。大家可以花一分钟设置一下。 趁大家配置的时候，我想问问现场：有多少人已经在 CI 流程里使用 AI 代码审查工具？看起来不少，这正是我们想看到的。无论你现在有没有用，希望今天的内容都能给你一些帮助。大家登录并开通试用时，我们再多留一分钟。 接下来还有一个二维码。我保证今天的演示不全是二维码，不过这个很重要：它会带你们进入我们专门准备的 GitHub 工作坊仓库，让大家能运行 Gitar。这个项目会用来展示 Gitar 的一些强大能力，稍后 Killian 会带大家走一遍。先说明一下，今天所有操作都在浏览器里完成，不需要配置本地工具或安装开发环境；只要有 GitHub 账号，并能访问 Gitar，就可以跟着做。 简单说一下今天的安排：我们会把 Gitar 安装为 GitHub 应用，然后用它处理几个不同的 Pull Request 场景。演示准备了三个案例，展示 Gitar 的验证能力如何超越单纯的代码审查。即使你不太懂技术也没关系，工作坊对初学者很友好。我们先从开箱即用的验证功能开始，再逐步介绍进阶能力；还会创建项目专属配置，让 Gitar 学会遵守你们项目的惯例。最后会诊断 CI 失败，并演示如何直接在 PR 上自动修复。 跟着 Gitar 和这个仓库完成工作坊后，你会安装好 Gitar，完成三个经过验证的 PR，也会实际了解验证指令、仓库规则、CI 故障分析等内容。希望大家现在都已经登录 GitHub 并设置好 Gitar 了。先别急着 fork 仓库，Killian 接下来会带大家按这次演示的配置步骤来操作。 ## [4:19] 谁来验证智能体写出的代码？ · YouTube **Taylor Luttrell-Williams：** 我想先从一个大家可能都很熟悉、而且挺让人头疼的情况说起。AI 编程智能体写代码的效率非常高，速度快、产量也大。但它们让团队能更快写出更多代码时，我们也应该停下来问一句：智能体交付的代码，究竟由谁或什么来验证？这些代码是否安全、可维护、可靠？它们在实际业务中是否正确，而不只是功能上或技术上能跑通？ 智能体生成代码的速度已经快到人很难逐一检查，随之出现了几个严重问题。第一，代码审查成了明显的瓶颈。团队人数固定，AI 智能体提交的改动却越来越多；审查队列不断变长，PR 等着合并却无人处理。审查几乎成了一份没人想做、也没有时间和资源去做的苦差事。 第二，生产事故也在增加。变化越快，事故越多。编程智能体不一定遵守团队花了很多时间设计的项目架构、公司或组织的编码规范，也不了解你们定下的各种准则。它们缺少这些背景信息。要是不解决这些问题，编程智能体带来的进步可能反而会被抵消。我们需要一种比人手操作更快、审查质量也胜过人工审查的方式，才能跟上智能体引入改动的速度。接下来我们要介绍的就是…… ## [6:46] Gitar 的工作方式 · YouTube **Taylor Luttrell-Williams：** 这就是 Gitar，一个代码变更验证智能体。它有几方面的特点：它的信噪比高，能有效减少误报，从而提高修复率，也降低 token 成本。它还能诊断 CI 失败，区分真实故障、偶发测试噪声和基础设施噪声，并据此修复问题，而且可以自主修复。你可以自行决定自动化程度和参与程度，控制权在你手里。 Gitar 会持续迭代，直到所有改动都通过 CI，确保你能放心发布智能体生成的代码。它还提供专门的分析仪表盘，让你清楚看到审查过程和 CI 情况，从而持续提升代码交付的速度、质量和效率。概括来说，Gitar 面向平台和工程团队，帮助他们以智能体的产量和速度自信地交付代码。它还能理解每次代码变更的上下文和意图，与 SonarQube 相辅相成。 为做到这一点，Gitar 会利用多种上下文来源，给出有根据的修复建议，例如 PR 差异、PR 详情和评论、CI 日志，以及项目专属指令。你也可以在仓库规则里自行编写配置。今天我们会深入介绍其中一些能力。 如果你担心误报带来的噪声，Gitar 的设计重点就是提高信号质量。每个误报都要消耗 token，还可能触发一次带来意外改动的修复尝试。Gitar 不会在已经复杂的审查流程里再添噪声和决策负担，而是会设法把改动推进完成，同时验证并修复问题，尽量不让你亲自处理这些琐事。 大体上，PR 一旦创建，Gitar 的审查引擎就会启动，调用刚才提到的各种上下文，生成发现和修复建议，并直接贴到 PR 上，作为可操作的指导供你评论互动；如果启用了自动化，也可以自动修复并合并。接下来我把时间交给 Killian，由他带大家进入动手环节。有问题或遇到阻碍，随时举手叫我；我会在房间里走动，可以帮大家解决问题。谢谢。 ## [10:30] 动手操作：Fork 仓库 · YouTube **Killian Carlsen-Phelan：** 谢谢 Taylor。大家好，我是 Killian，是 Sonar 的开发者内容工程师。现在开始动手部分。首先像 Taylor 刚才说的，最好先安装好 Gitar 应用。如果还没装，请访问 app.guitar.ai 登录，然后开始安装 GitHub 应用。 第二步是打开工作坊仓库：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，应该就能看到你的仓库。 ## [12:43] Box Office 演示应用 · YouTube **Killian Carlsen-Phelan：** 好，我们开始练习。这是 Box Office，一个虚构的小型演出场馆售票 API。它是个很简单的 Python 项目：`orders.py` 负责购买门票、取消订单和退款；`checkin.py` 处理扫码入场的逻辑，也就是有人扫描二维码后进入演唱会。示例应用很基础，但有一套测试覆盖现有功能，每次打开 PR 都会运行测试。 我们现在要为仓库里的三个分支分别开 PR。Gitar 每次运行可能要几分钟，与其等一个审查完再开下一个，不如一次都开好，然后逐个看。注意把目标仓库设成你自己的 fork。我刚才不小心回到了上游仓库，不过这里可以切回来，再点击 New pull request。 目标要选你自己的运行仓库，然后依次选择 stage one、stage two、stage three，再创建 PR。再检查一遍，确保 PR 是针对你的 fork 发起的，不是上游仓库。现在三个 PR 都应该已经在跑了，Gitar 正在逐一审查；等待期间我们先点进去看看。 ## [15:43] PR 1：差异之外藏着的 Bug · YouTube **Killian Carlsen-Phelan：** 先看第一个 PR。这是 Gitar 开箱即用的审查，没有做任何配置。这个改动新增了购票后把票转给朋友的功能：比如我买了两张票，送给朋友一张，理论上我们俩都能去看演出。代码里做了一些基本校验，比如票不存在、邮箱地址无效或票已作废时，就不允许转票；也为这些情况写了测试。这个 PR 的测试通过了，工作流和 CI 都是绿的。 趁 Gitar 还在审查，我想指出它的分析方式和传统静态分析工具不一样。像 SonarQube 这样的静态分析非常重要，能发现 SQL 注入之类的安全问题；即使要跨越二十个文件和函数，它也能在数据进入数据库前把问题找出来。但它无法从代码中推断意图。它不会结合你的描述、标题和现有代码，判断新功能的业务逻辑是否合理。所以我们需要把两类能力结合起来，才能把应用验证完整。随着代码数量和速度一起增长，我们必须确保代码得到充分验证，否则服务中断和故障几乎不可避免。 回到 PR，Gitar 已经给出一条发现。它发现问题时，会在相关代码行下评论，也会发布包含全部发现、说明和修复建议的代码审查，并给出整体摘要。这里指出：购票人把票转出去之后，仍然可以退款并作废这张票。也就是说，我买了票并转给别人后，如果取消原来的订单，朋友手里的票也会被取消。这是一个没有考虑到的边界情况。原本有个测试会检查“票已作废时不能转让”，但没有覆盖反过来的情况。 Gitar 还指出问题实际上在原有的 `orders.py` 订单文件里。如果审查者只看 PR 差异，不一定看得出新代码有什么问题；你得了解应用原有的取消流程，才知道这次改动破坏了什么。智能体编程越多，这类问题就越严重：应用的复杂度不断增加，要跟上编码速度、记住每个函数的工作方式几乎不可能。像 Gitar 这样的审查工具就很有必要，因为它会把新功能和现有功能对照，即使问题没有直接出现在 PR 差异里也能发现。 ## [19:43] PR 1：差异之外藏着的 Bug（续） · YouTube **Killian Carlsen-Phelan：** 太好了，Gitar 已经发出审查。接下来怎么办？ ## [20:09] 一键修复 · YouTube **Killian Carlsen-Phelan：** 很简单，点击这里的 Apply fix，或者直接评论“Gitar fix”。随后 Gitar 会在 PR 上新增一个提交，继续迭代并重新验证。如果工作流出现副作用，它也会继续处理；每个 PR 不会额外收费，直到最终所有检查都通过。 Gitar 正在处理这个额外修复，最后会在 `orders.py` 里增加校验。整个过程只要几分钟，它把故障诊断、再次提交、修复和每次提交后的验证都自动化了。 我非常坚持一点：我们不能发布未经验证的代码。这件事至关重要。每个 PR 都需要结合上下文进行验证，既要有确定性的检查，也要能从逻辑上理解改动到底做了什么。 修复提交落地后，PR 会更新，我们能在文件变更差异里看到它。Gitar 会分析并确认工作流变绿，之后应该就可以合并了。我先快速转到第二个 PR，接下来讲讲上下文。 ## [22:08] PR 2：教会它你的业务规则 · YouTube **Killian Carlsen-Phelan：** 每个仓库、每个团队都有一些额外规则和业务逻辑，不一定会写进代码里。它们可能只存在于资深工程师的脑子里、Wiki 或 Confluence 页面上。这些业务规则未必关乎代码本身是否正确。 这个 PR 要给每张票加收 3.50 美元服务费。买一张 50 美元的演出票，最后要付 53.50 美元。但这个虚构公司的规则是：展示给客户的每个价格都必须是含全部费用的总价。不知道你们怎么想，我买票时最受不了的就是先看到 30 美元，最后加上各种费用变成 70 美元。这家公司很重视用户体验，所以他们定了这条规则。那怎么让代码审查智能体也遵守它呢？ 可以通过两种方式配置。一种是 `.gitar/review` 目录：你可以把需要的上下文、业务逻辑写进任意数量的 Markdown 文件，Gitar 会据此调整审查。这个能力很强，大家可以自己试着给它提供尽可能多的上下文；Gitar 能高效地读取并应用这些信息。 另一种是 `.gitar/rules` 目录，里面的规则可以在 PR 满足某些条件时触发相应动作。我经常设置这类规则。比如每次定价文件有改动时，就列出所有面向客户的字段，并告知审查者这些价格是否都是含全部费用的总价。规则还能做很多事。比如你和另一位工程师在 Slack 讨论了新功能，可以设一条规则：只要 PR 描述里贴了 Slack 链接，就去读那段对话，再根据讨论内容检查代码。每次都能自动触发，我很喜欢这个能力。 往下看，差点提前给大家剧透 Gitar 找到的问题了。这里新增了服务费和一些测试。回到 PR 讨论，Gitar 已经发了代码审查，并应用了规则。它检查这些定价字段，告诉你哪些价格是总价、哪些不是，并发现了问题。这并不一定是狭义的工程错误：如果你只是一个脱离业务背景、技术能力顶尖的程序员，这么写未必错；但对于具体业务和使用场景来说，这未必符合预期。Gitar 可以按照业务规则检查代码，这很有用。这个 PR 我们暂时不会合并，先留着，再进入第三个练习。 ## [26:11] PR 2：教会它你的业务规则（续） · YouTube **Killian Carlsen-Phelan：** 顺便看一下刚才那个“Gitar fix”。上一个练习的改动已经完整验证，Gitar 批准并修复了它。我们看一下差异：它修改了 `orders.py`，增加了额外检查。 ## [26:36] PR 3：诊断 CI 失败并自动合并 · YouTube **Killian Carlsen-Phelan：** 进入第三个练习。这次我们会开启完整自动化：从 PR 打开那一刻起，对整个流水线进行验证，直到它最终合并。这里需要调整一些设置。想跟着做的话，我很推荐；如果想先看演示、之后再设置，仓库的 README 里有完整说明。 先到 Rules 页面往下滚，点击 Allow auto merge，这会启用 GitHub 的自动合并设置。然后进入 Rule sets，创建新的分支规则集。名称随意，比如“workshop rule”，确保规则集处于启用状态，并且目标是默认分支。需要添加的规则是“要求状态检查通过”。在这里输入 `test`，就会要求 CI 变绿、测试通过之后才允许自动合并。如果刚才漏了步骤，README 里也列出了所有要求。现在创建规则集。像我所在的公司那样配置了 SSO 的话，可能还会要求输入验证码；我这里已经准备好了。 好，规则集建好了。你可能已经看到这个 PR 被挡住了，因为有个测试失败。这个改动重构了门票扫码流程：现在要把票据更新到票务页面 URL，并调整应用里原有的一部分逻辑。但测试没过。点进去看，失败信息是“票不能被重复扫描”。重构漏掉了这项检查。我的票扫一次就应该用完，不能反复扫描、让后面一群朋友都拿同一张票进场。这条规则很基本，但从逻辑上确实容易漏掉。 Gitar 的审查能检查 CI。它指出 CI 失败，并说明有一项测试在检票环节失败：已经使用过的票第二次扫描时却返回了 200。流水线里任何检查失败，Gitar 都能读取日志并尝试修复。 工程师生涯里最烦人的事情之一，就是反复检查测试日志：找出哪里失败、诊断原因、本地修好、推送，然后等流水线重跑。有些流水线很长，等半天又失败，整个过程耗时又烧钱。你可能还得不断催另一位工程师来审查。光想想我就头疼。Gitar 可以把整个过程自动化，持续处理。操作很简单，只要输入…… ## [30:38] PR 3：诊断 CI 失败并自动合并（续） · YouTube **Killian Carlsen-Phelan：** 抱歉，我单手操作。输入“Gitar auto apply on”，然后再输入“Gitar auto merge on”。自动应用会让 Gitar 不用每次都等你点击确认，就能持续推送修复；自动合并则会在它确认没有更多问题、流水线全部通过后，直接替你合并。 好，我把它们加上。刷新一下……Gitar 已经动手了，给它点个赞，谢谢。Gitar 会持续迭代、推送修复、验证和检查，最后合并进去，整个过程只要几分钟。 这确实很强大。顺便说一下，刚才我们用评论来设置，是因为在工作坊里我不想让另外两个 PR 自动合并。你也可以在 Gitar 控制台里，为任意仓库单独打开自动批准和自动合并。每个仓库的自动化和审批级别都可以选择。如果你的智能体工作流本身已经有很多防护措施、测试和成熟的流水线，再叠加 Gitar，就可以一开始就让它们自行运转。 我刷新看看。Gitar 还在工作，会继续推送，直到所有内容都完全合并。也鼓励大家回家后继续用这个仓库练习，README 末尾还有一些进阶功能。你们有 14 天专业版试用，可以用在这个仓库，也可以用在自己的仓库，我觉得会很有收获。我们就不让大家一直等着看 Gitar 迭代并自动合并了；接下来交给 Taylor 介绍更多功能。 ## [33:24] 进阶：跨仓库与跨 PR 分析 · YouTube **Taylor Luttrell-Williams：** 谢谢 Killian 带来精彩的演示。希望大家已经顺利用上 Gitar。我想再补充几个进阶功能。Killian 刚才提过，但完整讲解会超出这场简短工作坊的范围。仓库 README 最下面有“进一步探索”一节，大家可以在工作坊结束后按自己的节奏回去尝试。 Gitar 还有更多功能，包括功能验证。正如 Killian 提到的，它会把每个 PR 和对应的工单（例如 Jira 工单）对照，确认改动正确且完整，而不只是代码整洁。目前它可以接入 Jira、Linear，也支持 Slack；可以在 Gitar 控制台的 Settings、Integrations 里连接。比如，你可以引用一条 Slack 消息或 Jira 工单，让 Gitar 更准确地理解并组织审查。 Gitar 还有一个叫 Knowledge 的功能，会从收到的反馈以及你提供的反馈中学习项目惯例和哪些发现属于误报。它甚至会按照审查者的资历给反馈加权，这挺有意思。界面会展示每条审查背后的规则、来源，以及它为什么会被触发。 今天想重点展示两项能力：跨仓库分析和跨 PR 分析。跨仓库分析能发现某个 PR 单独合并看起来没问题，实际上却可能破坏另一个仓库里的代码；它分析的仓库数量没有上限。跨 PR 分析则会把正在进行中的 PR 相互对照。你们可能也遇到过，我肯定遇到过：两个 PR 单独都能通过检查，合在一起却会把生产环境弄坏。随着工作流里增加的智能体越来越多，这种风险也会随之增加。 Killian 正在带大家看控制台，我简单说明一下这两类发现。点开其中一条，你会看到它指出修复方案和问题发生的位置，也会解释这个问题为什么重要，以及为什么可以让 Gitar 来处理。以上就是 Gitar 的概况。希望这些内容对大家有帮助。大家可以回去继续熟悉工具，尝试提供各种上下文，让审查更有依据。部分功能属于企业版；这些功能都会随专业版推出。现在开放提问，谢谢大家。 ## [36:54] 问答 · YouTube **Taylor Luttrell-Williams：** 大家如果有问题，我们很乐意回答。非常感谢。 **现场提问：** 对，Gitar 支持 MCP 连接，可以通过多种方式接收这类上下文。 **Taylor Luttrell-Williams：** 可以配置你自己的集成。嗯，这听起来和我们说的 Knowledge 能力有点不同，更像是上下文能力：它可以根据架构规范之类的内容来审查代码。我们这里的 Knowledge 标签页，是用来引导 Gitar 自己的审查方式。比如 Gitar 提出审查意见、建议了一种修复方法，你可以告诉它：“我们通常会用这种方式，或者按 XYZ 这样处理。”Gitar 就能记住这些做法，用于之后自己的修复。 这是个好问题。Knowledge 到底如何摄取信息，我得再向你确认一下。不过我确实知道，有办法把这些内容接进来；至于能不能直接连到 Knowledge 功能里，我得再跟你核实。