AI Commit 2：基于AI的智能Git提交信息生成工具实战指南

1. 项目概述：AI Commit 2，一个智能化的版本控制助手

如果你和我一样，每天在终端里敲git commit -m "fix bug"或者git commit -m "update"的次数比喝水还多，那你肯定也经历过那种“词穷”的尴尬时刻。明明代码改动逻辑清晰，功能完善，但到了写提交信息这一步，大脑却一片空白，最后只能草草写个“修复问题”了事。时间一长，项目提交历史就成了“垃圾堆”，想回溯某个功能的引入原因或者排查特定问题的引入时机，简直比大海捞针还难。

这就是aicommit2要解决的核心痛点。它不是一个简单的命令行工具，而是一个反应式 CLI，专门为 Git、YADM 和 Jujutsu 生成高质量的提交信息。它的工作原理非常直接：分析你暂存的代码变更（git diff），然后调用你配置好的 AI 模型（比如 OpenAI 的 GPT、Anthropic 的 Claude、Google 的 Gemini，或者本地的 Ollama），让 AI 理解这些变更的意图，并生成符合规范、语义清晰的提交信息。

我最初接触这类工具时，也持怀疑态度——AI 生成的提交信息会不会很“水”？会不会不理解业务逻辑？但实际使用aicommit2几个月后，我的看法彻底改变了。它不仅大幅提升了我的提交效率，更重要的是，它强制性地为每一次提交都附上了有意义的描述，这让团队协作和后期维护变得异常轻松。现在，我的提交历史看起来更像是精心维护的变更日志，而不是随意的草稿纸。

aicommit2适合所有使用版本控制的开发者，无论你是独立开发者维护个人项目，还是大型团队中的一员。特别是对于那些已经采用 Conventional Commits 或 Gitmoji 规范，但苦于执行不彻底的团队，这个工具能起到“强制执行器”的作用。接下来，我会带你从零开始，深入拆解它的核心设计、详细配置、高级用法以及我踩过的那些坑，让你也能轻松驾驭这个提升开发体验的利器。

2. 核心设计思路与架构解析

2.1 为什么是“反应式” CLI？

“反应式”这个词听起来有点玄乎，但在aicommit2的语境下，它指的是工具的工作流是交互式和可选择的。这与一些早期 AI Commit 工具“生成即提交”的粗暴方式有本质区别。

传统的自动化提交工具，往往是生成一条消息后直接提交，用户没有反悔或选择的余地。如果 AI 的理解有偏差，生成了不准确的信息，你就得手动git commit --amend去修改，反而增加了操作步骤。aicommit2的“反应式”设计体现在：它生成一条或多条候选消息，展示给你看，让你选。你可以用方向键浏览，按回车确认使用某一条，或者按e键进入编辑器进一步润色，甚至按c键只复制到剪贴板而不提交。

这种设计哲学的核心是“AI 辅助，人类决策”。AI 负责提供高质量的草稿，减轻你构思的负担；而你保留最终的控制权和审核权，确保提交信息的准确性。这完美平衡了自动化带来的效率提升和手动控制带来的可靠性。

2.2 多版本控制系统支持的设计考量

aicommit2没有把自己局限在 Git 上，而是原生支持了 YADM 和 Jujutsu。这背后有很实际的考量。

YADM是一个用 Git 管理 dotfiles（用户配置文件，如.bashrc,.vimrc）的工具。很多开发者用 Git 管理代码，用 YADM 管理配置。aicommit2能自动识别 YADM 仓库，意味着你在更新完.vimrc后，可以直接运行aicommit2，它会调用yadm diff而不是git diff，并最终通过yadm commit提交。这省去了你记忆两套命令的麻烦，实现了工具链的统一。

