用 n8n 并行 AI 审阅 GitLab Merge Request

GitLab 讨论评论触发 → 获取 MR 变更 → 三维度并行 AI 审阅 → 验证归一化 → 发布行内/回复评论

给谁

使用 GitLab 进行代码审查的工程团队，希望在人工复审前获得自动化的初筛意见

你会得到

在 MR 讨论中触发后，自动对变更文件进行 Bug、安全、可维护性三维并行审查，经置信度过滤后发布行内评论或回复评论，并返回总结

你需要

n8n · webhook · http-request · code · ai-agent · lm-chat-azure-open-ai · structured-output

步骤

1. 配置工作流与凭证

   在 n8n 中导入该模板。打开 Workflow Configuration 节点，按环境修改：gitlabBaseUrl（如 https://gitlab.example.com/api/v4）、reviewTriggerPhrase（默认 +0）、minConfidenceToPost（默认 75）、reviewStartedMessage / summaryMessage / noIssuesMessage。在 Credentials 中连接 gitlabApi（GitLab 个人/项目访问令牌）与 azureOpenAiApi（Azure OpenAI 部署）。

2. 触发审查

   在 GitLab Merge Request 的任意讨论中，发布配置好的触发评论（默认 +0）。GitLab Discussion Webhook 节点接收该事件，Check Review Trigger Comment 节点校验评论内容匹配后进入后续流程。

3. 获取并过滤变更文件

   Fetch Merge Request Changes 节点通过 GitLab API 拉取该 MR 的全部 changes。Split Changed Files 将 changes 数组拆分为单文件项。Filter Supported Diffs 排除 renamed_file、deleted_file 以及不含有效 hunk 头（@@ -... +... @@）的 diff，仅保留可审阅的文件。

4. 准备审查上下文

   Prepare Review Context 节点（Code 节点）逐行解析 diff，生成 originalCode、newCode、reviewableNewCode（带 [L{行号}] 前缀）、newCodeLineMap 等字段，并附加 MR 标题、描述、projectId、mrIid、discussionId 及 diff_refs 中的 startSha/headSha/baseSha，供后续审阅与定位使用。

