大模型在代碼評審中的應用基于 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