IntelliGit第十一期：让 Git 听懂人话：自然语言助手的安全执行与 AI 辅助冲突解决

觉主730

344人浏览 · 2026-06-21 15:13:58

觉主730 · 2026-06-21 15:13:58 发布

一、前言：两个最容易"翻车"的场景

如果说上一期的 AST 引擎是把"代码"翻译成"语义"，这一期要解决的是两个更直接面向用户、也更容易出问题的场景：

自然语言操作 Git：用户一句话，系统翻译成 Git 命令并执行——这意味着任何解析偏差都可能直接破坏仓库。
Merge 冲突解决：传统冲突解决依赖人工逐行比对三方内容，效率低且容易出错。

这两个场景表面上差异很大，一个是"输入意图、输出命令"，一个是"输入冲突、输出合并结果"，但本质上面对的是同一个问题：AI 的输出不能被无条件信任。本期的核心工作，就是围绕这一点搭建"AI 增强 + 安全兜底"的双保险机制。

二、自然语言助手：从意图表达到安全执行

2.1 入口设计：降低"不知道怎么问"的门槛

自然语言交互最大的隐性成本，不是技术实现，而是用户根本不知道该输入什么、敢不敢信任系统会正确执行。为此做了两个针对性设计：一是在顶部工具栏放了一个常驻输入框，用户在任何页面下都能直接描述意图，回车后自动跳转到独立的 NLP 主视图并触发解析；二是页面内置了 8 条高频操作的快捷标签（比如"撤销上一次提交""推送到远程""丢弃所有未暂存改动"），点击即可直接填入并运行，省去用户"措辞"的负担。

这里有个容易被忽视的小细节：如果用户两次输入完全相同的文本，单纯依赖"输入内容变化"去触发解析是不够的——文本没变，事件可能不会被认为是一次新的请求。所以页面状态里专门维护了一个自增的运行令牌，每次触发都让它加一，解析逻辑监听的是这个令牌而不是文本本身，这样即便用户重复点同一个快捷标签，也能保证每次都真正触发一次新的解析，避免"点了却像没反应"的体验问题。

2.2 让模型了解仓库状态，而不是只看一句话

自然语言解析最大的误差来源，是模型不知道仓库当前处于什么状态。比如用户说"推送到远程"，模型需要知道当前分支是否已经关联了远程分支、本地是领先还是落后多少个提交，才能判断该生成 git push 还是需要先设置上游分支。因此每次解析前，系统都会组装一份仓库上下文，包括本地分支列表、远程分支列表、领先/落后的提交数、工作区变更和已暂存文件的数量、以及最近几条提交记录，连同用户输入一起交给模型。

更关键的一点是：模型的输出必须是符合预定义结构的数据，而不是一段自由格式的自然语言回复。只有结构化、可解析的输出，才能进入下一步的风险判断和命令执行——这是把"语言模型的生成能力"和"系统执行的确定性要求"对接起来的必要约束，少了这一层，后面所有的安全策略都无从谈起。

2.3 三档风险分级：safe / high / extreme

自然语言转命令最大的风险在于：一句话可能被解析成一个破坏性操作，比如强制推送覆盖远程历史，或是清空本地所有未提交的修改。所以系统给每一条解析出的操作都标注风险等级，并采用三档不同的处理策略：

safe：可自动执行，比如查看日志、暂存文件这类不会造成数据丢失的操作；
high：先把计划完整展示出来，必须用户手动确认才会执行；
extreme：默认直接阻止，提示用户去终端手动操作，系统不代为执行。

这个分级的设计哲学是：风险越高，留给用户的判断空间和确认成本应该越大，而不是统一走一套流程。把"自动执行"的门槛设得足够保守，宁可让用户多点一次确认，也不让自动化在用户没注意的瞬间执行了不可逆的操作。

2.4 默认拦截 + 显式解锁：对极高危操作的特殊处理

像强制推送和硬重置这类命令，一旦执行错误往往没有后悔的机会，所以被直接划入 extreme 档默认拦截。但完全锁死也不现实——确实有经验丰富的用户在明确知道后果的前提下需要用到这些操作。于是设计了一个显式的安全策略开关，默认两项都是关闭状态，用户需要主动去设置面板里打开。

这里最值得强调的设计取舍是：即便用户主动打开了开关，extreme 操作也只是降级为 high，而不会变成自动执行。 也就是说，"解锁"这个动作本身只是把"完全不让做"变成"允许做但还要再确认一次"，而不是直接跳过确认环节。这种设计避免了"用户图省事打开开关之后，某次自然语言指令被误解析成强制推送并被自动执行"这种最坏情况——开关解决的是"能不能做"的问题，而不是"要不要每次都确认"的问题，这两件事被刻意分开处理。

而且这种拦截不是只在一个地方判断一次，而是分了三层：解析阶段判断一次风险等级，应用安全策略时再判断一次是否被用户解锁，命令真正执行前，执行函数自身还会再检查一次风险等级——只要标记为 extreme，无论前面的逻辑是否有疏漏，最后这一道关卡都会把它挡下来。这种纵深防御的思路，本质上是不信任任何单一环节的判断，而是用多层互相独立的检查共同兜底。

2.5 操作历史：让每一次 AI 执行都可追溯

一旦一个 AI 工具具备了"代替用户执行操作"的能力，可审计就不再是锦上添花的功能，而是基本要求。每次自然语言解析和执行的结果都会被写入本地的历史记录文件——用户输入了什么、系统翻译成了什么具体命令、命令是执行成功、执行失败，还是因为风险等级被直接拦截，这些信息都会完整保留下来，并在界面上用不同颜色的标签清晰区分（成功、失败、已阻止）。

