在软件开发团队里，Code Review 是非常重要的一个质量保障环境。好的 Code Review 能促进团队成长，差的 Code Review 形同流水。而在有了 LLM 之后，事情又发生了一些微妙的变化：

• 随着代码产量上升，需要 review 的代码越多。
• 大量未经仔细阅读的 AI 代码。即由 GitHub Copilot、ChatGPT 生成的可以 work的代码，可能没有经过他的 pair （人类）进行过仔细的 review。
• LLM 也可以帮我们 review 代码了。

过去，一个小规模（6 人）左右的开发团队，平均每天得花费 30 分钟在代码检视上（CodeReview）。所以，不管，从提效的角度来说，还是从未来需要更多的代码检视时间，改善 Code review 迫在眉睫。

TL；DR 版本：

• AutoDev 插件更新到 1.3.0 即可体验初步版本的 Code Review
• 使用 DevOpsGenius 即可体验工具测：https://github.com/unit-mesh/devops-genius

思考：为什么 Code Review 需要协同组合？

首先，让我们来回顾一下：什么是好的技术实践 —— 诸如于如何写好提交信息？

1. 需求关联代码变更！

在编写提交信息里，又或者在 DevOps 标准化初中，业内的最佳实践是：保持提交信息与用户故事、需求的关联。

诸如于，我们使用的是 JIRA 工具里，需要结合 JIRA ID 在提交信息里；使用的是 GitHub 时，则使用 # + issue id 的形式，如下所示：feat(devops): init first review command #8 。基于此，我们来将需求信息与代码变更保持一致，方便于回顾。

问题来了，如果开发人员不愿意写好提交信息怎么办？—— 自然是用 AIGC 来自动生成了。

2. AIGC 不能取代质量管理工具！

了解完 AIGC 的基本原理之后，大部分人会关注 AIGC 生成代码的安全性问题。而对于代码的安全性问题，在没有 AIGC 之前，我们会采用 Sonarqube、JavaLint、ArchGuard、Feakin 等工具来监控、改进系统的代码、架构质量等等。

考虑到 AIGC 是受 prompt 影响结果的，并且在长 prompt 下如何失焦，所以在可靠性上不如静态代码分析来得稳定。

3. 我们关心的是业务还是代码问题？

事实上，根据不同的 Code Review 形式，诸如于时间（每日、每周、每次发布）、节点（发布前），每个人会关注的内容是有非常大差异的。诸如于，当我处在团队的不同阶段时：

• 初级开发，关注于是不是符合代码规范，即其他人的改进意见。
• 中级开发，关注于~~能不能按时下班~~ 。
• 高级开发，关注于其他人写的合不合理，是否偏离业务。
• 技术负责人，在 review 的同时，关注于是否会影响整体进度 —— 诸如于是否能按时完成。

所以，从 review 的内容来看，主要会关注于业务和技术两部分。而不同的人所关注的是不一样的，该交由传统工具的部分，还是应该交由传统工具。

设计：AIGC 辅助的 Code Review

在使用 AIGC 辅助 Code Review 上，网上已经有各种五花八门的解决方案，我们也只是其中的一种方案。

门槛：良好的代码提交实践

回到先前我们在构建 AutoDev 的经验上，对于 Code Review 来时，难点并非在于 Review 点的设计，而在于如何处理上下文。与其他的领域不同的是，如果采用的不是小步提交的方式，那么在 review 时难点很大。

简单来说：如果代码提交实践做不好，那么 AIGC 的 Code review 会非常鸡肋。过于发散的意图，使得我们无法关注到每一个小点。

模拟真实 Code Review 设计

在设计我们的工具时，大致分析了网上的各类 prompt。为此，我们发现 prompt 并不是难点，结合 AIGC 进行 Code Review 的难点在于：如何模拟真实的 Code Review。只有了解、深入真正的 Code Review 实践，那么我们才能设计出好的工具。

