基于大模型的GitLab CodeReview 技术调研

初心丨哈士奇2025-03-12 20:58

消失已久，重回掘金，今天哈士奇为大家带来了针对大模型的gitlab的codereview方案，在后期也会分享具体实操的过程，希望能够帮助到大家在为公司接入大模型提供一些技术方案，同时最下面也有参考文献，大家也可以看看哈士奇整合的参考文献。

痛点

提高代码审查效率

1、大模型可快速扫描代码，自动识别语法错误、代码风格不一致（如缩进、命名规范）、简单的逻辑错误等，减少人工审查的重复性劳动。（只需要接入知识库加入企业的代码规范，就可以解决此问题）

2、在频繁提交或大规模代码变更时，大模型能并行处理多个审查任务，避免人工审查成为开发流程的瓶颈。

提高代码质量

1、大模型能分析代码的上下文逻辑，发现潜在的死循环、边界条件错误、资源泄漏（如未关闭文件句柄）等问题。

2、检测常见安全漏洞（如SQL注入、XSS、硬编码凭证），甚至结合上下文建议修复方案。

3、识别代码冗余或低效实现，建议更优的设计模式或算法（例如用哈希表替代多层循环）。

需求分析

  • 提交代码至GitLab
  • 大模型CodeReview代码
  • 对于代码中不合理的部分进行评论
  • 发送到飞书工作信息

开发语言技术选型

Python 与Node.js

1. 核心场景适配性对比

维度 Python 优势 Node.js 优势
AI / 大模型 集成 生态完善（PyTorch/TensorFlow/OpenAI库） 需通过API调用或外部库（如ai模块）
异步高 并发 异步支持较弱（需asyncio） 原生事件循环，适合高并发Webhook场景
开发效率 语法简洁，适合快速验证AI逻辑 适合构建轻量级API服务
代码审查场景 更易处理代码解析（AST操作库丰富） 需依赖第三方库（如acorn解析JS代码）

2. 典型场景推荐

选择 Python 更适合：
  • 需要直接调用本地 大模型（如Code Llama本地部署，需GPU加速）。
  • 涉及复杂代码分析 （如用libcst解析Python代码，或用tree-sitter跨语言解析）。
  • 团队已有 Python 技术栈（如熟悉FastAPI/Flask框架）。
  • 需快速实现与 大模型 交互的 提示词 工程（Python的文本处理更直观）。
选择 Node.js 更适合：
  • 高并发 Webhook 处理（如每秒处理数十个GitLab事件）。
  • 前后端统一技术栈（如前端用React，后端用Node.js保持一致性）。
  • 轻量级中间服务（仅需转发请求到模型API并返回结果）。
  • 实时流式响应（如通过SSE向GitLab实时推送审查进度）。

3. 关键代码实现对比

Python 示例（FastAPI + GPT-4 API调用）
python 复制代码 
from fastapi import FastAPI
import openai

app = FastAPI()

@app.post("/code-review")
async def code_review(diff: str):
    response = openai.ChatCompletion.create(
        model="gpt-4",
        messages=[
            {"role": "system", "content": "你是一个代码审查助手"},
            {"role": "user", "content": f"审查代码差异：\n{diff}"}
        ]
    )
    return {"result": response.choices[0].message.content}
Node.js 示例（Express + OpenAI API调用）
ini 复制代码 
const express = require("express");
const OpenAI = require("openai");
const app = express();

app.post("/code-review", async (req, res) => {
  const diff = req.body.diff;
  const openai = new OpenAI({ apiKey: process.env.OPENAI_KEY });
  
  const response = await openai.chat.completions.create({
    model: "gpt-4",
    messages: [
      { role: "system", content: "你是一个代码审查助手" },
      { role: "user", content: `审查代码差异：\n${diff}` }
    ]
  });
  
  res.json({ result: response.choices[0].message.content });
});

4. 决策建议

推荐 Python 的场景：
  • 团队熟悉AI开发，需本地调试大模型。
  • 需结合传统代码分析工具（如pylint、black）。
  • 审查逻辑涉及复杂数据处理（如提取代码AST结构）。
推荐 Node.js 的场景：
  • 已有Node.js微服务架构，需快速集成。
  • 审查服务需与其他JavaScript工具链交互（如ESLint插件）。
  • 要求低延迟响应（如异步队列处理）。

