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 能改文件之前，项目必须有可恢复的状态。

最容易误删的几种场景

AI 编程误删文件通常不是突然发生的，而是来自几类常见指令。

1. “帮我清理项目”

这句话风险很高。

AI 可能会把它理解成：

删除未引用的文件；
删除旧组件；
删除重复脚本；
删除看起来没用的 Markdown；
清理 tmp、dist、build、public；
合并目录后删除原目录。

但真实项目里，“看起来没用”和“真的没用”差别很大。有些文件只在 CI、部署脚本、文档站、动态加载、插件机制里被引用，简单 grep 不一定能查到。

更安全的说法是：

`1`	`先只列出你认为可以清理的文件和原因，不要删除。等我确认后再处理。`

2. “重构一下目录结构”

移动文件比修改代码更危险，因为它会影响：

import 路径；
静态资源路径；
Hugo、Next.js、Vite 等框架的约定目录；
CI/CD 脚本；
文档链接；
多语言内容；
部署产物。

如果 AI 同时移动目录、修改引用、删除旧目录，一旦中间理解错，很难判断到底哪一步造成问题。

更安全的流程是：

先生成迁移计划。
列出会移动的文件。
列出会改的引用。
小批量执行。
每批后跑检查。
确认无误后再删除旧路径。

3. “把没用的都删掉”

这是最危险的提示词之一。

“没用”必须有判断标准。否则 AI 可能根据文件名、更新时间、搜索结果来猜。对于动态项目，这种猜测经常错。

建议改成：

`1`	`请只找出没有被静态引用的候选文件，按风险分级列出来，不要删除。`

然后再让它补充：

`1`	`这些文件是否可能被运行时动态加载、配置文件引用、构建脚本引用或部署流程使用？`

第一步：改动前必须看 Git 状态

AI 动手前，先看：

`1`	`git status --short`

如果工作区已经有很多未提交改动，风险会变高。因为 AI 误删后，你很难区分哪些是它删的，哪些是你之前改的。

推荐规则：

干净工作区：适合让 AI 修改。
少量已知改动：可以继续，但要明确“不要碰这些文件”。
大量未提交改动：先提交、stash 或备份，再让 AI 做大改。
有重要未跟踪文件：先确认是否要纳入 Git，别让 AI 当成垃圾文件删掉。

特别注意未跟踪文件：

1
2
3

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

这些文件不在 Git 历史里。它们被删后，git restore 救不回来。对 AI 来说，未跟踪文件尤其危险，因为它可能把它们当作临时产物。

第二步：用小步提交给自己留恢复点

在让 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 很重要，它会把未跟踪文件也一起保存。否则新建但未提交的文件仍然可能丢。

不过日常更推荐小步提交，而不是长期依赖 stash。提交记录可见、可比较、可回滚，更适合真实项目。

第三步：把 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 在独立目录里工作，即使改乱了，也不会直接破坏主工作区。

第四步：给危险命令设人工确认

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`

这类命令在路径变量算错时非常危险。AI 如果用字符串拼命令、批量枚举路径再删除，很容易扩大范围。

更安全的要求是：

`1`	`遇到删除、覆盖、批量移动、git reset、git clean、rsync --delete 这类操作时，先停下来说明目标路径和影响范围，等我确认。`

如果工具支持权限模式，不要一上来给全自动写入和执行权限。日常开发建议保留确认步骤，尤其是涉及删除和覆盖时。

第五步：先审查，再删除

AI 很适合帮你找“候选删除项”，但不应该直接决定删除。

可以让它输出一个清单：

文件	AI 判断原因	风险等级	是否建议删除
`old-script.js`	没有静态引用	中	需人工确认
`dist/`	构建产物	低	可删除但需确认
`legacy-config.json`	名称像旧配置	高	不建议直接删

然后继续追问：

`1`	`请检查这些文件是否可能被配置文件、CI、部署脚本、动态 import、文档链接或外部系统引用。`

只有当证据足够明确时，再做删除。

如果你在用 Claude Code subagent，可以专门建一个只读 cleanup-reviewer，只允许它列候选文件，不允许修改。关于 subagent 适合什么项目，可以看：/2026/07/10/claude-code-subagent-project-fit-guide/。

第六步：把项目规则写进 AI 记忆文件

如果你经常使用 AI 编程工具，建议在项目里写一个给 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 自作主张。

如果你已经在整理多项目记忆，可以把“哪些目录不能碰、哪些命令必须确认、哪些文件是生成物”放进项目级记忆。相关方法可以参考：/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/`	默认禁止读取和修改

不要让 AI 通过文件名猜。最好在 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 做清理时更不容易误判。

第八步：恢复流程要提前会

真的误删了，先别继续让 AI 大量修改。越继续改，越难恢复。

恢复已跟踪文件

如果文件已经被 Git 跟踪，可以先看状态：

`1`	`git status --short`

恢复单个文件：

`1`	`git restore path/to/file`

恢复整个目录：

`1`	`git restore path/to/directory`

恢复到某个提交版本：

`1`	`git restore --source HEAD~1 path/to/file`

找回被删除但 Git 里存在的文件

查看最近提交：

`1`	`git log -- path/to/file`

从某个提交恢复：

`1`	`git restore --source <commit> path/to/file`

误删未跟踪文件怎么办

未跟踪文件不在 Git 里，恢复更麻烦。可以按顺序检查：

编辑器本地历史；
Windows 回收站；
OneDrive、Dropbox、Syncthing 等同步工具的版本记录；
NAS 快照或备份；
文件恢复工具；
AI 对话记录里是否还保留了内容。

这也是为什么大改前要先提交或 git stash push -u。

第九步：让 AI 每次删除前输出差异

删除文件前，要求 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、Claude Code、Cursor 还是其他 Agent 工具，原则都差不多。

Codex

适合做仓库级修改，但要注意：

开始前看 git status；
明确禁止删除未跟踪文件；
大改前先让它给计划；
遇到 Remove-Item、rm -rf、git clean、git reset 要停下来确认；
让它最终汇报实际改了哪些文件。

Claude Code

适合终端内长任务和项目工作流。建议：

把文件安全规则写进 CLAUDE.md；
用 subagent 做只读审查，不让审查角色直接删文件；
使用 hooks 时避免自动触发破坏性脚本；
明确哪些命令需要人工确认。

Cursor / IDE 类工具

IDE 工具有可视化 diff，但也容易批量接受修改。建议：

不要一次性接受大范围删除；
先看文件树变化；
对删除文件逐个确认；
重要项目仍然以 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 经常跑长任务，还可以把每个阶段的状态、改动范围和恢复点写清楚，减少中断后重复执行危险命令。这个方向可以继续看：/2026/07/10/ai-agent-long-task-resume-guide/。

开发安全 on KnightLi的博客