Jujutsu是一个新兴的、与 Git 兼容但设计理念不同的版本控制系统。它采用变更集模型，并且从 0.34.0 版本开始，其仓库与 Git 仓库是“共置”的（即同一个目录下既有.git又有.jj）。aicommit2的自动检测逻辑会优先识别.jj目录，并调用jj diff和jj describe。更贴心的是，它默认只运行jj describe来设置提交信息，而不会自动创建新的变更集（jj new），这符合许多 Jujutsu 用户喜欢手动控制工作流节奏的习惯。当然，你也可以通过配置让它自动执行jj new。

这种多 VCS 支持的设计，体现了工具对开发者真实工作环境的深度适配。它不是强迫你改变习惯去适应工具，而是让工具灵活地适应你已有的、可能混合的工作流。

2.3 多 AI 提供商集成的策略

支持十几种 AI 提供商（OpenAI, Claude, Gemini, Ollama...）听起来很美好，但实现起来面临几个挑战：API 规范不统一、计费方式不同、响应速度各异。aicommit2的解决方案很巧妙。

首先，它以 OpenAI 的 API 规范为事实标准。对于 Anthropic、Gemini 等提供商，它在内部做了一个适配层，将它们的 API 请求和响应格式，转换成类 OpenAI 的格式。这样做的好处是，核心的 AI 调用逻辑只需要写一套，大大降低了维护成本。

其次，它引入了“模型”作为配置单元的概念。你可以在配置中为同一个提供商指定多个模型，比如OPENAI.model=gpt-4o-mini,gpt-3.5-turbo。当你运行aicommit2时，它可以（如果你配置了）同时向这些模型发起请求。这意味着你可以在几秒钟内，同时获得来自 GPT-4 和 Claude 对同一段代码变更的“解读”，然后选择你认为最贴切的那一条。这相当于用一次git add的成本，获得了多位“资深代码评审员”的提交建议。

最后，对于像Ollama这样的本地模型，aicommit2做了特别优化。本地模型通常响应较慢，且可能不稳定。工具提供了watchMode等配置，允许更长的超时时间和更宽松的错误处理，确保在离线或注重隐私的场景下也能顺畅使用。

这种架构带来的直接好处是抗风险和高可用性。如果某个 AI 服务商临时宕机或你的 API 额度用尽，你可以快速切换到另一个备选提供商，而无需改变你的提交习惯。

3. 从零开始的详细安装与配置指南

3.1 选择并执行安装命令

安装aicommit2主要有三种方式，我的推荐顺序是：Homebrew > npm > Nix。

通过 Homebrew 安装（macOS/Linux 首选）

brew install aicommit2

这是最干净、管理最方便的方式。Homebrew 会自动处理依赖和更新。安装后，直接运行aicommit2命令即可。

通过 npm 安装（跨平台通用）

npm install -g aicommit2

确保你的 Node.js 版本在 v18 或以上。用node --version检查。npm 安装的包会全局可用，但需要注意，如果你需要Copilot SDK支持，必须使用 npm 安装，因为 Homebrew 版本由于许可原因不包含此私有依赖。

通过 Nix 安装（NixOS 或 Nix 用户）

# 临时运行 nix run github:tak-bro/aicommit2 # 永久安装到用户环境 nix profile install github:tak-bro/aicommit2

Nix 方式能提供完全可复现的环境，适合追求环境一致性的高级用户。

实操心得：对于大多数 macOS 用户，无脑选 Homebrew。如果你在 Windows 上通过 WSL 开发，Homebrew 同样可用。只有当你明确需要使用 GitHub Copilot SDK 时，才选择 npm 安装。

3.2 配置 AI 提供商：交互式向导与手动配置详解

安装完成后，核心步骤是配置至少一个 AI 提供商。aicommit2提供了极其友好的交互式向导。

强烈推荐：使用交互式向导 (aicommit2 setup)运行这个命令，你会进入一个命令行交互界面：

