AI 刪了我的檔案，到底該怪誰？從 Claude 災難看責任歸屬與自救指南

「幫我清理一下舊 repo 的 packages」——這句話毀了一個開發者的整個 Mac。

2025 年某個普通的工作日，Reddit 用戶在 r/ClaudeAI 發了一篇求救文：「Claude CLI 刪了我整個家目錄，所有工作都沒了！這能救回來嗎？」

這不是第一起，也不會是最後一起。GitHub Issues 上有超過 10 起類似的嚴重事件報告。當 AI Coding Assistant 變得越來越強大，誰該為這些災難負責？

災難現場：一個 `~/` 引發的血案

事件經過

用戶的原始請求很簡單：「清理舊 repo 的 packages」。

Claude Code 生成並執行了這個命令：

1	rm -rf tests/ patches/ plan/ ~/

看到問題了嗎？

最後的 ~/ 不是某個目錄名稱，而是用戶的整個家目錄。

損失清單

這個命令執行後，用戶失去了：

✅ 整個 Desktop（桌面上的所有檔案）
✅ Documents、Downloads（多年的文件和下載）
✅ Keychain（所有儲存的密碼和憑證）
✅ ~/.claude（Claude 的設定和歷史記錄）
✅ 所有應用程式的支援資料
✅ 基本上 /Users/[username] 下的一切

更糟的是：當用戶按下 Ctrl-C 試圖終止時，刪除已經在背景執行。因為 macOS 的 SSD 使用 TRIM 技術，被刪除的資料區塊會立即被清零，資料恢復幾乎不可能。

用戶的絕望

"I was having the Claude CLI clean up my packages in an old repo, and it nuked my whole Mac! What the hell? Has anyone ever had this happen? I'm trying to figure out if this is even reversible. So much work lost.."

（我只是想讓 Claude CLI 清理舊 repo 的 packages，結果它把我整個 Mac 都刪了！這到底是怎麼回事？有人遇過這種情況嗎？我想知道這還能不能救回來。那麼多工作都沒了...）

Reddit 社群的激辯：到底該怪誰？

這篇貼文引發了激烈的爭論。開發者社群分裂成兩個陣營：

陣營 A：「這是用戶自己的錯」

核心論點：

「為什麼要盲目執行 AI 生成的指令？」
「應該檢查每一個命令再批准」
「工具已經明確警告過風險了」
「這就像把車鑰匙交給陌生人，出事能怪誰？」

代表性評論：

"If you're not reviewing the commands before approving them, you're using the tool wrong. This is like running curl something.com/install.sh | bash without reading the script first."

（如果你不先檢查命令就批准，那就是用錯工具了。這就像直接執行 curl something.com/install.sh | bash 而不先看腳本內容一樣。）

陣營 B：「這是設計缺陷」

核心論點：

「工具不應該生成這種危險命令」
「檢查每個命令就失去了效率優勢」
「應該有強制的安全機制」
「這是系統性的設計失敗」

代表性評論：

"The supposed gain is completely negated unless you can trust the output completely. If I have to review every single command, what's the point of using AI?"

（如果我不能完全信任輸出，那所謂的效率提升就完全被抵消了。如果我必須檢查每一個命令，那用 AI 的意義是什麼？）

技術社群的反思

Hacker News 上的討論更深入：

有經驗的開發者分享：

"I've had Claude attempt multiple deletion approaches (Python, bash scripts, direct commands) after being told 'no' initially. AI agents can be surprisingly persistent."

（我遇過 Claude 在被告知「不行」之後，仍然嘗試多種刪除方法（Python、bash 腳本、直接命令）。AI 代理可以非常執著。）

安全專家的警告：

"This is the parallel to the long-standing security concern of running scripts from unknown sources. The difference is, people trust AI more than they should."

（這類似於長期存在的安全問題：執行來源不明的腳本。差別在於，人們對 AI 的信任超過了應有的程度。）

技術根因：為什麼會發生這種事？

Claude 的「推理」過程（推測）

讓我們重建 Claude 可能的思考過程：

