如何在 Claude Code 中復原變更：/rewind 與 git

如何實際使用 Ailoot，請參閱文件。

Claude Code 的復原是什麼？為什麼三個層級還不夠？#

我開始使用 Claude Code 的第一週就啟用了 /rewind，因為它只用了兩個提示就把專案的驗證邏輯弄壞了。我復原、鬆了一口氣，然後繼續工作。一個月後又遇到另一種狀況：我正在編寫結構描述遷移，Claude 幫了忙，我提交變更、切換分支，才發現漏了一個必要步驟。/rewind派不上用場，因為工作階段已經不同了。使用 git checkout 回到前一個提交才解決問題。再過一個月，我不小心對代理人說：「把所有東西都退回最後一次 push」，它就執行了 git reset --hard，毀掉三小時的工作。git reflog救了我，因為被毀掉的提交雜湊仍然存在。

這三個故事代表三個運作方式不同的保護層級；它們能捕捉不同錯誤，因此全都不可或缺。本指南會逐一說明各層級的指令、限制與範例，也會介紹如何預先設定專案，避免 Claude 第一次犯錯就把專案弄壞。

復原的 3 個層級：用途與時機

接下來會逐一介紹每個層級：具體要怎麼做、有哪些陷阱，以及如何設定，讓事情沒出錯、自然也就無須復原。

如何呼叫 /rewind：輸入指令還是按兩次 Esc？#

每次回覆後，Claude 都會自動為它在該工作階段編輯過的所有檔案建立快照。快照會儲存在 ~/.claude/file-history/{sessionId}/，最多保留 30 天。快照採增量方式，只儲存狀態之間的差異，不會儲存整份檔案。預設每個工作階段最多儲存 100 個快照。因此，在多數實際專案中，你隨時都能看到 Claude 一整天工作期間所做變更的完整歷史。

輸入欄空白時，連按兩次 Esc 即可開啟復原選單：

[user-input is empty]
> _

[press Esc, Esc]

Rewind to which message?
  1. Create a migration for the User table          (3 files changed)
  2. Add the lastLoginAt field                      (1 file changed)
  3. Rewrite the authorization logic                (5 files changed)
  ...

如果輸入欄中有文字，第一次連按兩次 Esc 會清除文字並存入 Up 歷史。如果你已經開始輸入，才發現需要復原，這個功能就很實用。以下引述自 Anthropic 官方文件：

/rewind 指令會執行相同動作，也就是開啟選單。別名 /checkpoint 也會前往同一處。哪種方式比較順手取決於習慣。我使用 Esc Esc，因為速度較快，而且不用把手移離鍵盤。

復原選單中的 6 種模式：該選哪一種、什麼時候選？#

從清單中選一個時間點後，就會進入操作選單。共有六個項目，各自的功能都不同。

模式完整對照表：

Summarize up to here 功能出現在 Claude Code v2.1.139-v2.1.142，這些版本於 2026 年 5 月 11 日至 15 日、第 20 週發布：

Restore 和 Summarize 的差異很根本。Restore 會回到先前狀態，撤銷所選時間點之後發生的一切。Summarize 不會撤銷任何內容，只會壓縮；原始訊息仍保留在工作階段逐字稿中供參照，但作用中的上下文只會保留摘要。想要「當作這件事從未發生」時，使用 restore；想要「保留內容，但不要占用上下文空間」時，使用 summarize。

使用 Restore conversation 或 Summarize from here 後，所選提示的原始文字會回到輸入欄，你可以編輯後重新傳送。使用 Summarize up to here 後，輸入欄會是空的，對話則仍停在最末端。

/rewind 無法復原哪些變更？#

這是許多人遇到的主要限制：/rewind 顯示綠色勾號並說「復原成功」，但專案仍然壞掉，因為 Claude 動過的不只是檔案。來看看這三種情況。