1. 它会列出所有支持的 AI 提供商。
2. 你可以用方向键选择你想配置的一个或多个（支持多选）。
3. 对于每个选中的提供商，它会提示你输入 API Key。
4. 接着，它会让你为该提供商选择默认的模型。
5. 向导会自动将配置写入正确的文件。

这个过程对新手非常友好，避免了手动查找配置项和编辑配置文件的麻烦。

手动配置（适合进阶用户或自动化脚本）所有配置最终都保存在一个 INI 格式的配置文件里。你可以用命令来管理：

# 设置 OpenAI 的 API Key aicommit2 config set OPENAI.key=sk-your-actual-openai-key-here # 设置 Anthropic 的 API Key 和模型 aicommit2 config set ANTHROPIC.key=sk-your-antropic-key ANTHROPIC.model=claude-3-5-sonnet-20241022 # 查看当前所有配置 aicommit2 config list

配置文件的默认位置遵循 XDG 规范，通常在~/.config/aicommit2/config.ini。你也可以通过aicommit2 config path命令查看确切路径。

关于 API Key 的安全存放我强烈建议不要将明文 API Key 长期保存在配置文件中。更好的做法是使用环境变量。

# 在 shell 配置文件（如 ~/.zshrc 或 ~/.bashrc）中设置 export OPENAI_API_KEY='sk-...' export ANTHROPIC_API_KEY='sk-...' # 然后让 aicommit2 从环境变量读取 aicommit2 config set OPENAI.envKey=OPENAI_API_KEY aicommit2 config set ANTHROPIC.envKey=ANTHROPIC_API_KEY

这样，你的密钥只存在于内存中，配置文件里只有一个指向环境变量的引用，安全得多。对于团队项目，可以将这些环境变量定义在项目的.env文件中（但切记不要提交该文件！）。

3.3 基础验证与首次运行

配置完成后，不要急着用在正式项目上。先建立一个测试仓库来验证一切是否正常。

mkdir test-aicommit && cd test-aicommit git init echo "# Test Project" > README.md git add README.md aicommit2

如果配置正确，你会看到类似下面的交互界面：

? Select a commit message: (Use arrow keys) ❯ feat: add README.md with project description docs: create README.md file chore: initial commit with README

按回车选择第一条，工具就会自动完成git commit -m "feat: add README.md with project description"这个操作。到这一步，基础安装配置就成功了。

4. 核心功能深度使用与实战技巧

4.1 日常提交工作流优化

默认的aicommit2命令已经很好用，但结合一些参数，能让你的体验更上一层楼。

生成多条建议并选择 (--generate)

git add . aicommit2 --generate 3

--generate（或-g）参数让 AI 一次性生成多条（这里是3条）不同角度的提交信息供你选择。这特别适合复杂的变更，因为单条建议可能只捕捉到一个侧面。多条建议能给你更全面的视角。不过要注意，这会产生多倍的 API 调用和费用。

自动暂存更改 (--all)

aicommit2 --all # 等价于 git add -u && aicommit2

--all（或-a）参数会自动暂存所有已跟踪文件的更改，然后生成提交信息。这省去了先git add .的步骤。但务必小心！它只暂存已跟踪文件的修改，不会添加新文件。如果你新增了文件，仍需先git add <新文件>。

生成后直接编辑 (--edit)

aicommit2 --edit

选择提交信息后，不会直接提交，而是会打开你的默认编辑器（如 Vim、VSCode），让你在最终提交前对信息进行微调。这是“人类决策”的终极体现，我几乎每次都加这个参数。

仅生成不提交 (--dry-run)

aicommit2 --dry-run # 或 aicommit2 -d

这个参数非常有用。它让aicommit2执行所有步骤——分析差异、调用 AI、生成信息、让你选择——但唯独不执行最终的git commit。选中的信息会显示在终端。我通常在两种情况下用它：

1. 审查模式：我想看看 AI 会怎么描述我的改动，但可能还没决定要提交。
2. 非 Git 场景：有时我只是想快速获得一段代码变动的文字描述，用于写周报或注释，-d模式完美适配。

