昨天，和我的前同事（他们 Thoughtworks Global，我们前 Thoughtworks 中国区，现 Inspire）聊完 AI Code Review 之后，觉得有几个点非常不错 的点，应该会影响到不少人对于对 AI 代码检视的架构设计与思考。

在 2024 年，我们的观点一直是现有的代码质量工具，Sonarlint、Ktlint 等等语言 Lint 已经非常不错了，还有诸如于 CodeQL 等可以编写自定义规则。所以，AI 辅助更适合于分析 Lint 误报，生成规则等。但是，到了 2025 年，工具的 Agentic 化变成了主流的方式，诸如于 CodeRabbit 等构建的 Agent Review 也展现了非常好的潜力。

从 Sonarlint 到实时 CodeQL，再到 Agentic Review，影响我们的就是 token 数了。

为什么你不想做好 AI 代码检视？Spec 驱动了毛线检视

在 2025 年，我们依然能看到大量互联网企业，靠那种“长到能吓死人的 AI 代码检视提示词”来支撑所谓的 AI Review 体系。把一个超长的 prompt 当作“靠提示词吃饭的万能检视引擎”，并寄希望它能覆盖所有团队、所有项目、所有语言、所有上下文。

然后所有人都惊讶：为什么它总是失效？

因为单一提示词的上限就是纸面效果，一旦进入真实项目场景（复杂架构、历史包袱、团队约定、混合技术栈），它立刻原形毕露。AI Coding 这两年踩过的坑， 在 Code Review 上一个都不会少。你要问——“为什么 AI Coding 投了几百亿模型也才做到现在这个效果，你就凭一份 prompt 想解决 AI Code Review？” 换谁都做不到。

传统 LLM 给你写代码，是靠你丢一段 prompt，告诉它“帮我改一下这个函数”。 Agentic 模式则完全不同：

模型不会“自以为懂”，它会主动调用工具：项目结构、类关系、接口契约、依赖图、用例、上下游调用关系、Spec 文档…… 它会为一次任务构建一个专属的 Task Context Graph：任务相关的文件、规则、上下文、提示词。

Code Review 也是同样逻辑：你不提供上下游调用关系、架构约束、项目 Spec，AI 凭什么 review？

从 Coding Agent 学习构建 Code Review Agent

AI 不可能无上下文地理解你的代码，它需要结构化、动态收集、可组合的上下文体系。

而这三项核心能力，在 Code Review 里都是刚需：

• Agentic RAG。即每次 Coding 之前，要调用工具获取需求所需要的上下文，才会进一步开始编码。
• 自定义 Spec/Skill。既然每个项目是有差异的，那么每个项目应该自己定义自己的规则。
• Context Engineering。围绕编程的基础设施，构建所需要的上下文工具链，提供 MCP 等各类能力。
• Token 成本。各类 AI 厂商可以低价打包模型卖，以收到部分的成本，顺便打压对手。但是，自己开发时，就受限于这个成本因素。
• ……

我们可以直接参考 Code Rabbit 来看看好的 Code Review 是如何设计的：

为了确保 AI Review 确实是有效率的，Code Rabbit 做了一个提示词的基准线：代码与相关上下文1：1。对于每一行正在审查的代码，们都会向 LLM 提供同等权重的周边上下文。简单来说，如果你要 review 10 行代码，那么我从我的上下文工程中，应该获取到 10 行的上下文信息， 诸如于：用户意图、文件依赖关系、预期结果。这些上下文来源于：

• 需求意图分析：从需求信息（issue）、PR 的标题、描述以及受影响的提交范围，以帮助理解代码变更背后的“原因”。
• 增量代码构建的代码关系图（Code Graph），从相关联的函数，以丰富当前代码的上下文。
• 静态代码分析工具的结果：Sonarlint、PMD、Checkstyle 等，以提供代码质量问题的上下文。
• 自定义指令：包括但不限于：基于路径的过滤、审查规则，导入 Coding Agent 规则等。
• 历史信息：诸如历史 PR、聊天记录等。
• ……

在完成初步 review 之后，会调用 Verification Agents 来验证 AI 的建议是否正确，以确保这些评论确实能对代码库带来有意义的改进。诸如于编写验证脚本（verification scripts）， 并运行，以确保 AI 的建议不会引入新的问题。

ROI 导向的 AI Code Review

在足够的 context 能影响结果的情况下，我们的问题就变成了，我们是否值得投入这么多去做这件事？我们就需要考虑到成本。 这里的成本由两部分构建：

• 构建此类 Agent 的成本。构建 AI Agent 的成本现在已经很低了，你可以快速用 AI 生成一个可用的原型 —— 依赖于你的提示词和工程经验。
• 运行 AI Agent 的成本。如果每个系统都要进行大负荷的计划，是不是真的值得，有些系统对于质量的要求并没有那么高。

在企业环境中，这个成本问题更为复杂：是否统一提供一种工具，还是根据系统特点使用不同工具？并非所有系统的价值都相同：

• 一些内部系统即便出现问题也不会造成重大影响；
• 许多系统仅由少数人维护，而这些人通常还负责其他系统，这也增加了管理和运行成本。

因此，从成本视角出发，AI Code Review 的应用策略可以根据系统的重要性和价值来决定：一些系统使用传统工具（如 Sonarlint）即可， 而关键系统则可采用更高等级的 AI Review。

• Level 0，轻量 Lint 增强。AI 结合现有静态分析工具（Sonarlint、PMD、Checkstyle），给出修复的 PR 等。
• Level 1，核心模块定期 Agentic Review。针对关键模块或核心逻辑，收集有限上下文（相关函数、受影响文件、需求描述）； AI 参与建议优化、发现潜在 bug；
• Level 2，全量 Agentic Review。构建完整 Task Context Graph，包括调用链、依赖图、历史 PR、测试覆盖率等；适合大型项目或对质量要求极高的核心系统； 并结合 Verification Agent 自动验证 AI 建议。
• Level 3，持续智能优化。将 AI Code Review 与 CI/CD、知识库、历史决策数据深度整合；支持自学习、自定义 Spec/Skill 的持续优化；ROI 高但成本最大，适合企业级核心系统或安全敏感系统。

在企业中落地 AI Code Review，不仅是技术问题，也是组织与流程的问题。简单地堆积工具和模型，无法解决真正的质量问题。

小结：AI 不是万能，但可以被 ROI 驱动

2025 年的 AI Code Review 不再是单纯的“写 prompt 就能解决问题”。真正有效的体系是 Agentic + Context + Verification 的组合， 通过分级策略匹配成本与价值，从而最大化 ROI。

未来的趋势是：

• 上下文丰富化：代码关系、历史记录、需求文档、测试覆盖率都将成为 AI Review 的标配输入。
• 工具链深度整合：AI Review 将与 CI/CD、知识库、代码图谱、自动测试工具形成闭环。
• 自学习能力：通过持续反馈和项目定制，AI Review 将逐步理解团队特有规则，实现更高的准确率和价值。

如果你希望真正让 AI Code Review 在企业落地，不仅要关注模型能力，更要关注 成本、上下文、验证与组织匹配。ROI 不仅是指标，更是设计 AI Review 架构的核心指南。