本文轉(zhuǎn)載自：《用好你的 jj - 重新思考 Agent 時(shí)代的版本控制》

作者：王巍 (onevcat)

原文鏈接：https://onevcat.com/2026/03/jj-for-agent-era/

作品采用 CC BY 4.0 知識共享許可協(xié)議。

過去大半年我一直在高強(qiáng)度地用 AI agent 寫代碼，用著用著發(fā)現(xiàn)一個(gè)問題：“怎么組織 agent 吐出來的東西”這件事，比我原來想的重要太多了。

這話聽著可能有點(diǎn)奇怪。大家關(guān)心的一般都是模型能力、prompt 怎么寫、上下文夠不夠長…… 但真的和 agent 密集配合過一陣子之后，你會(huì)發(fā)現(xiàn)有個(gè)更底層的東西一直在拖后腿：版本控制。說得再具體一點(diǎn)，就是你拿什么樣的心智模型來管理本地的代碼變更。

我現(xiàn)在的結(jié)論是：Git 作為遠(yuǎn)端協(xié)作和代碼托管的標(biāo)準(zhǔn)還是沒什么好說的，但在本地工作流這頭，jj (https://github.com/jj-vcs/jj) 明顯更適合現(xiàn)在這種人和 agent 來回切著干活的開發(fā)方式。這篇文章就是來安利這個(gè)的。

Git 在 Agent 時(shí)代的摩擦

Git 是個(gè)偉大的工具，這一點(diǎn)沒啥好爭的。但它的很多設(shè)計(jì)假設(shè)，是建立在二十年前“人類手工編程”的時(shí)代背景上 —— 一個(gè)人坐在編輯器前面，想清楚要改什么，改完檢查一遍，然后add、commit、push。這套流程是給人類的線性思維量身做的：staging area 給你一個(gè)“最后再看一眼”的機(jī)會(huì)，branch 幫你隔離不同的工作流，stash 讓你臨時(shí)把手頭的東西放一放。

說白了，這些機(jī)制就是給人類留一口喘氣的時(shí)間。

但 agent 不需要喘氣。

agent 一介入開發(fā)，staging area、detached HEAD、rebase in progress、stash 棧 —— 這些隱性狀態(tài)全都變成了絆腳石。Agent 不理解這些狀態(tài)，也沒必要理解。但你為了讓 agent 正確操作 Git，又不得不把這些狀態(tài)信息當(dāng)成額外上下文喂給它，白白浪費(fèi) token。

這里有個(gè)要緊的觀察：agent 的干活方式是“先嘩嘩地生成一堆，回頭再整理歷史”，而 Git 的模型偏向“邊想邊提交”。這兩件事天然就是擰著的。

想想你有多少次在心流里把自己打斷，跟 agent 說“提交一下”“先 stash 一下”“切到那個(gè)分支”。每一次都是一次脫軌 —— 你從“想產(chǎn)品想代碼”切到了“想 Git 狀態(tài)管理”。以前沒有 agent 的時(shí)候，這點(diǎn)開銷還能忍；但你和 agent 配合的節(jié)奏越快、頻率越密，每次打斷的代價(jià)就越高。

jj 和 Change：一個(gè)更簡單的心智模型 jj 的定位

jj 是一個(gè)可以和 Git 無縫共存的版本控制工具。本地用 jj 管理變更，遠(yuǎn)端依然通過jj git push/fetch和標(biāo)準(zhǔn) Git 交互 —— 對 GitHub 和你的同事來說，看到的就是普通的 git commit 和 branch，沒有任何區(qū)別。

也就是說你可以隨時(shí)試試看，不喜歡也可以隨時(shí)退回 Git，沒有遷移成本，不存在被鎖定的問題。

安裝也就一行的事：

brewinstall jj
cdyour-repo
jjgit init --colocate

jj 的核心概念是change。與其列一堆定義，不如直接上手看看。

假設(shè)你在一個(gè)現(xiàn)有 repo 里剛啟用了 jj，跑一下jj log：

@  kxryzmsp  (empty) (no description set)
○  master

@表示你當(dāng)前所在的 change，kxryzmsp是它的Change ID—— 一個(gè)跨 rebase 不變的唯一標(biāo)識。你不需要記 branch name 或 commit hash，這個(gè)短 ID 就是你在 jj 世界里的坐標(biāo)。一般來說，你甚至可以只用前兩個(gè)或者前三個(gè)字母來代表它。

現(xiàn)在開始寫代碼。改了幾個(gè)文件后，再跑jj log：

@  kxryzmsp  (no description set)
│  modified: src/auth.rs, src/main.rs
○  master

注意：你什么都沒做，改動(dòng)已經(jīng)屬于當(dāng)前 change 了。沒有git add，沒有 staging area，不存在“改了但還沒 add”這種中間態(tài)。在 jj 里，你的 working copy 本身就是一個(gè) change，文件一改，它就跟著變。

這段工作做完了，給它一個(gè)描述：

jj describe -m "feat: add auth module"

這就像寫 commit message，但有一個(gè)重要區(qū)別：隨時(shí)可以改。甚至可以對任意 change 改（jj describe -r -m "..." ），不需要rebase -i來修改歷史消息。

開始下一項(xiàng)工作：

jjnew

@  wqnyzlkr  (empty) (no description set)
○  kxryzmsp  feat: add auth module
○  master

jj new做的事情很簡單：把當(dāng)前 change 定格，創(chuàng)建一個(gè)新的空 change 作為你的新工作臺。相當(dāng)于 Git 的commit+ 開始新工作，但不需要add這個(gè)步驟。（順便一提，為了照顧git習(xí)慣，jj commit也存在：jj commit -m "..."就是describe+new的 alias。）

幾個(gè) change 下來，你的jj log可能長這樣：

@  tpqrstuv  (empty) (no description set)
○  wqnyzlkr  feat: add token refresh
○  kxryzmsp  feat: add auth module
○  master

到這里，你其實(shí)已經(jīng)理解了 jj 80% 的日常。接下來幾個(gè)操作也很直觀。

分叉：jj new

從某個(gè) change 開始新工作，不影響原來的鏈：

jjnew kx

○  wqnyzlkr  feat: add token refresh
│
│ @  mnopqrst  (empty) (no description set)
├─╯
○  kxryzmsp  feat: add auth module
○  master

jjedit kx

直接跳回那個(gè)kxryzmspchange 繼續(xù)改代碼。改完后，后續(xù)所有 change 自動(dòng) rebase，沒有 detached HEAD，也不需要手動(dòng)操作。

值得一提的是：對于已經(jīng)推送到遠(yuǎn)端的 immutable change，jj edit會(huì)直接報(bào)錯(cuò)（Error: Commit is immutable ），防止你意外改寫已發(fā)布的歷史。jj 在工具層面幫你守住了這個(gè)安全邊界，你不需要自己記住” 這個(gè)能不能改”。

Merge：給jj new傳多個(gè) parent

jjnew wqnyzlkr mnopqrst
# 當(dāng)然，只要不重復(fù)，你也可以寫
# jj new wq mn

@  uvwxyzab  (empty) (no description set)
├─╮
○ │  wqnyzlkr  feat: add token refresh
│ ○  mnopqrst  fix: hotfix for auth
├─╯
○  kxryzmsp  feat: add auth module
○  master

把mnopqrst移到wqnyzlkr后面：

jjrebase -s mnopqrst -d wqnyzlkr

@mnopqrst  fix:hotfixforauth
○wqnyzlkr  feat:addtokenrefresh
○kxryzmsp  feat:addauthmodule
○master

原本分叉的兩條線變成了一條直線，就這么簡單。

和遠(yuǎn)端 Git 交互

jj 通過bookmark和 Git 世界橋接。jj git fetch時(shí)，遠(yuǎn)端的 Git branch（比如master）會(huì)自動(dòng)映射為 jj 的 bookmark—— 所以你在jj log里看到的master就是遠(yuǎn)端的masterbranch。

拉取并 rebase 到最新：

jjgit fetch
jjrebase -d master

相當(dāng)于 Git 的git pull --rebase，但拆成了兩個(gè)明確的步驟：先拿數(shù)據(jù)，再?zèng)Q定怎么整合。