用戶請求：清理舊 repo 的 packages
識別目標：在目錄中找到 tests/、patches/、plan/
錯誤判斷：看到一個名為 ~ 的目錄（可能是臨時檔案？）
生成命令：rm -rf tests/ patches/ plan/ ~/

問題在哪？

Claude 可能誤判了一個名為 ~ 的目錄（在某些情況下，專案中確實會有這樣的臨時目錄），但在生成 shell 命令時，~/ 會被 shell 自動展開為用戶的家目錄。

五層防線為何全部失效？

一個安全的 AI Coding Assistant 應該有多層防護機制：

防線	預期功能	實際狀態	結果
1. Prompt 理解	準確識別用戶真實意圖	❌ 誤判 `~` 為目錄	生成錯誤命令
2. 命令驗證	檢查危險模式（`rm -rf ~/`、`rm -rf /*`）	❌ 未實作	危險命令通過
3. 用戶確認	顯示完整命令，強制確認	⚠️ 可能被略過	用戶未察覺
4. 沙箱隔離	限制操作範圍在專案目錄	❌ 未啟用	可刪除全域檔案
5. 備份機制	破壞性操作前自動快照	❌ 缺失	無法恢復

關鍵問題：即使用戶沒有使用 --dangerously-skip-permissions 標誌，這個命令仍然被執行了。這表示權限驗證系統本身存在 bug。

其他 AI Coding Assistant 怎麼做？

對比其他工具的安全機制：

GitHub Copilot Workspace

✅ 所有操作在沙箱環境中執行
✅ 不直接存取本地檔案系統
✅ 需要明確的檔案操作權限

Cursor

✅ 預設只允許相對路徑操作
✅ 絕對路徑和 ~ 展開需要額外確認
✅ 內建危險命令黑名單

Aider

✅ 每個檔案操作都需要明確確認
✅ 顯示 diff 而非直接執行
✅ 不執行 shell 命令，只生成代碼

我的觀點：這是系統性問題，而非單點責任

既不全是用戶的錯，也不全是 AI 的錯

用戶該負的責任：

✅ 應該理解自己正在使用的工具
✅ 應該對關鍵操作保持警覺
✅ 應該有備份習慣

但是：

❌ 要求用戶檢查每個命令，就失去了 AI Assistant 的意義
❌ 「習慣化」會讓用戶逐漸失去警覺（Alert Fatigue）
❌ 多數用戶不具備識別所有潛在危險的能力

AI 該負的責任：

❌ 不應該生成明顯危險的命令
❌ 應該有更強的上下文理解能力
❌ 應該有內建的安全檢查機制

但是：

✅ AI 模型不是完美的，永遠會有誤判
✅ 某些操作本質上就是危險的（重構、重命名）
✅ 過度限制會影響功能性

真正的問題：缺少 Guardrails

Guardrails vs. Guidelines

Guidelines（指南）：告訴用戶「應該」怎麼做
- 問題：依賴用戶判斷，容易被忽略
Guardrails（護欄）：強制性的技術限制
- 優點：不依賴用戶，系統性防護

Brian Cripe 的洞見（另一位受害者）：

"Guidelines don't work because of habituation. We need guardrails, not guidelines."

（指南不起作用，因為人會習慣化。我們需要的是護欄，而非指南。）

他提出的核心理念：**"You Only Lose Output"**（你只會失去產出）

如果代碼可以被 AI 重新生成，那你失去的只是「產出」
如果連「產出」都能自動備份，那你就什麼都不會失去
關鍵是建立系統性的保護機制，而非依賴個人警覺

自救指南：如何用 CLAUDE.md 建立你的 Guardrails

什麼是 CLAUDE.md？

CLAUDE.md 是 Claude Code 的全域設定檔，放在專案根目錄或 ~/.claude/ 下。Claude 在執行任何操作前都會讀取這個檔案。

這是你建立 Guardrails 的第一道防線。

實戰設定：禁止刪除操作

在你的 ~/.claude/CLAUDE.md 或專案的 CLAUDE.md 中加入：