5. 混合架构可能性

  • Python 作为 AI 核心层：专用于模型推理和复杂分析。
  • Node.js 作为网关层：处理HTTP请求、负载均衡和缓存。

👉 结合两者优势，但复杂度较高，适合中大型项目。

总结

  • 保守选择：优先使用团队更熟悉的语言。
  • AI 密集型选 Python ，高 并发 I/O选Node.js。
  • 如果从零开始且无历史包袱，Python 更适合 CodeReview 场景（生态碾压性优势）

大模型对比

模型名称 特点 开源/商用 适用场景
Code Llama Meta开源代码模型，支持多语言，可本地部署 开源 定制化需求、私有化部署
GPT-4/Codex OpenAI通用模型，代码理解能力强，需API调用 商用API 快速集成、多语言支持
StarCoder BigCode开源模型，支持代码生成与审查 开源 本地化、低成本场景
DeepSeek-Coder 国产代码大模型，中文支持较好 商用/开源 中文代码注释场景
QWQ 阿里开源代码大模型，中文支持较好，需要配置不高 商用/开源 本地化、低成本、中文代码注释场景

这里比较推荐QWQ，原因在于仅需要32B就能达到DeepSeek的671B相似的效果，相对来说比DeepSeek的32B的蒸馏模型要强许多

技术实现方案

方案一：基于GitLab CI/CD 流水线

1. 流程图：

2. 实现步骤

1. 配置GitLab CI/CD 流水线

目标：当Merge Request（MR）创建或更新时，自动触发代码审查。

步骤：

  1. 创建 .gitlab-ci.yml文件
yaml 复制代码 
stages:
  - code_review

variables:
  OPENAI_API_KEY: $OPENAI_API_KEY  # 在GitLab CI设置中配置此变量

code_review:
  stage: code_review
  image: node:18  # 使用Node.js镜像
  script:
    - npm install axios  # 安装依赖
    - node code-review.js  # 运行审查脚本
  rules:
    - if: $CI_MERGE_REQUEST_IID  # 仅在有MR时触发
  1. 编写Node.js审查脚本（ code-review.js）：
javascript 复制代码 
const axios = require('axios');
const { execSync } = require('child_process');

// 获取MR的Diff
const diff = execSync(`curl --header "PRIVATE-TOKEN: ${process.env.GITLAB_TOKEN}" "${process.env.CI_API_V4_URL}/projects/${process.env.CI_PROJECT_ID}/merge_requests/${process.env.CI_MERGE_REQUEST_IID}/diffs"`).toString();

// 调用本地Ollama API
async function codeReview(diff) {
  const response = await axios.post(
    'http://localhost:8000/api/v1/code-review', // 假设本地Ollama API运行在这个地址
    {
      model: "ollama-gpt-4",
      messages: [
        { role: "system", content: "你是一个资深代码审查助手，请分析以下代码差异，指出潜在问题并提供建议。" },
        { role: "user", content: diff }
      ]
    },
    { headers: { Authorization: `Bearer ${process.env.OLLAMA_API_KEY}` } }
  );
  return response.data.choices[0].message.content;
}

// 提交评论到GitLab MR
async function postComment(comment) {
  await axios.post(
    `${process.env.CI_API_V4_URL}/projects/${process.env.CI_PROJECT_ID}/merge_requests/${process.env.CI_MERGE_REQUEST_IID}/notes`,
    { body: `### AI代码审查结果\n${comment}` },
    { headers: { 'PRIVATE-TOKEN': process.env.GITLAB_TOKEN } }
  );
}

// 主流程
codeReview(diff)
  .then(postComment)
  .catch(err => console.error('Error:', err.message));
2. 环境变量配置

  • 在GitLab仓库的 Settings > CI/CD > Variables 中添加：

    • OPENAI_API_KEY: OpenAI API密钥
    • GITLAB_TOKEN: 具有API访问权限的GitLab Personal Access Token（需勾选api权限）
3. 关键要点
  • Diff获取：通过GitLab API获取MR的代码差异。
  • 结果提交：使用GitLab Notes API将结果以评论形式添加到MR。
  • 安全性：敏感信息通过CI/CD变量传递，避免硬编码。

方案二： Webhook + 中间服务

  1. 部署中间服务监听GitLab Webhook事件。
  2. 服务端调用大模型处理代码差异（Diff），通过GitLab API回写评论。

1. 流程图