推送時(shí)反過來，給你的 change 貼一個(gè) bookmark（映射成 Git branch）：

jjbookmark create my-feature -r wqnyzlkr
jjgit push

Bookmark 只在和遠(yuǎn)端交互時(shí)才需要，本地工作幾乎不用想 branch 這個(gè)概念。

這些就是 jj 的全部日常了。沒有 staging area，沒有 detached HEAD，沒有 stash 棧。光是這些，日常在本地干活就已經(jīng)清爽不少了。但 jj 真正讓我覺得“這東西必須推薦給別人”的地方，是它和 agent 工作流之間的那種天然的契合感。

實(shí)戰(zhàn)場景：當(dāng) jj 遇上 Agent 工作流

接下來是我最想聊的部分。每個(gè)場景我都會(huì)列出 Git 時(shí)代的做法 —— 包括你可能會(huì)對 agent 說的話 —— 和 jj 下的做法。一對比就很清楚了。

場景 1：最簡單的日常 —— 開始下一項(xiàng)工作

Git 時(shí)代

你：看看現(xiàn)在的改動(dòng)情況，把這些變更提交并推送，
    然后新建一個(gè)分支，開始下一項(xiàng)工作：實(shí)現(xiàn)用戶頭像上傳功能

工作結(jié)束后：

