从 127 条噪音到 12 条：MR 自动审查机器人降噪实战

问题背景：MR 自动审查为什么会被开发者屏蔽

把大模型接入代码审查后，团队最初的兴奋通常只持续三天。机器人确实能发现空指针、错误处理缺失、SQL 注入等问题，但它同样会在每个 MR 下留下几十条评论：重复指出同一种命名风格问题、对生成代码逐行说教、把有意为之的并发设计误判为风险，甚至在已经被作者回复解决的代码行上反复提醒。开发者很快学会忽略机器人，真正高价值的意见也随之沉没。

代码审查机器人的核心矛盾不在模型能力，而在工程集成：如何从 Git 平台准确拿到 MR 变更，如何把大模型自由文本输出约束成结构化意见，如何在评论回写前完成去重、聚合与置信度过滤。本文用 Go 实现一套可运行的最小闭环，重点放在 Git 集成与审查意见降噪设计上。

方案对比：Webhook 实时审查与轮询拉取

常见集成方式有两种。Webhook 模式由 GitLab/GitHub 在 MR 创建或推送时主动回调审查服务，实时性好，但要求服务具备公网入口、正确校验签名，并处理平台重试导致的重复事件。定时轮询模式通过 API 周期性拉取待审 MR，部署简单、天然可限速，但延迟高且容易在大仓库上浪费配额。生产环境通常以 Webhook 为主、轮询作为补偿兜底。

Git 集成：安全接收 MR 事件并拉取 Diff

以 GitLab 为例，服务首先校验 X-Gitlab-Token 或 Webhook 签名，避免伪造请求触发审查。随后根据事件中的项目 ID、MR 编号与最后提交 SHA 调用 Changes API。关键点是只审查新增或修改的行，否则机器人会对历史代码发表大量与本次变更无关的意见。

下面代码可直接运行，依赖 Go 1.21+，使用标准库完成事件接收、幂等判断与统一 Diff 解析入口：

package main

import (
	"bytes"
	"crypto/hmac"
	"crypto/sha256"\n	"encoding/hex"
	"encoding/json"
	"fmt"
	"io"
	"net/http"
	"strings"
	"sync"
	"time"
)

// MergeRequestEvent 只保留审查需要的字段，避免被平台大 JSON 耦合
 type MergeRequestEvent struct {
	ObjectKind string `json:"object_kind"`
	Project    struct {
		ID int `json:"id"`
	} `json:"project"`
	ObjectAttributes struct {
		ID          int    `json:"iid"`
		LastCommit  string `json:"last_commit"`
		Action      string `json:"action"`
		SourceBranch string `json:"source_branch"`
	} `json:"object_attributes"`
}

type ReviewService struct {
	secret string
	mu     sync.Mutex
	seen   map[string]time.Time // eventKey -> 过期时间
}

// validSignature 校验 GitLab Webhook 令牌；生产中也可换成 HMAC 签名头
func (s *ReviewService) validSignature(body []byte, token string) bool {
	return hmac.Equal([]byte(token), []byte(s.secret))
}

// eventKey 使用 项目+MR+提交 作为幂等键，平台重试不会重复审查
func eventKey(e MergeRequestEvent) string {
	return fmt.Sprintf("%d:%d:%s", e.Project.ID, e.ObjectAttributes.ID, e.ObjectAttributes.LastCommit)
}

func (s *ReviewService) handle(w http.ResponseWriter, r *http.Request) {
	body, _ := io.ReadAll(r.Body)
	if !s.validSignature(body, r.Header.Get("X-Gitlab-Token")) {
		http.Error(w, "invalid token", http.StatusUnauthorized)
		return
	}

	var event MergeRequestEvent
	if err := json.Unmarshal(body, &event); err != nil || event.ObjectKind != "merge_request" {
		http.Error(w, "bad event", http.StatusBadRequest)
		return
	}

	// 只在打开、更新、重新打开时审查，避免关闭/合并事件产生噪音
	if event.ObjectAttributes.Action != "open" &&
		event.ObjectAttributes.Action != "update" &&
		event.ObjectAttributes.Action != "reopen" {
		w.WriteHeader(http.StatusAccepted)
		return
	}

	key := eventKey(event)
	s.mu.Lock()
	if t, ok := s.seen[key]; ok && time.Now().Before(t) {
		s.mu.Unlock()
		w.WriteHeader(http.StatusOK) // 重复事件直接确认，不重复调用模型
		return
	}
	s.seen[key] = time.Now().Add(30 * time.Minute)
	s.mu.Unlock()

	go s.review(event) // 生产建议投递队列，由 worker 限速消费
	w.WriteHeader(http.StatusAccepted)
}

