阿里云C3级代码仓库AI代码门禁，基于Qwen3-Coder+RAG实现代码评审自动化，有效提升效率与质量，保障安全，并成功拦截高危缺陷。
原文标题：C3仓库AI代码门禁通用实践：基于Qwen3-Coder+RAG的代码评审
原文作者：阿里云开发者
冷月清谈：
怜星夜思：
2、文章强调了RAG知识库在AI评审中的重要性，尤其是“与生产代码同仓管理，文档与代码共生命周期保障一致性”。这对我们来说有什么启示？在实际操作中，大家会如何保证RAG知识库的质量和时效性，避免知识库过时导致AI“乱说”的问题？是靠人工定期维护，还是有更自动化的方法？
3、这项AI代码评审实践能够复用于各种代码门禁平台或AI辅助编程工具。除了文章提到的测试设计、用例生成、故障模式分析，大家觉得还可以有哪些“脑洞大开”的应用场景？或者说，你希望未来AI能在代码开发流程的哪个环节带给你最大的惊喜或便利？
原文内容
摘要
本文介绍在C3级代码仓库中落地LLM代码评审的Agent实践。针对C3仓库禁用闭源模型的安全要求，基于Qwen3-Coder、RAG、Iflow实现，通过百炼Embedding构建知识索引，RAG知识库与生产代码同仓管理，文档与代码共生命周期保障一致性，AI辅助人工代码评审。
在CI流水线监听代码修改自动触发AI评审，LLM进行代码解释、逻辑分析和识别并发缺陷、资源泄漏、边界错误、性能瓶颈及规范问题。以块存储C/C++百万行大库为例，已累计执行上千次评审，并部署至存储统一代码门禁平台，支持平台接入所有仓库。
实践表明，AI可有效发现传统CR易忽略的逻辑风险，已数十次成功拦截高危缺陷，显著提升评审效率与质量。当前持续优化准确性、误报率、采纳率，增强上下文感知，探索修复建议生成。该实践可复用于各类代码门禁平台或AI辅助编程工具。
人机协同：AI代码评审的优势和局限
术语说明
1.RAG（Retrieval-Augmented Generation）：是一种融合检索与生成的技术，通过从外部知识库（如文档、数据库）获取信息并注入提示（Prompt），使大语言模型基于最新、可信数据生成回答，提升准确性与实时性，缓解知识局限、幻觉和安全风险，广泛应用于私域知识问答场景。
3.Qwen3-Coder：一个480B 参数、35B有效参数、原生支持256K上下文的开源 MoE 智能编程引擎。
应用场景
Code Review 是 LLM 辅助的理想切入点，因为代码评审容错性高，且旨在增强而非取代人工环节。
然而，传统人工评审成本高、效率低，且评审质量严重依赖个人经验，复杂系统的逻辑缺陷和深层问题容易被遗漏。团队虽已使用 Copilot 完成数千次评审，但其发现的问题主要集中于语法级错误，缺乏上下文理解与逻辑推理能力，难以识别系统级缺陷；如果没有见过具体垂直领域的保密数据，模型通常在某个公司内部具体业务系统上表现欠佳。
同时，团队主仓库为 C3 级安全等级，无法使用 Cursor、Qoder 等工具。团队基于 Qwen3-Coder 构建评审 Agent，通过 RAG 注入私域知识（如设计文档、历史缺陷），增强 LLM 的上下文感知能力，并结合 Iflow 实现自动化工作流。Agent 部署于 CI 流水线，代码提交后自动触发评审，如下图所示，辅助开发者完成逻辑检查与风险分析，提升代码评审效率与质量。
|
示例 1
代码改动5000行左右
|
示例 2
代码改动1500行左右
|
|
风险采纳率80%（8个被采纳：潜在越界，除零，参数错配等问题）
|
Top2 风险采纳：1. 缺失边界索引检查；2.多线程并发访问
|
优势局限
LLM + RAG 代码评审并非替代人工，而是作为“初级评审助手”，在提交前提供自动化逻辑预检。
用户普遍反馈 LLM 评审在代码逻辑总结方面表现出色，在风险分析缺陷发现方面符合预期，已多次有效辅助发现边界场景、并发访问、资源泄漏等缺陷。尽管如此，LLM 评审也存在模型输出不稳定、误报等问题，在对比其风险缺陷发现能力时，LLM+RAG评审与传统方法的优劣势如下表所示：
如何构建：Qwen3-Coder+RAG实现
工作流部署
流程：Webhook代码监听 → 知识库向量检索 → Promp引导拼接 → 输入LLM → 输出返回结果；
实现：RAG + Iflow + Qwen3-Coder，RAG使用的是百炼的 text-embedding-v4 模型进向量数据库索引；
知识库构建
输入给LLM之前进行RAG检索的时候，是从Agent服务所在的本地向量数据库faiss消费数据，并非从git仓库实时获取；git仓库管理知识库只是作为人与人之间方便共享、知识库与代码之间同步的远程存储工具；所以RAG每次检索并非git仓库最新的版本，而是离线定时更新Word2Vec到本地向量知识库（该实现机制和Cursor的Code2Vec和Word2Vec后台向量知识库更新一致）。
代码仓库Documentation包含design/test目录保存文档，ebs/Documentation/README.md 文件如下图所示：
提示词设计
-
Prompt 模板设计： 角色 + 原则 + CoT思维链 + 输出规范 + Few-Shot 少样本学习，引导 LLM；
-
交互策略设计： 区分 For Reviewer (逻辑解释)、For Submitter (风险分析)、LLM汇总 三种角色。
For Reviewer.md
你的任务是生成一份专业的 EBS CodeReview 分析报告，供代码审查者参考。报告必须包含以下结构和内容:格式要求
1. 使用 Markdown 格式
2. 标题为 “# EBS CodeReview For Reviewer 总结报告”
3. 报告必须保存到 /tmp/ebs_code_review.{PatchId}.reviewer.md 文件中
4. 使用 加粗 标记关键信息和重要结论
5. 使用项目符号列表组织内容，使结构更清晰
6. 每个主要章节使用 ## 标题，子章节使用 ### 标题内容要求
1. 代码变更核心目的:
- 明确描述本次代码变更要解决的核心问题或实现的功能
- 简洁清晰，直击要点
- 使用加粗突出核心目的2. 代码变更原因和原理:
- 详细说明变更的技术背景和原因
- 深入分析实现原理和设计思路
- 解释关键技术点和创新之处
- 按小节组织内容（如：变更背景、实现原理等）3. 主要变更点概览:
- 按模块分类列出所有重要变更
- 对每个变更点提供详细说明
- 指出关键文件和函数的修改
- 使用加粗和项目符号突出重要信息
- BlockMaster 端、Client 端、协议层等分别详细说明4. 对 EBS 系统的影响和作用:
- 分析变更对系统整体架构的影响
- 评估性能、稳定性、安全性等方面的改进或风险
- 说明变更的业务价值
- 使用加粗突出正面影响和潜在风险5. Code Review 重点关注:
- 从架构设计、性能优化、异常处理、代码质量等维度指出需要重点关注的地方
- 指出潜在的风险点和技术债
- 提供具体的审查建议
- 按维度分类（架构设计层面、性能优化方面、异常处理方面、代码质量方面等）6. 建议和改进点:
- 基于深入分析提出具体的改进建议
- 按风险等级分类建议项（如：性能监控、配置调优、错误处理优化等）内容深度要求
1. 分析必须全面、深入、细致，不遗漏任何重要变更点
2. 每个技术点都要解释清楚原因和实现方式
3. 要结合 EBS 系统特点进行分析
4. 要具体指出文件名、函数名、关键代码逻辑
5. 要评估影响，包括正面和负面表达方式要求
1. 使用专业但易懂的技术术语
2. 使用加粗强调关键信息、重要结论、核心概念
3. 使用项目符号列表组织并列内容
4. 使用清晰的逻辑结构，段落之间有良好的过渡
5. 条理清晰，先总后分，先重要后次要分析流程
1. 通过读取以下文件获取 Patch 修改的基本信息:
1.1 /tmp/ebs_code_review.{PatchId}.merge_request_detail (Patch 基本内容)
1.2 /tmp/ebs_code_review.{PatchId}.changed_files_list (变更文件列表)
1.3 /tmp/ebs_code_review.{PatchId}.changed_files_diff (详细变更信息)
1.4 /tmp/ebs_code_review.{PatchId}.doc (钉钉文档内容，可能不存在)2. 深入分析代码变更:
2.1 仔细阅读每个变更文件的 diff
2.2 理解变更的核心目的和实现原理
2.3 结合 EBS 系统架构进行分析3. 利用辅助工具增强分析:
3.1 使用 ebs_doc_rag 工具获取 EBS 架构文档
3.2 使用 ebs_doc_rag 工具获取 EBS 代码规范
4. 生成专业报告:
4.1 报告内容必须准确、详细、有条理
4.2 分析必须深入、客观、有理有据
4.3 重点关注点必须具体、可操作
4.4 务必参考示例文件的格式和表达方式
For Submitter.md
你的任务是生成一份专业的 EBS CodeReview Bug 分析报告，供代码提交者参考以改进代码质量。报告必须包含以下结构和内容:格式要求
1. 使用 Markdown 格式
2. 标题为 “# EBS CodeReview ForSubmiter 总结报告”
3. 报告必须保存到 /tmp/ebs_code_review.{PatchId}.submitter.md 文件中
4. 使用 加粗 标记关键信息和重要结论
5. 使用项目符号列表组织内容，使结构更清晰
6. 每个主要章节使用 ## 标题，子章节使用 ### 标题
7. 问题描述使用标准格式（风险等级标识、问题标题、问题描述、代码范围、修改建议）内容要求
1. 代码变更核心目的:
- 简明扼要地重述本次代码变更的核心目的
- 说明变更的技术背景
- 使用加粗突出核心目的2. 主要变更原理:
- 按模块详细分析各个部分的实现原理
- 重点解释关键技术点和设计思路
- BlockMaster端、客户端、协议层等分别详细说明
- 使用加粗和项目符号突出重要信息3. 发现的问题和修改建议:
- 按风险等级分类（高风险
中风险
低风险）
- 每个问题必须包含：
清晰的问题标题（带风险等级标识）
详细的问题描述
具体的代码范围（文件名和行号）
明确的修改建议
- 问题必须基于代码分析，有理有据，不能无中生有
- 使用加粗突出关键问题和建议4. 测试代码分析:
- 分析测试代码是否覆盖了关键场景
- 评估测试的完整性和有效性
- 指出测试中可能存在的问题或改进建议
- 使用加粗突出测试覆盖情况和改进建议5. 总结:
- 综合评估代码变更的整体质量
- 提出最终建议
- 使用加粗突出最终结论分析维度要求
在分析问题时，请从以下维度全面评估代码质量：
- 逻辑正确性：新增代码逻辑是否正确实现预期功能
- 边界条件：异常情况、边界值处理是否完善
- 资源管理：内存、文件句柄等资源是否正确释放
- 并发安全：多线程环境下是否存在竞态条件
- 性能影响：是否有潜在性能瓶颈或不当的性能优化
- 安全性：是否存在安全漏洞或不当的安全处理
- 可维护性：代码结构、命名、注释是否清晰
- 兼容性：是否存在兼容性问题
- 可扩展性：是否存在可扩展性问题内容深度要求
1. 分析必须全面、深入、细致，不遗漏任何重要问题
2. 每个问题都要详细描述原因和影响
3. 要结合 EBS 系统特点进行分析
4. 要具体指出文件名、函数名、行号
5. 要提供可操作的修改建议表达方式要求
1. 使用专业但易懂的技术术语
2. 使用加粗强调关键信息、重要结论、核心概念
3. 使用项目符号列表组织并列内容
4. 使用清晰的逻辑结构，段落之间有良好的过渡
5. 条理清晰，先总后分，先重要后次要
6. 问题描述要结构化，便于理解和修复分析流程
1. 通过读取以下文件获取 Patch 修改的完整信息:
1.1 /tmp/ebs_code_review.{PatchId}.merge_request_detail (Patch 基本内容)
1.2 /tmp/ebs_code_review.{PatchId}.changed_files_list (变更文件列表)
1.3 /tmp/ebs_code_review.{PatchId}.changed_files_diff (详细变更信息)
1.4 /tmp/ebs_code_review.{PatchId}.doc (钉钉文档内容，可能不存在)
1.5 /tmp/ebs_code_review.{PatchId}.reviewer.md (Reviewer分析报告，帮助理解变更目的)2. 深入分析代码变更:
2.1 逐文件、逐段分析所有代码变更
2.2 结合上下文全面理解代码逻辑
2.3 识别潜在问题和改进点3. 利用辅助工具增强分析:
3.1 使用 ebs_doc_rag 工具获取 EBS 代码规范
3.2 使用 ebs_doc_rag 工具获取 EBS 架构信息
4. 生成专业报告:
4.1 按风险等级分类所有发现的问题
4.2 每个问题都必须有明确的修改建议
4.3 报告结构清晰，内容准确详实
4.4 务必参考示例文件的格式和表达方式
LLM汇总.md
1. 读取核心报告总结内容 1.1 CodeReview For Reviewer 的报告总结文件路径: /tmp/ebs_code_review.{PatchId}.reviewer.md 1.2 CodeReview For Submitter 的报告总结文件路径: /tmp/ebs_code_review.{PatchId}.submitter.md 1.3 CodeReview 生成的总体流程图的 Url 链接存放路径: /tmp/ebs_code_review.{PatchId}.url 2. 整合多分报告, 并按照 Markdown 方式合并生成. 注意: 必须不能遗漏, 清晰分类, 重复的只保留 For Reviewer, 链接要支持用 [总体流程分析链接](...) 方式跳转 2.1 结果要写入到本地 /tmp/ebs_code_review.{PatchId}.summary 2.1 输出结果 - 代码变更核心目的 (背景 + 目的) - 主要变更原理 - 代码审查发现的潜在问题 - 测试代码覆盖情况 - 对 EBS 系统的影响和作用 (正面影响 + 潜在风险) - 总结
3. 通过 aone mcp comment_merge_request 接口统一上传到 CR 中
落地实践：CI代码门禁的自动化集成
CI 流水线集成
我们与存储代码门禁平台团队合作，将AI Agent工作流嵌入到门禁平台，支持平台所有接入仓库，不同角色的实现交互：
代码门禁webhook监听触发的AI评审任务列表如下图所示：
上下文构建
代码评审聚合“在线上下文”（短期记忆）和“离线知识库”（长期记忆）信息，构建成一个完整的Prompt输入给大模型作为决策依据。
每个Patch强制要求关联Aone单，建议关联设计/测试钉钉文档，标准规范Git Log Message如下图所示：
仓库所有历史代码提交均关联Aone需求/缺陷单，如下图所示：
评审效果
LLM 代码评审的用户交互反馈功能开发中，暂无全量的采纳率、误报率等量化数据，初见效果：
1.累计使用次数：已在EBS仓库代码门禁触发上千次LLM代码评审，日均 1W 次模型调用、5 亿 Token 使用量；
2.评审效率：10 分钟/次：从PR创建到收到AI首轮评论，大幅缩短了代码评审的等待周期；
3.发现问题多样性：不限于编码错误，多次识别出深层次的并发问题、边界场景和资源泄漏等。
根据开发者用户反馈，LLM 代码逻辑解释总结能力很强，For Reviewer 大幅提到的代码理解效率；For Submitter 风险发现能力有待提升，褒贬不一，抽样选择了L/M/S/XS的PR，代码修改行数分别是5000行/1500行/300行/30行的评审质量对比，存在100%建议全部被Accept的情况，也存在100%建议被Ignore的情况，评审质量很大程度取决于Code Diff聚合程度和Git Log Message的质量，部分用户反馈如图：
最佳实践：开发者和维护者协同机制
开发使用建议
结合前文所述，Prompt上下文引导融合了Patch特有的“在线上下文”和系统通用“离线知识库”信息，实践验证，上下文和 Prompt 质量对输出影响很大，对于开发者而言，有如下建议：
系统维护经验
在系统维护过程中，我们发现理论上的“最优”并不总是等于实践中的“有效”，分享一些尝试经验：
持续探索：AI 代码评审复用优化演进
复用场景
一次企业级安全要求 RAG+开源LLM代码评审探索，该方法具备高度的通用性和扩展性：
1.“LLM评审功能” 横向复用： 将当前AI Agent封装为标准化的原子能力，嵌入到代码门禁平台或作为IDE插件，让其他团队仅需维护自己的知识库即可“开箱即用”。
2.“RAG+开源LLM” 纵向拓展： 知识库不仅能服务于代码评审，亦可辅助 Feature 测试设计、用例生成、故障模式分析等，实现“一次沉淀，多次复用”。
优化方向
维护经验表明，提升AI评审质量并非依赖单一技巧，而是必须建立系统化的调优流程。核心在于构建“反馈-评估-优化”闭环，依托固定评测集和量化指标，系统性排查知识库质量、向量切片策略、RAG检索精度、Prompt引导方式及LLM能力边界等关键因素。
实践中，“模型+Prompt+知识库+参数”的任意组合变化均可能引发结果波动，组合爆炸导致验证成本显著上升。要将AI评审打造成真正有效助力开发提效的工具，需持续投入人力进行工程打磨，开展充分的回归测试与A/B验证，确保迭代可衡量、效果可预期。
原生 SQL 轻松实现多模态智能检索
传统 AI 开发需将数据从 OLTP 数据库迁移至专用向量库实现特征匹配，跨系统数据搬运会引发多环境数据冗余、版本混乱等核心问题。本方案基于阿里云 PolarDB 与阿里云百炼，融合 Polar_AI 智能插件，赋予数据库原生的 AI 能力。通过标准 SQL 语法直接调用多模态 AI 服务，高效完成图像特征提取与向量化处理。
点击阅读原文查看详情。