你：檢查一下改動(dòng)，沒問題的話提交并推送

每項(xiàng)工作的開頭和結(jié)尾，你都得指揮 agent 走一遍“檢查 → add → commit → push”的儀式，開始新工作前還得記著建分支。這些指令跟你真正想做的事情一點(diǎn)關(guān)系都沒有，但一天可能得說上好幾遍。

jj

你：開始下一項(xiàng)工作：實(shí)現(xiàn)用戶頭像上傳功能

jj 永遠(yuǎn)是“干凈”的，Agent 直接無腦jj new就可以開始干活。甚至可以jj describe -m "feat: avatar upload"后在這個(gè) change 上直接工作。不需要 add，不需要顯式 commit。當(dāng)你需要推送時(shí)，再貼 bookmark 并 push。

版本控制從“每次都要交代的儀式”變成了“背景里自然發(fā)生的事”。

場景 2：做到一半，臨時(shí)切去處理別的事

Git 時(shí)代

你：先 stash 一下，切到 master，拉最新代碼，新建一個(gè)分支來修這個(gè) bug

Agent 需要執(zhí)行git stash → git checkout master → git pull → git checkout -b hotfix → ...修完... → git checkout - → git stash pop。這個(gè)鏈條中間任何一步出了岔子（比如 stash 沖突），agent 都可能卡住或者搞出更多問題來。

jj

你：先去修一下那個(gè) bug

Agent 只需要jj new master，在新 change 里修 bug，修完后jj edit回到之前的 change 繼續(xù)。沒有 stash，沒有分支切換，沒有什么狀態(tài)要恢復(fù)。

場景 3：完成工作后，拆分變更內(nèi)容

這大概是日常里最常見的整理場景了：agent 完成了一項(xiàng)（甚至多項(xiàng)）工作，產(chǎn)出了一大坨改動(dòng)，現(xiàn)在你需要把它們拆成邏輯清晰的提交歷史。

Git 時(shí)代

你：檢查我們的變更，按照修改的邏輯進(jìn)行合理拆分，
    并多次提交，保持 commit 合理可追溯

說實(shí)話，這對 agent 來說挺難的。它需要理解整個(gè) diff、想好怎么拆，然后git reset HEAD~1，再git add -p交互式地選 hunk—— 或者手動(dòng)git add特定文件然后 commit，來回好幾次。這個(gè)過程非常脆弱：agent 很容易 add 的時(shí)候漏掉文件，少選幾行，或者把不相關(guān)的改動(dòng)混進(jìn)同一個(gè) commit。

jj

你：按模塊拆分當(dāng)前 change：功能實(shí)現(xiàn)、測試、文檔各一個(gè)

Agent 執(zhí)行jj split，選擇文件或 hunk 歸到第一個(gè) change，剩下的自動(dòng)成為第二個(gè)。再jj split一次就拆成三個(gè)。全程沒有“暫存區(qū)”這個(gè)概念，也永遠(yuǎn)不會(huì)丟東西，不存在“reset 后忘了 add 某個(gè)文件”的風(fēng)險(xiǎn)。拆分錯(cuò)了就回去 edit，后面的 changes 自動(dòng) rebase。

