使用 Gitar 验证拉取请求：超越代码差异

Taylor Luttrell-Williams 介绍自己和 Killian Carlsen-Phelan 是 Sonar 的开发者内容工程师。他们在工作坊中通过一个示例票务项目和三个拉取请求，演示代码更改验证智能体 Gitar。关于工具能力的说法来自供应商的演示。

工作坊使用 14 天试用和一个专门的 GitHub 仓库。讲者说，练习在浏览器中完成，需要 GitHub 账号和 Gitar 应用。他们计划先演示开箱即用的审查，再加入项目特定指令，最后展示 CI 失败分析。

Luttrell-Williams 将问题描述为验证瓶颈。编码智能体可以快速生成更改，但团队仍需判断代码是否安全、可维护、可靠，以及是否符合预期的业务行为。她说，当更改队列增长时，人数固定的审查团队可能难以跟上。

她认为，智能体可能缺少项目特定上下文，因而遗漏现有架构或编码规范。她担心，如果团队不验证结果，更快的产出可能带来更多事故。这些是讲者的观点；工作坊没有提供独立的事故发生率分析。

Luttrell-Williams 将 Gitar 描述为审查拉取请求、诊断 CI 失败并可以建议或应用修复的更改验证智能体。她说，用户可以选择自动化和人工审查的参与程度。她还声称，产品经过调整以减少误报，并能提供分析数据。

根据演示，上下文可以包括拉取请求的代码差异与讨论、CI 日志以及项目特定指令。拉取请求打开时会触发审查，发现和建议更改会发布回请求中。自动修复和合并是可选设置，并不天然保证结果正确。

Carlsen-Phelan 接手实操演示。他说参与者应安装 Gitar 的 GitHub 应用，并将工作坊仓库复刻到安装了该应用的组织中。他强调取消勾选“仅复制主分支”，因为练习需要多个分支。

随后，他在复刻仓库中启用 GitHub Actions，并检查仓库是否出现在 Gitar 配置中。这些设置属于演示的一部分：Actions 和后续合并权限决定了该仓库可以使用哪些自动检查和操作。

示例应用 Box Office 是一个小型 Python 票务 API。Carlsen-Phelan 介绍，orders.py 用于购买和取消门票，checkin.py 用于通过二维码让观众入场。仓库还包含测试，每次打开拉取请求时都会运行。

他在自己的复刻仓库中为三个练习分支打开拉取请求，让审查在他解释场景时并行运行。他提醒参与者将自己的复刻仓库选为目标仓库，避免不小心向上游项目发起请求。

第一个拉取请求增加了将门票转给朋友的功能。它包含对门票不存在、邮箱无效和门票已作废的基本校验，也包含测试。在展示的时刻，测试和 CI 工作流都已通过。

Carlsen-Phelan 比较了静态分析和上下文审查。他说，静态分析可以追踪某些安全问题，而演示中的智能体还会考虑描述、预期行为和现有代码。他认为两种方法互补；这个例子并不能证明任何一种方法可以发现所有缺陷。

Gitar 发布了一个发现：买家可以先转出门票，再取消原订单，导致收票人的门票失效。遗漏的情况与现有测试方向相反：现有测试阻止转出已作废的门票。相关取消逻辑位于现有的 orders.py 文件中，不在当前审查的直接更改里。

演示者解释，只看新增代码差异的审查者可能漏掉这个交互，因为还需要了解现有取消流程的运作方式。他用这个例子说明，随着更改和代码库增长，更广泛的上下文为什么重要。

为请求修复，他展示了“应用修复”控件或一条 Gitar fix 评论。他说智能体会增加一次提交并重新检查更改。稍后的演示中，他展示了 orders.py 中增加的额外校验；工作坊并没有证明每次自动修复都会正确。

第二个拉取请求为每张票增加 3.50 美元的服务费。因此，一张 50 美元的票在结账时需要支付 53.50 美元。虚构企业还有一条规则：向客户展示的每个价格都必须包含必需费用，所以计算即使在技术上能运行，也可能违反产品要求。

Carlsen-Phelan 展示了 .gitar/review 和 .gitar/rules 两个项目配置位置。审查指令可以提供项目上下文，规则则可以定义条件和动作。在这个例子中，定价文件的更改会触发一项检查，将面向客户的价格与全包价格规则比较。

他描述了另一条可能的规则：当拉取请求描述中包含 Slack 链接时，集成可以使用对话作为审查上下文。这是他介绍的产品能力，并不是本文读者需要执行的操作。团队需要配置自己打算使用的集成和权限。

演示中的审查列出定价字段，并指出哪些价格包含费用。它标记活动页面展示的价格不是全包价。Carlsen-Phelan 指出，这属于业务规则不匹配，未必是语法或类型错误。他没有合并第二个练习。

第三个练习演示针对门票扫描更改的可选自动化。演示者启用 GitHub 自动合并，并配置要求状态检查通过的分支规则。想要复现练习的参与者可以在工作坊仓库的说明中找到设置细节。

该拉取请求有一项失败的测试：重构后，已经扫描过的门票可能再次被接受。审查指出了失败的 CI 检查并描述了缺失的保护。Carlsen-Phelan 用它说明，智能体可以检查失败信息，而不只是依赖代码差异。

他发布评论，为演示启用自动应用修复和自动合并。他解释，自动应用允许智能体继续提交修复；自动合并则计划在配置好的流水线通过且智能体没有剩余发现时执行。这些操作取决于仓库设置和实际配置的检查。

演示者说 Gitar 会继续迭代，也可以在仪表板中按仓库选择性配置自动化。录制过程中，他转入下一个环节时工具仍在运行；他对最终合并的预期，不应误认为屏幕已经显示合并完成。

Luttrell-Williams 回来介绍主要练习之外的高级功能。她说，功能验证可以将更改与关联的 Jira 工单比较；配置后，集成还可以从 Jira、Linear 和 Slack 等工具引入上下文。

她介绍了一项知识功能，旨在学习规范并使用审查者反馈，包括对误报的反馈。她说审查者的资历会影响权重，界面也会显示审查规则的来源。这些是讲者对产品的描述，并非经过独立测试的结果。

讲者区分了跨仓库分析和跨拉取请求分析：前者寻找可能破坏另一仓库代码的更改，后者检查各自通过却可能相互作用并造成问题的进行中请求。他们展示了包含发现及其重要性说明的仪表板。

在最后的问答中，讲者说 Gitar 可以通过 MCP 和其他集成获取上下文。他们区分了项目上下文与用于引导未来审查建议的知识；其中一位讲者表示，知识摄取的具体细节需要后续确认。