Cole Gannaway：代码审查、跨仓库风险与 AI 软件工厂

我是 Qodo 的解决方案工程师 Cole Gannaway，工作是帮助组织了解产品如何融入他们的工作流程。今天我想讨论以 AI 为先的团队如何构建软件工厂，以及 Qodo 在其中的位置：我们专注于其中一部分，而不是整个工厂。

客户很期待把工单直接推进到生产环境，但不少团队在拉取请求和审查阶段遇到瓶颈。代码生成的问题还没有完全解决，但速度正在迅速提高。审查环节需要为人和智能体提供足够的上下文，才能判断一个改动是否可信。

来看一个使用开源密码管理器 Bitwarden 的示例。开发者重命名了数据模型中的一个字段。改动只有一行，构建、单元测试和代码检查都通过了。它看起来符合需求，因此审查者可能会自然地批准。

但绿色检查标记并不意味着所有下游依赖都经过了检查。现场许多人承认，曾经在没有逐行阅读所有改动的情况下合并拉取请求。我们依赖工具，但不同工具看到的上下文和能够支持的结论并不一样。

这一行重命名可能影响其他仓库中的客户端：网页、移动端、CLI 和 MCP 集成可能都依赖服务器字段。这是用于说明问题的示例，不是在报告 Bitwarden 真实事故。如果忽视这些依赖，问题可能要等到生产环境中的客户端出错才会暴露。

Qodo 提出的方法是构建软件关系图，映射仓库及其集成接口。知道 Android 仓库连接了服务器，不如知道哪些字段和组件跨越了这个边界有用。这些细节可以帮助审查者或审查智能体评估改动的影响范围。

审查知识并不全是功能测试。资深审查者可能会运用组织特有的规则，或从过去错误中积累的判断。与其让同一个人反复成为所有改动的瓶颈，不如把其中一些知识反馈到审查流程。

例如，团队可以为公共 API 的改动制定规则：重命名或移除字段之前先标记弃用，或者要求更严格的审查。目标是让这些标准持续可用，包括提供给智能体，而不是只存在于某个人的记忆里。

相同的上下文应当在提交拉取请求之前，甚至生成代码之前就可用。MCP 服务器可以在编码智能体实现改动时提供仓库知识、依赖信息和自定义规则。这不能保证结果正确，但提供了更早避免错误的机会。

团队有时会问，负责实现的智能体是否也应该审查自己的代码。它掌握有用信息，但同时还在调试、探索代码库和编写代码。上下文窗口变大，并不意味着重要细节不会被淹没，也不意味着智能体不会产生幻觉。

独立的审查智能体可以将上下文集中在审查任务上，并加入本次运行特有的信息。我也希望编写者和审查者相互独立：团队可以更换模型或运行框架，甚至引入对抗式审查者，以减少共同偏差。

如果不同审查者指出同一个问题，这可能是一个有用信号；如果发现的问题完全不同，就值得进一步调查。一致意见并不是证明，独立性也不能消除错误，但比较不同视角可以发现单次审查遗漏的问题。

复盘既能带来组织和流程上的经验，也能带来代码层面的教训。对后者而言，挑战是将个人经验转化为组织能够反复使用的知识，而不是让它停留在私下交流中。

在这个示例中，拉取请求上的评论促使 Qodo 建议一条供后续审查使用的规则。关系图还可以标记一行改动具有较大的下游影响，提醒人类或其他智能体更加仔细地检查。

软件工厂需要正确的上下文、相关标准，以及在拉取请求前和提交时进行的检查。MCP 或 CLI 可以让更早的审查成为可能。在代码生成阶段发现的问题，比合并之后发现的问题更容易处理。

一位观众介绍了自己与智能体一起审查改动，并记录文档以指导下一次运行的做法。另一位观众问，客户是否难以在写代码前传达意图：智能体即便遵循现有上下文，也可能解决错误的问题，或者过度设计方案。

作为回应，我展示了与 Jira 或 Linear 工单的集成。审查可以参考工单验收标准，突出需求与拟议改动之间的缺口。这与代码在语法或功能上是否正确是两个不同的问题：实现是否真正完成了预期任务？

我建议在实现过程中定期运行专门的审查，例如在大约 25%、50% 和 75% 的进度点检查，而不是等到最终拉取请求。审查智能体可以像向导一样，帮助实现智能体在错误方向上走得太远之前调整路线。

审查阶段是 Qodo 在软件工厂中关注的部分：为人和智能体提供代码情报、共享知识以及评估风险所需的上下文。下一步要回答的是，哪些改动可以不经人工检查就安全合并，哪些需要更仔细的审查。影响范围信息可以帮助作出判断。