前几天参加了七牛云 XEngineer 实训营。在第二批次的三个议题中有一道题目很有意思：

题目三：AI PR Review 助手

• 请开发一个AI代码评审工具，帮助开发者提升Pull Request的Review效率与质量。
• 要求：请了解开发者在代码评审中的真实需求，设计并实现一个以 AI 辅助分析为核心的工具。用户指定GitHub PR，系统自动获取代码变更并智能分析，辅助发现问题。需支持PR变更总结、风险代码识别、Review建议生成等。请综合考虑分析准确性、上下文理解、误报与漏报控制、响应速度及使用体验等关键因素，并在作品中说明系统在模型选择、上下文获取方式及未来扩展方向上的设计思路。

刚看到题目的时候，我下意识觉得：这不就是一个 AI Agent 项目吗？读 GitHub 然后调用大模型接着输出 Review 就结束了。后来真正开始做的时候，我才发现，它最难的部分，其实不是生成评论而是理解改动。

第一部分：为什么 PR Review 很难

想象一下：现在有一个 Pull Request。总共改了 37 行代码，但是项目有十万行。如果你是一名开发者，你会怎么做？

大概率是不会把整个项目重新读一遍，而是会直接点开 Diff 然后去查看：

• 改了什么
• 为什么改
• 有没有副作用

所以真正重要的信息并不在代码本身。而在代码变化（Diff）里。这也是 GitHub Pull Request 的核心。

这个结论在最开始我并没有意识到，所以在刚开始做 PR Review 的时候，我下意识会把注意力放在代码整体上。但后来慢慢发现，这种方式其实是低效的。在大多数 PR 里，并不需要重新理解整个系统，而是只需要理解“这一次到底改了什么”

代码审查，本质上不是在理解一个静态系统，而是在理解一次变化：这次改动改变了什么，它可能影响哪里，以及为什么要这样改。如果把整个仓库当成输入，反而会稀释掉这种信息密度。模型会被大量无关上下文干扰，最后只能给出一些泛化的结论。但是把注意力聚焦在 Diff 上时，问题会变得非常清晰了。

这也是我在开发过程中最重要的一个认知转变：从让 AI 看懂代码，变成让 AI 看懂变化。

第二部分：让 AI 看懂 Diff

我尝试过直接把整个 Diff 扔给大模型然后让它去根据 Diff 去提出意见，但是我发现这是一个非常愚蠢的想法。因为只给 Diff 的时候，大模型确实能读懂变化，但它很难理解变化的意义。

问题又绕回来了：如果只给 Diff，上下文不够；如果给整个仓库，上下文又太多。于是我开始意识到，问题的关键不在于给 AI 更多信息，而在于给 AI 更合适的信息。

要实现这一点，我尝试了多种方式，最终发现'上下文压缩'——即在保留关键依赖信息的前提下，剔除无关代码——是最有效的方式。我们需要筛选出与当前改动真正相关的部分。所以当我把这一层补上之后，整个流程开始变得清晰起来。Diff 不再是唯一输入，而是触发点。系统会先基于 Diff 找到相关的上下文，再把压缩后的信息交给模型进行分析。这样一来，模型不再被迫面对整个仓库，而是站在一个被整理过的局部世界里工作。输出的 Review 质量，也开始明显稳定下来。

第三部分：从“看代码”到“看影响”

在前置的问题都解决掉之后，我又面临一个问题：怎么样让 AI 理解变更后的影响从而输出高质量的建议呢？

我想到了多 Agent 系统，可以通过预设不同身份和责任的 Agent 让他们互相协同工作。这里我预设了三个 Agent 来进行合作，分别是 Summary 、Risk 和 Comments。他们开始尝试回答三件不同的事情：

• 这个 PR 做了什么（Summary）
• 这个改动可能带来什么风险（Risk）
• 作为 Reviewer 应该重点关注什么（Comment）

它们输入的是同一份 Diff，但输出完全不同。Summary 不再需要考虑风险，只需要讲清楚变化本身；Risk 不需要解释背景，只需要盯住可能出问题的地方；Comment 则更接近真实人类然后进行判断。

并且 Summary 和 Risk 并行执行，在 Summary 和 Risk 生成结果之后 Comments 根据输出结果在给出建议。这样一来 Agent 们有了一个比较清晰的分层。下游负责变化是什么、影响在哪里。下游则负责表达。

第四部分：我学到的东西

这次项目最大的收获，并不是完成了一个 AI PR Review 系统，而是帮助我重新理解了软件工程这件事本身。

在一开始，我对软件工程的理解其实很朴素：写代码、拆模块、设计架构、解决问题。但在做这个项目的过程中，我慢慢意识到，这种理解其实只停留在“实现层”。真正的软件工程，并不是单纯的在写代码，而是侧重于处理信息的复杂度。

一开始我以为，Review 的核心是检查代码对不对。后来发现不是，代码对不对，其实只是最表层的一层问题。重要的是我们该怎么样让 AI 可以去理解这种变化。我们应该如何在一堆繁杂的信息中如何抓住重点并且针对整个重点用尽各种手段去解决。

代码只是静态结果，真实的软件世界一直在发生变化：需求再变、接口在变、依赖在变、人对系统的理解也在变。而所谓的工程能力，本质上就是在管理这种变化的能力。很多时候，不是问题太复杂，而是我们没有抓住核心。真正决定工程能力的不是说你有多会写代码而是一种去理解复杂问题的能力。

从这个角度看，这个项目最终指向的其实不是一个工具，而是一种能力：在信息越来越复杂的系统里，依然能抓住关键变量。

面向 AI 时代，代码的生产成本会越来越低，但理解问题、定义问题、以及在复杂约束中做取舍的能力，会变得越来越重要。

项目地址：asJEI/PR-Review