组合使用示例一个我常用的高效命令组合是：

aicommit2 --all --edit --generate 2

翻译过来就是：“自动暂存所有已跟踪文件的改动，让 AI 给我 2 个提交建议，我选一个，然后在编辑器里最终确认后提交。” 一条命令覆盖了从暂存到提交的全流程。

4.2 提交信息风格与本地化定制

aicommit2支持两种主流的提交信息风格，通过--type参数指定。

Conventional Commits (--type conventional)这是默认风格，也是目前社区最流行的规范。格式为：<type>(<scope>): <subject>。例如feat(auth): add user login with OAuth。这种风格高度结构化，便于机器解析，能自动生成变更日志。

• type可以是feat,fix,docs,style,refactor,test,chore等。
• AI 会根据代码变动的性质自动判断并填入合适的type。

Gitmoji (--type gitmoji)这种风格在提交信息开头添加一个表情符号，使得提交历史在终端或 GitHub 上看起来更直观有趣。例如✨ Add new feature或🐛 Fix critical bug。

• 它同样遵循一定的语义，每个表情对应一种变更类型。
• 适合喜欢视觉化、项目氛围较轻松的团队。

本地化支持 (--locale)这是一个很棒但容易被忽略的功能。如果你的母语不是英语，或者你的团队内部使用其他语言，你可以让 AI 生成对应语言的提交信息。

aicommit2 --locale zh # 中文 aicommit2 --locale ja # 日文 aicommit2 --locale fr # 法文

AI 会尝试用指定语言生成提交信息的主体部分。不过根据我的经验，对于技术术语和专有名词（如函数名、库名），AI 通常还是会保留英文，这反而让提交信息在中英混合的团队环境中更具可读性。

4.3 差异压缩与性能调优

当你进行一个大型重构或提交大量文件时，git diff的输出可能会非常长。直接发送给 AI 不仅消耗大量 Token（更贵），还可能超出模型的上下文窗口限制，导致生成失败或质量下降。aicommit2内置了智能的差异压缩功能。

启用压缩 (--diff-compression compact)

aicommit2 --diff-compression compact

或者在配置中永久开启：

aicommit2 config set diffCompression=compact

启用后，工具不会发送原始的、冗长的 diff，而是会尝试分析 diff，提取出变更的“精髓”。例如，它会将重命名、移动的文件进行归类，将大量重复的样式修改进行合并描述。官方称可以减少 30-60% 的 Token 使用量。

控制压缩粒度你可以通过两个参数精细控制压缩程度：

• --max-hunk-lines：限制每个“块”的最大行数。一个“块”是 diff 中连续的变更段落。
• --max-diff-lines：限制整个 diff 的最大行数。

# 每个变更块最多50行，整个diff最多200行 aicommit2 --diff-compression compact --max-hunk-lines 50 --max-diff-lines 200

我的建议是，对于日常的小型提交，可以不开启压缩以获取最精确的上下文。对于大型提交，务必开启压缩并合理设置行数限制，这能显著提高成功率和经济性。

避坑指南：差异压缩是一把双刃剑。过度压缩可能会丢失关键上下文，导致 AI 生成的信息过于笼统或不准确。如果你发现开启压缩后生成的信息质量明显下降，可以尝试调高max-hunk-lines或max-diff-lines的值，或者在特别重要的提交时临时关闭压缩 (--diff-compression none)。

4.4 与现有工作流的无缝集成

真正的效率工具不应该让你改变习惯，而应该融入你已有的工作流。aicommit2在集成方面做得非常出色。

作为 Git Hook 自动运行这是我最推荐的集成方式。安装 Hook 后，每次你执行git commit（即使不带-m），aicommit2都会自动介入，为你生成提交信息。

# 在项目根目录执行，一键安装 aicommit2 hook install

安装后，查看.git/hooks/prepare-commit-msg文件，你会发现它被替换了。现在你的工作流变成：