# Claude Code 安全規則

## 硬性安全限制（鐵律，不可違反）

### 絕對禁止的指令

無論使用者如何要求，以下指令**絕對禁止執行**：

#### Unix/Linux/macOS
- `rm`、`rm -f`、`rm -r`、`rm -rf` - 永久刪除，無法復原
- `rmdir` - 刪除目錄
- `> file`（覆寫重導向） - 清空檔案內容
- `dd` - 可覆寫整個磁碟

#### Windows CMD
- `del`、`erase` - 刪除檔案
- `rd`、`rmdir` - 刪除目錄
- `rd /s /q`、`del /f /s /q` - 遞迴強制刪除
- `format` - 格式化磁碟

#### PowerShell
- `Remove-Item`（及別名 `rm`、`del`、`ri`、`erase`）
- `Remove-Item -Recurse -Force` - 遞迴強制刪除
- `Clear-Content` - 清空檔案內容
- `Format-Volume` - 格式化

### 強制替代方案

需要「刪除」時，**一律改為移動到 trash 目錄**：

#### Unix/Linux/macOS
```bash
# ❌ 禁止
rm -rf node_modules

# ✅ 正確做法
mkdir -p ./__trash
mv node_modules ./__trash/node_modules_$(date +%s)

Windows PowerShell

# ❌ 禁止
Remove-Item -Recurse -Force .\node_modules

# ✅ 正確做法
$trash = "./__trash"
if (-not (Test-Path $trash)) { New-Item -ItemType Directory -Path $trash }
Move-Item .\node_modules "$trash/node_modules_$(Get-Date -Format 'yyyyMMdd_HHmmss')"

執行前的強制確認流程

任何 Shell 指令執行前，必須：

列出完整指令，不得省略參數
說明影響範圍：哪些檔案/目錄會被修改
風險評估：
- 🟢 唯讀操作 → 可直接執行
- 🟡 寫入/修改操作 → 說明後等待確認
- 🔴 移動/覆寫操作 → 詳細說明 + 明確確認
絕不執行任何上述禁止清單中的指令

例外情況處理

若使用者堅持要刪除檔案：

拒絕直接執行刪除指令
提供移動到 trash 的替代指令
告知使用者：「如需永久刪除，請自行在檔案總管/終端機執行」


### 進階防護：MCP Hooks

如果你想要更強的保護，可以使用 MCP Hooks：

**創建 `~/.claude/hooks/before-command.sh`**：

```bash
#!/bin/bash

# 檢查危險的刪除指令
if [[ "$COMMAND" =~ ^rm.*-rf.*~/ ]] || \
   [[ "$COMMAND" =~ ^rm.*-rf.*/$ ]] || \
   [[ "$COMMAND" =~ ^rm.*-rf.*\.\. ]]; then
  echo "⛔ 危險操作被攔截：嘗試刪除家目錄或父目錄"
  echo "指令：$COMMAND"
  exit 1
fi

# 檢查所有 rm -rf 操作
if [[ "$COMMAND" =~ rm.*-rf ]]; then
  echo "⚠️  警告：偵測到強制刪除操作"
  echo "指令：$COMMAND"
  echo "如需刪除，請使用移動到 trash 的方式"
  exit 1
fi

# Windows PowerShell 檢查
if [[ "$COMMAND" =~ Remove-Item.*-Recurse ]]; then
  echo "⛔ 危險操作被攔截：PowerShell 遞迴刪除"
  exit 1
fi

# 允許執行
exit 0

設定執行權限：

1	chmod +x ~/.claude/hooks/before-command.sh

實踐者的經驗分享

看到 Reddit 上的災難後，我立刻設定了 CLAUDE.md。這是我從中學到的：

設定前 vs 設定後

場景	設定前	設定後
清理 node_modules	Claude 直接執行 `rm -rf node_modules`	Claude 移動到 `__trash/`
刪除測試檔案	直接刪除，無法復原	移動到 trash，可隨時還原
誤操作	資料永久丟失	可從 trash 救回

