大模型在代码评审中的应用基于 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使用正则表达式从带冲突标记的文件中提取出 HEADOurs、||||||| baseBase以及 branchTheirs三方的原始代码片段及行号区间。基于 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 (?Pours_label[^\n])\n r(?Pours_code[\s\S]*?) r(?:\|\|\|\|\|\| (?Pbase_label[^\n])\n(?Pbase_code[\s\S]*?))? r\n r(?Ptheirs_code[\s\S]*?) r (?Ptheirs_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 OverviewPython ast Module SpecificationTree-sitter Parser Infrastructure