1. 不會追蹤 Bash 指令。 如果 Claude 在某一輪執行 rm file.txt 或 mv old.txt new.txt，這些變更不會納入檢查點。Anthropic 文件明確指出：

也就是說，如果 Claude 使用 Bash 工具自行刪除、移動或複製檔案，/rewind 就無法完整還原。git checkout 或從備份還原可能有幫助，但不只按兩個鍵就能完成。

2. 不會捕捉外部編輯。 如果你手動在 VS Code 開啟檔案並編輯，或第二個 Claude 工作階段同時變更相同檔案，第一個工作階段看不到這些變更。檢查點快照會在 Claude 結束目前工作階段的一輪時建立。兩輪之間發生的事情不在它負責的範圍內。

3. 完全不涵蓋檔案以外的操作。 透過 npx prisma migrate dev 套用 Prisma 遷移會變更資料庫結構描述；/rewind 不會撤銷這項變更，因為資料庫位於專案檔案系統之外。推送到 origin/main 也是一樣：提交已傳送到遠端伺服器，檢查點無法將它取回。會扣款或刪除記錄的遠端 API 呼叫，只能透過該 API 自己的機制撤銷。

規則： 如果任務會影響專案檔案之外的內容──例如資料庫遷移、git push、遠端 API──請為每一項外部影響準備獨立的復原策略。/rewind 只負責目前工作階段內的本機檔案歷史。

/rewind 和 git 有什麼不同？為什麼兩者都需要？#

Anthropic 的文件直接說明了這種搭配方式：

差異整理如下：

兩者搭配很簡單：每當你覺得「這樣可以運作，而且我不想失去它」時，就建立 git commit。提交之間使用 /rewind；它能立即復原、不需要提交訊息，也不會讓 git 歷史充滿中間狀態。工作完成後就提交，最好建立有意義且原子化的提交。

為什麼一個 /rewind 無法涵蓋整項任務？#

復原是上下文工程的一種情況。管理工作階段上下文（何時提交、何時按 /rewind、在 CLAUDE.md 中設定哪些規則），就能讓 Claude 的行為可預期，不會破壞專案或遺失工作。

為什麼要求 Claude「退回」時，git reset --hard 很危險？#

「儲存目前狀態並退回最後一次 push」這樣的請求，可能會導致以下指令：

git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix"  # 已儲存尚未提交的變更
git reset --hard 35eb731                                                # 摧毀提交 d63695e..882e618

第一個指令是正確的，它把尚未提交的變更存入 stash。第二個指令則具有破壞性：它將分支改寫到提交 35eb731，兩者之間直到 882e618 的所有提交都成了孤立提交。預設情況下，孤立提交會留在 .git/objects/ 中，直到 git gc 執行；通常會在兩週內自動執行。但如果你當下不知道該怎麼做，時間已經開始倒數。

邏輯很簡單：自然語言中的「退回」、「回去」、「還原」、「回復」和「復原」，意思是「回頭查看」或「回到安全的地方」，而不是「摧毀歷史」。git reset --hard 會摧毀歷史──它會改寫分支，並移除從 HEAD 無法再連結到的提交。安全的替代方案是 git checkout <commit>，它會建立 detached HEAD，讓你在不動到分支的情況下查看舊狀態。

實務上最重要的結論，是在任何重要任務前先提交目前狀態，尤其是要重構多個檔案時。先建立一個提交，Claude 就算搞砸，也能用一個 git checkout . 指令復原，不會失去工作。

破壞性的 reset 之後，git reflog 如何救回你的工作？#

發生破壞性 reset 後，請立刻執行 git reflog：

git reflog

輸出會像這樣：

35eb731 HEAD@{0}: reset: moving to 35eb731
882e618 HEAD@{1}: commit: middleware refactoring complete
d63695e HEAD@{2}: commit: leaveRemove method finalized
1f9c8a3 HEAD@{3}: commit: tracker enter/leave disabled
35eb731 HEAD@{4}: pull origin main