历史记录还做了一个简单但必要的容量控制，只保留最近的若干条，避免文件无限增长。这部分工作单看代码量不大，但它支撑的是一个更长远的能力——后续做操作撤销、执行回放、生成审计报告，都得依赖这份持续积累的历史数据。

三、冲突解决：从三方文本到 AI 辅助合并

3.1 一次性把"上下文"准备齐全

冲突解决面板需要承载完整的工作流：检测仓库是否处于 merge 状态、展示冲突文件列表、加载某个冲突文件的三方内容（共同祖先、当前分支、目标分支）、生成合并建议、采纳建议并写回文件、自动暂存。

这里有个体验上的考虑：打开面板时会自动探测当前仓库的 merge 状态，而不需要用户先去终端跑一遍命令确认；点击某个冲突文件后，会一次性把三方内容都拉取回来，并区分文本冲突和二进制冲突两条不同的处理路径——图片、压缩包这类文件没法做文本层面的合并，必须走"整体保留某一侧"的策略，这一点在设计阶段就被单独处理，而不是事后打补丁。

3.2 规则兜底：AI 不可用时也要能工作

如果冲突建议完全依赖大模型，一旦用户没配置 API Key 或者网络不通，这个核心功能就会整体瘫痪。所以第一步先实现了一套不依赖 AI 的规则策略，覆盖几类能够安全判断的常见情况：如果一侧内容为空、另一侧有实际改动，倾向于保留有内容的一侧；如果双方内容完全一致，直接合并；如果某一侧的内容明显更接近共同祖先，说明改动更可能发生在另一侧，可以适当倾向另一侧。

但规则策略也很清楚自己的能力边界——遇到双方差异都很大、无法用简单规则安全判断的情况，它不会强行给出一个可能是错的合并结果，而是诚实地标记为"建议人工合并"，并提示用户合并后要检查调用关系、函数签名、类型定义，跑一遍测试再提交。这个"知道自己不知道"的设计，比"什么情况都给一个答案"更负责任，也是规则系统和 AI 系统都应该具备的基本素养。

3.3 AI 建议：用 AST 上下文替代裸文本

AI 冲突建议没有直接把三方文本丢给模型去做"拼接式合并"，而是先用上一期介绍的 AST 引擎，针对冲突双方的内容构建结构化上下文——包括函数签名有没有变化、字段有没有被删除等信息，再连同三方文本一起交给模型。这个设计背后的逻辑很直接：纯文本合并本质上是字符串层面的操作，模型看不到"这段代码改的是哪个函数、签名变了没有"，很容易合并出语法正确但语义错误的结果；而注入了 AST 上下文之后，模型至少有机会理解"双方改动的是同一个函数的不同部分"还是"完全不相关的两处改动"，从而做出更合理的判断。

另一个关键设计是结果的兜底合并：如果 AI 调用失败，直接退回规则建议；即便 AI 调用成功，返回结果里如果有字段缺失（比如没给出合并后的内容，或者没给出风险提示），也会用规则建议的对应字段去补全，而不是让界面上出现一片空白或者报错。这种"AI 结果和规则结果做合并而不是互斥替换"的处理方式，让系统的健壮性不完全依赖于 AI 输出的完整性。

面板上还会把这份 AST 上下文展示出来，让用户能看到"AI 这次给的建议，依据是什么"，而不是把模型当成一个不可解释的黑盒去信任。

3.4 一键采纳与自动暂存

用户确认建议之后，系统会直接把内容写入文件，并主动询问是否要顺手暂存这个文件。这一步看起来只是省了几次点击，但实际上是把原本"手动编辑文件 → 保存 → 执行暂存命令 → 继续合并流程"这样一套需要在编辑器和终端之间来回切换的操作，收敛成一条在界面内就能走完的线性路径——这也是冲突解决体验最容易让用户感到挫败的环节，路径收敛带来的体验提升，往往比功能本身的"智能程度"更直接。

四、设计上的共同思路

回头看自然语言助手和冲突解决这两个模块，会发现它们贯彻的是同一套设计哲学：

AI 增强，而非 AI 依赖：无论是自然语言解析还是冲突建议，AI 不可用时系统都有规则兜底路径，保证核心功能不会因为模型服务的问题而整体中断。
结构先行：要求模型的输出必须符合预先定义好的结构，而不是接受任意格式的自然语言回复，这是让 AI 输出能够安全进入后续判断和执行流程的前提。
纵深防御：危险操作的拦截不是依赖单一开关，而是在解析、策略应用、执行三个相互独立的环节分别设防，任何一层失守，其余两层依然能兜底。
可审计：凡是由 AI 代为做出判断或执行的动作，都要留下痕迹——自然语言助手有完整的操作历史，冲突建议会展示其依据的语义上下文。

这几点结合起来，呼应的是同一个产品判断：AI 辅助开发工具的价值，不在于"让 AI 替你做决定"，而在于"让 AI 给你更好的决策依据，同时确保它不会在你没留意的时候捅娄子"。 这也是为什么这两个模块虽然分别面对"执行命令"和"合并代码"两种完全不同的任务，最终却收敛到了同一套设计原则上。

五、后续计划

自然语言助手：解析失败、或用户主动取消高风险操作时也写入历史记录；为待执行的命令计划提供更直观的预览；支持多轮自然语言修改既定计划（比如"刚才说的不要 push，只 commit 就行"）；考虑加入"演练模式"，只展示将要执行的命令而不真正执行。
冲突解决：目前一个文件里的多处冲突标记还是合并成单一区块处理，后续要拆成真正独立的多个冲突块，分别生成 AST 上下文；支持只采纳建议的一部分内容；合并完成后自动跑一遍测试或类型检查，再提示用户确认完成。

系列导读