代码审查进化：从通用审查到领域专家，Kitta 代码审查智能体的实践

随着 AI 深度参与研发流程，代码审查正在从辅助环节演变为质量保障体系的核心节点。阿里云技术专家周远航在 2026 云栖大会上分享了《代码审查进化：从通用审查到领域专家，Kitta 代码审查智能体的实践》。她详细介绍了代码审查智能体 Kitta 逐步打造为「领域专家」的进化历程：先分析 Al Coding 浪潮下研发流程面临的质量问题与代码审查场景的核心挑战，再从流程、数据、模型三个层面，介绍 Kitta 的领域定制方法、在龙蜥社区的落地效果，以及与 Qwen 基座模型协同进化的机制和信任边界的设计共识。

Kitta 在龙蜥社区线上运行至今，累计完成超 7 万个补丁的审查，门禁准确率达 97%，合入率稳定在 62%。其领域定制方法论已在操作系统内核、编译器、Agent 平台型应用等六大领域验证，实现 17.0%–31.6% 的审查质量提升，成功将 Maintainer 的精力从逐行审查释放至关键争议裁决。

AI Coding 时代的代码质量危机

当 AI 辅助编程的占比持续升高，研发流程正在出现结构性的代码质量危机。两组行业数据清晰地呈现了这一趋势。

• 从安全侧看，根据 Linux 基金会与 OpenSSF 联合发布的 2026 CRA 报告，2026 年第一季度软件开发行业的 CVE 提报数量显著增长：总体增长 394%，高危漏洞增长 811%。每一个 CVE 编号背后，都对应着一个真实存在的代码安全问题。
  
• 从效能侧看，DORA 在 2025 年专项报告中给出了三个关键数字一一AI 辅助编程逐步普及之后，代码 Bug 率上升 9%，平均 PR 体积膨胀 154%，代码评审时间增加 91%。
  

综合两组数据，可以得到一个清晰的趋势：当 AI 持续提升代码产出速度，团队面临的主要问题不再是「如何写出更多代码」，而是「如何守住代码质量」。这种危机在真实的大型开源软件研发中，已经有非常具体的呈现。

在上游，Linux 内核上游社区各版本修复 CVE 数量的变化趋势显示：从 7.0 版本开始，修复数量快速增长；到 7.3 版本，数字即将突破 2000。上游的代码质量压力直接传导至下游一一AI 原生操作系统开源根社区龙蜥的两个主要内核发行版，近两年每月 PR 合入量快速增长，增幅达 8.9 倍，与上游几乎同步。

AI 辅助编程突破了人类开发速度的瓶颈，新代码产出速度快速增长；与此同时，代码中的缺陷与漏洞也在被更快地引入、暴露和放大。这是当下众多研发团队正在面对的最真实的代码质量危机。

AI Native 研发组织的智能化持续集成（Agentic CI）

面对代码质量压力，如今的 Al Native 研发组织已不再满足于「用 AI  写代码」，而是构建一套全新的智能化持续集成工作流一一Agentic Cl。要让 Al 的能力不再停留在代码生成这一刻，而是贯穿代码从产出、交付到产生价值的全生命周期。

以龙蜥社区为例，一段代码从诞生到合入主线、进入生产环境，需要经过四个步骤：

1.AI 协同编程。人机共写代码已成为日常，编码速度不再受制于人力瓶颈，研发产能普遍激增。

2.智能化代码评审。产能释放之后，海量代码迎面撞上第一堵墙。AI 代码评审连接着代码生产体系与质量保障体系，解决的是代码「能不能安全、稳定、合规地进入后续流程」。这要求 AI 像领域专家一样完成全面审查，覆盖四个维度：研发规范与流程的合规性；架构与设计的一致性；变更完整性与前置依赖的准备情况；缺陷与安全风险。这些问题无法依靠规则匹配解决，需要 AI 像资深代码专家一样理解上下文、判断风险，并给出可信结论。