HEAD@{1} 到 HEAD@{3} 就是那些被「摧毀」的提交。它們並沒有從 git 的本機物件儲存區消失，只是無法再透過分支存取。復原方法如下：

# 從最後一個「被摧毀」的提交建立分支
git branch recovered-work 882e618

# 或直接切換
git reset --hard 882e618

完成後，分支就會重新包含直到事故發生前的所有歷史。

reflog 的限制：

1. 僅限本機。 reflog 儲存在 .git/logs/HEAD，不會存放於遠端儲存庫。force-push 後若刪除本機儲存庫副本，reflog 也會隨資料夾一起消失。
2. 預設為 90 天。 較舊的項目可能會被 git gc 清除。你可以用 git config gc.reflogExpire 200.days.ago 設定期限。
3. 不涵蓋從未進入 HEAD 的內容。 如果某個提交只存在 stash 中，而 stash 被摧毀，reflog 只會顯示 stash 的最新狀態，不會顯示其內部歷史。

團隊規則： 發生事故後，絕不要立刻執行 git gc --aggressive。先用 reflog 調查並復原，其他事情之後再處理。也不要在確定所有需要的內容都已 push 之前，刪除本機儲存庫複本。

如何透過 CLAUDE.md 防止破壞性的 git 指令？#

漏洞在於，Claude 預設沒有防護脈絡。它會把「退回」解讀成 git reset --hard，因為技術上這確實是一種有效方法。請將保護規則放進專案的系統提示檔案 CLAUDE.md。

基本規則（加入你的 CLAUDE.md）：

## Git Safety Protocol

- 除非我明確要求，否則絕對不要執行具破壞性的 git 指令（push --force、reset --hard、checkout .、restore .、clean -f、branch -D）。未經授權執行破壞性操作沒有幫助，還可能造成工作遺失。
- 當我說「回復」、「退回」、「還原」、「撤銷」或「復原」時，請解讀為檢視指令：使用 `git log`、`git diff`、`git checkout <commit>`（建立 detached HEAD）或 `git stash`（保留變更）。
- 執行任何下列指令前，一律先徵求確認：
  - 將分支上的 HEAD 移至另一個提交
  - 修改提交歷史
  - 可能會遺失尚未提交的工作
  - 包含 --hard、--force、--aggressive 旗標
- 執行任何破壞性指令前，先列出編號比較：
  - 安全：使用 `git checkout <commit>` 暫時檢視
  - 具破壞性：使用 `git reset --hard` 永久摧毀
- 等我明確選擇後再執行。

團隊擴充規則（加入儲存庫根目錄的 CLAUDE.md）：

## Git Workflow Rules

- 每個可運作里程碑都要提交。WIP 提交前，先執行 `git status` 和 `git diff`，只用 `git add -- path/to/file` 暫存明確審查過的具名檔案，再查看 staged diff 後提交。計時提醒用來審查，不是暫存整個工作目錄的許可。
- Claude 提交時絕不要使用 `git add .` 或 `git add -A`。先執行 `git status` + `git diff`，再逐一指定檔案名稱。
- 對 main 執行 `git push --force` 前，先停下來詢問我。在功能分支上謹慎 force-push，只有確定我願意失去上一個版本時才執行。
- 解決合併衝突時，不要立刻選「ours」或「theirs」；先把兩個版本都展示給我，再由我決定。
- `.gitignore` 必須包含 `.env*`、`.claude/personal/`、`node_modules/`、`dist/`。缺少時請補上。

加入這些區塊後，下一次有人說「退回最後一次 push」，Claude 就會這樣回覆：

我看到 3 個尚未提交的檔案，而且最後一次 push 之後有 4 個提交。可以選擇以下兩種做法：