在日常的 Code Review 中，首先，我们需要知道对应的业务背景；其次，忽略大量无关的非代码变更，诸如文档更新、测试数据更新等等；最后，如果变更复杂的场景，则跳过 patch，直接查看代码。

基于此，我们构建了 Code Review 的 Prompt 演进路线。第一个版本则比较简单，即围绕于优化 prompt 长度来包含更多的上下文：

• 结合 DevOps 平台获取业务信息。
• 过滤非必要的文件。
• 过滤 patch 中非必要的内容。
• 优化生成的结果。

即通过实践 + 配置化的方式，来突出重点、核心的内容，而忽略无关紧要的东西。

实现： AutoDev + DevOpsGenius

不论是在 IDE 端，还是在平台端，在当前的第一个版本里，两个处理逻辑都是相似的。主要过程如下（由 ChatGPT 生成）：

1. 获取提交消息：从版本控制系统中获取一系列提交消息。
2. 解析提交消息：将提交消息解析成可处理的格式。
3. 筛选需要审查的提交：根据一些条件，决定哪些提交需要进行代码审查。
4. 获取相关用户故事信息：提取提交消息中的问题标识，然后获取相关的用户故事标题。
5. 生成差异内容：生成提交之间的差异内容以进行审查。
6. 发送审查请求：向审查工具发送审查请求并等待审查结果。

比较大的差异是两个 Prompt 是针对不同场景下的，IDE 是针对于开发人员想知道业务变化，而平台端则是对语法等进行检查。

Prompt 设计

先看 Prompt 中的上下文（PS：更详细可以阅读代码中的 simple-review.open-ai.vm 模板文件）。

.....

Business Context: ${context.businessContext}

Commit Message: ${context.fullMessage}

Code Changes: ${context.changes}

简单来说：

• Business Context 是指从看板、需求系统中获取的业务上下文。
• Commit Message 是指用户编写的提交信息。
• Code Changes 则是根据提交之前的 patch 文件。

需要注意的是：由于大部分编码大模型语料和数据中都是基于 patch 来进行训练的，所以它的效果会比较好。所以，需要根据不同的模型来选择，理想的 changes 形式。

结合提交信息与过滤配置

如下是 Conventional Commits 进行的提交格式示例：

<type>[optional scope］：<subject>

[optional description]
[optional footer（s）］

从中解析出我们所需要的 type、references 等信息，作为过滤条件的一部分：

// 从配置文件中读取，并过滤掉不需要 review 的 commit，诸如 chore、ci, docs 等
// 如果没有配置，则全部需要 review
val filterCommits = parsedMsgs.filter {
    if (it.meta.containsKey("type")) {
        val type = it.meta["type"] as String
        project.commitLog?.isIgnoreType(type) ?: true
    } else {
        true
    }
}

进而只呈现关键的上下文，减少 prompt 长度。更详细的可以阅读 AutoDev 和 DevOps Genius 的代码和文档：https://devops.unitmesh.cc/code-review 。

IDE 与 DevOpsGenius 平台中的 Prompt 差异

在结合 IDE 的 Code Review 里，我们往往会选择自己的多次提交，来讲解对应的业务功能、实现等等。而这也意味着，在 IDE 的场景下，让 AI 来 summary 更容易超出上下文限制。所以，需要添加更多的 review 方式来支持。

而在平台上时，更适合结合单次提交或者 Pull Request 的方式来进行。尽管，如此，但是在基本的 patch 优化上都是相似的策略。

不足之处

事实上，如果你参与到真正的团队 review 里，会发现哪怕是同一个部门下，不同团队的 Code Review 方式，以及其所关注的点是不一样的。如何有机结合关注点与 prompt 进行整合，是我们下一步需要考虑的。

未来：演进

结合 LLM 重塑软件开发中的 DevOps 实践，并不是一件简单事情，如果你有兴趣，欢迎来一起探索：https://github.com/unit-mesh/devops-genius 。