重點
Claude Code 的復原分成三個層級：內建的 `/rewind` 指令（在工作階段內立即復原）、`git checkout`（回到上一次提交的狀態），以及 `git reflog`（有人執行 `git reset --hard` 時的最後一道安全網）。每個層級只涵蓋各自的一類錯誤，無法超出其範圍。只知道 `/rewind`，第一次遇到嚴重失誤時就會毫無招架之力。
我開始使用 Claude Code 的第一週就啟用了 `/rewind`，因為它只用了兩個提示就把專案的驗證邏輯弄壞了。我復原、鬆了一口氣，然後繼續工作。一個月後又遇到另一種狀況：我正在編寫結構描述遷移，Claude 幫了忙，我提交變更、切換分支，才發現漏了一個必要步驟。`/rewind`派不上用場，因為工作階段已經不同了。使用 `git checkout` 回到前一個提交才解決問題。再過一個月，我不小心對代理人說：「把所有東西都退回最後一次 push」，它就執行了 `git reset --hard`，毀掉三小時的工作。`git reflog`救了我，因為被毀掉的提交雜湊仍然存在。
這三個故事代表三個運作方式不同的保護層級；它們能捕捉不同錯誤，因此全都不可或缺。本指南會逐一說明各層級的指令、限制與範例，也會介紹如何預先設定專案，避免 Claude 第一次犯錯就把專案弄壞。
**復原的 3 個層級：用途與時機**
| 層級 | 指令 | 涵蓋範圍 | 不涵蓋 |
|----|----|----|----|
| 1\. 工作階段內 | `/rewind` 或 `Esc Esc` | Claude 使用自己的工具變更的檔案；對話記錄 | Bash 指令、外部編輯器、資料庫遷移 |
| 2\. 提交之前 | `git checkout .` 或 `git stash` | 檔案中所有尚未提交的變更 | 已提交的提交 |
| 3\. 災難復原 | `git reflog` + `git reset --hard ` | 被 `reset --hard` 或 force-push 摧毀的提交 | 具破壞性的 Bash 指令（rm、資料庫遷移） |
接下來會逐一介紹每個層級：具體要怎麼做、有哪些陷阱，以及如何設定，讓事情沒出錯、自然也就無須復原。
## 如何呼叫 /rewind：輸入指令還是按兩次 Esc？
重點
在 Claude Code 中開啟復原選單有兩種方法。第一種是在輸入欄輸入 `/rewind`。第二種是在輸入欄空白時連按兩次 `Esc`。如果輸入欄中已有文字，先連按兩次 Esc 會清除文字並將內容存入輸入歷史；再連按一次兩下才會開啟選單。`/rewind` 指令也有別名 `/checkpoint`。
每次回覆後，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 官方文件：
如果提示欄中有文字，連按兩次 Esc 會先清除文字，而不是開啟選單。清除的文字會儲存在輸入歷史中，因此你可以在復原選單之後按向上鍵還原。
— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
`/rewind` 指令會執行相同動作，也就是開啟選單。別名 `/checkpoint` 也會前往同一處。哪種方式比較順手取決於習慣。我使用 `Esc Esc`，因為速度較快，而且不用把手移離鍵盤。
## 復原選單中的 6 種模式：該選哪一種、什麼時候選？
重點
在復原選單中選取一個時間點後，會出現第二個選單，內含六種模式。三種會還原狀態（`Restore code and conversation`、`Restore conversation`、`Restore code`），兩種會壓縮歷史（`Summarize from here`、`Summarize up to here`），一種會取消操作（`Never mind`）。最常見的情況──「程式碼和對話都要復原」──應選第一個選項。
從清單中選一個時間點後，就會進入操作選單。共有六個項目，各自的功能都不同。
**模式完整對照表：**
| 模式 | 功能 | 適用情況 |
|----|----|----|
| `Restore code and conversation` | 將檔案和對話記錄都還原至所選時間點 | 最常見的情況：Claude 走錯方向，我想重新用正確的說法開始 |
| `Restore conversation` | 只復原對話記錄；檔案維持目前狀態 | 程式碼沒問題，但對話偏離方向；我會從這裡重新表述，同時保留目前的變更 |
| `Restore code` | 復原檔案；對話維持目前狀態 | Claude 有些變更並不需要，但我仍需要對話脈絡（例如已商定後續步驟） |
| `Summarize from here` | 將所選時間點之後的所有內容壓縮成摘要，不變更檔案 | 長時間偵錯耗盡了上下文；我需要騰出空間，同時完整保留最初的指示 |
| `Summarize up to here` | 將所選時間點之前的所有內容壓縮成摘要，不變更檔案 | 最初的說明很長，後來才開始具體任務；將說明濃縮成一則訊息，近期工作則維持原樣 |
| `Never mind` | 不做任何變更並關閉選單 | 我改變主意了 |
`Summarize up to here` 功能出現在 Claude Code v2.1.139-v2.1.142，這些版本於 2026 年 5 月 11 日至 15 日、第 20 週發布：
你可以使用復原選單中的「Summarize up to here」壓縮早期上下文。
— Anthropic What's new, https://code.claude.com/docs/en/whats-new
`Restore` 和 `Summarize` 的差異很根本。Restore 會回到先前狀態，撤銷所選時間點之後發生的一切。Summarize 不會撤銷任何內容，只會壓縮；原始訊息仍保留在工作階段逐字稿中供參照，但作用中的上下文只會保留摘要。想要「當作這件事從未發生」時，使用 restore；想要「保留內容，但不要占用上下文空間」時，使用 summarize。
使用 `Restore conversation` 或 `Summarize from here` 後，所選提示的原始文字會回到輸入欄，你可以編輯後重新傳送。使用 `Summarize up to here` 後，輸入欄會是空的，對話則仍停在最末端。
## /rewind 無法復原哪些變更？
重點
`/rewind` 只追蹤 Claude 使用自己的檔案編輯工具所做的變更。它看不到也無法還原其他變更。共有三類不可見變更：Bash 指令（rm、mv、cp）、外部編輯（你在 IDE 中手動編輯、其他工作階段所做的變更），以及檔案以外的操作（資料庫遷移、git push、遠端 API 呼叫）。
這是許多人遇到的主要限制：`/rewind` 顯示綠色勾號並說「復原成功」，但專案仍然壞掉，因為 Claude 動過的不只是檔案。來看看這三種情況。
**1. 不會追蹤 Bash 指令。** 如果 Claude 在某一輪執行 `rm file.txt` 或 `mv old.txt new.txt`，這些變更不會納入檢查點。Anthropic 文件明確指出：
檢查點不會追蹤透過 Bash 指令變更的檔案。例如，Claude Code 執行 rm file.txt、mv old.txt new.txt、cp source.txt dest.txt 時，這些檔案變更無法透過復原撤銷。
— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
也就是說，如果 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 有什麼不同？為什麼兩者都需要？
重點
`/rewind` 是單一 Claude Code 工作階段中的本機回復機制。它會儲存增量快照，最多保留 30 天，每個工作階段最多 100 個。git 則是團隊共享的長期專案歷史，具備分支、合併衝突和遠端儲存庫。兩者不能互相取代。最佳做法是在每個邏輯里程碑建立 `git commit`，並在提交之間使用 `/rewind`。
Anthropic 的文件直接說明了這種搭配方式：
檢查點是為了快速復原工作階段而設計。提交、分支和長期歷史仍應使用版本控制系統（例如 Git）。檢查點是補充正常版本控制，而非取而代之。可以把檢查點想成「本機復原」，把 Git 想成「永久歷史」。
— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
差異整理如下：
| 項目 | /rewind | git |
|----|----|----|
| 粒度 | 對話中的每一輪 | 每次提交 |
| 儲存 | 最多 30 天、每個工作階段最多 100 個，儲存在本機 `~/.claude/file-history/` | 永久保存在儲存庫的 `.git/` 和遠端伺服器 |
| 追蹤內容 | Claude 使用自己工具所做的編輯 | 所有已提交的變更 |
| 不追蹤內容 | Bash、外部編輯、遷移、push | 尚未提交的變更 |
| 指令形式 | Claude 內的指令 | 外部版本控制系統 |
| 復原對話 | 是 | 否 |
| 跨工作階段使用 | 僅限同一工作階段 | 任何地方都可以 |
兩者搭配很簡單：每當你覺得「這樣可以運作，而且我不想失去它」時，就建立 `git commit`。提交之間使用 `/rewind`；它能立即復原、不需要提交訊息，也不會讓 git 歷史充滿中間狀態。工作完成後就提交，最好建立有意義且原子化的提交。
## 為什麼一個 /rewind 無法涵蓋整項任務？
復原是**上下文工程**的一種情況。管理工作階段上下文（何時提交、何時按 `/rewind`、在 `CLAUDE.md` 中設定哪些規則），就能讓 Claude 的行為可預期，不會破壞專案或遺失工作。
## 為什麼要求 Claude「退回」時，`git reset --hard` 很危險？
重點
自然語言中的「退回」代表「查看歷史」，而不是「摧毀歷史」；Claude 預設應提供 `git checkout`，而非 `reset --hard`；保護規則應設定在 CLAUDE.md 中。
「儲存目前狀態並退回最後一次 push」這樣的請求，可能會導致以下指令：
```bash
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 `，它會建立 detached HEAD，讓你在不動到分支的情況下查看舊狀態。
實務上最重要的結論，是在任何重要任務前先提交目前狀態，尤其是要重構多個檔案時。先建立一個提交，Claude 就算搞砸，也能用一個 `git checkout .` 指令復原，不會失去工作。
## 破壞性的 reset 之後，git reflog 如何救回你的工作？
重點
`git reflog` 會顯示儲存庫中 HEAD 所有移動的本機歷史，包括透過 `git reset --hard` 或 force-push 移除的提交。每次移動預設會保留 90 天。如果 Claude（或你，或其他人）使用破壞性指令摧毀提交，`git reflog` 會顯示它們的雜湊，你可以透過 `git reset --hard ` 還原分支。
發生破壞性 reset 後，請立刻執行 `git reflog`：
```bash
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 的本機物件儲存區消失，只是無法再透過分支存取。復原方法如下：
```bash
# 從最後一個「被摧毀」的提交建立分支
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.md` 中加入指示區塊，定義 Claude 可以自行執行哪些 git 指令、哪些需要明確確認，以及哪些必須等使用者逐字說出特定語句才允許執行。Claude 會將 CLAUDE.md 視為專案的系統提示，並預設遵守其中規則。這能把一個「危險」提示拆解成兩個安全指令。
漏洞在於，Claude 預設沒有防護脈絡。它會把「退回」解讀成 `git reset --hard`，因為技術上這確實是一種有效方法。請將保護規則放進專案的系統提示檔案 `CLAUDE.md`。
**基本規則**（加入你的 `CLAUDE.md`）：
```markdown
## Git Safety Protocol
- 除非我明確要求，否則絕對不要執行具破壞性的 git 指令（push --force、reset --hard、checkout .、restore .、clean -f、branch -D）。未經授權執行破壞性操作沒有幫助，還可能造成工作遺失。
- 當我說「回復」、「退回」、「還原」、「撤銷」或「復原」時，請解讀為檢視指令：使用 `git log`、`git diff`、`git checkout `（建立 detached HEAD）或 `git stash`（保留變更）。
- 執行任何下列指令前，一律先徵求確認：
- 將分支上的 HEAD 移至另一個提交
- 修改提交歷史
- 可能會遺失尚未提交的工作
- 包含 --hard、--force、--aggressive 旗標
- 執行任何破壞性指令前，先列出編號比較：
- 安全：使用 `git checkout ` 暫時檢視
- 具破壞性：使用 `git reset --hard` 永久摧毀
- 等我明確選擇後再執行。
```
**團隊擴充規則**（加入儲存庫根目錄的 `CLAUDE.md`）：
```markdown
## 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 ` 建立 `view-last-push` 分支。我會保留所有工作，但暫時顯示 push 時的狀態。
> 2. 具破壞性：執行 `git reset --hard `，永久摧毀 4 個提交和所有尚未提交的變更。90 天內只能透過 `git reflog` 復原。你要選哪一個？
這只需要半分鐘的對話，不必損失四小時的工作。
## Claude Code 中復原的 5 種方式是什麼？該如何選擇？
重點
發生問題時，有五個嚴重程度不同的層級：`/rewind`（工作階段內）、`git checkout .`（尚未提交的變更）、`git checkout `（回到舊提交而不遺失歷史）、`git reset --hard `（讓分支退回，並失去其後的提交）、`git reflog` + 復原（災難情況，所有內容都不見了）。每個層級都比前一個更有力，也更危險。
「Claude 把東西弄壞了，我得趕快還原」這種情況，請從這架梯子的最底層開始往上走。務必從第 1 層開始。
**第 1 層。`/rewind`──在工作階段內立即復原。**
連按兩次 `Esc` 或輸入 `/rewind`。選擇問題發生前的時間點，再選擇模式（通常是 `Restore code and conversation`）。一秒後就會回到過去，可以重新開始。這能處理 80%「Claude 做錯事」的情況。
**第 2 層。`git checkout .`──撤銷所有尚未提交的變更。**
```bash
git diff # 先查看實際變更內容
git checkout . # 撤銷所有檔案中尚未提交的變更
# 或只指定檔案：
git checkout -- path/to/file.ts # 僅一個檔案
```
`/rewind` 沒有作用時（例如 Claude 透過 Bash 修改了檔案），或你需要撤銷工作階段歷史以外的變更時，這個方法很有用。所有尚未提交的變更都會永久消失。如果你可能會後悔，請先執行 `git stash`（請參閱第 2.5 層）。
**第 2.5 層。`git stash`──先把變更擱置起來。**
```bash
git stash save "might still need this"
# 回到乾淨狀態（不包含變更）
# ...
# 如果改變主意，從 stash 還原：
git stash pop
```
這是在「永遠失去」和「維持原樣」之間的折衷方案。stash 會留在本機，直到你明確清除它。
**第 3 層。`git checkout `──回到舊提交而不遺失歷史。**
```bash
git log --oneline # 找出正確提交的雜湊，例如 abc1234
git checkout abc1234 # detached HEAD，可檢視而不變更任何內容
# 如果喜歡這個狀態，就從該狀態建立分支：
git checkout -b recovery abc1234
# 返回：
git checkout main
```
這是安全的「暫時回到舊狀態」方法。detached HEAD 不會變更分支；目前在 `main`（或其他分支）上的工作仍會保留。如果要在這個狀態下繼續工作，請建立分支。
**第 4 層。`git reset --hard `──讓分支退回某個時間點。**
⚠️ 這是破壞性操作。指定雜湊之後的提交會變成孤立提交。
```bash
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，把工作清掉了。該怎麼辦？
```bash
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/` 中懸空的提交。這幾乎像考古，但有時仍然有效。
**如何選擇層級：**
| 發生的狀況 | 層級 |
|-----------------------------------------------|-----------------------------|
| Claude 用錯誤方式改寫了 3 個檔案 | 1\. `/rewind` |
| 我試過了，但不喜歡；工作階段幫不上忙 | 2\. `git checkout .` |
| 我手動弄壞了，不想失去它，可能還會想復原 | 2.5. `git stash` |
| 已經提交；需要退回上一個提交 | 3\. `git checkout ` |
| 我確定不需要後續的提交 | 4\. `git reset --hard` |
| 已經用破壞性指令清掉了 | 5\. `git reflog` |
## 如何保護專案，讓你根本不必復原？
重點
最好的復原方式，就是不需要復原。三項保護規則：每 30 分鐘檢查進度，在可運作里程碑只暫存明確審查過的路徑後提交；在 `.gitignore` 中加入必要的 `.claude/personal/` 和 `.env*`；大型實驗使用獨立分支 `git checkout -b experiment-`。這可縮小已提交檔案的復原缺口；外部系統與未提交工作仍需要自己的復原計畫。
**規則 1. 每 30 分鐘提交一次。**
不要等到「任務完成」才提交。任何可運作的中間步驟都要提交。提交訊息可以隨意撰寫，重點是 Claude（或你）只需一個 `git checkout` 指令，就能回到可運作的狀態。
```bash
# 工作開始時
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`。**
專案根目錄必須包含以下內容：
```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 分支上進行：
```bash
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`。**
進行資料庫遷移、大型重構或相依套件更新前，先建立標籤：
```bash
git tag pre-prisma-migration-v2
# 工作
# 發生問題時：
git reset --hard pre-prisma-migration-v2
# 或只查看狀態：
git checkout pre-prisma-migration-v2
```
標籤是指向某個提交的具名指標，即使 reflog 清除後也不會遺失。
## 接下來：復原如何融入上下文工程？
重點
復原不是獨立技能，而是管理 Claude Code 工作階段上下文的一部分。知道何時按 `/rewind`、何時執行 `git commit`、何時使用 `git stash`，代表你管理的是整套工作流程，而不只是單一指令。這屬於 **Context Engineering** 的一部分。缺少它時，Claude 表現得像一般助理；具備它時，Claude 就像可預測的工具。
這三個復原層級是其中一項技能的基礎：在狀態出錯時知道如何還原。單獨來看，這項技能的範圍有限，但搭配其他上下文工程工具後，就能發揮更大的作用。
Plan Mode 不會讓你立刻寫程式碼──必須先規劃、確認，再執行。這是一種預防性復原：計畫事先經過審查，就不會寫下之後還得撤銷的內容。請參閱[Claude Code 的 Plan Mode](https://ailoot.ai/blog/zh-hant-tw/claude-code-plan-mode/)指南。
[CLAUDE.md](https://ailoot.ai/blog/zh-hant-tw/claude-md-template/)會設定 Claude 預設遵守的規則，包括前面介紹的 Git Safety Protocol。這能預防破壞性指令。
[Second Brain](https://ailoot.ai/blog/zh-hant-tw/claude-code-second-brain/)會在不同工作階段之間提供專案記憶給 Claude──它知道有哪些程式碼、商業邏輯為何，以及之前達成哪些協議。記憶越完整，Claude 做錯事的可能性就越低。
[Skills 和子代理人](https://ailoot.ai/blog/zh-hant-tw/claude-code-skills-library/)是以程式碼呈現的方法論。如果把正確的 git 工作流程寫進 Skill，就不會有子代理人未經確認便執行 `git reset --hard`。
以上全部合起來就是 **Context Engineering**。在提示之前管理上下文，而不是在提示過程中管理。更多內容請見[什麼是上下文工程](https://ailoot.ai/blog/zh-hant-tw/context-engineering/)。
復原是最後一道防線。Plan Mode + CLAUDE.md + Second Brain + Skills 是前四道防線。設定好這些項目後，復原就會少見且簡單；若沒有設定，復原就會成為日常工作。
### 來源
- [Anthropic Docs - Checkpointing](https://code.claude.com/docs/en/checkpointing)
- [Anthropic Docs - What's new (Week 20, 11-15 May 2026)](https://code.claude.com/docs/en/whats-new)
- [Anthropic Docs - Permission Modes](https://code.claude.com/docs/en/permission-modes)
- [Git Reference - reflog](https://git-scm.com/docs/git-reflog)
規劃結束之處，就是復原開始之處。
[開啟 Ailoot](https://ailoot.ai/)。
## 常見問題：如何在 Claude Code 中復原變更：/rewind 與 git
### WIP 檢查點應使用 git add . 嗎？
不應。先執行 `git status`、`git diff`，只暫存逐一審查過的具名檔案，再用 `git diff --cached` 檢查後提交。定期檢查點不代表可以納入無關或先前已暫存的變更。
### /rewind 能復原資料庫遷移或遠端 API 操作嗎？
不能。指南中的檢查點只涵蓋該工作階段支援的檔案編輯。資料庫、遠端 Git 與 API 效果需另有復原流程；檢查點範圍外的檔案應靠 Git 或備份。
## Ailoot · 公司及其專案組合
Ailoot以累積的營運經驗、廣大的客戶群、穩定的服務及持續的KPI管理為基礎。
公司及其專案組合：數百萬客戶，每月銷售額達數十億。
Ailoot將這些營運經驗用於API存取，讓客戶的產品、代理、應用程式及自動化流程使用AI功能。