采访嘉宾｜蒋思源，硅心科技（aiXcoder)算法专家；黄宁，硅心科技（aiXcoder)产品专家
当 GitHub Copilot、CodeRabbit 等代码审查在 2024 年掀起行业讨论热潮时，距离 Meta 工程师 Marius Eriksen2021 年预言 AI 代码助手的潜力不过三年。
<!---->如今，据不完全统计，市面辅助编码相关工具已超过 20 种，涵盖通用代码审查、安全漏洞检测等多个细分领域。这些工具已形成割据之势，宣称能将代码审查效率最高提升 300%。
然而，这些工具的实际表现却引发诸多争议。有工程团队反馈，部分 AI 代码审查工具与传统的静态代码分析工具（linters）功能高度重叠，只是披上了 AI 的外衣。Echios 首席技术官 Jon Freedman 表示，在小规模团队中，部分工具每月 30 美元的成本物有所值，但在复杂项目中，其作用有限。
这种局限性在处理复杂业务逻辑或跨模块交互的代码时尤为明显。一些 AI 编码工具虽标榜拥有“完整代码库上下文”，但在实际应用中，仍难以穿透项目特有的业务规则和架构设计。
误报问题也让开发者头疼。Reddit 上有用户表示，初级开发人员为了满足 AI 工具的规则，可能会修改代码就为了“让工具闭嘴”，但却忽视了潜在的性能或安全风险，反而给工程团队带来更多工作。
可以看到，AI 代码审查工具在软件开发流程中既带来效率革命，又引发深层矛盾的现状。面对这种复杂局面，InfoQ 采访了硅心科技算法专家蒋思源和产品专家黄宁，试图厘清几个关键问题：在 AI 生成代码日益普及的今天，传统审查方法该如何进化？各家的 AI 审查工具究竟有何本质差异？更重要的是，我们该如何在利用 AI 优势的同时，规避其潜在风险？
以下为访谈实录，经编辑：
InfoQ：当前针对 AI 生成的代码，业内是如何做代码审查的？靠 AI 代码审查工具更多还是人工代码审查更多？
蒋思源：我认为当前业内对 AI 生成代码的审查正在形成一个清晰的三层分层体系，这种分层反映了不同类型问题的技术特性和处理难度。
在基础层面，语法错误和编译错误这类问题已经被传统软件工程工具很好地解决了。这些工具能够快速且准确地检测出此类错误，因此没有必要专门让 AI 模型介入这个环节。实际上，如果将这些错误信息反馈给生成代码的 AI 模型，它们基本都能自行修复。这意味着在 AI 代码生成的流程中，这类基础错误可以在生成阶段就被避免，而不需要在后续审查中耗费资源。我们在 aiXcoder 的实践中，已将传统静态分析与大模型结合，成功提升了代码质量的检测能力。
中间层涉及代码的可维护性、可靠性和安全性等质量属性问题。传统软件工程工具虽然一直在关注这些方面，但受限于规则的复杂性和上下文理解能力，只能检测出其中一小部分问题，且准确率有限。这恰恰是 AI 审查工具能够发挥重要作用的领域，AI 模型能够结合传统软件工程工具识别更加复杂和隐蔽的代码质量问题，比如潜在的性能瓶颈、安全漏洞模式、代码异味等。目前业内的实践表明，在这个层面采用 AI 工具与传统静态分析工具相结合的方式，能够显著提升问题检出率和准确性。
InfoQ：对于 AI 代码审查工具来说，最难的是审查哪些代码？
蒋思源：最具挑战性的是第三层，业务逻辑和功能正确性层面的审查。无论是传统软件工程工具还是当前的 AI 模型，都难以准确判断代码是否真正实现了预期的业务需求。这类问题高度依赖具体的业务场景、领域知识和需求理解，需要人类审查者基于经验和专业判断来把关。
基于这种分层认识，当前正在形成"工具自动化处理基础问题、AI 增强中层质量检测、人工把控高层业务逻辑"的协同审查模式。这种模式既充分发挥了各种技术手段的优势，又确保了代码质量的全面保障。随着 AI 技术的不断进步，中间层的 AI 审查能力会持续增强，但人工在业务逻辑审查中的核心地位在可预见的未来仍将保持不变。
AI 代码审查工具的核心壁垒是什么
InfoQ：在 AI 辅助编程（如 GitHub Copilot、Cursor、Claude 等）盛行的当下，传统的代码审查方法是否仍然适用？哪些地方需要调整？AI 代码审查工具核心能力到底是什么？
蒋思源：传统代码审查的方式会变化，因为传统代码审查主要关注代码规范、潜在 bug、性能问题等方面，审查者通常假设代码是由了解项目背景的开发者编写的。但 AI 生成的代码打破了这个假设——AI 可能生成看似合理但实际上与项目整体架构不协调的代码，或者使用了技术上正确但不符合团队约定的实现方式。因此，代码审查的重点除了“这段代码写得对不对”，还新增了一个审查方向：“这段代码是否真正适合我们的项目”。
例如，代码审查流程可能需要在以下两个方面进行调整。首先是审查范围的扩展，除了检查代码本身的质量，还需要验证 AI 生成代码与现有代码库的一致性，包括编码风格、设计模式、依赖管理等。其次是审查深度的加强，需要更加关注代码的语义正确性和业务逻辑合理性，因为模型可能生成"看起来很专业"但实际上偏离需求的代码。
总的来说，AI 代码审查，核心能力还是对于代码项目的理解，对于项目行为与意图的理解。只有具有完整且正确的代码项目理解，才有可能判断代码逻辑的正确性。
aiXcoder 也正在专注于做好模型对代码项目的整体理解，我们希望先利用软件工程已有的能力，为大语言模型注入软件工程师专业的知识与动作空间，从而加强模型对代码项目的理解，识别更具业务属性的代码问题。
InfoQ：目前业内比较主流的 AI 代码审查工具，各家能力有什么本质不同吗？
黄宁：目前市面上主流的 AI 代码审查工具其实不少，比较有代表性的主要有这么几类：
第一类是以 cursor、copilot 和 aiXcoder 为代表的智能助手，主要是帮开发者在写代码的过程中做自动补全、提醒和简单的错误检测。它们的优势在于集成度高、响应速度快，适合日常开发提效。
第二类是以 Sync Code 为代表的专注于代码审查、质量分析的工具，这类产品的侧重点更多在于静态分析、漏洞检测、复杂度评估以及代码可维护性等。这些工具通常会结合 AI 和传统规则引擎，一起提升代码质量的自动化检测能力。
前者更注重个人场景和效能提升，后者则更专注于代码质量安全和团队协作。
总的来说，目前没有哪一款 AI 代码审查工具是“全能型”的，大家的定位和侧重点各有不同，企业和开发者可以根据自己的需求去选择和组合这些工具。
InfoQ：我们了解到，目前 AI 代码审查工具能发现的问题仍然局限在代码本身，如错别字、拼写错误或代码风格问题，对于语法之外的问题，如业务逻辑或团队规范问题，只能依赖人工审查。这是目前 AI 代码审查工具普遍无法解决的瓶颈问题吗？这种情况如何应对？
黄宁：这是个好问题，目前的一些 AI 代码审查工具确实缺少“看到”代码之外信息的能力，针对这个问题，行业内目前有这样几种解决方式：
一是通过为 AI 制定规则，主动引导 AI 聚焦在特定的规范和代码风格要求上；二是通过智能体自发进行工具调用来获取环境信息，为 AI 提供更符合团队要求的上下文。
硅心科技的 aiXcoder 目前主要采用 AI 规则的形式，同时在大力研究更精准的智能上下文系统，通过两种手段的结合来提高审查效率，相信在不久的将来，这类问题将不再成为 AI 代码审查的瓶颈。
蒋思源：只有大模型对代码项目有完整且正确的代码项目理解，才有可能判断代码逻辑的正确性，才能尝试解决业务逻辑问题。
“软件开发本来没有绝对的安全”
InfoQ：就像上面提到的，自动 AI 审查工具虽然可以识别漏洞并提高代码质量，但它们并不是万无一失的，这些工具可能会带来安全风险。安全软件开发商 Snyk 公司使用 AI 代码审查工具的经验表明，这些工具可能建议使用不安全的代码。但调查发现，75.8%的受访者认为 AI 生成的代码比人类编写的代码更安全。这就出现了一个矛盾现象：AI 代码审查工具能帮助发现漏洞，但它们本身也可能引入风险，我们该如何利用它的优势而去规避它带来的风险？
蒋思源：AI 可以是尽可能少误报代码漏洞，也可以尽可能多覆盖可能的代码漏洞，这两者之间本来就存在权衡关系，实际需要看具体的开发模式以偏向于某个方向。但不论如何都需要人工逐条评审来最终确认，风险把控掌握在人的手上，所以只是看哪种风格更能降低人的成本。
黄宁：其实软件开发本身就包含不断发现和修复漏洞的过程。哪怕是最资深、最严谨的开发者，也难以写出绝对没有问题的代码。
软件工程作为一门学科，最核心的目标其实就是用各种方法和流程，把这些风险降到最低，尽量提前发现和修复，而这恰好就能解决 AI 代码审查中遇到的一些问题。
传统软件工程上，我们有一整套流程用于保障代码质量和提高安全性：从单元测试到集成测试、从设计评审到代码复核；这些流程共同构成了一个“多重保护网”，每一层互为补充，共同拦截问题。
在当下 AI 开发正热的时代，我们完全可以把这些环节引入到 AI 代码的审查流程中，这样一来，即便 AI 有疏漏或出现不安全建议，也有多层机制把控风险。而开发团队也能在 AI 做初步审查后，再进行二次人工复查。
说到底，软件开发本来就没有绝对的安全，只有更高的安全概率。因此 aiXcoder 加强了 AI 与人工审查的结合，通过 AI Rules 引导 AI 关注团队约定的编码风格，并结合实际开发场景来优化 AI 审查过程，把 AI 的效率优势和传统工程的稳妥性结合起来，让每一层都能发挥作用，整体把风险降到最低。整个行业几十年积累下来的“安全常识”，在 AI 时代同样适用。
InfoQ：如果 AI 能生成大量代码，审查速度跟不上怎么办？是否应该调整代码审查的粒度（如更小的 MR/PR），或者需要新的代码审查工具或流程来适应 AI 生成代码的特点？例如，是否应该先让 AI 做初步自检，再交给人类审查，就有点类似采用分层审查（如 AI →初级工程师→资深工程师）？
蒋思源：代码审查需要分层，不同层级的问题可以通过模型与软工工具的结合，做到不同程度的处理。
黄宁：我非常同意分层审查的思路，尤其是在 AI 生成代码量越来越大的情况下，靠单一环节去兜底，效率和安全都难以兼顾。
首先，如果想真正提升效率，AI 必须更多地参与到初步审查的环节。它可以自动过滤掉绝大多数明显的低级错误和重复劳动，让人工审查资源用在更有价值的地方。否则，一大批自动生成的代码堆积在那儿，靠人工一点点看，根本跟不上迭代速度。
其次，安全性这块，其实 AI 工具可以做得更主动。一种方式是“预先拒绝”——也就是 AI 本身对高风险、不符合规范的代码直接不通过，甚至在 PR/MR 阶段就自动拦截。
另一种方式是“自我解释”——让 AI 在推荐或生成代码时，同时输出理由和安全性分析，方便后续人工快速定位和判断风险。不光让 AI 给出答案，还要让它说明“为什么这样写”，这对提升信任感和审查质量都很有帮助。
总的来说，为了达到更高效的 AI 协作开发，由人定义和监控问题、由 AI 实施和处理细节，这样的分层架构一定是未来的发展方向。
InfoQ：当前，AI 工具尚未达到完美的程度，因为它们有时会将无关紧要的事项错误地标识为潜在问题。或者，它们可能无法识别真正的代码漏洞。误报可能会使开发人员感到沮丧，因为他们不得不花费大量的时间来处理不构成真正威胁的警告。随着时间的推移，这会导致“警报疲劳”，导致软件专业人员忽略有效的警告，这种局面该如何解决？
蒋思源：静态分析工具与大语言模型，要高召回还是高精度，这个只能根据实际场景决定，哪种方式能降低人的工作量就采用哪种方式，但必然带来另外一方向的效果降低。
黄宁：这个问题其实在软件工程领域一直存在，叫做 completeness 和 soundness 的权衡——也就是“全面发现所有问题”和“只报告真正的威胁”这两者是鱼和熊掌难以兼得的。AI 工具时代，这种取舍依然摆在我们面前。
通常来说，我们会把选择权交还给实际的使用者。比如在安全特别重要的场景下，我们宁可多报一些“疑似问题”，哪怕有些误报，也不能漏掉任何潜在风险。这时候，工具的“敏感度”会调高，开发团队也会为此准备更细致的复查流程。
而在对效率、性能要求很高的业务里，如果误报太多，确实容易造成“警报疲劳”，工程师会逐渐忽略警告，反而影响整体质量。这时，我们会适当放宽 AI 工具的检测严格度，优先保证团队开发的流畅性。
在 AI 代码审查场景下，这种权衡同样重要。我的建议是让 AI 工具支持自定义配置，让团队根据不同阶段和需求灵活调整误报与漏报之间的平衡点。比如，核心模块可以采用高敏感度、多层复查的策略，非核心模块则适度放宽，减少无谓干扰。
更进一步，AI 工具还可以通过“学习反馈”持续优化，比如开发者每次手动处理误报时，AI 系统自动记录这些案例，逐步减少类似的无效警告，提高整体体验。
总之，“警报疲劳”不是 AI 独有的问题，但 AI 工具的灵活性和可调节性让我们有更多方法去应对。关键还是要让团队有权根据实际情况调整策略，把主动权和选择权还给工程师，而不是一味追求“万能检测”。
InfoQ：你希望 AI 代码审查工具在未来增加哪些功能，才能让它真正帮助团队，而不是增加负担？如果 AI 能学习团队的编码风格和业务逻辑，而不仅仅是通用规则，你觉得它会更有用吗？
黄宁：这个方向其实我们 aiXcoder 内部也经常讨论，我觉得未来 AI 代码审查工具要真正有价值：第一就是要能主动适应团队的实际情况。就像你说的，AI 就像个新生儿，他需要不断被“教”——可以通过团队手动配置一些规则，也可以靠 AI 自己去学习代码库、历史提交、评审记录等环境信息。这样，AI 给出的建议才能真正贴合团队的实际需求，而不是总是“教条式”地提醒一堆无关紧要的问题。第二，就是交互上要更人性化、更智能。比如每次提交，AI 能自动跟踪上下文、自动关联合并请求、自动生成简明易懂的报告，甚至根据不同开发者的习惯调整提示方式。这样一来，开发者用起来更顺手，也不用花太多时间去理解 AI 到底在说什么，或者去手动整理各种审查结果。
我希望未来的 AI 代码审查工具，不仅仅是个“检测机器”，更像是一个能主动理解团队、会不断成长的“AI 同事”。只有这样，它才能真正帮团队减少负担、提升效率，而不是变成一种新的负担。
代码审查永远离不开人类参与
InfoQ：在您看来，未来 3-5 年，代码审查流程可能会如何演变？是否会完全自动化？还是说很长时间里仍然需要以人工审查为主？
黄宁：未来几年，代码审查流程一定会越来越自动化。可以预见的是，很多基础性的细节，包括语法、风格、常见的安全问题、重复代码检测等等，都会交给 AI 工具自动处理。AI 能帮我们把这些琐碎的事情做好，省下大量人力。
但与此同时，我认为自动化的提升方向不是让 AI“包打天下”，而是让人类工程师把精力集中在更高层次的抽象和设计判断上。比如，AI 可以把底层的大量细节自动整理、归纳、聚合，最后呈现给人工的，是一些更接近架构和业务本质的“高层框架”和抽象问题。这样，团队能更快、更准确地评估代码是否符合整体设计目标、是否有逻辑漏洞。
另外，很重要的一点是，未来的审查流程一定要有一个良好的追踪和溯源机制。也就是说，高层的设计判断和底层的具体实现要能互相关联，保证我们在发现架构隐患或设计失误时，能够快速定位到具体实现细节，反之亦然。
至于说会不会“完全自动化”，我个人觉得，在高可靠的 AI 模型真正出现之前，最后一到两层的重要审批还是要靠有经验的工程师把关。毕竟，业务逻辑、行业背景、特殊场景的判断，目前 AI 还很难做到像人一样灵活和全面。
所以我的判断是，未来的代码审查会高度自动化、分层协作，但最关键的地方还是要留给人工，只有这样才能保证安全性和可靠性。
蒋思源：基础错误交给工具与模型，通用错误人和模型协作，业务逻辑错误模型辅助人来判断。开发者，尤其是理解业务与背景知识的开发者，仍然处于核心地位。
InfoQ：据您了解，目前有哪些团队已经在尝试“AI +人类协作”的审查模式，能给我们分享下他们是怎么做的，效果咋样？他们的经验教训是什么？
黄宁：我们 aiXcoder 团队就在积极实践这种审查模式。前后尝试了两种模式：最开始我们把整个审查任务直接全盘交给 AI，最后看报告，但是发现 AI 会陷入细节，无法发觉更大的问题。
于是后来我们调整为人+AI 分布协作。具体流程是：人指导 AI 先对每个提交的每个文件进行检查、分析；再将新提交与现有仓库比对、检查风格一致性和冲突；最后将整体审查结果生成报告交给人类工程师审查。这样虽然人的介入变多了，但整体准确性得到大幅度提升。
所以目前 aiXcoder 的经验就是，人必须引导 AI 该做什么，要做什么，这样才能发挥其最大价值。
InfoQ：开发者应该如何提升自己的代码审查能力，以适应 AI 时代的代码质量保障需求？
蒋思源：开发者需要从局部的代码逻辑抽离出来，更多地考虑项目的整体架构，以及具体业务上下游流转的所有逻辑，以判定代码实现的合理性。我们可以让大语言模型和软件工程的工具帮我们判断局部代码的正确性，但应该站在更高的层面上审查业务逻辑的正确性。
黄宁：思源说的这一点很重要，我再额外补充一点：开发者们必须提高对代码问题的敏感性，对“问题的定义”、“问题的根源”和“问题的解决方案”三个方面有更扎实的认知，这样无论是站在使用 AI 的角度去检查它的结果，还是在设计 AI 的角度去开发更精准的代码审查 AI，都会起到效果。
