---

引言：当人类的“慢思考”撞上 Agent 的“快执行”

在软件开发的漫长历史中，Git 无疑是伟大的。它定义了过去二十年程序员协作的范式。然而，当我们进入 2025 年，当 GitHub Copilot、Cursor、Claude Engineer 成为我们每个人的“赛博义体”时，一个尴尬的现实浮出水面：Git 的心智模型正在成为 AI 时代的生产力瓶颈。

Git 的设计初衷是为“人类”服务的。人类需要 staging area（暂存区）来反复确认，需要 branch（分支）来隔离思维，需要 stash（暂存）来处理突发中断。这些机制本质上是给人类留出的“喘息空间”。

但 Agent 不需要喘息。它一秒钟可以修改 20 个文件，吐出上千行代码。如果你还在用旧的 Git 命令去指挥 Agent，你会发现自己陷入了无尽的 add、commit、rebase 循环中。

今天，我们要聊的是 jj (Jujutsu)。它不是要取代 Git 的远端地位，而是要重塑你的本地工作流。

---

第一部分：Git 的“原罪”与 Agent 的摩擦

1.1 消失的心流：被版本管理打断的逻辑

在使用 Agent 开发时，最痛苦的莫过于：你正在构思一个复杂的业务逻辑，Agent 已经写好了一半，这时你发现需要先提交一下之前的改动。

• Git 做法： git add . -> git commit -m "part 1" -> git checkout -b new-feature。
• 痛点： 你的大脑从“业务逻辑”被迫切换到了“Git 状态机”。

1.2 冗余的上下文：Token 的隐形浪费

Agent 并不理解什么是 detached HEAD，也不理解为什么 rebase 冲突后需要 git add 再 continue。为了让 Agent 正确操作 Git，你不得不把大量的 Git 状态信息喂给它。在长上下文对话中，这些都是昂贵的、无意义的 Token 消耗。

1.3 脆弱的撤回机制

如果 Agent 搞砸了（这经常发生），在 Git 里回滚到特定状态是一件高风险操作。git reset --hard 可能会让你丢失未提交的灵感，而 git reflog 对大多数初学者来说简直是天书。

---

第二部分：认识 jj —— 为变更（Change）而生

jj 的核心哲学极其简单：你的工作目录本身就是一个持续的变更。

2.1 安装与初始化：一分钟无缝衔接

jj 可以和 Git 共存。它读取 .git 文件夹，但提供了一套完全不同的操作界面。

# 安装 jj (以 macOS 为例)
brew install jj

# 在现有的 Git 项目中初始化 jj
# --colocate 参数非常重要，它让 jj 和 git 共享同一个工作区
jj git init --colocate

2.2 核心概念：Change ID vs Commit Hash

在 Git 中，Hash 是随内容变化的；在 jj 中，Change ID（如 kxryzmsp）是跨 rebase 不变的。这意味着你可以永远通过这个短 ID 找到你的这块工作，而不用担心它被移动到了哪里。

---

第三部分：实战演练 —— 像呼吸一样自然的操作

3.1 自动保存：再也没有 git add

在 jj 的世界里，只要你改了文件，改动就自动属于当前的 Change。

# 查看当前的变更状态
jj log

# 输出示例：
# @  kxryzmsp (no description set)  <-- 这是你当前正在改的东西
# │  modified: src/auth.rs
# ○  master

3.2 描述变更：随时随地的“后悔药”

在 Git 里修改 commit message 很麻烦（需要 commit --amend 或 rebase -i），而在 jj 里：

# 随时修改当前变更的描述
jj describe -m "feat: 实现用户登录逻辑"

# 甚至可以修改很久以前的某个变更
jj describe -r kx -m "fix: 修复了之前的登录漏洞"

3.3 开启新任务：jj new 的魔力

当你完成了一个阶段的工作，只需要输入 jj new。

# 这会将当前的 Change 定格，并开启一个新的空 Change
jj new