2. 实现步骤

步骤1：创建Express.js服务

javascript 复制代码 
const express = require('express');
const bodyParser = require('body-parser');
const crypto = require('crypto');
const axios = require('axios');

const app = express();
app.use(bodyParser.json());

// 验证Webhook签名（防止伪造请求）
function verifySignature(req, secret) {
  const signature = req.headers['x-gitlab-token'];
  return signature === secret;
}

// 处理Merge Request事件
app.post('/webhook', async (req, res) => {
  if (!verifySignature(req, process.env.WEBHOOK_SECRET)) {
    return res.status(403).send('Invalid signature');
  }

  const { object_attributes } = req.body;
  if (object_attributes.action === 'open' || object_attributes.action === 'update') {
    const diffUrl = `${object_attributes.target.web_url}/diffs?private_token=${process.env.GITLAB_TOKEN}`;
    const diffResponse = await axios.get(diffUrl);
    const reviewResult = await callAIModel(diffResponse.data);
    await postGitLabComment(object_attributes.target_project_id, object_attributes.iid, reviewResult);
  }

  res.status(200).send('OK');
});

// 调用本地Ollama API
async function callAIModel(diff) {
  const response = await axios.post(
    'http://localhost:8000/api/v1/code-review', // 假设本地Ollama API运行在这个地址
    {
      model: "ollama-gpt-4",
      messages: [
        { role: "system", content: "请审查以下代码变更：" },
        { role: "user", content: diff }
      ]
    },
    { headers: { Authorization: `Bearer ${process.env.OLLAMA_API_KEY}` } }
  );
  return response.data.choices[0].message.content;
}

// 提交评论到GitLab
async function postGitLabComment(projectId, mrIid, comment) {
  await axios.post(
    `https://gitlab.com/api/v4/projects/${projectId}/merge_requests/${mrIid}/notes`,
    { body: `AI Review: ${comment}` },
    { headers: { 'PRIVATE-TOKEN': process.env.GITLAB_TOKEN } }
  );
}

app.listen(3000, () => console.log('Server running on port 3000'));

步骤2：配置GitLab Webhook

  1. 进入GitLab仓库的 Settings > Webhooks
  2. 填写URL：https://your-service.com/webhook
  3. 设置Secret Token（需与代码中WEBHOOK_SECRET一致）
  4. 触发事件选择 Merge Request events

步骤3. 部署中间服务

使用Docker部署（示例 Dockerfile）：

sql 复制代码 
FROM node:18-slim
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["node", "server.js"]

环境变量：

ini 复制代码 
# .env文件
OPENAI_API_KEY=your_openai_key
GITLAB_TOKEN=your_gitlab_token
WEBHOOK_SECRET=your_webhook_secret

技术区别

1. 触发机制

方案 触发方式 依赖关系
GitLab CI/CD 流水线 通过.gitlab-ci.yml配置，在代码提交或合并请求（MR）时自动触发流水线任务 强依赖GitLab Runner和CI/CD环境
Webhook + 中间服务 通过GitLab Webhook监听代码事件（如MR创建），被动触发外部服务 依赖独立的中间服务（如K8s Pod）

关键区别：

  • CI/CD方案与GitLab原生流程深度绑定，适合已有成熟CI/CD管道的团队。
  • Webhook方案更灵活，可独立于GitLab Runner运行，适合需要自定义事件处理逻辑的场景。

2. 架构复杂度

方案 架构 维护成本
GitLab CI/CD 流水线 轻量级，仅需编写CI脚本和模型调用逻辑 低（复用现有CI/CD基础设施）
Webhook + 中间服务 需部署独立服务（如FastAPI/Flask应用） 高（需维护服务可用性、监控等）

关键区别：

  • CI/CD方案适合快速验证，无需额外运维；
  • Webhook方案适合长期大规模使用，但需处理服务高可用、负载均衡等问题。

3. 资源消耗

方案 资源占用场景 性能瓶颈
GitLab CI/CD 流水线 每次触发启动独立Runner，短时占用资源 Runner并发能力、模型响应延迟
Webhook + 中间服务 中间服务常驻运行，长期占用计算资源 服务端GPU/CPU资源、请求队列管理

关键区别：

  • CI/CD方案资源按需分配，适合低频次审查；
  • Webhook方案需预留固定资源，适合高频次或实时性要求高的场景。

4. 扩展性与灵活性