3.智能化测试。通过评审后，代码进入更深度的质量验证，包括漏洞挖掘、补丁定向测试、安全补丁验证，以及完整的回归测试与性能测试。

4.社区审核合入。流程的最后仍由人做最终决策。即使 AI 已深度参与每一个环节，最终的确认与兜底仍由人完成——决定代码能否进入生产环境的，依然是人。

在这一工作流中，代码质量本身决定着组织的交付速度。

代码审查不再是传统流程里的辅助环节，而是代码生产、验证、交付的第一个核心节点，是 AI 生产力真正落地、转化为企业技术资产并持续积累的核心基石。

AI Code Review 的三大深层挑战

用 AI 完成相对简单的代码审查、识别基本的编码规范问题并不难，AI 也确实能发现一些潜在缺陷与漏洞。但当代码审查进入深水区——尤其在大型开源软件社区中，面对错综复杂的审查任务，甚至参与实际的 CI 发布流程时，水面之下的深层挑战便会显现。其中三个核心技术挑战，直接制约着 AI 代码审查在大型开源社区的落地。

• 挑战一：领域知识匮乏。 不同项目之间的差异犹如鸿沟——内核、编译、网络，每个领域背后都有一整套深厚、专业且持续演进的知识体系。通用模型不可能天然理解这些垂直领域，难以一开始就具备足够深入的专业知识，也很难持续跟上知识更新。换言之，AI 能看懂一段代码「写了什么」，却未必理解它在特定领域语境中意味着什么。
  
• 挑战二：业务理解不足。 除技术领域本身外，AI 还需理解项目的研发方式。不同项目的研发模式、协作与流转规则差异很大，代码审查关注的检查清单与核心侧重点也随之不同：下游内核社区关注回合补丁与上游补丁的一致性；另一些项目则更关注 API 兼容性、发行版规范或特定合规约束。如果 AI 只是机械套用通用审查模板，不知道当前变更处于哪条研发流水线、需要遵守哪套流转规则与业务约束，其评审意见就难以称得上充分和专业。
  
• 挑战三：信任边界模糊。 AI 提出建议后，如何判断其是否可信？用什么标准评估审查质量？当 AI 的判断与人类专家不一致时，该听谁的？这些问题不解决，AI 与人类之间的信任基础便无从建立，研发组织很难将其纳入日常流程，它也难以成为研发流程中被依赖、被采纳、被长期使用的一环。
  

三个挑战可以浓缩为一句话：今天的 AI 或许已经能「看懂代码」，但还远没有「看懂项目」。

它未必真正理解代码所处的技术领域、背后的研发流程，以及它在整个工程体系中的真实约束。行业需要的不是只会「挑代码毛病」的工具，而是真正理解领域知识、理解业务规则，并能在流程中建立可信度的代码审查智能体。

Kitta 的领域定制「三步走」

针对上述挑战，团队研发了领域专用的代码审查智能体 Kitta，目标是在龙蜥社区这类真实研发环境中，提供贴近项目实际、具备专家水平的代码审查能力。方法上主要做了三件事。

第一步：构建项目级专家资产，解决领域知识匮乏

Kitta 的核心思路是从真实的项目研发历史中挖掘专家级知识。数据来源包括 GitHub 上的审查历史、社区讨论数据，以及仓库本身的提交记录与演进轨迹。在数据基础上，通过数据采集、语义解析与隔离复现，把其中稳定、有效、可验证的知识，提炼为一套项目级专家资产，包括评审原则、项目中反复出现的典型缺陷模式以及项目惯例。

这套资产的内涵分为两层：作为「评判标准」的评审原则、缺陷模式与项目惯例，以及由问题样本、正常样本和预期结论构成的「验证样本」。其本质是让研发历史成为 Kitta 的学习对象，从历史数据中学习审查规则与业务约束。

第二步：双轮驱动的审查定制，解决业务理解不足

Kitta 的定制从「看得全」和「看得深」两个方向入手。

