想在提交前審查 AI agent 改的程式碼，用 Lazygit 的做法是：讓 agent 從一個乾淨的提交開始改；改完後按 0（或 Enter）開啟檔案 diff，用 Space、a、v 只暫存你看懂的 hunk 和行，其餘保持未暫存。然後檢查已暫存的 diff，用 git stash push --keep-index --include-untracked 只對這份快照跑測試，再以小而有名字的提交落庫。沒暫存的部分仍留在工作區，留給下一輪處理。
Coding agent 一次可能改很多檔案。Lazygit 能按 hunk 甚至按行接受改動，不必全收或全退，所以審查更快。下面的按鍵對應 Lazygit v0.66.3（2026 年 11 月 7 日釋出），來自它的官方按鍵文件和 README；Git 命令來自 Git 官方文件。暫存後測試這一套流程，我們在 2026 年 11 月 10 日用 Git 2.47.3 實際跑過一遍。
適合誰
- 你讓 Claude Code、Codex、Cursor 或其他 agent 改 Git 倉庫，想自己決定哪些內容進入提交。
- 你在用或想試 Lazygit。如果還要和 fzf、Yazi 一起配置，先看終端工作流教程，那裡講了基礎的按 hunk 暫存。
- 一行就能在
git diff裡看完的小改動用不上這套流程。agent 的 diff 大到你一眼記不住時，它才划算。
agent 開工前，先回到一個乾淨的提交
把倉庫交給 agent 之前，先提交或 stash 你自己的改動。這樣之後 Lazygit 裡出現的都是 agent 的改動，不會和你的混在一起。給 agent 任務單開一個分支，失敗時整個丟掉也方便。
這是我們的習慣，不是兩個工具的規定。它重要，是因為後面的審查都依賴於對照一個已知起點來讀 diff。
怎樣看到 agent 改動的全部內容？
在倉庫裡開啟 lazygit。Files 面板列出所有改動檔案，包括 Git 還沒追蹤的新檔案。未追蹤檔案最容易漏：agent 可能新建了輔助檔案、測試資料或草稿檔案，普通 git diff 根本不顯示。git status --short 用 ?? 標出它們。
看 agent 的 diff 時，三個檢視設定有用：
Ctrl+w切換是否顯示只改空白的變動。讀邏輯時可以開啟它遮蔽格式化噪音，暫存前再關掉，確認自己提交的是什麼。}和{增加、減少每處改動周圍的上下文行數，預設 3 行（配置項git.diffContextSize）。- 終端裡看不清時，
Ctrl+t用你配置的外部 diff 工具（git difftool）開啟。
怎樣只暫存你看懂的部分？
用主檢視的選擇模式。在 v0.66.3 中：
- 選中一個改動檔案，按
0（或Enter）把焦點移到主檢視裡的 diff。 - 初始選中的是整個 hunk。
Space暫存這個 hunk 並跳到下一個；←/→（或h/l）在 hunk 之間跳。 - 如果一個 hunk 裡既有想要的也有不想要的，按
a切到逐行選擇，按v選一段行，再按Space只暫存這些行。 - 已暫存的行會出現在下方窗格。
Tab在未暫存和已暫存窗格之間切換；在已暫存窗格按Space取消暫存。 - 需要手工改暫存內容時，
E用外部編輯器開啟當前 hunk。
如果某個鍵的效果和這裡寫的不同，可能是版本不同。在 Lazygit 裡按 ? 開啟當前面板的按鍵選單。
我們的規則：一行只有在你能解釋它為什麼存在時才暫存。除錯用的 print、被改寫的註釋、無關的重新命名，都可以先不暫存，回頭再決定。
不想要的部分怎麼處理？
先讓它們保持未暫存。未暫存的改動沒有成本，之後可以單獨提交、發回給 agent，或再丟棄。
有兩個鍵要小心：
- 主檢視裡的
d會丟棄選中的未暫存改動；對已暫存的選擇，它是取消暫存。 z（撤銷）根據 reflog 撤銷上一條 Git 命令，Lazygit 文件明確寫著它不包括工作區的改動。被丟棄的工作區改動，z救不回來。只丟棄你確定不要的，或先 stash。
想就某處改動追問 agent 時，選中那幾行按 Ctrl+o，Lazygit 會把選中的 diff 行復制到剪貼簿，直接貼進下一條提示詞，不用再口頭描述。
怎樣只測試你將要提交的內容？
要測的是已暫存的快照，而不是整個工作區。工作區裡還有未暫存的部分，在那裡測試通過，不代表單獨這個提交也能工作。Git stash 文件在 「Testing partial commits」 裡給出了這種場景的例子：
git diff --staged # 讀一遍將要提交的內容
git diff --staged --check # 有沒有衝突標記或空白錯誤？
git stash push --keep-index --include-untracked
# 在這裡跑測試：此時工作區只有已暫存的改動
git commit -m "fix: reject zero divisor"
git stash pop # 把未暫存的部分放回來按 Git 文件，各步作用是：--staged 是 --cached 的同義詞，顯示為下一次提交暫存的改動；--check 在改動引入衝突標記或空白錯誤時發出警告；--keep-index 保留已暫存內容、把其餘改動存進 stash；--include-untracked 把未追蹤檔案也存進去，這樣 agent 留下的多餘檔案不會讓測試碰巧通過。
我們在 2026 年 11 月 10 日（Git 2.47.3，一個兩檔案的 Python 小專案）試過：模擬一次 agent 修改，修了除零錯誤、加了一行除錯 print、新建了未追蹤的 scratch.py。只暫存修復後，git diff --staged --check 以狀態碼 2 退出，指出「agent」在改動行末留下的空格。測試期間工作區只剩已暫存的檔案改動，scratch.py 不在；提交後 git stash pop 把除錯行和 scratch.py 都放了回來。這只是一個小例子，不是評測。如果中間你又改了同幾行，stash pop 可能衝突，所以先 pop 再開始新的改動。
Lazygit 的 stash 選項也能做同樣的事（Files 面板按 S 可選擇只 stash 已暫存或未暫存等方式）。上面把 Git 命令寫出來，是為了讓你看清每一步發生了什麼。
分成小提交
按 c 提交已暫存的改動，在 diff 檢視裡也可以直接提交。相關的幾個鍵：
A用當前已暫存的改動修訂（amend）上一次提交。Ctrl+f找出你當前改動所基於的提交，適合 agent 的改動其實是在修之前某個提交的情況；具體流程見 Lazygit 的 fixup 文件。w提交時跳過 pre-commit hook。審查 agent 改動時我們不用它：hook 是 agent 和提交歷史之間少數自動檢查之一。
如果 agent 已經自己提交了，也還能審。選中該提交，按 Enter 看它的檔案，再聚焦某個檔案的 diff。Lazygit README 寫到：在舊提交的 diff 裡選中一個 hunk 按 d，可以把它從那個提交中移除，後台用互動式 rebase 改寫提交。已推送到共享分支的提交不要這樣做。
五分鐘檢查清單
- agent 開工前倉庫是乾淨的（或在新分支上）。
- 在 Files 面板檢查過未追蹤檔案，而不只看已修改的檔案。
- 每一行已暫存內容你都能解釋。
git diff --staged --check沒有報錯。- 工作區只保留已暫存改動時，測試通過。
- 提交資訊寫的是改動做了什麼，而不是「AI 改動」。
- 剩下未暫存的部分：單獨提交、發回給 agent，或有意識地丟棄。
常見問題
這不就是 git add -p 嗎？
思路相同，介面不同。git add --patch 逐個 hunk 詢問：y 暫存，n 跳過，s 拆成更小的 hunk，e 手工編輯。hunk 拆不動時，只能手改補丁文字。Lazygit 可以直接選單獨的行，並把已暫存和未暫存兩個窗格並排顯示。
已暫存的 diff 很乾淨，就說明改動正確嗎？
不。它只說明你知道自己提交了什麼。改動能不能用是另一項檢查：修改前後各跑一次失敗用例，看測試到底斷言了什麼。這部分見 AI 生成程式碼驗收清單、怎樣驗證 AI 修的 bug 和 AI 寫的測試會不會失敗。
本文對應哪個 Lazygit 版本？
v0.66.3，即 2026 年 11 月 10 日時的最新版本。README 說主檢視初始選中整個 hunk。如果你的版本一開始選中的是單行，或者某個鍵作用不同，請在應用程式裡按 ?，或檢視你所用版本的按鍵文件。
Lazygit 能撤銷丟棄操作嗎？
z 不行。Lazygit 的撤銷基於 reflog，只考慮提交，不包括工作區改動。確定之前，把不要的改動留在未暫存狀態或先 stash。
應該讓 agent 自己暫存和提交嗎？
這由團隊決定。我們的看法是：暫存應該由負責審查的人來做，因為暫存這一步就是在決定你為哪些內容擔保。agent 仍然可以提出拆分提交的建議，由你來核對。