方案 扩展能力 定制化场景
GitLab CI/CD 流水线 受限于GitLab Runner配置，扩展性较弱 适合简单逻辑（如单模型调用）
Webhook + 中间服务 可自由扩展（如多模型路由、异步队列等） 适合复杂逻辑（如混合审查策略）

关键区别：

  • Webhook方案可通过中间服务实现 异步处理、多模型协同 等高级功能，而CI/CD方案多为同步阻塞式调用。

5. 数据隐私与安全

方案 隐私风险 缓解措施
GitLab CI/CD 流水线 若使用云端模型API，代码可能外泄 仅限本地模型或私有化部署
Webhook + 中间服务 中间服务可完全私有化部署，控制数据流向 内网隔离+模型本地化

关键区别：

  • Webhook方案更易实现端到端私有化（代码→模型→结果均在内部网络流转）。

6. 适用场景推荐

方案 推荐使用场景
GitLab CI/CD 流水线 - 小型团队快速验证 低并发场景 无需复杂逻辑的轻量级审查
Webhook + 中间服务 - 企业级高频次审查 需要混合模型策略 （如Code Llama+SonarQube） 数据敏感场景

总结

能力 CI/CD 方案 Webhook 方案
触发时机 MR创建/更新时立即触发 实时性更高，可处理更复杂事件流
复杂度 简单，只需维护CI脚本 需维护独立服务+基础设施
扩展性 有限，依赖GitLab Runner配置 高，可自由添加队列、缓存等组件
适合场景 中小项目快速落地 企业级应用，需高可靠性和扩展性
前端 友好度 需学习GitLab CI语法 可用Node.js实现，技术栈更匹配
  • CI/CD 方案：若团队已有GitLab CI/CD经验，且需求简单，优先快速落地。
  • Webhook 方案：若需长期稳定运行、高频调用或深度定制，建议投入中间服务开发。

其他 功能实现

代码差异提取

  • 使用git diff或GitLab API获取变更代码片段。
  • 示例：GET /projects/{id}/merge_requests/{mr_iid}/diffs

大模型提示词设计

  • 结构化提示词模板以提高审查准确性：

哈士奇在下面已经写了一个提示词模板，如果比较懒可以复制粘贴

markdown 复制代码 
## 1.Commit 规模检查
### 1.1 ⽂件数量检查
- 确认修改文件数是否在合理范围内。一般来说，若一次提交修改文件数较少（如不超过 5 个），可能意味着提交过于细碎，缺乏关联
- 如果超过 20 个文件，需要提交者说明修改的整体性和关联性，判断是否有必要拆分为多个 commit 以保证版本历史的清晰性。
### 1.2 代码行数检查
- 确认修改总⾏数是否在合理范围。少量的修改（如不超过 100 行）可能是简单的修复，若超过 2000 行，要评估修改的复杂性和风险。
- 如果超过 2000 行，提交者需详细说明修改内容和目的，审查者要重点检查对现有功能的影响以及是否引入新的问题。同时，评估是否可以将大的修改拆分成更细粒度的提交。
## 2.代码质量检查
### 2.1 基础检查项
- 确认代码能够正常编译
- 确认是否通过所有安全
- 检查是否存在测试数据
### 2.2 样式处理 
- 检查是否存在可以用 CSS 实现的逻辑却使用了 JavaScript。优先使用 CSS 来处理布局、动画、样式切换等效果
- 对于复杂的 JS 样式计算，需要满足以下条件：
    - 考虑过纯 CSS 解决⽅案。在使用 JavaScript 进行样式计算之前，先尝试使用 CSS 的特性（如 Flexbox、Grid、CSS 动画等）来实现相同的效果。
    - 参考过竞品实现⽅式。了解其他类似产品或优秀开源项目是如何处理相同或相似的样式需求的，从中获取灵感和最佳实践。
    - 在团队中讨论过技术⽅案。与团队成员共同探讨使用 JavaScript 处理样式的必要性和可行性，确保方案的合理性和一致性。
