最近 r/ClaudeCode 有一篇帖子，标题叫 Claude rm -rf ed my pc。发帖者讲了一次高后果命令带来的麻烦，帖子有两千多赞、四百多条评论。评论区里还有人顺着聊隔离会话、真实仓库和工作目录的边界。
这类帖子只能说明开发者在担心什么。截图没有给出完整环境，命令前后做过什么、权限如何配置、机器后来怎样处理，外人都很难核实。把它当成某个产品已经坐实的漏洞，走得太远了。
我读下来更在意另一件事。大家真正怕的，往往不是某条命令本身。Agent 开始改文件、跑迁移、清理资源、触发部署以后，一次错误会把后面的动作一起带偏。人到最后才发现问题，面对的经常是一份很长的 diff、一批被覆盖的配置，或者一个说不清从哪步开始不对的环境。
确认框能拦住一条命令，却管不住这件事。
确认框解决的是授权。你点了允许，表示同意 Agent 去做。可它做错以后会丢多少东西，能不能停住，恢复要花多久，确认框给不出答案。对于会碰共享资源和线上状态的任务，我会在开始前问一句，做错了以后，我们能不能回到原来的状态。
这就是我说的可逆性验收。
一次任务会越过多少边界
人自己在终端里工作，通常知道刚刚改过什么。Agent 的路径更长。它读配置，改文件，运行脚本，看报错，再继续尝试。单看每一步，理由可能都说得通。几轮积累下来，最早那批改动已经很难单独拿出来判断。
“清理测试环境”就是常见例子。它先删临时文件，发现磁盘占用没有明显下降，接着去找部署脚本，又发现里面留着一段旧清理逻辑。到这里，任务已经从删几个目录，变成了处理一套自己也不完全了解的环境。
这种时候，盯着 rm、drop、delete 之类的字眼不够。真正决定风险的是对象在哪里，是否有人正在用，改完以后有没有版本可找，回退时能不能把系统带回可用状态。
删除一个专门为任务创建的 worktree，后果有限。覆盖共享环境的一段配置，即使没有出现删除命令，也可能让后续排查很难受。
先把动作放到合适的地方
日常任务不该处处弹窗。搜索代码、读取日志、查看配置，本来就应该顺畅。Agent 在独立分支里改几个文件，通常也可以放得宽一些，因为改动还在 Git 能处理的范围内。
动作开始碰共享状态，规则要变。
批量改配置、数据库迁移、覆盖既有文件，需要先准备快照。删共享资源、对外发送消息、发布生产环境、写入无法直接撤回的数据，需要人看过目标和恢复方式以后再放行。
团队不必搞一套复杂的审批系统，先把任务写清楚就已经能避开不少坑。测试环境到底是哪一个，允许改哪些目录，能否连接共享数据库，失败后哪些日志要留下，这些话写在任务里，Agent 才有边界可守。
有一篇文章写过 Claude Code 的分支和 worktree 工作流。这里再提它，不是为了推销某个 Git 技巧。独立分支让一次尝试留在它该待的地方。试错可以继续，主工作区不用陪着一起变乱。
高后果操作前，留四样东西
第一样是快照。
它可以是一条 Git commit、一个数据库备份、一份配置副本，也可以是部署前导出的状态。形式随项目而定，关键在于后来的人能找到它。只写“已备份”没有多少帮助。过几天再看，谁也不知道它备的是哪个环境，能不能恢复。
|
|
第二样是范围。
范围最好能落到路径、服务、环境、账户、区域或资源 ID。任务说“清掉旧资源”时，Agent 很难判断哪些资源算旧。换成“只处理 staging 账户里带有 temp-build 标签、创建时间早于七天的对象”，它至少知道自己不该顺手碰到别处。
执行前打印目标清单也很有用。人看到列表，常常会立刻发现一个不该在里面的服务。等任务跑完再从审计日志里倒推，成本高得多。
第三样是回滚入口。
“必要时可回滚”这句话听起来让人放心，真正出事时没法照着做。回滚需要一个入口，也需要前置条件和验收办法。撤回镜像后，健康检查是否通过。恢复备份后，缓存、队列和配置有没有回到同一版本。这些都该写出来。
|
|
最后一样是演练记录。
备份文件放在那里，回滚命令也写好了，人很容易觉得万事俱备。可恢复路径会过期。权限收紧、密钥更换、备份格式升级，都可能让那条命令到需要时失效。
小团队不必每周做完整灾备演练。新迁移脚本可以在测试数据上跑一次上行和下行。新增清理任务可以先挑十个样本 dry-run，记录它准备删什么。生产发布前，也可以先在 staging 走一遍撤回流程。
演练记录给后来的人留下一条证据。这条恢复路径至少在相近条件下走通过。
让 Agent 先把话说明白
下面这段可以放进任务说明、项目规则，或者 Agent 的工作指令。它不会拦住正常探索，只要求高后果动作前先交代清楚。
|
|
这段文字让几个常被省略的问题提前出现。范围说不清，Agent 应该停下来。没有快照，它不该把高后果动作当成普通编辑。回滚没有验过，团队就该承认这件事还没准备好。
规则是否让 Agent 变慢，取决于规则放在哪里。每个文件改动都要求确认，人很快就不看提示了。把确认留给共享资源、外部动作和不可逆状态，日常编码通常不会多出太多阻力。临时分支、dry-run 和目标清单反而会让任务更好推进，因为 Agent 不必猜自己能走到哪一步。
这几道防线各有位置
权限确认处理谁有资格执行。Prompt Injection（提示词注入）处理 Agent 读到的外部文本能不能影响它的判断。事故复盘处理出错以后怎样还原经过、查找原因，再把教训写回流程。
可逆性验收放在执行前。它默认人会看错，模型也会判断错，所以先收紧一次失误能造成的损失，再准备好回来要走的路。
Agent 负责执行，权限系统决定它能不能碰某个动作，可逆性验收要求团队在放行前准备范围、快照、回滚和恢复证据。下次让 Agent 跑迁移、批量改配置或清理资源时，可以先让它把这些内容写出来。看完再决定是否执行。很多问题到这里就已经暴露了，任务也有机会换成更安全的做法。
参考资料
扩展阅读
- Claude Code 安全文章 讨论评论区 Prompt Injection 如何进入 AI Agent 的执行链
- Meta工程师的 Claude Code 分支工作流 了解分支与 worktree 如何隔离试验性改动
- OpenChamber 一个以 Agent 为中心的开发环境，可作为可观察性工作流的参考
以上社区帖子和视频用于观察开发者的担忧与实践方向，不构成对特定产品缺陷或事故细节的独立验证。