場景 4：先規(guī)劃骨架，再讓 agent 分段實(shí)現(xiàn)

我個(gè)人覺得這是 jj 在 agent 工作流里最厲害的用法。

Git 時(shí)代

基本沒有什么對應(yīng)的自然操作。你頂多在一個(gè)外部文檔里列出步驟，然后讓 agent 一個(gè)個(gè)做完再 commit。但如果中間某步需要回頭改前面的實(shí)現(xiàn)，整個(gè)提交歷史就得用rebase -i來整理 —— 光是跟 agent 解釋清楚怎么 interactive rebase，就夠燒一輪上下文了。

jj

先創(chuàng)建一串 change 骨架，每個(gè)都是空的，只有描述（jj的提交格式和git一致：首行作為標(biāo)題，后續(xù)空行后作為描述，所以你也完全可以在-m后面寫小作文甚至 prompt）：

jj commit -m "refactor: extract auth module"
jj commit -m "feat: add token refresh logic"
jj commit -m "test: update auth tests"
jj commit -m "docs: update API documentation"

然后對 agent 說：

你：參考各 change 的描述，從 kxry 開始，順次處理每個(gè) change 的實(shí)現(xiàn)

Agentjj edit到第一個(gè) change，寫代碼；寫完后jj edit到下一個(gè)。每個(gè) change 填充完后，后續(xù) change 自動(dòng) rebase，不需要任何手動(dòng)操作。

還有個(gè)比較野的玩法：agent 甚至可以拿描述本身當(dāng)驗(yàn)收標(biāo)準(zhǔn) —— 你把測試方法和通過條件都寫在-m里，或者把你的 spec 拆成一堆骨架 change。Agent 跑完一個(gè)步驟，自己對照描述確認(rèn)達(dá)標(biāo)了，才往下走 —— 這就自然形成了一個(gè)自驅(qū)動(dòng)的循環(huán)。在 Git 里搞這種事情，你得額外維護(hù)一份文檔，agent 來回對照，可能還得配合 Ralph Loop 之類的東西才行，遠(yuǎn)沒有直接把標(biāo)準(zhǔn)寫進(jìn) change 描述來得順手。

場景 5：多 agent 并行開發(fā)

多 agent 并行在現(xiàn)在的開發(fā)里越來越常見了，Git 那邊git worktree已經(jīng)是很多團(tuán)隊(duì)的標(biāo)配。jj 通過 workspace 提供了對等的能力：

jjworkspace add ../agent-1
jjworkspace add ../agent-2
jjworkspace add ../agent-3

每個(gè) workspace 有獨(dú)立的磁盤目錄，但共享底層 store。多個(gè) agent 同時(shí)從同一個(gè) base 分叉干活：

       → b1 (agent 1)
base   → b2 (agent 2)
       → b3 (agent 3)

做完后jj new b1 b2 b3合并。和git worktree比的話，jj workspace 不需要提前建 branch，也不需要一個(gè)個(gè)合并搞出一堆 merge commit，配合 change 模型用起來更順手一些，不過核心能力是對等的。選 jj 不會(huì)在多 worktree 并行的場景下丟掉什么能力。

場景 6：Agent 搞砸了，需要快速回退

這件事幾乎一定會(huì)發(fā)生，而且會(huì)經(jīng)常發(fā)生。

Git 時(shí)代

你：撤回剛才的修改。
你：什么？操作丟了？你上下文里還有么？（大汗...）

Agent 得先判斷現(xiàn)在是啥情況：該用git reset --hard？git checkout .？git revert？還是得翻git reflog找到之前的狀態(tài)再reset？每種選擇的副作用都不一樣，選錯(cuò)了可能把工作成果弄丟，一天白干。

jj

你：撤回剛才的操作

Agent 執(zhí)行jj undo。一個(gè)命令，撤回最后一個(gè)操作，不管那個(gè)操作具體是什么。如果需要回退到更早的狀態(tài)，jj op log查看操作級別的歷史，jj op restore 恢復(fù)到任意節(jié)點(diǎn)。什么都不會(huì)真正丟。

小結(jié)

