AI 編程如何避免誤刪檔案：從 Git、權限到恢復流程

Fri, 10 Jul 2026 11:48:09 +0800

AI 編程最嚇人的事故，不一定是程式碼寫錯，而是檔案被刪了。

Codex、Claude Code、Cursor 這類工具已經能讀寫專案檔案、執行命令、批量重構、移動目錄。一旦上下文理解錯，或者使用者給了過寬權限，它可能真的會刪檔案、覆蓋設定、清空生成物，甚至把還沒提交的改動一起處理掉。

所以使用 AI 編程工具時，第一條安全原則不是「讓它更聰明」，而是：讓它沒有機會在錯誤範圍裡做破壞性操作。

這篇文章整理一套實用流程：減少 AI 編程誤刪檔案的機率，並且真的刪錯時能快速恢復。

先給結論：防誤刪要靠多層保護

不要把安全寄託在一句「不要刪除檔案」上。更穩的做法是疊幾層保護：

防護層	做什麼	解決什麼問題
Git 工作區	改動前先看 `git status`，重要節點小步提交	誤刪後能恢復
工作目錄隔離	只讓 AI 在目前專案或臨時分支裡操作	避免碰到無關資料
危險命令確認	刪除、覆蓋、批量移動前必須人工確認	防止模型自動執行破壞性命令
只讀審查	先讓 AI 分析影響面，不直接改	降低大範圍誤操作
忽略規則	把快取、建置產物、密鑰、資料目錄排除	防止把不該碰的檔案納入任務
恢復流程	準備 `git restore`、資源回收筒、備份和快照	出事後不慌

最重要的是：AI 能改檔案之前，專案必須有可恢復的狀態。

最容易誤刪的幾種場景

1. 「幫我清理專案」

這句話風險很高。AI 可能理解成刪除未引用檔案、舊元件、重複腳本、看起來沒用的 Markdown，或清理 tmp、dist、build、public。

但真實專案裡，「看起來沒用」和「真的沒用」差很多。有些檔案只在 CI、部署腳本、文件站、動態載入或插件機制裡被引用。

更安全的說法是：

`1`	`先只列出你認為可以清理的檔案和原因，不要刪除。等我確認後再處理。`

2. 「重構一下目錄結構」

移動檔案比修改程式碼更危險，因為它會影響 import、靜態資源路徑、框架約定目錄、CI/CD、文件連結、多語內容和部署產物。

更安全的流程是：

先生成遷移計畫。
列出會移動的檔案。
列出會改的引用。
小批量執行。
每批後跑檢查。
確認無誤後再刪除舊路徑。

3. 「把沒用的都刪掉」

「沒用」必須有判斷標準。否則 AI 可能根據檔名、更新時間、搜尋結果來猜。

建議改成：

`1`	`請只找出沒有被靜態引用的候選檔案，按風險分級列出來，不要刪除。`

再追問：

`1`	`這些檔案是否可能被執行期動態載入、設定檔引用、建置腳本引用或部署流程使用？`

第一步：改動前必須看 Git 狀態

AI 動手前，先看：

`1`	`git status --short`

如果工作區已經有很多未提交改動，風險會變高，因為 AI 誤刪後，你很難區分哪些是它刪的，哪些是你之前改的。

推薦規則：

乾淨工作區：適合讓 AI 修改。
少量已知改動：可以繼續，但要明確「不要碰這些檔案」。
大量未提交改動：先提交、stash 或備份。
有重要未跟蹤檔案：先確認是否納入 Git，別讓 AI 當成垃圾檔刪掉。

未跟蹤檔案尤其危險：

1
2
3

?? notes.md
?? scripts/new-tool.ps1
?? content/post/2026/07/41/

這些檔案不在 Git 歷史裡，被刪後 git restore 救不回來。

第二步：小步提交留恢復點

讓 AI 做大改前，先做安全提交：

1
2

git add .
git commit -m "chore: save working state before ai changes"

如果不想正式提交，也可以 stash：

`1`	`git stash push -u -m "before ai changes"`