- 避免使⽤内联样式 
- 禁⽌滥⽤ !important 
- 复杂样式计算必须团队评审
### 2.3 数据处理
- 使⽤早期返回提⾼代码可读性 
- 检查变量是否在函数/组件的合适作用域内定义。避免使用全局变量，尽量将变量的作用域限制在最小范围内，以提高代码的可维护性和可测试性。
- 避免深层嵌套中的数据访问。深层嵌套的数据结构（如 `obj.a.b.c`）会使代码难以理解和维护，建议使用解构赋值或中间变量来简化数据访问。
- 检查是否过度使⽤可选链操作符。
- 确保数据处理逻辑遵循单一职责原则。每个函数或组件应该只负责一个明确的数据处理任务，避免一个函数处理过多不同类型的数据操作。
- 对于异步数据处理，要处理好错误情况和加载状态。使用 `try...catch` 块捕获异步操作中的错误，并在界面上正确显示加载状态和错误信息。
### 2.4 性能优化
- 避免不必要的重渲染 
## 3. ⼯具使⽤规范 
### 3.1 组件库使⽤ 
- 优先使⽤团队基础组件 
- ⾃定义组件需要团队评审 
- 禁⽌⼤量覆盖基础组件样式
- 检查数字处理是否使⽤合适的库。对于复杂的数字计算（如货币计算、精度处理等），建议使用专业的库（如 `decimal.js`）来避免 JavaScript 原生数字计算的精度问题。
### 3.2 工具与文件处理
- 检查⽂件⼤⼩处理是否合理。对于图片、字体等静态资源，要进行压缩和优化，避免引入过大的文件影响页面加载速度。可以使用工具（如 ImageOptim、TinyPNG 等）对图片进行压缩。
- 检查是否使⽤了已有的工具函数或组件。避免重复造轮子，优先使用团队内部或开源社区提供的工具函数和组件，提高开发效率和代码质量。
## 4. 代码风格检查
### 4.1 命名规范
- CSS 类名和⽂件名使⽤ kebab-case（短横线分隔）
- Interface 类型使⽤ PascalCase（大驼峰命名）
- Props 回调函数使⽤ camelCase 并以 `on` 开头
- 内部处理函数使⽤ `handle` 开头的 camelCase
- 常见事件处理函数命名遵循通用约定（如 `handleClick`、`handleExpand`），保持命名的一致性和可读性
- 变量和函数名使用有意义的名称，能够清晰表达其用途和功能，避免使用无意义的缩写或单字母命名。
### 4.2 代码整洁度
- 检查是否存在⼤段注释。如果注释内容过多，可能意味着代码本身的可读性较差，需要考虑重构代码，使代码本身更易于理解。对于必要的注释，要保持简洁明了
- 检查是否存在未使⽤的变量、函数或导入语句。及时清理这些无用的代码，避免代码库的臃肿
- 检查是否存在冗余代码。对于重复的代码逻辑，要进行提取和复用，提高代码的可维护性和可扩展性
- 代码缩进和空格使用要统一，遵循团队的代码格式化规范（使用 Prettier 进行格式化）
### 4.3 代码结构规范
- 组件文件内部结构要清晰，按照一定的顺序组织代码，例如先导入模块，再定义常量和变量，然后是函数和组件，最后是导出语句
- 对于大型组件或复杂逻辑，要进行适当的拆分，将不同的功能封装成独立的子组件或函数，提高代码的可维护性
### 4.4 注释规范
- 函数和类需要添加 JSDoc 注释，说明函数的功能、参数、返回值等信息，方便其他开发者理解和使用
- 关键代码逻辑处要添加注释，解释代码的意图和实现思路，尤其是复杂的算法或业务逻辑
- 避免使用无意义的注释，注释要与代码的实际功能相关
## 5. 开发准则 
### 5.1 代码质量原则 
- 遵循 DRY（Don't Repeat Yourself）原则 
- 优先考虑代码可读性，其次是性能优化 
- 保持代码简洁，避免过度⼯程化 
- 确保代码完整性，不遗留 TODO 或占位符 
### 5.2 开发流程规范 
- 编写代码前先进⾏详细的技术⽅案设计 
- 使⽤伪代码描述实现逻辑，再进⾏具体编码 
- 确保所有功能完整实现，不留未完成项 
- 编写代码时必须包含必要的类型定义和导⼊声明 
### 5.3 代码审查准则 
- 确保代码符合团队最佳实践 
- 验证功能完整性和正确性 
- 检查组件命名的规范性和语义性 
- 确认是否有遗漏的依赖项或类型定义
### 反馈格式
请按照以下格式提供审查反馈：
1. 严重问题（如有）：
 - 影响系统运⾏或安全的问题，如编译错误、安全漏洞等。
 - 需要⽴即修复的架构问题，如跨层调用、数据层与视图层未分离等。