回頭看這些場景，jj 的好處不光是“少打幾個(gè)命令”或者“步驟簡單一些”。更要緊的是：你跟 agent 說話的時(shí)候可以只說業(yè)務(wù)上的事，不用操心版本控制的狀態(tài)。

當(dāng)你不再需要說“先 stash”“切到那個(gè)分支”“interactive rebase 一下”的時(shí)候，你和 agent 之間的溝通帶寬才算真正被釋放出來了。你腦子里想的是產(chǎn)品邏輯和代碼設(shè)計(jì)，而不是 Git 的狀態(tài)機(jī)怎么轉(zhuǎn)。

在 AI 時(shí)代，更重要的能力不是“一次生成完美的提交歷史”，而是“低成本地把已有結(jié)果整理成合理的歷史”。jj 的設(shè)計(jì)，恰好就是在做這件事。

如果你看到這里已經(jīng)有點(diǎn)心動(dòng)了，下面這張表就是你需要的全部。十個(gè)命令，覆蓋 jj 的日常使用：

操作

jj

Git 等效

查看狀態(tài)和歷史

jj loggit log --oneline --graph

+git status

給當(dāng)前改動(dòng)寫描述

jj describe -m "..."git commit -m "..."

（但 jj 可隨時(shí)改）

開始下一段工作

jj newgit commit

+ 繼續(xù)編輯

切到某個(gè) change 繼續(xù)編輯

jj edit git checkout

（但不會(huì) detach）

拆分一個(gè) change

jj splitgit reset HEAD~1

+ 反復(fù)git add -p+git commit

撤回上一步操作

jj undogit reflog

+git reset

拉取遠(yuǎn)端

jj git fetchgit fetch

Rebase 到最新 master

jj rebase -d mastergit rebase master

標(biāo)記要推送的 change

jj bookmark create feat -r @git branch feat

推送

jj git pushgit push

會(huì)這些就夠了。剩下的，邊用邊學(xué)。

讓 Agent 直接用上 jj

一般來說直接讓你的 agent 使用 jj 就好，它的生態(tài)和 agent 對它的認(rèn)識，基本可以做到無縫切換，你只需要在 AGENTS.md 或者 CLAUDE.md 提上一句“這個(gè) repo 在本地使用jj管理”，然后按照jj的方式組織提示詞并工作就好。

但如果你想要給你的 agent 喂一個(gè)更精確的操作指南的話，我也配套制作了一個(gè) jj 的 agent skill：onevcat-jj（https://github.com/onevcat/skills/tree/master/skills/onevcat-jj），讓它可以更好地理解和使用 jj 來管理版本控制 —— 包括本文提到的所有場景。

如果你的 agent 工具支持 skills.sh 生態(tài)，一行命令就能安裝：

npxskills add onevcat/skills --skill onevcat-jj

如果你裝了 OMA (Oh My Agents)，點(diǎn)一下就能裝：

或者，你也可以直接把下面這段話丟給你的 agent，讓它自己搞定：

讀取 https://github.com/onevcat/skills/tree/master/skills/onevcat-jj 的
SKILL.md 內(nèi)容，將它作為一個(gè) skill 安裝到本地。詢問我希望安裝到用戶全局
還是當(dāng)前項(xiàng)目，然后把文件放到對應(yīng)的 skills 目錄。

Git 在過去二十年里定義了現(xiàn)代軟件開發(fā)的協(xié)作方式，不管是慣性使然還是生態(tài)積累，我想這個(gè)地位在很長一段時(shí)間內(nèi)都不會(huì)變。但“協(xié)作”和“本地工作”是兩碼事。Git 在協(xié)作這頭還是沒得說的標(biāo)準(zhǔn)；而在本地這頭 —— 你怎么組織變更、怎么整理歷史、怎么和 agent 配合 —— 也許確實(shí)到了該重新想想的時(shí)候了。

jj 給出的答案挺樸素的：把那些為人類心理安全感設(shè)計(jì)的中間狀態(tài)砍掉，讓版本控制的心智模型回到最簡單的樣子。當(dāng) agent 越來越深地參與到日常開發(fā)里，這種低成本地重寫、拆分、回退和并行的能力，只會(huì)越來越重要。

Git 仍然是你和世界協(xié)作的語言；但 jj 可能是你和 agent 一起思考的更好方式。