-u 很重要，它會把未跟蹤檔案也一起保存。日常更推薦小步提交，因為可見、可比較、可回滾。

第三步：把 AI 限制在正確目錄裡

不要在使用者目錄、下載目錄、桌面根目錄直接開 AI 編程工具。

更安全的做法是在專案根目錄裡執行：

`1`	`cd C:\Work\my-project`

然後明確告訴 AI：

`1`	`只允許修改目前倉庫裡的檔案。不要讀取或修改倉庫外路徑。`

臨時檔案也要指定位置：

`1`	`所有臨時檔案都放到 tmp/ai-work/，不要在其他目錄建立或刪除臨時檔案。`

高風險改動可使用 Git worktree：

`1`	`git worktree add ../my-project-ai-test -b ai-test`

第四步：危險命令要人工確認

AI 編程裡最需要警惕的是：

rm -rf
del /s
Remove-Item -Recurse
git clean -fd
git reset --hard
git checkout -- .
mv
move
robocopy /MIR
rsync --delete

它們不是一定不能用，但必須知道目標路徑、影響範圍和恢復方式。

Windows PowerShell 裡尤其要小心：

`1`	`Remove-Item -Recurse -Force`

更安全的要求是：

`1`	`遇到刪除、覆蓋、批量移動、git reset、git clean、rsync --delete 這類操作時，先停下來說明目標路徑和影響範圍，等我確認。`

第五步：先審查，再刪除

AI 很適合幫你找「候選刪除項」，但不應該直接決定刪除。

檔案	AI 判斷原因	風險等級	是否建議刪除
`old-script.js`	沒有靜態引用	中	需人工確認
`dist/`	建置產物	低	可刪但需確認
`legacy-config.json`	名稱像舊設定	高	不建議直接刪

然後繼續追問是否可能被設定檔、CI、部署腳本、dynamic import 或文件連結引用。

如果你用 Claude Code subagent，可以建一個只讀 cleanup-reviewer，只允許它列候選檔案，不允許修改。關於 subagent 的使用場景，可以看：/zh-tw/2026/07/10/claude-code-subagent-project-fit-guide/。

第六步：把專案規則寫進 AI 記憶檔案

可以在 AGENTS.md、CLAUDE.md 或工具支援的專案說明檔裡加入：

# File Safety Rules

- Do not delete files unless the user explicitly asks for deletion.
- Before deleting, moving, or overwriting files, list the exact paths and wait for confirmation.
- Never run git reset --hard, git clean -fd, rm -rf, Remove-Item -Recurse, rsync --delete, or robocopy /MIR without explicit confirmation.
- Do not modify files outside the repository root.
- Treat untracked files as user-created files, not disposable temporary files.
- Prefer small edits and small commits.

中文專案也可以直接寫中文：

# 文件安全規則

- 不要主動刪除檔案。
- 刪除、移動、覆蓋前，必須先列出完整路徑和原因。
- 未跟蹤檔案預設視為使用者檔案，不要當成臨時檔案處理。
- 不要執行 `git reset --hard`、`git clean -fd`、`Remove-Item -Recurse` 等破壞性命令，除非使用者明確確認。
- 不要修改倉庫外的檔案。

這類規則不能保證 100% 不出錯，但能顯著減少 AI 自作主張。

如果你已經整理多專案記憶，可以把「哪些目錄不能碰、哪些命令必須確認、哪些檔案是生成物」放進專案級記憶。相關方法可參考：/zh-tw/2026/07/08/claude-code-multi-project-memory-team-workflow/。

第七步：區分原始碼、生成物和使用者資料

很多誤刪來自「檔案性質不清」。

類型	示例	AI 能不能刪
原始碼	`src/`, `app/`, `content/`	不能直接刪
設定	`.env.example`, `config/`, `package.json`	高風險
生成物	`dist/`, `build/`, `public/`	可重建時才可刪
快取	`.cache/`, `.next/cache/`	通常可刪
使用者資料	`uploads/`, `data/`, `notes/`	預設禁止
本地密鑰	`.env`, `*.key`, `secrets/`	預設禁止讀取和修改

