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

作者：王巍 (onevcat)

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

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

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

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

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

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

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

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

但 agent 不需要喘氣。

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

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

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

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

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

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

安裝也就一行的事：

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)識(shí)。你不需要記 branch name 或 commit hash，這個(gè)短 ID 就是你在 jj 世界里的坐標(biāo)。一般來(lái)說(shuō)，你甚至可以只用前兩個(gè)或者前三個(gè)字母來(lái)代表它。

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

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

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

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

jj describe -m "feat: add auth module"

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

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

jjnew

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

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

幾個(gè) change 下來(lái)，你的jj log可能長(zhǎng)這樣：

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

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

分叉：jj new

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

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，沒(méi)有 detached HEAD，也不需要手動(dòng)操作。

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

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

jjnew wqnyzlkr mnopqrst
# 當(dāng)然，只要不重復(fù)，你也可以寫(xiě)
# 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

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

和遠(yuǎn)端 Git 交互

jj 通過(guò)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í)反過(guò)來(lái)，給你的 change 貼一個(gè) bookmark（映射成 Git branch）：

jjbookmark create my-feature -r wqnyzlkr
jjgit push

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

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

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

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

場(chǎng)景 1：最簡(jiǎn)單的日常 —— 開(kāi)始下一項(xiàng)工作

Git 時(shí)代

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

工作結(jié)束后：

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

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

jj

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

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

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

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

Git 時(shí)代

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

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

jj

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

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

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

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

Git 時(shí)代

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

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

jj

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

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

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

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

Git 時(shí)代

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

jj

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

然后對(duì) agent 說(shuō)：

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

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

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

場(chǎng)景 5：多 agent 并行開(kāi)發(fā)

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

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 模型用起來(lái)更順手一些，不過(guò)核心能力是對(duì)等的。選 jj 不會(huì)在多 worktree 并行的場(chǎng)景下丟掉什么能力。

場(chǎng)景 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查看操作級(jí)別的歷史，jj op restore 恢復(fù)到任意節(jié)點(diǎn)。什么都不會(huì)真正丟。

小結(jié)

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

當(dāng)你不再需要說(shuō)“先 stash”“切到那個(gè)分支”“interactive rebase 一下”的時(shí)候，你和 agent 之間的溝通帶寬才算真正被釋放出來(lái)了。你腦子里想的是產(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)寫(xiě)描述

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

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

開(kāi)始下一段工作

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

一般來(lái)說(shuō)直接讓你的 agent 使用 jj 就好，它的生態(tài)和 agent 對(duì)它的認(rèn)識(shí)，基本可以做到無(wú)縫切換，你只需要在 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 來(lái)管理版本控制 —— 包括本文提到的所有場(chǎng)景。

如果你的 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 安裝到本地。詢問(wèn)我希望安裝到用戶全局
還是當(dāng)前項(xiàng)目，然后把文件放到對(duì)應(yīng)的 skills 目錄。

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

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

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