1. git add .
2. git commit（不写-m）
3. 自动弹出aicommit2界面让你选择/编辑信息。
4. 保存退出编辑器，提交完成。

这完全符合标准的 Git 提交流程，毫无侵入感。卸载同样简单：aicommit2 hook uninstall。

与 pre-commit 框架共存如果你的项目使用了pre-commit框架来管理代码质量钩子，你可以将aicommit2加入其中，而不是用它替换默认的 Git Hook。

# .pre-commit-config.yaml repos: - repo: local hooks: - id: aicommit2 name: AI Commit Message Generator entry: aicommit2 --pre-commit language: node stages: [prepare-commit-msg] always_run: true

记得运行pre-commit install --hook-type prepare-commit-msg来激活。--pre-commit参数是专门为这个框架设计的，能确保更好的兼容性。

深度集成 LazyGit对于 LazyGit 的重度用户，aicommit2提供了原生级别的集成体验。通过配置 LazyGit 的自定义命令，你可以将 AI 生成信息的能力直接绑定到快捷键上。

# 在 ~/.config/lazygit/config.yml 中添加 customCommands: - key: 'C' # 使用 Shift+C 触发 context: 'files' description: 'AI Commit (with preview)' command: bash -c 'aicommit2 --output json | jq -r \"[.subject, .body] | join(\"\\\\n\\\\n\")\" | fzf --preview=\"echo {}\" --preview-window=top:60% | head -1'

这个配置（需要jq和fzf工具）会让你在 LazyGit 的文件面板按Shift+C时，调用aicommit2生成消息，并用fzf提供一个漂亮的预览界面供你选择，选中后自动填充到提交信息框。这比在终端和 LazyGit 之间切换流畅得多。

5. 高级配置、问题排查与性能调优

5.1 多模型与多提供商的高阶配置

aicommit2配置系统的强大之处在于其层次化和灵活性。

配置优先级与作用域配置的生效优先级从高到低是：命令行参数 > 环境变量 > 模型专属配置 > 全局配置 > 默认值。这让你可以在不同层级进行覆盖。

# ~/.config/aicommit2/config.ini [general] generate=1 temperature=0.7 [OPENAI] key=${OPENAI_API_KEY} model=gpt-4o-mini temperature=0.5 # 覆盖全局的0.7 [GEMINI] key=${GEMINI_API_KEY} model=gemini-2.0-flash-exp temperature=1.0 # 使用自己的温度值 generate=3 # 为 Gemini 单独设置生成3条建议

在上面的配置中，当使用 OpenAI 时，temperature是 0.5；使用 Gemini 时，temperature是 1.0，且会生成3条消息；对于其他未配置的提供商，则使用全局的temperature=0.7和generate=1。

为同一提供商配置多个模型这是实现“多模型竞速”的关键。

aicommit2 config set OPENAI.model="gpt-4o-mini,gpt-4o,o1-preview"

这样配置后，当你运行aicommit2，它会同时向 OpenAI 的这三个模型发起请求。哪个先返回结果，你就先看到哪个的建议。这既能对比不同模型的“文风”，也能在某个模型暂时不可用时作为降级方案。当然，这会产生多份 API 费用。

使用本地模型 (Ollama) 作为主力或备胎对于注重隐私、网络受限或想控制成本的场景，Ollama 是绝佳选择。

[OLLAMA] model=llama3.2:latest baseUrl=http://localhost:11434 timeout=30000 # 本地模型可以设置更长超时 watchMode=true # 更宽松的错误处理

你可以将 Ollama 作为默认提供商，或者将其设置为其他云服务的备胎。在配置中调整提供商的顺序或使用--provider参数可以控制使用哪个。

5.2 自定义提示词模板：让 AI 更懂你的团队

默认的提示词已经能生成不错的提交信息，但如果你团队有特殊的规范、术语或格式要求，自定义提示词是终极解决方案。