最好在 README 或 AI 規則檔裡寫清楚：

## Directory Notes

- `content/` is source content. Do not delete posts.
- `public/` is generated by Hugo and can be rebuilt.
- `.env` and `secrets/` must not be read or modified.
- `tmp/ai-work/` is the only allowed temporary workspace.

第八步：提前會恢復流程

真的誤刪了，先別繼續讓 AI 大量修改。

恢復已跟蹤檔案：

git status --short
git restore path/to/file
git restore path/to/directory
git restore --source HEAD~1 path/to/file

從歷史恢復：

1
2

git log -- path/to/file
git restore --source <commit> path/to/file

如果是未跟蹤檔案，依序檢查：

編輯器本地歷史；
Windows 資源回收筒；
OneDrive、Dropbox、Syncthing 等版本記錄；
NAS 快照或備份；
檔案恢復工具；
AI 對話記錄裡是否還保留內容。

這也是為什麼大改前要先提交或 git stash push -u。

第九步：刪除前輸出差異

刪除前，要求 AI 先展示：

1
2

git diff --stat
git status --short

並解釋哪些檔案會被刪除、哪些會被移動、哪些只是修改、哪些是未跟蹤檔案，以及刪除後如何恢復。

看到這種狀態要特別小心：

1
2
3

D  src/important.ts
 D content/post/2026/07/old/index.zh-cn.md
?? backup/

D 表示 Git 跟蹤的檔案被刪除，?? 表示未跟蹤檔案，Git 不會自動幫你恢復。

AI 做完改動後，也應該再看一次：

`1`	`git status --short`

第十步：不同工具的防護思路

Codex

開始前看 git status；
明確禁止刪除未跟蹤檔案；
大改前先給計畫；
遇到 Remove-Item、rm -rf、git clean、git reset 要停下確認；
最後回報實際改了哪些檔案。

Claude Code

把檔案安全規則寫進 CLAUDE.md；
用 subagent 做只讀審查；
hooks 避免自動觸發破壞性腳本；
明確哪些命令需要人工確認。

Cursor / IDE 類工具

不要一次性接受大範圍刪除；
先看檔案樹變化；
對刪除檔案逐個確認；
重要專案仍以 Git 為準，不只依賴 IDE 復原。

一套安全提示詞模板

以後讓 AI 做清理、重構、遷移時，可以直接用：

請先分析，不要修改文件。

目標：找出這次任務可能需要修改、移動或刪除的文件。

要求：
1. 不要刪除任何文件。
2. 不要執行 git reset、git clean、rm -rf、Remove-Item -Recurse、rsync --delete、robocopy /MIR。
3. 未跟蹤文件默認視為用戶文件，不要當作臨時文件處理。
4. 先輸出計劃、影響範圍和風險點。
5. 如果確實建議刪除文件，列出完整路徑、原因、風險等級和恢復方式，等待我確認。

真正要執行時，再給第二段：

1
2
3

只執行我確認過的這些文件操作。
每次刪除或移動前，再輸出目標路徑。
完成後運行 git status --short，並匯報新增、修改、刪除的文件。

最後：AI 編程不是不刪檔案，而是可控地刪

專案裡確實會有需要刪檔案的時候：廢棄元件、舊腳本、重複資源、過期文件、建置快取，都可能需要清理。

關鍵不在於永遠不刪，而在於：刪除前有證據、有清單、有確認；刪除後能驗證；出錯後能恢復。

AI 編程越強，越要把檔案安全當作工作流的一部分。Git、小步提交、只讀審查、權限確認、專案規則和備份恢復，能把「誤刪檔案」從災難變成可回滾的小事故。

如果你的 AI Agent 經常跑長任務，還可以把每個階段的狀態、改動範圍和恢復點寫清楚，減少中斷後重複執行危險命令。這個方向可以繼續看：/zh-tw/2026/07/10/ai-agent-long-task-resume-guide/。

開發安全 on KnightLi的博客