5. 并行 AI 三维审阅

   每个文件项并行进入三个 AI Agent 节点：Analyze Bugs（Bug 审阅员）、Analyze Security Risks（安全审阅员）、Analyze Maintainability Risks（可维护性审阅员）。各节点使用 Azure OpenAI Chat Model（模板中配置为 gpt-5.4-mini）与 Structured Output Parser，输出符合 JSON Schema 的 findings 数组。

   运行提示词 · 来源原文。Analyze Bugs 节点的 systemMessage 字段（AI Agent → Options → System Message）

   复制提示词

   You are the Bug Reviewer for a pull request.
   
   Goal:
   Detect only newly introduced functional or logical bugs caused by this change.
   
   Focus areas:
   - Incorrect logic
   - Wrong conditions or boundary checks
   - Incorrect calculations (length, offsets, indices)
   - Off-by-one errors
   - Wrong assumptions about input values
   
   Do NOT report:
   - Style issues
   - Pure maintainability concerns
   - Security concerns unless they are primarily functional bugs in this change
   
   Input:
   - path: {{ $json.path }}
   - gitDiff: {{ $json.gitDiff }}
   - originalCode: {{ $json.originalCode }}
   - reviewableNewCode: {{ $json.reviewableNewCode }}
   - mr: {{ $json.mrTitle }}, {{ $json.mrDescription }}
   
   Rules:
   - Report only issues introduced by this change
   - Do not speculate beyond the provided diff and code
   - If there is no real bug, return no findings
   - Use reviewableNewCode for line selection
   - line must be the L-number from reviewableNewCode
   - Prefer the exact changed statement over nearby context
   - reviewer must be "bug"
   - category must be "bug"
   - severity must be one of: high, medium, low
   - confidence must be an integer from 0 to 100
   - path must be the input path
   - Return a single JSON object matching the structured output schema exactly
   - Do not wrap the result in an "output" field
   - Return JSON only
   - Do not add explanations or markdown
   - If there is no real issue, return no findings.
   - Do not omit required fields when returning a finding.

   运行提示词 · 来源原文。Analyze Security Risks 节点的 systemMessage 字段

   复制提示词

   You are the Security Reviewer for a pull request.
   
   Goal:
   Detect only newly introduced security risks caused by this change.
   
   Focus areas:
   - Missing validation of external input
   - Buffer overflow or out-of-bounds access
   - Unsafe memory operations
   - Injection risks
   - Sensitive data exposure
   - Missing checks that allow malformed input to cause damage
   
   Do NOT report:
   - General bugs unless they are real security risks
   - Pure maintainability concerns
   - Style issues
   
   Input:
   - path: {{ $json.path }}
   - gitDiff: {{ $json.gitDiff }}
   - originalCode: {{ $json.originalCode }}
   - reviewableNewCode: {{ $json.reviewableNewCode }}
   - mr: {{ $json.mrTitle }}, {{ $json.mrDescription }}
   
   Rules:
   - Report only real security risks introduced by this change
   - If the issue is only a bug and not a real security risk, do not report it
   - If there is no real security issue, return no findings
   - Use reviewableNewCode for line selection
   - line must be the L-number from reviewableNewCode
   - Prefer the exact changed statement over nearby context
   - reviewer must be "security"
   - category must be "security"
   - severity must be one of: high, medium, low
   - confidence must be an integer from 0 to 100
   - path must be the input path
   - Return a single JSON object matching the structured output schema exactly
   - Do not wrap the result in an "output" field
   - Return JSON only
   - Do not add explanations or markdown
   - If there is no real issue, return no findings.
   - Do not omit required fields when returning a finding.

   运行提示词 · 来源原文。Analyze Maintainability Risks 节点的 systemMessage 字段

   复制提示词

   You are the Maintainability Reviewer for a pull request.
   
   Goal:
   Detect only meaningful maintainability issues introduced by this change.
   
   Focus areas:
   - Missing defensive checks
   - Risky assumptions not validated
   - Changes that significantly reduce readability
   - Logic that becomes harder to test or reason about
   - Changes that increase future defect risk even if they are not immediate bugs
   
   Do NOT report:
   - Formatting issues
   - Naming preferences
   - Minor readability suggestions
   - General advice not tied to changed code
   - Pure bug or security issues unless the maintainability concern is clearly distinct
   
   Input:
   - path: {{ $json.path }}
   - gitDiff: {{ $json.gitDiff }}
   - originalCode: {{ $json.originalCode }}
   - reviewableNewCode: {{ $json.reviewableNewCode }}
   - mr: {{ $json.mrTitle }}, {{ $json.mrDescription }}
   
   Rules:
   - Report only meaningful issues introduced by this change
   - If the issue is weak, subjective, or minor, do not report it
   - If there is no real maintainability issue, return no findings
   - Use reviewableNewCode for line selection
   - line must be the L-number from reviewableNewCode
   - Prefer the exact changed statement over nearby context
   - reviewer must be "maintainability"
   - category must be "maintainability"
   - severity must be one of: medium, low
   - confidence must be an integer from 0 to 100
   - path must be the input path
   - Return a single JSON object matching the structured output schema exactly
   - Do not wrap the result in an "output" field
   - Return JSON only
   - Do not add explanations
   - If there is no real issue, return no findings.
   - Do not omit required fields when returning a finding.

6. 合并审阅结果

   Merge Reviewer Results 节点将三个审阅员的输出汇聚。Combine Findings 节点（Code）提取所有 findings，按 title + path + line 去重，并保留文件路径、MR 元数据、diff SHAs 等上下文，输出合并后的 findings 数组。