第一个轮子是审查流程定制，回答「审查要看哪里」——先定义当前项目中代码审查应关注哪些问题。Kitta 结合不同项目的研发模式与流转规则配置审查重点：在下游回合场景中，重点检查下游补丁与上游补丁的语义一致性、变更完整性；在另一些项目中，则更关注 API 兼容性、发行版规范或集成风险。

第二个轮子是领域知识定制，回答「问题怎么判」。Kitta 将第一步提炼的项目级专家资产，沉淀为多源、分层的领域知识库；审查时根据补丁所属的模块、子系统和具体领域自动匹配上下文，路由到对应的典型缺陷模式。由此，Kitta 给出的评审意见不再是通用的代码建议，而是结合项目语境与领域知识的深入建议，更符合真实的项目需求。

第三步：在线—离线协同的持续迭代进化，解决信任边界模糊

Kitta 上线之后并不是一个固定不变的系统，而是通过离线验证与线上反馈两条路径持续迭代、进化。

离线侧，利用项目沉淀的真实样本持续进行隔离评测，检验审查质量；发现问题后，进行针对性的反思、调整与知识更新。在线侧，持续追踪 Kitta 的真实线上表现——包括采纳率、用户反馈，以及后续真实发生的代码动作——以线上信号校准审查方向，让真实使用效果成为持续进化的依据。

两条路径协同工作：离线验证保证能力持续提升，线上反馈保证提升的方向，使 Kitta 始终贴近用户的真实需求

Kitta 落地效果

龙蜥社区内核仓库的实践

Kitta 已在龙蜥社区的真实研发流水线中持续落地运行，沿着一条完整的五阶段流水线对每一个内核 PR 进行审查。开发者提交 PR 或在评论中输入 /check-code-review 后，审查任务即被触发；整个流程先分类、再检查规范与依赖、最后落到代码质量，层层递进。

Stage 1. PR 分类。Kitta 首先判断这是纯自研补丁还是回合补丁：如果 Commit 中存在类似 commit xxxx upstream 的上游补丁声明，则归为回合补丁。分类决定后续检查范围——纯自研补丁不会执行补丁完整性检查和回合一致性检查，避免不必要的开销。

Stage 2. PR/Commit Message 规范性检查。基于龙蜥社区规范文档，对 PR 描述、Commit Title、Commit Message 等进行检查。这一步看起来“轻”，却能提前拦住大量因描述不清、标题不规范导致的维护成本。没有问题则不报告；有问题则给出 Message 规范建议，供开发者参考。

Stage 3. 补丁完整性检查。针对回合补丁，Kitta 会智能追踪其上游依赖链，自动识别上游对应的 Fixes 补丁，按“检索上游 Fixes → 判断是否在 PR 中 → 判断是否在下游仓库已存在”的流程排查遗漏。检查结果分为三类：无遗漏 Fixes 表示无需补充；已合入的 Fixes 补丁说明相关修复已存在于下游仓库；遗漏的 Fixes 补丁则要求开发者补充，防止已知漏洞被重新引入下游。

Stage 4. 补丁回合一致性检查。对于声明了上游来源的回合补丁，Kitta 会先获取上游原补丁，再从三个层次对比：基础对比看修改的文件和代码块是否一致；上下文对比看引用的符号、函数、变量定义是否一致、是否做了合理适配；语义对比则通过 LLM 判断上下游补丁是否实现了相同功能和语义。检查结果从 consistent 到 text-inconsistent、semantic-inconsistent、inconsistent 分层输出，让开发者和 Maintainer 快速定位差异性质。

Stage 5. 代码质量审查。最后落到代码本身，Kitta 将审查出的问题按严重程度分为Critical 、 Medium / Low，Critical 问题通常会以内联评论定位到具体代码行，需要开发者处理或明确是否为误报；未发现风险则给出 LGTM 。

Kitta 上线至今，核心运行数据如下：