2. 常规问题：
 - 代码质量问题，如变量作用域不合理、过度使用可选链等。
 - 规范违反问题，如命名不规范、未遵循样式处理规范等。
 - 性能优化建议，如文件大小未处理、组件嵌套过多等。
3. 改进建议：
 - 代码可读性改进，如添加注释、优化命名等。
 - 最佳实践建议，如使用合适的工具库、遵循架构分层等。
 - 其他优化建议，如代码结构调整、兼容性处理等。

飞书转发消息

1、通过飞书群机器人转发消息

2、通过飞书机器人发送给本人

结果处理与展示

  • 将模型输出解析为GitLab评论格式：
markdown 复制代码 
### 代码审查结果（AI生成）
- ⚠️ **潜在问题**：第15行未处理空指针异常。
- ✅ **建议**：使用Optional类型注解改进可读性。

注意事项

广域网访问问题

在使用过程中考虑到webhook的访问问题，因此考虑了一些其他方案，一般建议部署到公司云服务器上面

方案一：云服务器部署（推荐）

适用场景：追求高效稳定、无本地硬件依赖、需长期使用

步骤：

选择云服务商

  • 推荐阿里云（华东1/2区）、腾讯云（上海/南京）或AWS（中国香港），确保两地延迟<30ms。

  • 配置建议：

    • CPU：8核（如AMD EPYC）

    • GPU：A10或A100（根据模型大小选择）

    • 内存：64GB+

    • 带宽：10Mbps以上（突发至50Mbps）

部署Ollama

  • 登录云服务器控制台，安装Linux系统（如Ubuntu 22.04）。

  • 按官方文档安装Ollama并加载模型（需提前下载模型文件至云服务器）。

访问配置

  • 开放11434端口并绑定弹性公网IP。

  • 为安全起见，建议：① 配置Nginx反向代理+SSL证书（免费申请Let's Encrypt）；② 设置访问密码（如ollama auth）。

团队使用

  • 团队成员直接通过公网地址访问（如https://ollama.example.com:11434）。

方案二：本地服务器+ VPN （适合已有高性能设备）

适用场景：已有本地高性能电脑、需数据本地化、团队技术能力较强

步骤：

硬件准备

  • 本地电脑需具备：

    • 高速互联网连接（建议500Mbps+光纤）
    • 固定内网IP（如192.168.1.100）

搭建WireGuard VPN

  • 在本地电脑上部署VPN服务器：

    ini 复制代码 
      # 安装WireGuard
  sudo apt-get install wireguard
  # 生成密钥对
  wg genkey | sudo tee /etc/wireguard/privatekey | wg pubkey | sudo tee /etc/wireguard/publickey
  # 配置wg0.conf
  [Interface]
  Address = 10.8.0.1/24
  ListenPort = 51820
  PrivateKey = [私钥内容]
  PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
  PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

  [Peer]
  PublicKey = [上海成员公钥]
  AllowedIPs = 10.8.0.2/32

  • 外地成员安装WireGuard客户端并配置连接。

访问Ollama

  • 本地电脑启动Ollama服务：ollama serve --host 0.0.0.0 --port 11434
  • 外地成员通过VPN虚拟IP访问：http://10.8.0.1:11434

方案三：内网穿透+ 负载均衡 （低成本过渡方案）

适用场景：临时需求、预算有限、模型较小

步骤：

选择穿透工具

  • 推荐frp（开源免费）或花生壳（付费更稳定）。

配置穿透规则

  • 南京电脑运行frp客户端：

    ini 复制代码 
      [common]
  server_addr = frp.example.com
  server_port = 7000

  [ollama]
  type = tcp
  local_ip = 192.168.1.100
  local_port = 11434
  remote_port = 11434

  • 外地成员通过穿透后的公网地址访问（如http://frp.example.com:11434）。

优化体验

  • 购买穿透服务商的加速节点（如花生壳VIP节点）；
  • 限制同时连接人数（Ollama默认支持10个并发）。

方案对比

