大模型在代码评审中的应用：基于 AST 与 LLM 的 Git 合并冲突智能解析实践-二趣网

大模型在代码评审中的应用：基于 AST 与 LLM 的 Git 合并冲突智能解析实践

在多人并行开发的大型业务系统中，分支合并产生的 Git 冲突是日常研发流程中的高频痛点。传统 Git 在处理冲突时，默认采用基于文本行的 diff3 算法。该算法依赖最长公共子序列（LCS）寻找差异，完全不感知编程语言的语法结构（AST）与作用域上下文。

在实际代码评审与分支合并过程中，这种纯文本行匹配暴露出了几个明显的缺陷：

语法结构破坏：当两个分支同时在同一函数的入参列表或返回值处添加字段时，文本合并往往会将多余的逗号或括号截断，产生语法不合法的代码。
假冲突与冗余打扰：如果两名开发者分别在类的开头和结尾添加了不相干的私有方法，仅因为文本缩进或行尾换行符的变动，diff3 就可能把整个类体标记为冲突区。
语义断层：在重构场景下，一个分支修改了方法签名，另一个分支在别处调用了该方法。文本合并能无冲突地通过git merge，但后续编译阶段或运行时会直接抛出空指针或方法未定义异常。

排查一次因分支合并丢失依赖import导致的线上故障后，我开始思考：能否在 CI/CD 代码评审阶段，引入 AST 语法树剪枝与 LLM 语义推理，建立一套自动识别并智能消除 Git 冲突的管道？

基于 AST 作用域剪枝与 LLM 语义融合的物理流程

为了让大模型准确理解冲突背景，直接将包含冲突标记的整个源文件喂给 LLM 并不是一个明智的方案。长文本不仅拉高 Token 消耗，还会让模型在无关代码中产生逻辑幻觉。因此，工程上的物理流程需要分为“冲突提取 - AST 剪枝 - 语义融合 Prompt 构造 - 后置语法校验”四个步骤。

flowchart TD GitConflictFile[包含冲突标记的源码文件] --> RegexExtract[Pass 1: 正则解析 Ours/Base/Theirs 三方片段] RegexExtract --> ASTPrune[Pass 2: AST 定位与上下文剪枝] ASTPrune --> PromptBuilder[Pass 3: 构造强约束语义融合 Prompt] PromptBuilder --> LLM[LLM 智能冲突合并] LLM --> MergedSnippet[输出消解后的代码段] MergedSnippet --> ASTCheck{Pass 4: 后置 AST 语法解析校验} ASTCheck -->|解析失败| HumanEscalate[降级人工介入合并] ASTCheck -->|解析成功| SafeMerge[自动替换回源文件并通过 CI]

整个解题链路拆解如下：

物理冲突解析（Pass 1）：使用正则表达式从带冲突标记的文件中，提取出<<<<<<< HEAD（Ours）、||||||| base（Base）以及>>>>>>> branch（Theirs）三方的原始代码片段及行号区间。
基于 AST 的作用域剪枝（Pass 2）：将文件代码输入 AST 解析器。通过行号比对，定位冲突代码落在哪一个FunctionDef（函数定义）或ClassDef（类定义）节点内部。随后将该节点外的无关函数剥离，仅保留冲突节点父级结构与全局Import声明，构成最小闭环上下文。
LLM 语义融合与决策（Pass 3）：将提取出的三方代码差异、父级函数签名以及相关依赖，组装为带 CoT（思维链）推导要求的结构化 Prompt。要求 LLM 遵循语法完备性原则，输出消除冲突后的代码以及消解逻辑。
后置 AST 静态编译校验（Pass 4）：拿到 LLM 输出的消解代码后，替换回原文件的冲突区域，调用ast.parse()进行语法合法性检查。若解析失败，则放弃自动合并并提醒开发人员介入。

生产级代码实现与最佳实践

基于 Python 内置的ast模块与re模块，我编写了一套支持语法提取、Prompt 构造以及后置编译验证的 Git 冲突智能解析引擎。