ANCK 的代码变更以回合补丁和自研补丁为主，既要保证与上游语义一致，又要适配下游产品化需求，审查深度和准确率要求都很高。基于线上评估框架对 Kitta 上线以来处理过的所有已合入 PR 进行回溯统计，两类核心场景都取得了可量化的效果：

• 回合补丁场景：一致性检查意见采纳率 70.4%、准确率 99.8%；
  
• 自研 PR 场景：Code Review 意见采纳率 41.8%、准确率 73.6%。
  

Kitta 的介入让大量代码问题在进入人工审查之前就被识别，并给出可定位、可验证的修改建议。实践中，很多 PR 在 Kitta 给出意见后，开发者会直接依据建议补充依赖补丁或调整实现，大幅减少了 Maintainer 反复追问、来回确认的回合数。对社区 Maintainer 来说，这意味着他们可以把注意力从“逐行看变更”转移到“判断关键争议点”；对开发者来说，则意味着更快的反馈和更可预期的合入节奏。

Benchmark 评估体系：让定制效果可衡量

为了让定制效果可衡量，Kitta 还构建了 Benchmark 评估体系：基于三类来源收集数据——LKML（真实社区 Reviewer 的评审过程，问题分布均匀、真实性强）、sashiko benchmark（单 commit—单 issue 精确对应）、龙蜥社区数据。其中：

• LKML 数据让 Kitta 能够对齐真实社区 Reviewer 的判断标准；
  
• sashiko benchmark 提供了严格的单 commit—单 issue 映射，让能力改进方向足够聚焦；
  
• 龙蜥社区数据则把评估拉回到 Kitta 实际服务的仓库语境中。
  

通过与 sashiko、review-prompts、qoder 等 SOTA 方案横向对比，Kitta 能够清楚看到自身在特定缺陷类型、特定子系统上的差距，并把这些差距转化为 Skill 迭代的优先级。后续该 Benchmark 系统还将支持接入其他 Skills/Benchmark 进行评估，持续迭代优化能力。

跨领域通用实践

Kitta 的能力并不局限于内核。通过把专家资产和审查流程抽象为可迁移的 Skill，Kitta 已经在操作系统内核、编译器、文件系统、网络系统、云原生平台、AI 计算框架六个领域完成验证。这些领域共同的特点是代码规模大、语义深、审查门槛高，传统通用 Review 工具往往难以给出有价值的结论。Kitta 在这些场景下的表现如下：

跨领域的稳定提升说明 Kitta 的“领域定制”方法论具有通用性：无论是内核的锁语义、编译器的中间表示，还是云原生平台的配置约定，都可以通过沉淀专家资产、定制审查流程来构建专家级 Review 能力。这也为后续向 LLVM、CRIU、BaseOS 等更多基础软件项目扩展奠定了基础。

数据飞轮：数据向下沉淀，模型能力向上反哺

Kitta 在服务过程中还在持续沉淀数据，可以用于千问基座模型的形成“数据向下沉淀、能力向上反哺”的飞轮：

评审过程中产生的专家标注、思维链轨迹、用户偏好与后续代码改动，既是改进 Review 服务本身的燃料，也在反哺基座模型更基础的能力。反哺基座模型更基础的能力。更重要的是，这些数据来自真实的社区运行，而不是人工构造的静态数据集，因此每一次迭代都在让 Kitta 更贴近实际研发场景。

应用效果：跨领域提升与规模化落地

Kitta 已在多个高难度、大规模、不同类型的软件项目中实现应用，在内核、网络等六大领域均取得了 17%～30% 的审查质量提升。这表明其背后的领域定制方法并非一次性特例，而是可复制、可迁移、稳定有效的方法。

其中最具代表性的是内核场景。内核是一个代码量巨大、复杂度极高的开源协同软件项目：一个补丁可能跨越多个子系统、涉及大量代码改动，审查难度极高。即便如此，Kitta 依然交出了令人满意的答卷。