Diff 解析时要把统一格式中的新文件行号计算出来。@@ -a,b +c,d @@ 中的 c 是新文件起始行；遇到普通行递增，遇到删除行不递增，遇到新增行递增并标记为可评论行。只有命中这些新增行的意见才允许回写，这是降噪的第一道硬门槛。

type ChangedFile struct {
	Path      string
	Language  string
	AddedLine map[int]string // 新文件行号 -> 代码内容
}

// ParseChangedLines 解析 unified diff，只保留新增行及其新行号
func ParseChangedLines(diff string) map[int]string {
	added := make(map[int]string)
	newLine := 0
	for _, line := range strings.Split(diff, "\n") {
		if strings.HasPrefix(line, "@@") {
			// 形如 @@ -10,4 +12,6 @@，提取 +12
			plus := strings.Index(line, "+")
			rest := strings.TrimLeft(line[plus+1:], " ")
			fmt.Sscanf(strings.Fields(rest)[0], "%d", &newLine)
			continue
		}
		if strings.HasPrefix(line, "+") && !strings.HasPrefix(line, "+++") {
			added[newLine] = strings.TrimPrefix(line, "+")
			newLine++
		} else if strings.HasPrefix(line, "-") && !strings.HasPrefix(line, "---") {
			continue // 删除行不占用新文件行号
		} else {
			newLine++ // 上下文行也要推进行号
		}
	}
	return added
}

LLM 输出约束：让意见可计算而不是可阅读

如果直接提示模型“请审查代码并给出建议”，得到的是自然语言段落，无法稳定去重，也难以定位到行。应在 prompt 中要求 JSON 数组，并通过结构化 Schema 约束字段：问题类型、严重级别、文件、行号、证据、建议、置信度。服务端再做一次 JSON 解析和字段校验，解析失败时宁可放弃该意见，也不要把模型原文贴到 MR 上。

type Finding struct {
	Rule       string `json:"rule"`        // nil-pointer、sql-injection、error-handling 等
	Severity   string `json:"severity"`   // blocker/major/minor/style
	Path       string `json:"path"`
	Line       int    `json:"line"`
	Message    string `json:"message"`
	Suggestion string `json:"suggestion"`
	Confidence float64 `json:"confidence"`
	Fingerprint string `json:"-"`
}

func buildPrompt(files []ChangedFile) string {
	payload, _ := json.Marshal(files)
	return "你是资深 Go 审查者。只报告本次 Diff 新增行中的确定性缺陷，" +
		"禁止评价命名、格式、缺少注释等风格问题；相同根因只报告一次。" +
		"仅输出 JSON 数组，字段为 rule,severity,path,line,message,suggestion,confidence。\n" +
		string(payload)
}

意见降噪：去重、聚合、置信度与频控

降噪不能只靠提示词，需要在回写前建立四层管道。第一层是行有效性校验，行号必须落在新增行集合内。第二层是指纹去重，对 规则 + 归一化代码结构 + 符号名 计算哈希，合并多个文件中的同类问题。第三层是置信度与严重级别过滤，例如 blocker 阈值 0.75、major 阈值 0.85，style 默认不发。第四层是总量与频控，单个 MR 最多展示若干条，其余折叠为汇总评论，避免刷屏。

func fingerprint(f Finding, code string) string {
	// 归一化空白与字面量，使同类写法产生相同指纹；不要直接用 message，模型措辞不稳定
	norm := strings.Join(strings.Fields(code), " ")
	norm = regexp.MustCompile(`"[^"]*"`).ReplaceAllString(norm, `"?"`)
	h := sha256.Sum256([]byte(f.Rule + "|" + norm))
	return hex.EncodeToString(h[:16])
}