维度 云服务器方案 VPN方案 内网穿透方案
延迟 低（<30ms） 中（50-80ms） 高（80-150ms）
稳定性 最高（专业机房） 较高（依赖本地带宽） 较低（依赖服务商）
安全性 高（SSL+云防护） 高（端到端加密） 中（需依赖服务商加密）
成本 中（月费 <math xmlns="http://www.w3.org/1998/Math/MathML"> 50 − 50- </math>50−200） 低（仅需服务器电费） 低（免费/月费 <math xmlns="http://www.w3.org/1998/Math/MathML"> 10 − 10- </math>10−30）
维护难度 低（云服务商托管） 中（需维护VPN服务） 低（配置简单）

建议

优先云服务器：若预算允许且需长期使用，推荐阿里云A10实例（约¥800/月），性能与稳定性最佳。

混合方案：若模型较大但需本地化，可在南京部署本地服务器+云服务器作为备份，通过rsync同步模型文件。

监控与优化：

  • 使用Prometheus+Grafana监控Ollama服务状态；
  • 根据访问日志调整带宽或升级硬件。

数据加密问题

在使用过程中由于异地必须通过互联网发送数据传输考虑到数据安全，需要对于传输数据进行数据加密

后续优化方向

1、添加向量数据库，结合历史代码提交记录或者内部规范 实现rag

2、使用dify创建工作流，使机器人功能更稳定，场景更强

开源方案

GitHub - sunmh207/AI-Codereview-Gitlab: 基于大模型(DeepSeek,OpenAI等)的 GitLab 自动代码审查工具；支持钉钉/企业微信/飞书推送消息和生成

测试效果

deepseek-8b

diff 复制代码 
// 模拟的代码差异内容
const sampleDiff = `
diff --git a/src/components/Button.js b/src/components/Button.js
index 1234567..abcdefg 100644
--- a/src/components/Button.js
+++ b/src/components/Button.js
@@ -1,5 +1,7 @@
 import React from 'react';
+import { useTheme } from '../hooks/useTheme';
+import { trackEvent } from '../utils/analytics';
 
 const Button = ({ onClick, children, disabled }) => {
+  const theme = useTheme();
+  
   return (
-    <button onClick={onClick} disabled={disabled}>
+    <button 
+      onClick={(e) => {
+        trackEvent('button_click');
+        onClick && onClick(e);
+      }} 
+      disabled={disabled}
+      style={{ 
+        color: theme.buttonText, 
+        backgroundColor: theme.buttonBackground,
+        borderRadius: '4px',
+        padding: '8px 16px'
+      }}
+    >
       {children}
     </button>
   );
+
+  // TODO: 添加按钮加载状态
`;
markdown 复制代码 
### 审查反馈：

#### 1. 严重问题：
无。

#### 2. 常规问题：
- **命名规范更正**：修复了@click事件名称不规范的问题，将@click改为handleClick，符合团队命名规范。
  - **影响范围**：需要确保所有调用处都已更新到handleClick事件，以免出现意外的行为。

#### 3. 改进建议：
- **添加按钮加载状态**：在TODO中提及，建议添加按钮加载状态以提升用户体验。
- **优化注释和文档**：增加详细的JSDoc注释，尤其是在复杂逻辑处，以便其他开发者更好地理解代码。
- **主题组件化**：使用useTheme composable可以考虑将按钮样式移动到单独的主题文件中，以便集中管理和扩展。

### 反馈详情：
- **命名规范改进**：事件名称从@click改为handleClick，符合团队命名规范。
- **性能优化**：已使用动态class和style属性，提升了性能表现。
- **代码结构优化**：将逻辑拆分到setup函数中，更利于维护和扩展。

### 结论：
总体来说，修改后的代码更符合团队规范，并且已经考虑到了可扩展性和性能。建议继续添加加载状态功能，并确保所有使用场景已更新到最新的事件名。

---
*此审查基于团队代码规范自动生成，如有疑问请与开发团队讨论。*
diff 复制代码 
diff --git a/src/components/Button.vue b/src/components/Button.vue
index 1234567..abcdefg 100644
--- a/src/components/Button.vue
+++ b/src/components/Button.vue
@@ -1,9 +1,25 @@
 <template>
-  <button @click="onClick" :disabled="disabled">
+  <button 
+    @click="handleClick" 
+    :disabled="disabled"
+    :class="['custom-button', { 'is-disabled': disabled }]"
+    :style="buttonStyle"
+  >
     <slot></slot>
   </button>
 </template>
 
 <script>