目前，Kitta 已在龙蜥社区全面落地，服务 ANCK 内核发行版。累计审查规模超过 7 万个补丁，门禁准确率达到 97%，代码合入率达到 62%。Kitta 将会对补丁进行全方位的审查后，将意见进行归类和分级，以清晰的方式呈现在评论区和页面报告中，并将高危问题直接嵌入代码标识。

Kitta 在龙蜥社区中应用真实案例链接：https://gitee.com/anolis/cloud-kernel/pulls/12920

Kitta 的实践结果表明：领域专用的代码审查智能体不仅做得出来，而且能够在真实的大型开源社区中稳定运行、规模落地，并持续创造价值。

我们正稳步推进 Kitta 能力的服务化部署。我们将把 Kitta 的能力开放出去，Kitta 未来将以更通用、更开放的服务形态面向广大开发者上线。

与 Qwen 基座模型的双向反哺

Kitta 的实践揭示了一个关键判断：构建代码审查 Agent，仅把工程链路搭起来是不够的，背后的基座模型才是决定能力上限的核心。因此，Kitta 的设计思想不是简单「调用」一个大模型，而是从一开始就与 Qwen 基座模型深度绑定，构建一套双向反哺的进化闭环：

• 一方面，Kitta 线上服务积累的各类真实数据持续向下沉淀，支撑 Qwen 的能力评估、训练与优化；
  
• 另一方面，Qwen 基座模型能力的增强向上反哺 Kitta，持续提升其线上审查效果。
  

具体而言，Kitta 会沉淀四类关键数据：

相应地，这些数据驱动 Qwen 在四个方向上形成能力增强，再反哺 Kitta 的线上审查效果。

这一「数据向下沉淀、能力向上反哺」的闭环是一个持续积累的过程：运行越久，沉淀的专家资产越厚，模型能力越强，对项目的理解也越深。目前，Kitta 数据已参与 Qwen 3.8 flash 训练，加强了其代码审查能力；未来，Kitta 将继续依托 Qwen 底座，在真实研发现场中持续学习、持续进化。

信任的刻度：AI Code Review 的边界与共识

在工程方法之外，人机信任边界是代码审查智能体绕不开的核心议题：AI 与人类之间的边界应该如何划分？Kitta 的设计理念可以概括为三句话。

• 原则一：精准分级，克制打扰。 最好的 AI 门禁，不是把所有问题一股脑全抛出来——全量告警只会让开发者疲劳、麻木。Kitta 对问题做分级处理：安全漏洞、破坏性变更等真正高风险的问题坚决拦截 CI 流程；一般性建议仅作提示。这件事本质上考验的不是「报出多少问题」，而是能否把人类注意力留给最值得处理的风险。
• 原则二：行为作证，拒绝自嗨。 真实使用场景中，用户往往不会明确表态一条建议是否有用——不点赞、不回复是常态。但有一件事不会骗人：后续改了什么代码。因此，Kitta 不把沉默当成认可，也不以一两条正向反馈作为证明，而是以真实代码行为为准：判断一条意见的价值，看它是否真正推动了后续的代码修正、消除了代码风险。客观的代码变更，是驱动审查与模型迭代的最终依据。
  
• 原则三：人类兜底，适时退场。 无论 AI 能力发展到什么程度，在整个研发流程中，AI 的角色如同探照灯，而握着方向盘的始终是人。AI 负责照亮风险、补充证据、缩小问题范围；是否接受建议、是否放行代码进入生产环境，由研发者最终决定。AI 应该在能发挥作用的地方尽可能前移、深入，在需要承担最终责任的地方适时退场。
  

未来规划

Kitta 的领域专家级代码审查的实践表明：让代码审查智能体真正「看懂项目」，需要领域知识、业务理解与信任机制的系统化建设，需要模型能力和平台建设的相互支持。

目前，我们正稳步推进 Kitta 能力的服务化部署。我们会将这套经过验证的审查能力开放出来，以更通用、更标准的服务形态，支持各类不同项目的领域专用代码审查。欢迎大家持续关注 Kitta 在龙蜥社区的最新动态。

—— 完 ——