创建自定义提示词文件首先，创建一个文本文件，例如~/.config/aicommit2/prompts/my_team_prompt.txt。

你是一个经验丰富的软件工程师，正在为我们的项目生成 Git 提交信息。 项目主要使用 TypeScript 和 React。 请严格遵守以下规则： 1. 提交类型必须使用：feat, fix, refactor, docs, test, chore, perf, ci。 2. 范围（scope）是可选的，但如果改动涉及特定模块（如`auth`, `ui`, `api`），必须加上。 3. 主题行（subject）必须简洁，以动词开头，使用现在时态，首字母小写，结尾不要句号。 4. 正文（body）需要详细说明“为什么”进行这个改动，而不是“改了什么”。重点描述业务背景、问题根源或设计决策。 5. 如果有关联的 Jira 任务号（如 PROJ-123），请在正文第一行注明。 6. 如果改动是破坏性的（breaking change），必须在正文中明确以“BREAKING CHANGE:”开头进行说明。 以下是你需要总结的代码变更（git diff）： {{diff}} 请生成符合上述规范的提交信息。

注意{{diff}}这个占位符，aicommit2在运行时会将实际的代码差异填充到这里。

应用自定义提示词

# 通过命令行参数指定 aicommit2 --system-prompt-path ~/.config/aicommit2/prompts/my_team_prompt.txt # 或在配置中永久设置（对所有提供商生效） aicommit2 config set systemPromptPath=~/.config/aicommit2/prompts/my_team_prompt.txt # 或只为特定提供商设置 aicommit2 config set OPENAI.systemPromptPath=~/.config/aicommit2/prompts/openai_specific_prompt.txt

通过精心设计的提示词，你可以让 AI 的输出高度契合你团队的代码文化和流程要求，生成的提交信息几乎可以直接使用，无需修改。

5.3 健康检查与使用统计

工具用久了，你需要知道它是否健康，以及你的使用习惯。

健康检查 (aicommit2 doctor)这个命令会检查所有已配置的 AI 提供商的连接状态和配置有效性。