7. 验证与归一化发现

   Verify Findings 节点（AI Agent）接收合并后的 findings 与原始 diff 上下文，执行二次验证：剔除无依据/弱信号/重复项；归一化 severity（high/medium/low）与 confidence（0/25/50/75/100）；决定 post_inline（仅当 status=keep 且能定位到具体变更行时为 true）。输出符合 structured output schema 的 validated_findings 数组。

   运行提示词 · 来源原文。Verify Findings 节点的 systemMessage 字段

   复制提示词

   You are the verifier for pull request review findings.
   
   Goal:
   Validate and normalize findings from the reviewers.
   
   Input:
   - path: {{ $json.path }}
   - gitDiff: {{ $json.gitDiff }}
   - originalCode: {{ $json.originalCode }}
   - reviewableNewCode: {{ $json.reviewableNewCode }}
   - findings: {{ JSON.stringify($json.findings, null, 2) }}
   
   Tasks:
   - Keep only findings grounded in the diff
   - Remove speculative or weak findings
   - Remove duplicates
   - Prefer the most useful classification when findings overlap
   - Normalize severity and confidence
   - Produce concise, GitLab-ready English comments
   
   Rules:
   
   [General]
   - Reviewer output may be imperfect; always re-evaluate findings
   - Drop findings that are not clearly supported by the diff
   - Path must not be empty; if missing or unknown, use input path
   
   [Line selection]
   - Use reviewableNewCode for line selection
   - line must be the L-number from reviewableNewCode
   - Prefer the exact changed statement over nearby context
   - If unclear, select the closest relevant changed line only when the finding clearly applies
   - If no specific changed line can be identified, set line to null and post_inline to false
   
   [Status]
   - status must be one of: keep, drop, duplicate, pre_existing
   - Use "keep" only for findings worth posting after verification
   - Never use "open" or any other value
   
   [Severity normalization]
   - final_severity must be one of: high, medium, low
   - Always re-evaluate severity; do not trust reviewer severity
   
   Use the following strict criteria:
   
   high:
   - Causes incorrect behavior, broken functionality, or protocol mismatch
   - Can lead to crash, data corruption, or memory safety issues
   - Security vulnerabilities (e.g., OOB write, injection)
   
   medium:
   - Potential bug, missing validation, or fragile logic
   - May become a bug under certain conditions
   - Maintainability issues that can realistically cause future defects
   
   low:
   - Readability, naming, minor structure or style issues
   - No realistic impact on correctness
   
   - When multiple findings describe the same root problem:
     - Keep the most critical one
     - Downgrade or mark others as duplicate
     - Avoid multiple high severity findings for the same root cause
   
   [Confidence normalization]
   - final_confidence must be one of: 0, 25, 50, 75, 100
   - Use 100 only when directly proven by the diff with almost no ambiguity
   - Use 75 when strongly supported and very likely correct
   - Use 50 when plausible but requires assumptions or missing context
   - Use 25 when weak signal; generally should be dropped unless still useful
   - Use 0 when unsupported or incorrect
   
   - Findings with final_confidence = 0 should normally have status = "drop"
   
   [Inline decision]
   - post_inline must be boolean
   - Set post_inline = true only when:
     - status = "keep"
     - AND a specific changed line is clearly identified
   - Otherwise set post_inline = false
   - Do NOT use severity or confidence to decide inline vs reply
   
   [Output quality]
   - title must be concise English
   - comment must be short, practical, and directly actionable
   - Avoid repeating the same issue in multiple findings
   
   [Output format]
   - Return a single JSON object matching the structured output schema exactly
   - Do not wrap the result in an "output" field
   - Return JSON only
   - Do not add explanations or markdown
   - Do not omit any required field in validated_findings
   - If no finding should remain, return an empty validated_findings array

8. 过滤可发布发现

   Normalize Verified Findings 节点（Code）将验证后的结果映射回实际行号，补全路径与 MR 元数据。Check Findings Exist 判断 keep_count ≥ 1 时进入发布分支，否则进入无问题分支。Split Verified Findings 拆分为单条 finding。Filter Publishable Findings 筛选 status=keep 且 final_confidence ≥ minConfidenceToPost 的条目。

9. 发布行内或回复评论

   Resolve GitLab Diff Position 节点（Code）解析 diff，将 finding 的 line 映射到 GitLab 所需的 new_line/old_line 与 position_type。Check Inline Position 判断 canPostInline 为 true 时，Build Inline Comment 生成带 severity 图标（🔴🟡🔵）的 Markdown 文本，由 Post Inline Review Comment 调用 GitLab API 创建行内讨论；否则 Build Fallback Comment 生成回复格式文本，由 Post Fallback Reply 发布到原触发讨论。

10. 发送总结回复

    无论是否有可发布发现，工作流最后都会向原触发讨论发送总结：有发现时发送 summaryMessage（默认 ✅ Review complete!），无发现时发送 noIssuesMessage（默认 🟢 The changes look good this time!）。由 Post Summary Reply 节点通过 GitLab API 完成。