import ast import re import json from typing import Dict, List, Optional, Tuple, Any class GitConflictParser: """Git 冲突文本正则表达式提取器""" # 匹配三方冲突标记正则表达式 (Ours / Base / Theirs) CONFLICT_PATTERN = re.compile( r"<<<<<<< (?P<ours_label>[^\n]+)\n" r"(?P<ours_code>[\s\S]*?)" r"(?:\|\|\|\|\|\| (?P<base_label>[^\n]+)\n(?P<base_code>[\s\S]*?))?" r"=======\n" r"(?P<theirs_code>[\s\S]*?)" r">>>>>>> (?P<theirs_label>[^\n]+)\n", re.MULTILINE ) @classmethod def parse_conflicts(cls, file_content: str) -> List[Dict[str, Any]]: conflicts = [] for match in cls.CONFLICT_PATTERN.finditer(file_content): conflicts.append({ "start_pos": match.start(), "end_pos": match.end(), "ours_label": match.group("ours_label").strip(), "ours_code": match.group("ours_code"), "base_code": match.group("base_code") or "", "theirs_code": match.group("theirs_code"), "theirs_label": match.group("theirs_label").strip() }) return conflicts class ASTScopePruner(ast.NodeVisitor): """ AST 作用域剪枝器。 寻找指定代码片段在 AST 中所属的最紧凑父节点（FunctionDef / ClassDef）。 """ def __init__(self, target_snippet: str): self.target_snippet = target_snippet.strip() self.enclosing_node: Optional[ast.AST] = None def visit_FunctionDef(self, node: ast.FunctionDef) -> None: func_code = ast.unparse(node) if hasattr(ast, "unparse") else "" if self.target_snippet in func_code: self.enclosing_node = node self.generic_visit(node) def visit_ClassDef(self, node: ast.ClassDef) -> None: class_code = ast.unparse(node) if hasattr(ast, "unparse") else "" if self.target_snippet in class_code and not self.enclosing_node: self.enclosing_node = node self.generic_visit(node) class LLMConflictResolver: """ LLM 智能冲突解消控制器。 包含上下文裁剪、Prompt 组装以及后置 AST 校验。 """ def __init__(self, llm_client: Any): self.llm_client = llm_client def build_prompt(self, conflict: Dict[str, Any], context_code: str) -> str: return f""" 你是一个资深 Git 冲突解决专家。请分析以下代码合并冲突，并合并出一个语法完备、无逻辑缺失的正确代码段。 【所属上下文定义】: {context_code} 【Ours (当前分支代码)】: {conflict['ours_code']} 【Base (共同基线代码)】: {conflict['base_code']} 【Theirs (目标合并分支代码)】: {conflict['theirs_code']} 请按照以下 JSON 格式输出消除冲突后的合并结果： {{ "resolved_code": "消解冲突后的完整代码段", "explanation": "简要说明合并逻辑与语法保障依据" }} 仅输出 JSON 本身，禁止包含任何 Markdown 格式包裹词！ """ def resolve_file_conflict(self, full_file_content: str) -> Tuple[bool, str]: conflicts = GitConflictParser.parse_conflicts(full_file_content) if not conflicts: return True, full_file_content modified_content = full_file_content for conflict in conflicts: # 1. 尝试使用 AST 定位最窄作用域 try: tree = ast.parse(full_file_content.replace( full_file_content[conflict["start_pos"]:conflict["end_pos"]], conflict["ours_code"] )) pruner = ASTScopePruner(conflict["ours_code"]) pruner.visit(tree) context_code = ast.unparse(pruner.enclosing_node) if pruner.enclosing_node else "Global Scope" except Exception: context_code = "Global Scope" # 2. 构建 Prompt 并调用 LLM prompt = self.build_prompt(conflict, context_code) raw_response = self.llm_client.generate(prompt) try: clean_json = raw_response.strip().replace("```json", "").replace("```", "") result = json.loads(clean_json) resolved_code = result["resolved_code"] # 3. 后置 AST 编译校验：测试替换后的片段是否会破坏全局语法 candidate_content = modified_content.replace( modified_content[conflict["start_pos"]:conflict["end_pos"]], resolved_code ) ast.parse(candidate_content) modified_content = candidate_content except Exception as e: return False, f"自动消除冲突失败：解消产物无法通过后置 AST 静态校验 ({str(e)})" return True, modified_content

边界分析与架构权衡（Trade-offs）

在将 AST 剪枝与 LLM 冲突解消引擎引入大厂 CI/CD 合并流水线时，需要处理以下工程权衡：

1. 语义自动消除与人肉 Review 阻断的边界

虽然 LLM 结合 AST 能够解决 80% 以上由于缩进、方法重构或依赖调整引发的冲突，但绝对不能将“自动 Commit 并 Push”的完全决定权下发给程序。

在 CI 管道中，当系统成功消解冲突后，必须自动将explanation（消解理由）与上下文 Diff 作为特殊的 Comment 提交至 Pull/Merge Request 页面，并标注[Auto-Resolved]标签，强制要求原作者进行最后的人肉点选确认。

2. 多语言 AST 解析器适配开销

Python 内置的ast模块仅支持 Python 语法。在面对 Java、Go、C++ 等多语言混合仓库时，引入庞大的第三方 AST 解析库（如 Tree-sitter）会增加 CI 镜像打包开销。工程上的折中方案是采用统一的 Tree-sitter C-binding 引擎，利用同一套语法树遍历逻辑适配全语言上下文抽取。

总结

解决 Git 冲突不应停留在基于字符匹配的纯文本层。

通过利用 AST 抽取冲突块的作用域上下文，结合 LLM 的语义理解能力进行代码融合，最后在提交前使用 AST 静态编译进行后置校验，可以有效降低研发团队在频繁合并分支时的内耗。将机器擅长的语法检查与 LLM 的语义推理结合，才是提升研发协作效能的可靠方向。

参考资料

Git diff3 Merge Algorithm Overview
Python ast Module Specification
Tree-sitter Parser Infrastructure

企业官网建设流程全解析