1. 安全：透過 git checkout <last-push-hash> 建立 view-last-push 分支。我會保留所有工作，但暫時顯示 push 時的狀態。
2. 具破壞性：執行 git reset --hard <last-push-hash>，永久摧毀 4 個提交和所有尚未提交的變更。90 天內只能透過 git reflog 復原。你要選哪一個？

這只需要半分鐘的對話，不必損失四小時的工作。

Claude Code 中復原的 5 種方式是什麼？該如何選擇？#

「Claude 把東西弄壞了，我得趕快還原」這種情況，請從這架梯子的最底層開始往上走。務必從第 1 層開始。

第 1 層。/rewind──在工作階段內立即復原。

連按兩次 Esc 或輸入 /rewind。選擇問題發生前的時間點，再選擇模式（通常是 Restore code and conversation）。一秒後就會回到過去，可以重新開始。這能處理 80%「Claude 做錯事」的情況。

第 2 層。git checkout .──撤銷所有尚未提交的變更。

git diff                    # 先查看實際變更內容
git checkout .              # 撤銷所有檔案中尚未提交的變更
# 或只指定檔案：
git checkout -- path/to/file.ts   # 僅一個檔案

/rewind 沒有作用時（例如 Claude 透過 Bash 修改了檔案），或你需要撤銷工作階段歷史以外的變更時，這個方法很有用。所有尚未提交的變更都會永久消失。如果你可能會後悔，請先執行 git stash（請參閱第 2.5 層）。

第 2.5 層。git stash──先把變更擱置起來。

git stash save "might still need this"
# 回到乾淨狀態（不包含變更）
# ...
# 如果改變主意，從 stash 還原：
git stash pop

這是在「永遠失去」和「維持原樣」之間的折衷方案。stash 會留在本機，直到你明確清除它。

第 3 層。git checkout <commit>──回到舊提交而不遺失歷史。

git log --oneline               # 找出正確提交的雜湊，例如 abc1234
git checkout abc1234            # detached HEAD，可檢視而不變更任何內容
# 如果喜歡這個狀態，就從該狀態建立分支：
git checkout -b recovery abc1234
# 返回：
git checkout main

這是安全的「暫時回到舊狀態」方法。detached HEAD 不會變更分支；目前在 main（或其他分支）上的工作仍會保留。如果要在這個狀態下繼續工作，請建立分支。

第 4 層。git reset --hard <commit>──讓分支退回某個時間點。

⚠️ 這是破壞性操作。指定雜湊之後的提交會變成孤立提交。

git reflog                                  # 記下目前狀態的雜湊
git reset --hard abc1234                    # 改寫分支
# 發現弄錯了？透過 reflog 回復：
git reset --hard HEAD@{1}                   # 回到 reset 前的狀態

只有在你確定不需要後續提交時才使用。也務必在 reset 前先查看 git reflog，以便知道改變主意時要回到哪裡。

第 5 層。git reflog + 復原──災難情況。

Claude、你或同事已經執行 git reset --hard 或 force-push，把工作清掉了。該怎麼辦？

git reflog                                          # 尋找災難發生前最後一個雜湊
git branch recovered HEAD@{N}                       # 從該處建立分支
git checkout recovered                              # 切換到該分支
git diff main                                       # 與目前狀態比較
git checkout main && git merge recovered            # 確定後再還原到 main

如果 reflog 已經清除（預設在 90 天後），最後手段是 git fsck --lost-found，它會顯示 .git/objects/ 中懸空的提交。這幾乎像考古，但有時仍然有效。

如何選擇層級：

如何保護專案，讓你根本不必復原？#

規則 1. 每 30 分鐘提交一次。

不要等到「任務完成」才提交。任何可運作的中間步驟都要提交。提交訊息可以隨意撰寫，重點是 Claude（或你）只需一個 git checkout 指令，就能回到可運作的狀態。

# 工作開始時
git status                        # 檢查所有已暫存與未暫存路徑
git diff                          # 審查變更
# 將此範例路徑換成實際審查過的檔案。
git add -- path/to/file.ts
git diff --cached                 # 確認將提交的確切內容
git commit -m "wip: starting User schema migration"

