本地LLM写commit零消耗：git-courer实战测评
用本地大模型写 Git 提交，零 Token 消耗：git-courer 的实现原理
多数 AI 辅助编程工具处理 Git 提交的思路几乎一致：将 git diff 结果直接喂给大模型，让其生成一条提交信息。这的确能工作，但存在几个明显短板——提交类型（feat/fix/refactor）全靠大模型猜测，猜错就得手动修正；大型差异对比会吞噬大量 Token；而且所有代码都会上传云端，隐私问题让人难以放心。
git-courer 走的是另一条路线：利用 Go 进行 AST 解析和依赖图分析，提交类型由代码结构本身决定，大模型只负责生成那条人类可读的消息。如果配置的是本地 Ollama，整个流程完全不接触云端。
核心机制
主要流程大致如下：
你说"帮我提交改动"↓AI 助手通过 MCP 调用 git-courer↓Go 解析 AST + 构建依赖图 → 确定提交类型↓本地大模型根据标注后的 diff 生成消息↓5 层安全扫描 → 自动备份 → 提交↓"✓ feat(auth): add OAuth2 token refresh"
关键就在中间那一步——提交类型不是大模型凭感觉猜测的，而是 Go 利用 go-enry 和 go-tree-sitter 解析 AST 后，依据确定性规则准确判断的。新增公开函数、修改函数签名、删除符号、破坏性变更，每种场景都对应固定的分类逻辑。大模型接收到的是已经标注好类型的结构化上下文，而不是原始的代码堆砌。
依赖图分析
在提交之前，git-courer 会先构建一张依赖图：暂存的文件到底会影响到哪些其他文件。
这就解决了一个非常实际的痛点：你修改了 auth/token.go，但调用它的 api/handler.go 实际上也需要一并提交。传统工具只知道你暂存了哪些文件，而 git-courer 能清晰掌握这些文件在整个代码仓库中的影响范围。
基于这张依赖图，它会将暂存文件按依赖关系拆分成多个原子提交，每个提交最多包含 12 个文件。换句话说，一次 git add . 之后，你可能得到的是三条结构清晰的提交，而不是一条“update stuff”敷衍了事。
三阶段提交流程
PREVIEW → 用户确认 → APPLY
执行 git-commit PREVIEW 后，git-courer 立即开始解析 AST、构建依赖图、生成提交计划。对于大型差异对比，这个过程是异步执行的：
{ "status": "processing", "job_id": "abc123" }
AI 助手无需原地等待，可以继续处理其他任务，稍后通过 git-commit STATUS 轮询即可。计划生成完毕后，它会展示给你确认，确认无误后再执行 APPLY。
每次 APPLY 成功后，提交消息都会写入 .git-courer/branches/。这份 CommitStore 在后续 release 流程中能发挥关键作用——即便之后进行了 rebase 或 squash，历史记录被重写，这份本地存档依然存在，生成 changelog 时完全不需要依赖 git log。
安全扫描
每次写操作提交前，差异对比会经过 5 层严格扫描：
- Magic bytes：直接扫描文件头部，检测二进制可执行文件
- 统计审计：检测伪装成文本的二进制载荷
- 路径黑名单：按文件名拦截（
.env、credentials等） - 内存正则：在内存中扫描暂存差异，匹配密钥模式
- AI 审计员：本地大模型执行最终检查，处理前四层未能覆盖的情况
注意，前四层在 Go 内部强制执行，不依赖大模型的判断能力——这是硬性规则。
自动备份与撤销
每次写操作（commit、amend、revert、merge、rebase……）执行前，git-courer 都会自动保存当前状态。遇到问题？一条命令即可恢复：
git-undo RESTORE
无需翻阅 reflog，不用记忆操作前的 commit hash，省心省力。
22 个 MCP 工具
git-courer 以 MCP 服务器的形式运行，提供 22 个工具，覆盖整个 Git 生命周期：
| 类别 | 工具 |
|---|---|
| 读取 | status、diff、history、blame、pr-review |
| 写入 | commit、amend、revert、stage、reset、stash |
| 分支 | branch、merge、rebase、cherry-pick、tag |
| 工具 | sync、backup、undo、remotes、config、commit-jobs |
所有工具均返回结构化 JSON，没有分页器挂起问题，也无需进行文本解析。例如，status 一次调用就能返回完整的仓库状态，替代了原本需要 5 个以上 Git 命令才能拼凑出的信息。
此外，pr-review 是一个一次性的 PR 前置检查工具：运行测试、检测冲突（附带 AST 标注的差异区块）、统计差异、检查分支分叉情况。全部通过才能合并，否则无法操作。
大模型后端配置
git-courer 兼容任何 OpenAI 兼容的服务器，并不局限于 Ollama：
| 后端 | provider 值 |
|---|---|
| Ollama（推荐） | ollama |
| LM Studio | lmstudio |
| vLLM | vllm |
| LocalAI | localai |
| 任意兼容服务器 | openai-compatible |
配置存放在 ~/.config/git-courer/config.yaml：
llm:provider: ollamamodel: qwen3.5:latest
经过测试的模型中，qwen3.5:latest（7b）性价比最高，提交质量好且响应速度快。低配置机器可以考虑 qwen3.5:0.8b，仅 1GB 大小，基础提交完全够用。
如果没有配置大模型后端，读取操作（status、diff、log）依然正常工作，但涉及 AI 的操作（提交消息生成、release changelog、安全 AI 审计员）会报错，这点需要留意。
安装
curl -fsSL https://raw.githubusercontent.com/Alejandro-M-P/git-courer/main/scripts/install.sh | sh
安装脚本会自动检测你机器上已有的 AI 工具并配置 MCP。目前已支持 12 个客户端：Claude Code、Cursor、Windsurf、Gemini CLI、Codex、VS Code、Zed、Continue、Cline、Roo Code、OpenCode、Claude Desktop。
如果想手动配置某个客户端，可以执行以下命令：
git-courer mcp setup cursor
不带参数直接运行 git-courer 会启动交互式 TUI，在里面可以选择要配置的客户端、设置大模型后端，预览配置后再保存。
架构
┌─────────────────────────────────────┐│ AI 助手（Claude、Cursor 等）│└──────────────┬──────────────────────┘ │ MCP 协议（JSON-RPC）┌──────────────▼──────────────────────┐│internal/delivery/mcp（MCP 层） │└──────────────┬──────────────────────┘ │┌──────────────▼──────────────────────┐│ internal/workflow（统一引擎） ││ - 原子操作 + 自动备份││ - 主动安全拦截││ - 统一 preview 生成│└──────┬───────┴──────────┬───────────┘ ││┌──────▼──────┐ ┌───────▼──────────┐│ core/domain │ │ adapters ││（纯领域模型） │ │（git、llm 多后端） │└─────────────┘ └──────────────────┘
采用六边形架构，所有需要 AI 或用户确认的 Git 操作都通过 workflow 引擎，确保原子性和安全性。
适用场景
以下几种场景下，git-courer 的优势尤为突出：
对代码隐私要求高：代码始终在本地运行，大模型在自己的机器上执行，不存在泄露风险。
频繁提交的项目：每次提交都调用云端大模型的话，Token 成本会逐渐累积，本地模型则完全没有这个顾虑。
多人协作项目：.git-courer/config.json 可以提交到仓库，团队共享 areas（模块划分）和 test_command 配置，release changelog 还能按模块分组生成。
有 release 流程的项目：CommitStore 保存了每条提交消息，rebase/squash 不会破坏 changelog 的数据源。
不太适合的场景：如果本地没有 GPU 或内存不足以运行 7b 模型，可以使用 qwen3.5:0.8b 降低门槛，但提交质量会有一定差距。
项目地址：github.com/Alejandro-M…