🩺 aicommit2 Health Check Providers: ✅ OPENAI API key configured ✅ OLLAMA Running (Host: http://localhost:11434) ⏭️ ANTHROPIC Not configured ⚠️ GEMINI API key configured, but model 'gemini-2.0-flash' may be deprecated Summary: 2 healthy, 0 error, 1 warning, 1 skipped

• ✅ Healthy: 配置正确，服务可达。
• ⚠️ Warning: 配置了但可能有问题（如 Ollama 未运行、模型已弃用）。
• ❌ Error: 配置错误（如 API Key 无效）。
• ⏭️ Skipped: 未配置。

定期运行doctor可以提前发现配置过期或服务异常的问题。

使用统计 (aicommit2 stats)这个功能让我清晰地看到了自己的“AI 提交成本分布”。

📊 aicommit2 Statistics Period: Last 30 days Overview: Total requests: 287 Success rate: 92.3% Avg response time: 1.8s Provider Usage: Provider Rate Bar Cnt Selected Time OPENAI 95% ████████████████████ 180 120 (66.7%) 1.2s OLLAMA 88% ██████████████████░░ 75 45 (60.0%) 3.5s GEMINI 92% ███████████████████░ 32 10 (31.2%) 2.1s

从统计中我能看出：

1. OpenAI 是我最常用且成功率最高的提供商。
2. Ollama 虽然慢（平均 3.5 秒），但在我选中的消息中占比不低（60%），说明其生成质量在某些场景下是可接受的。
3. Gemini 被我选中的比例较低，可能其生成的风格不太对我的偏好。 这些数据能指导我调整配置，比如减少 Gemini 的调用，或者为 Ollama 设置更长的超时时间。

5.4 常见问题与故障排除实录

在实际使用中，我遇到过一些典型问题，以下是排查思路。

问题一：运行aicommit2后无反应或立即退出。

• 检查：首先运行aicommit2 --verbose或aicommit2 -v。这会打开详细日志，输出每一步的执行信息，是排查的第一步。
• 可能原因：最常见的是没有配置任何有效的 AI 提供商。运行aicommit2 config list查看，并确保至少有一个 provider 的key或envKey配置正确。
• 可能原因：当前目录不是一个 Git、YADM 或 Jujutsu 仓库。确保你在正确的目录下执行。

问题二：AI 返回错误，如 “Invalid API Key” 或 “Model not found”。

• 检查：运行aicommit2 doctor。它会直接指出是哪个提供商的配置出了问题。
• 排查步骤：
  1. API Key 过期或无效：去对应 AI 服务商的控制台检查 Key 的状态和额度。
  2. 模型名称错误：AI 模型更新频繁。去对应服务商的文档确认你配置的模型名称（如gpt-4o-mini）是否仍然有效。aicommit2的默认配置通常是较新的，但如果你手动改过，可能已过时。
  3. 网络问题：特别是对于需要代理访问的服务（如 OpenAI），确保你的网络环境能稳定连接其 API 端点。对于 Ollama，检查ollama serve是否在本地运行。

问题三：生成的提交信息质量很差，过于笼统或错误。

• 原因：代码差异 (diff) 可能太大或太乱，超出了 AI 的理解能力。
• 解决方案：
  1. 提交更小的单元：这是最佳实践。不要一次性提交几十个文件的改动。遵循“原子提交”原则，每个提交只做一件事。
  2. 启用差异压缩：使用--diff-compression compact并配合--max-diff-lines限制，帮助 AI 聚焦于核心变更。
  3. 检查自定义提示词：如果你使用了自定义提示词，检查其指令是否清晰、无矛盾。可以暂时换回默认提示词 (aicommit2 config del systemPromptPath) 测试是否问题出在提示词上。
  4. 尝试不同的 AI 模型/提供商：不同的模型在代码理解能力上差异很大。从 GPT-4o 切换到 Claude Sonnet，或者试试本地的 CodeLlama，结果可能天差地别。

问题四：与 Git Hook 或其他工具（如 pre-commit）冲突。

• 表现：安装 Hook 后，git commit行为异常，或者aicommit2被重复调用。
• 排查：检查.git/hooks/prepare-commit-msg文件的内容。如果它是被其他工具（如 Husky）管理的，你可能需要将aicommit2 --hook-mode这行命令添加到对应的钩子脚本中（例如.husky/prepare-commit-msg），而不是直接覆盖。
• 解决：如果使用pre-commit框架，务必使用--pre-commit参数，并确保在.pre-commit-config.yaml中正确配置了stages: [prepare-commit-msg]。

问题五：在 Jujutsu 仓库中，aicommit2没有创建新的变更集。

• 原因：这是默认设计。aicommit2默认只运行jj describe来设置当前变更集的信息，而不是jj new。
• 解决方案：如果你希望它像git commit一样自动创建新变更集，有两种方式：

  # 单次使用 aicommit2 --jj-auto-new # 永久配置 aicommit2 config set jjAutoNew=true

  配置后，aicommit2会在生成描述后自动执行jj new，工作流就更接近 Git。

经过几个月的深度使用，aicommit2已经从我的一个“尝鲜玩具”变成了开发工作流中不可或缺的一环。它带来的最大价值不是节省了打字时间，而是提升了整个提交历史的可读性和规范性。现在回看项目历史，每一行提交信息都清晰地讲述了代码演进的故事，这对于新成员 onboarding、故障排查和知识传承都意义重大。工具本身也在快速迭代，社区活跃，遇到问题时去 GitHub 仓库的 Issue 里搜搜，通常都能找到答案或启发。如果你也受困于写提交信息，不妨花半小时配置试试，它很可能会改变你的开发习惯。