# 30 分鐘後（或第一次完成可運作的版本後）
git status
git diff
git add -- path/to/file.ts         # 實際審查路徑，不能用目錄萬用字元
git diff --cached
git commit -m "wip: User schema is ready, migration applied locally"

# 工作結束時，建立有意義的提交
git reset --soft HEAD~2           # 將三個 wip 提交合併為一個
git commit -m "feat(auth): add lastLoginAt field to User table"

若加入 PostToolUse 提醒，也應保留審查與具名路徑暫存規則。不要把計時器變成未檢查的自動提交，否則無關編輯或先前暫存檔案可能被一併提交。

規則 2. 最低限度的 .gitignore。

專案根目錄必須包含以下內容：

# 密碼與機密
.env
.env.local
.env.*.local

# 本機 Claude Code 設定（不會推送到團隊儲存庫）
.claude/personal/
.claude/sessions/
.claude/file-history/

# 相依套件與建置
node_modules/
dist/
.next/
build/

我會把 .claude/personal/ 資料夾用於自己的實驗和筆記，這些內容不應納入共用儲存庫。.claude/sessions/ 和 .claude/file-history/ 是 Claude Code 的本機儲存資料，不屬於儲存庫；它們會占用大量空間，而且與特定機器綁定。

規則 3. 在獨立分支上進行實驗。

如果任務規模很大（重構 10 個以上檔案、遷移至新資料庫、重寫模組），不要在 main 分支上進行：

git checkout -b experiment/auth-rewrite
# 工作、每 30 分鐘提交一次
# 如果成功：
git checkout main
git merge experiment/auth-rewrite
# 如果不成功：
git checkout main
git branch -D experiment/auth-rewrite     # 刪除分支
# 就這樣，main 分支維持原狀

這個簡單習慣能將「Claude 把專案搞砸了」變成「Claude 把一個分支搞砸了，我刪掉它，然後重新開始」。

規則 4. 執行危險操作前使用 git tag。

進行資料庫遷移、大型重構或相依套件更新前，先建立標籤：

git tag pre-prisma-migration-v2
# 工作
# 發生問題時：
git reset --hard pre-prisma-migration-v2
# 或只查看狀態：
git checkout pre-prisma-migration-v2

標籤是指向某個提交的具名指標，即使 reflog 清除後也不會遺失。

接下來：復原如何融入上下文工程？#

這三個復原層級是其中一項技能的基礎：在狀態出錯時知道如何還原。單獨來看，這項技能的範圍有限，但搭配其他上下文工程工具後，就能發揮更大的作用。

Plan Mode 不會讓你立刻寫程式碼──必須先規劃、確認，再執行。這是一種預防性復原：計畫事先經過審查，就不會寫下之後還得撤銷的內容。請參閱Claude Code 的 Plan Mode指南。

CLAUDE.md會設定 Claude 預設遵守的規則，包括前面介紹的 Git Safety Protocol。這能預防破壞性指令。

Second Brain會在不同工作階段之間提供專案記憶給 Claude──它知道有哪些程式碼、商業邏輯為何，以及之前達成哪些協議。記憶越完整，Claude 做錯事的可能性就越低。

Skills 和子代理人是以程式碼呈現的方法論。如果把正確的 git 工作流程寫進 Skill，就不會有子代理人未經確認便執行 git reset --hard。

以上全部合起來就是 Context Engineering。在提示之前管理上下文，而不是在提示過程中管理。更多內容請見什麼是上下文工程。

復原是最後一道防線。Plan Mode + CLAUDE.md + Second Brain + Skills 是前四道防線。設定好這些項目後，復原就會少見且簡單；若沒有設定，復原就會成為日常工作。

規劃結束之處，就是復原開始之處。

開啟 Ailoot。