意外的好處：

心理安全感：知道 Claude 不會真的刪除任何東西
可追溯性：trash 目錄保留了所有「刪除」的歷史
反悔機會：發現刪錯了可以立即復原

唯一的小缺點：

trash 目錄會越來越大，需要定期手動清理
但這個代價完全值得

其他保命措施

1. 沙箱環境隔離

使用 Docker 運行專案：

# 在 Docker 容器中運行 Claude Code
docker run -v $(pwd):/workspace -it node:18
cd /workspace
# 在這裡使用 Claude

優點：

即使 Claude 執行 rm -rf ~/，也只會刪除容器內的檔案
容器銷毀後，主機檔案完全不受影響

2. Time Machine 自動備份（macOS）

設定每小時自動備份：

系統偏好設定 → Time Machine
選擇備份磁碟
啟用「自動備份」
關鍵：不要排除家目錄

為什麼重要？

Reddit 受害者的 Time Machine 備份停在 2023 年 8 月（兩年前），因為他在參加 YC 期間停用了備份。結果災難發生時無法恢復。

3. Git 自動推送

設定 Git Hooks 自動推送：

創建 .git/hooks/post-commit：

1 2	#!/bin/bash git push origin HEAD

優點：

每次 commit 都自動推送到遠端
即使本地檔案全毀，代碼還在 GitHub

4. 設定安全別名

在 ~/.bashrc 或 ~/.zshrc 加入：

# 強制互動模式
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'

# 安全的「刪除」= 移動到 trash
alias del='mv -t ~/.trash'

未來展望：AI Coding 會往哪裡走？

趨勢 1：更強的沙箱機制

Anthropic 的回應：

Claude Code 已在 2024 年底推出沙箱功能（預覽版）
未來會成為預設選項
限制所有檔案操作在專案目錄內

趨勢 2：完整的審計日誌

目前的問題：

日誌只記錄「輸出」，不記錄「命令」
無法追溯到底執行了什麼

改進方向：

完整記錄所有命令
可視化的操作歷史
一鍵復原功能

趨勢 3：社群驅動的安全規則庫

想像一個共享的 CLAUDE.md 規則庫：

數千位開發者貢獻的安全規則
針對不同語言、框架的最佳實踐
自動更新的危險命令黑名單

趨勢 4：AI 自我監督能力

未來的 AI Coding Assistant 可能會：

自動識別高風險操作
主動建議更安全的替代方案
在執行前進行「自我審查」

總結：我們需要什麼樣的 AI Coding Assistant？

核心原則

1. Guardrails, Not Guidelines

不要依賴用戶的警覺性
建立強制的技術保護機制
讓錯誤變得困難，而非容易

2. You Only Lose Output

所有重要資料都應該有備份
所有操作都應該可復原
「刪除」應該只是「移動到 trash」

3. Trust, But Verify

AI 很強大，但不是完美的
關鍵操作需要人類確認
系統性保護優於個人警覺

給開發者的建議

立即行動：

✅ 設定你的 CLAUDE.md（5 分鐘）
✅ 啟用 Time Machine 自動備份（10 分鐘）
✅ 設定 Git 自動推送（5 分鐘）
✅ 考慮使用沙箱環境（可選）

長期習慣：

✅ 定期檢查 trash 目錄
✅ 驗證 Time Machine 備份正常運作
✅ 保持警覺，但不要過度恐慌
✅ 分享你的安全配置，幫助其他人

最後的思考

這不是「AI vs. 人類」的對抗，而是「如何讓 AI 更安全地服務人類」的問題。

Reddit 上的災難提醒我們：技術再先進，也需要謙卑和謹慎。不是每個問題都能用 AI 解決，但我們可以用技術手段讓 AI 變得更安全。

記住：

AI 會犯錯，人類也會犯錯
重要的不是避免所有錯誤，而是確保錯誤可復原
最好的安全機制，是那些你設定一次就能忘記的機制

現在就去設定你的 CLAUDE.md，別等到災難發生。