扣子机器人可自动审查GitLab MR代码：配置HTTPS Webhook接收事件，用Personal Access Token调用API获取diff和源码，结构化输入大模型生成JSON格式审查意见，再以评论形式提交至MR页面。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让扣子（Coze）机器人自动读取 GitLab 合并请求（MR）中的代码变更，并基于预设规则给出审查意见，而不是人工逐行查看。这要求扣子能实时接收 GitLab 的 MR 创建/更新事件，调用 GitLab API 获取 diff 和源码上下文，并将结构化数据送入大模型推理链路。
在 GitLab 中配置 Webhook 接收 MR 事件
进入目标项目的 Settings → Webhooks 页面，填写扣子 Bot 的 HTTPS 回调地址（如 https://bot.coze.com/webhook/gitlab-mr），勾选 Merge request events，取消勾选其他事件类型。
点击 Add webhook 保存。GitLab 会立即发送测试请求，若扣子服务未就绪，该测试将失败——此时不要反复重试，先完成后续 API 权限配置。
注意：Webhook URL 必须以 HTTPS 开头，HTTP 地址会被 GitLab 拒绝；【回调地址必须能被公网访问，且已配置有效 TLS 证书】。
为扣子获取 GitLab API 访问权限
在 GitLab 用户设置中打开 Access Tokens 页面，创建一个 Personal Access Token。
Token 名称填 coze-code-review，有效期建议设为 1 年，权限至少勾选：api 和 read_api —— 缺少 read_api 将无法获取 MR 的 changes、diffs 或源文件内容。
生成后立即复制 Token 字符串，【该字符串仅显示一次，关闭页面即永久丢失】。把它安全存入扣子 Bot 的环境变量中，变量名建议为 GITLAB_API_TOKEN。
在扣子 Bot 中解析 MR Webhook 并提取关键信息
在扣子 Bot 的「Bot」→「工作流」中新建一个 HTTP 触发节点，路径设为 /webhook/gitlab-mr，方法为 POST。
添加「JSON 解析」节点，从请求体中提取以下字段：object_attributes.id（MR ID）、project.id（项目 ID）、object_attributes.source_branch、object_attributes.target_branch、object_attributes.last_commit.id（用于定位变更快照）。
若 Webhook 中 changes 字段为空（常见于 MR 初始创建时），则跳过 diff 提取，直接调用 GitLab API 获取最新 MR 变更详情——因为 GitLab 的初始事件不包含完整变更列表。
调用 GitLab API 获取 MR 的文件级 diff 和上下文代码
使用「HTTP 请求」节点发起 GET 请求：
URL 拼接为：https://gitlab.example.com/api/v4/projects/{project_id}/merge_requests/{mr_id}/changes，Headers 中加入 Authorization: Bearer {GITLAB_API_TOKEN}。
成功响应后，遍历 changes 数组，对每个变更文件提取：old_path、new_path、diff（原始 diff 文本）、added_lines 和 removed_lines（用于快速判断修改密度）。
对每个新增或修改的 .py/.js/.java 文件，再发一次请求获取其当前版本完整内容：GET /projects/{project_id}/repository/files/{encoded_file_path}?ref={source_branch}，其中 file_path 需做 URL 编码（空格→%20，/→%2F）——【未编码的路径会导致 404，且错误不提示具体原因】。
构造审查提示词并调用大模型分析代码风险
将每个文件的 diff 内容 + 前后 3 行上下文代码 + 文件路径拼成一段结构化输入，格式如下：
[FILE] src/utils/auth.js<br>[DIFF]@@ -12,5 +12,6 @@ function verifyToken(token) {<br> if (!token) return false;<br>– return jwt.verify(token, process.env.SECRET);<br>+ return jwt.verify(token, process.env.SECRET || 'dev-key');<br>[CONTEXT]// ⬆️ 上下文：token 校验入口<br>// ⬇️ 下文：错误处理分支<br>try {
把所有文件块合并为单个 prompt，传给「大模型」节点。系统提示词需明确限定输出格式：仅返回 JSON 数组，每项含 file、line、severity（high/medium/low）、message、suggestion 字段，禁止任何解释性文字或 markdown 符号。
这一步若返回非 JSON 内容，后续解析节点将中断流程——因此必须在大模型节点设置「强制 JSON 输出」开关，并启用「失败重试」（最多 2 次）。
将审查结果以评论形式提交回 GitLab MR 页面
遍历大模型输出的 JSON 数组，对每个 high 级别问题，构造一条评论内容，例如：
⚠️ 安全风险：硬编码密钥 fallback 值（line 14）<br>建议移除 <code>'dev-key'，改用环境变量校验或抛出明确错误。
调用 GitLab API 提交评论：
POST /projects/{project_id}/merge_requests/{mr_id}/notes，Body 为 {"body": "⚠️ 安全风险……"}，Headers 同前。
每条评论独立发起请求，避免批量合并——GitLab 对单次请求的 body 长度有限制，超长会返回 413 错误；【单条评论超过 1000 字符时，应自动截断并在末尾添加「（内容过长，已省略）」】。