-export default {
-  props: {
+import { useTheme } from '../composables/useTheme';
+import { trackEvent } from '../utils/analytics';
+
+export default {
+  name: 'CustomButton',
+  props: {
+    disabled: {
+      type: Boolean,
+      default: false
+    }
+  },
+  setup(props, { emit }) {
+    const theme = useTheme();
+    
+    const buttonStyle = {
+      color: theme.buttonText,
+      backgroundColor: theme.buttonBackground,
+      borderRadius: '4px',
+      padding: '8px 16px'
+    };
+    
+    const handleClick = (e) => {
+      trackEvent('button_click');
+      emit('click', e);
+    };
+    
+    return {
+      buttonStyle,
+      handleClick
+    };
+  }
+};
+// TODO: 添加按钮加载状态
+</script>
+
+<style scoped>
+.custom-button {
+  font-weight: bold;
+  transition: all 0.3s ease;
+}
+.custom-button.is-disabled {
+  opacity: 0.5;
+  cursor: not-allowed;
+}
+</style>
`;
markdown 复制代码 
### 严重问题：
- 没有。

### 常规问题：
- 没有。

### 改进建议：
1. **注释补充**：在组件内部和样式中添加更详细的注释，特别是关于按钮加载状态和其他逻辑。
2. **优化命名**：确保所有class和变量名称符合团队规范，并且语义清晰。
3. **性能检查**：确认是否需要进一步优化样式或结构以提高性能，如减少绘制次数或优化动画。

这个组件已经很好地遵循了最佳实践，没有发现违反任何规定的内容。

---
*此审查基于团队代码规范自动生成，如有疑问请与开发团队讨论。*

参考文献

Introduction | 🦜️🔗 LangChain

Ollama

GitHub - ollama/ollama-js: Ollama JavaScript library

GitHub - ollama/ollama-python: Ollama Python library

【深度揭秘】AIGC驱动下的大模型+知识库集成：Code Review的高效实践_哔哩哔哩_bilibili

【AIGC】基于大模型+知识库的Code Review实践_aigc知识库-CSDN博客

飞书开放平台

基于大模型 + 知识库的 Code Review 实践

向量数据库大比拼：2025年如何选择适合你的工具？-驼峰Geek

开源项目中的人工智能代码审查实践

飞书集成和通知 | 极狐GitLab

基于飞书的webhook功能实现对gitlab的事件通知并@具体成员（二）_gitlab webhook-CSDN博客

Notes API | GitLab Docs

GitLab集成GPT进行自动化CodeReview实战（CI/CD）

相关推荐
answerball21 分钟前
🔥 Vue3响应式源码深度解剖：从Proxy魔法到依赖收集，手把手教你造轮子！🚀
前端·响应式设计·响应式编程
致Great44 分钟前
Gemma 3 27B版本超越DeepSeek V3：技术要点分析！
人工智能·llm
Slow菜鸟1 小时前
ES5 vs ES6：JavaScript 演进之路
前端·javascript·es6
小冯的编程学习之路1 小时前
【前端基础】：HTML
前端·css·前端框架·html·postman
音视频牛哥2 小时前
SmartMediakit在四足机器人和无人机巡检中的创新应用方案
人工智能·机器学习·计算机视觉
致Great2 小时前
推理大模型的后训练增强技术-强化学习篇
人工智能·llm
致Great2 小时前
关于DeepResearch设计实现的碎碎念
人工智能·llm
致Great2 小时前
推理大模型的后训练增强技术--LLM 推理模型的现状
人工智能·llm
致Great2 小时前
大语言模型对软件工程师的影响曲线
人工智能·llm
AI Echoes2 小时前
大语言模型（LLM）的微调与应用
人工智能·语言模型·自然语言处理
热门推荐
01如何在WPS和Word/Excel中直接使用DeepSeek功能02DeepSeek各版本说明与优缺点分析03本地部署DeepSeek教程（Mac版本）04从零安装 LLaMA-Factory 微调 Qwen 大模型成功及所有的坑05如何本地部署AI智能体平台，带你手搓一个AI Agent06DeepSeek R1本地化部署 Ollama + Chatbox 打造最强 AI 工具07DeepSeek RAGFlow构建本地知识库系统08Windows 11 安装 Dify 完整指南 非docker环境09本地化部署AI知识库：基于Ollama+DeepSeek+AnythingLLM保姆级教程10KGG转MP3工具|非KGM文件|解密音频