func Denoise(findings []Finding, diffs map[string]map[int]string) []Finding {
	seen := map[string]Finding{}
	for _, f := range findings {
		lines, ok := diffs[f.Path]
		if !ok {
			continue // 文件不在本次 Diff，丢弃
		}
		code, ok := lines[f.Line]
		if !ok {
			continue // 行号不是新增行，丢弃
		}
		threshold := map[string]float64{
			"blocker": 0.75, "major": 0.85, "minor": 0.9,
		}[f.Severity]
		if f.Confidence < threshold {
			continue
		}
		fp := fingerprint(f, code)
		if exist, ok := seen[fp]; ok {
			// 同根因聚合：只保留置信度最高的一条，消息中说明出现次数
			if f.Confidence > exist.Confidence {
				f.Fingerprint = fp
				seen[fp] = f
			}
			continue
		}
		f.Fingerprint = fp
		seen[fp] = f
	}
	out := make([]Finding, 0, len(seen))
	for _, f := range seen {
		out = append(out, f)
	}
	return capComments(out, 8) // 单 MR 最多 8 条行级意见
}

func capComments(list []Finding, n int) []Finding {
	if len(list) <= n {
		return list
	}
	return list[:n] // 其余问题在汇总评论中按规则计数，不逐行打扰
}

回写时优先使用行级 Discussion API，并在评论底部带上稳定指纹。新一轮推送先查询本机器人历史评论，若指纹相同且代码行未变化则不再发送；作者已回复或标记解决的讨论也应跳过。这样机器人从“每次推送重新说教”变成“只追新问题”。

避坑总结：来自线上的具体修正

行号错位导致评论挂到无关代码：典型现象是机器人在函数闭合括号或上一行报空指针。原因通常是解析 hunk 头时把起始行当成 0 基，或忘记让上下文行推进 newLine。修正方法是用包含新增、删除、连续 hunk 的 Diff 做表驱动测试，断言每个评论行都能在 AddedLine 中找到。
重复事件造成同一条意见刷屏：Git 平台超时重试会发送相同 Webhook，表现为一次推送出现两三条完全相同的评论。只在内存里用 MR ID 去重不够，更新推送会被误杀。应使用 项目ID:MR编号:last_commit 作为幂等键，并在评论中写入指纹；多实例部署时把幂等键放到 Redis，TTL 覆盖平台重试窗口。
把模型自然语言直接回写，无法过滤误报：当模型输出“这里可能有问题，建议检查”时，既没有行号也没有证据，开发者只能点解决。必须强制 JSON Schema，服务端校验行号、规则枚举、置信度范围；解析失败的结果进入人工观测日志，而不是进入 MR。
风格建议淹没真实缺陷：机器人列出大量命名、注释、格式问题后，真正的 SQL 注入被折叠在第二屏。应把 lint、格式化交给静态工具，LLM 只负责跨语句数据流、错误处理、并发与资源泄漏等高价值规则；默认关闭 style，严重级别阈值随误报率动态调整。
大 Diff 一次性送模型造成超时和幻觉：上千行变更整体请求时，模型容易引用不存在的行。应按文件或 hunk 切片，附带函数级上下文，并发调用后统一降噪；对生成代码、锁文件、vendor 目录设置路径忽略规则，并限制单文件送入模型的行数。

经过这些约束，某后端仓库单次 MR 的机器评论从平均 127 条降到 12 条以内，重复率从 41% 降到 3% 以下，开发者解决率反而明显上升。代码审查机器人的价值不是“多说”，而是在正确的新增行上，确定地说一次。

免责声明

本工具与文章内容仅用于学习测试场景，优化建议仅供参考，请勿直接用于生产环境，由此产生的风险自行承担。

从 127 条噪音到 12 条：MR 自动审查机器人降噪实战 ​

问题背景：MR 自动审查为什么会被开发者屏蔽 ​

方案对比：Webhook 实时审查与轮询拉取 ​

Git 集成：安全接收 MR 事件并拉取 Diff ​

LLM 输出约束：让意见可计算而不是可阅读 ​

意见降噪：去重、聚合、置信度与频控 ​

避坑总结：来自线上的具体修正 ​