AI热榜 在 LinkedIn 这样的体量下，单纯依赖人工审查或是直接把一个现成的 AI 审查工具架在 GitHub 前面都不是管理 PR 的有效方式。
为此，LinkedIn 工程师搭建了一个 多智能体 AI 代码审查平台 ——它能够理解组织自身的代码上下文，将代码审查视为生产级基础设施，并最大限度地减少 AI 幻觉与低价值反馈。
LinkedIn 构建代码审查平台的目标是生成开发者认为值得采纳的审查意见，最大化信噪比，并兼顾代码库的“标准、惯例和通用 AI 模型始终会遗漏的隐性知识”。
大规模生成 AI 审查评论本身轻而易举，难的是后续的东西：确保这些评论是基于代码差异的事实依据而非幻觉；确保高信噪比而非噪音；针对代码库的特定约定而非泛泛的最佳实践；并且赶在人工审查员之前生成，而非之后。
具体而言，依赖现成的 AI 审查工具会暴露出三大结构性局限：单一模型导致的盲点可能导致 AI 审查员遗漏同一类错误并标记同一类低价值问题；定制化不足导致难以同时纳入组织级策略、代码库特定约定以及针对高风险或高影响场景的专项指导；缺乏运营控制限制了将审查员作为工程基础设施的一部分进行控制、评估和监控的能力。
基于这一分析，LinkedIn 的平台通过以下方式解决上述局限：多个独立的 AI 审查员，使用不同的模型和推理方法；深度、可组合的定制化，涵盖组织级策略、代码库级约定和上下文特定规则；基于 Kubernetes 的架构，支持带有持久队列和水平扩展工作节点的事件驱动管道，从而能够监控延迟、接受率、完成率和供应商故障。
采用多个独立 AI 审查器实现交叉验证，提升对审查结论的置信度。
例如，当多个智能体独立识别出同一问题时，LinkedIn 会将这种趋同视为有力证据。
而对于仅由单个智能体提出的独特发现，也并不会被自动丢弃，而是另行进行单独验证。
最后，那些表面修饰性的、已被修复的、不相关的或与代码库约定不一致的建议都会在发布前被过滤掉。
为了衡量开发者实际采纳 AI 生成建议的频率，LinkedIn 构建了一个自动化的接受率评估流水线，将所有建议与最终合并的代码库进行比较。
该评估覆盖了 1727 个 PR 中的 5230 条抽样审查评论，发现其中 90.1% 可以基于合并代码进行高置信度评估。
总体而言，63.9% 的建议被采纳，不同类别之间存在显著差异：80% 的逻辑错误、58.1% 的缺陷修复、43.5% 的重构变更、40.6% 的安全相关修复以及 100% 的并发缺陷被采纳。
其他公司也解决了大规模代码审查的问题，但采用了不同的方法。
例如，Cloudflare 围绕开源编码智能体 OpenCode 构建了一个
🔗 原始来源
如果你要核对细节，可以再看原文： InfoQ AI原文链接