# 现在的 log 看起来像这样：
# @  wqnyzlkr (empty) (no description set)
# ○  kxryzmsp feat: 实现用户登录逻辑
# ○  master

---

第四部分：Agent 工作流的深度整合（核心干货）

这是 jj 真正降维打击 Git 的地方。

4.1 场景一：并行任务的完美隔离

想象一下，Agent 正在帮你写 UI，你突然发现后端有个 Bug 要修。

• Git 模式： stash -> checkout master -> pull -> new branch…（链路极长，容易出错）。
• jj 模式：
  1. jj new master（直接基于 master 开一个新 Change）。
  2. 修 Bug。
  3. jj edit kx（一键回到刚才的 UI 开发任务）。
     底层逻辑： jj 会自动处理文件系统的状态切换，Agent 甚至感觉不到中断。

4.2 场景二：精细化的“手术式”拆分

Agent 往往会一次性改动几十个文件。为了代码评审（Code Review），你需要把它们拆成：基础库改动、业务逻辑、测试用例。

# 使用 jj split 命令
jj split

# 这会进入一个交互式界面（或者让 Agent 操作）
# 你可以选择哪些文件归入第一个 Change，剩下的自动留在第二个
# 整个过程不需要暂存区，逻辑清晰如手术刀。

4.3 场景三：预设骨架，分段填充

这是我最推荐的高阶玩法：先写 Prompt，再填代码。

你可以先创建一串空的 Change，描述好每一步要做什么：

jj commit -m "step 1: 定义数据库模型"
jj commit -m "step 2: 实现 CRUD 接口"
jj commit -m "step 3: 编写集成测试"

然后告诉 Agent：“请依次 jj edit 到这三个 Change，并完成对应的实现。”
这种方式让 Agent 的执行具有了极强的结构化约束，比一段长 Prompt 效果好得多。

---

第五部分：安全感来源 —— jj undo 与操作日志

Agent 误删文件了？Agent 乱执行了 rebase？

在 Git 里，你可能要流汗了。在 jj 里：

# 撤回上一步操作（无论上一步是改代码、改描述还是 rebase）
jj undo

# 查看所有的操作历史（不仅仅是代码历史，而是你的操作指令历史）
jj op log

# 恢复到 10 分钟前的任何一个状态
jj op restore <operation_id>

这种**“操作级回滚”**赋予了开发者和 Agent 极大的试错空间。

---

第六部分：与世界和解 —— 如何推送到 GitHub？

jj 并不是孤岛。它通过 Bookmark（书签）与 Git 的 Branch 对接。

# 1. 给你的 Change 贴个标签（相当于 Git Branch）
jj bookmark create my-feature

# 2. 推送到远端
jj git push

# 你的同事在 GitHub 上看到的依然是标准的 Git Commit，
# 没人知道你用了 jj 这种黑科技。

---

结语：工具的进化，是为了解放思想

我们正处于从“手工业编程”向“工业化 Agent 编程”转型的节点。Git 是蒸汽机时代的杰作，而 jj 则是为电力时代准备的控制器。

jj 的核心价值在于：它让版本控制从一种“显性的负担”变成了“隐性的基座”。

当你不再需要指挥 Agent 去处理繁琐的分支管理和暂存区状态时，你和 Agent 之间的沟通带宽才真正被释放到了业务逻辑和创造力上。

现在就开始尝试吧：
不要担心迁移成本，因为它就在你的 .git 旁边。用好你的 jj，让 Agent 真正成为你的神助攻。

---

附录：jj 最小可用命令速查表

目标	jj 命令	对应 Git 逻辑
看状态	jj log	git log + status
改描述	jj describe -m "..."	git commit --amend
开新任务	jj new	git commit + 新编辑
修旧代码	jj edit <ID>	git checkout (无 HEAD 分离)
吃后悔药	jj undo	git reflog + reset (但更强)
同步远端	jj git fetch	git fetch
发布代码	jj git push	git push

---

本文旨在探讨 AI 协作下的工作流优化，更多技术细节请参考 jj 官方文档。