对比 · llmc 替代方案
aic 对比 llmc
llmc 是供应商最多的选择——13 个 LLM 后端、TOML 提示词和精美的终端界面。它是一款有真实优势的成熟工具。这份对比会保持公平：打成平手的地方，我们如实说平手。aic 胜出的地方——hunk 级分批和合并冲突解决、无需依赖 Node.js——正是切换的理由。
逐特性对比
| 能力 | aic | llmc |
|---|---|---|
| 把未暂存改动自动分批成多个提交 | 是——把未暂存改动拆成逻辑原子提交 | 否——每个暂存的 diff 只生成一条信息 |
| 在单个文件内跨提交拆分（per-hunk） | 是——按意图把每个 hunk 归入自己的提交 | 否——最多文件粒度 |
| 解决合并冲突 | 是——`aic resolve` 提出 diff，逐文件确认 | 否——只写提交信息 |
| 供应商数量 | 12（11 个一流 + OpenAI 兼容） | 13 |
| 终端体验 | 清晰、快速的行式输出 | 带进度计时器的精美 TUI |
| 运行时与依赖 | Rust 二进制——无需 Node.js | Node.js——npx / npm |
| 安装配置 | 交互式 `aic setup` 向导 | 可选的 `llmc init`（TOML 配置） |
| 自定义提示词 | 环境变量覆盖（`AIC_SYSTEM_PROMPT`） | 支持 `${diff}` 插值的 TOML 提示词 |
| 项目活跃度 | 每周发布 | 自 2025-10 起停更，无 GitHub 发布 |
| 多条候选信息 | 否 | 否 |
| 提交信息格式 | 约定式提交 | 约定式提交 |
aic 领先之处
- 把未暂存改动自动分批成多个提交 aic 的招牌功能。llmc 把你暂存的内容作为一条信息提交。
- 在单个文件内跨提交拆分（per-hunk） aic 在 hunk 级别读取 diff；llmc（和榜单里所有工具一样）把文件当作原子单位。
- 解决合并冲突 llmc 没有冲突处理能力——你仍然要手动解开合并。
- 运行时与依赖 aic 是单个静态二进制；llmc 通过 Node 和 npx 运行。
- 安装配置 aic 引导你完成 供应商 → 密钥 → 模型；llmc 默认值合理，但配置基于文件。
- 项目活跃度 aic 每周发布并有公开更新日志；llmc 已沉寂约 9 个月。
- 多条候选信息 各有利弊 两者都没有从 N 条中挑选的菜单——都只起草一条。
- 提交信息格式 各有利弊 两者都是设计上的约定式专属——平手。
llmc 仍然占优之处
llmc 赢得两项诚实的让步——供应商数量和终端观感。如果它们比原子化历史更重要，选它是公平的：
- 供应商数量 llmc 的菜单里多一个供应商。aic 用一流 Anthropic/Gemini/DeepSeek 和 OpenAI 兼容逃生舱来回应。
- 终端体验 llmc 的界面是它的招牌——实时状态和计时器。aic 更看重速度和可脚本化。
- 自定义提示词 llmc 的提示词配置更丰富；aic 提供系统提示词环境变量覆盖。
常见问题
aic 是 llmc 的好替代方案吗？
如果你希望未暂存工作被提交成原子、约定的提交并解决合并冲突，是的。llmc 在供应商数量（13）和终端观感上仍占优。
llmc 还在维护吗？
llmc 自 2025 年底以来一直沉寂，且没有 GitHub 发布。aic 每周发布并带有公开更新日志。
更多对比
一句话总结
如果未暂存的改动堆积成山、希望它们被提交成干净、原子、约定的提交——或者希望用 AI 解决合并冲突——选 aic。如果你想要最全的供应商菜单和最漂亮的终端输出，llmc 是不错的工具——只要知道它是文件粒度的，而且自 2025 年底以来就没什么动静。