Claude Code 改错了怎么撤回？

同一个会话里，Claude Code 做了两件事：用文件编辑工具改了 Home.tsx，又跑了一个脚本，把 report.json 整个覆盖了。你觉得方向不对，用 /rewind 回到较早的 checkpoint。Home.tsx 恢复了原样，report.json 却还是被覆盖后的内容。

很多新手心里都有一份“安全感清单”：有 checkpoint 能撤销，有测试能兜底，它自己也审查过一遍。可每一项保护都只管一段。checkpoint 追踪的是文件编辑工具的改动，只被脚本改过的文件不在里面；数据库写入、消息发送和部署，更是撤不回来。截图只证明一种状态，同一个会话里的自查也代替不了独立审查。

所以控制风险，先看清每项保护能兜住什么、兜不住什么，再按真实风险组合起来：

• 用四个问题判断一项操作的风险，决定给多大权限；
• 用 Git 保存正式版本，checkpoint 只当会话里的快速撤销；
• 按任务选验证方式，记录实际执行过的检查；
• 人工审查对照计划和 diff，说清还有哪些没覆盖。

动手前写清目标、边界和验收，再把这几层叠起来。判断安全时，能说出具体对象、可能后果、已有保护和没覆盖的部分，才算真正心里有数。

01 先写清目标、边界和验收

权限、恢复与验证要按真实风险组合，彼此替代不了：哪些动作需要限制，哪些变化能恢复，测试和人工审查各能证明什么，要分开看。

动手前，先写清三件事：

这三件事说清楚以后，再根据实际风险决定给 Claude Code 什么权限。

02 入门阶段用哪种权限

按风险选择权限模式，并确认界面上的实际模式和已有的放行规则。default（界面里叫 Manual）也会受已有放行规则影响，未必每次都询问；plan 中的探索命令同样要检查副作用。更宽松的模式会减少人工确认，入门阶段先不用。各模式的区别和切换办法，可以看权限请求的判断方法。

入门阶段，先用 default 和 plan 练习判断：

影响范围还不清楚             → 用 plan 先分析
范围明确，改错容易恢复       → 用 default 审查小改动
涉及数据库、支付等高风险区域 → 先只读分析

权限、部署和生产环境也按高风险处理。

提示词里写“只分析”，表达的是任务约定，实际模式还要另外设置。开始前确认界面状态；即使没有审批提示，也要核对动作是否在授权范围内。

03 用四个问题判断操作风险

批准前，从四个方面判断具体操作，命令名称和是否弹出确认都只是参考：

1. 做错后能轻松恢复吗？
2. 它会影响多少个文件或系统？
3. 它会悄悄向外部环境写入数据吗？
4. 它会接触密钥或其他敏感信息吗？

四个问题中，只要有一项还不确定，就先停下来查清。再用下面这张表作初步判断：

表中的等级只是初步参考。同一命令的参数、对象或环境变了，实际后果也可能跟着变；涉及数据或外部状态时，还要进一步确认：

凡是会影响数据、权限、部署、密钥、生产环境和不可逆删除的操作，都不要在新手阶段自动批准。

不确定一个命令是否安全时，先让 Claude Code 解释：

请先解释这个命令：
1. 它会做什么？
2. 会不会修改文件？
3. 会不会访问网络？
4. 会不会删除、覆盖或移动内容？
5. 有没有只读的替代检查方式？

这类问题值得问清。作用、范围和回退方式都有了依据，再决定是否批准，才是在判断风险。

04 checkpoint 和 Git 各管一段

checkpoint 可以恢复文件编辑工具追踪到的会话改动，Git 保存正式的版本历史。按官方 checkpoint 文档，Claude Code 会追踪文件编辑工具做的所有改动，可以用 /rewind 回退；某个文件只被 Bash 命令改过，就不在追踪范围内，会保持原样。官方在《Claude Code 如何工作》里也写明，数据库、API、部署这类影响远端系统的动作，都在 checkpoint 的范围之外。恢复对话，撤销不了这些外部结果。

回到开头的例子，回到较早的 checkpoint 后，要分开检查：

回退后，Home.tsx 可能已经恢复，report.json 却仍是被脚本覆盖后的内容，所以两份文件都得看。后者如果事先没有保存旧内容，就可能无从恢复。有没有恢复依据，取决于具体改动，以及记录它的是哪种机制。

新手可以这样记：

checkpoint = 本次 Claude Code 会话里的快速撤销
Git = 项目的正式版本历史

两层保护配合着用：

执行前：检查 `git status`，保存已有改动并确认恢复办法
执行中：必要时使用 checkpoint 和 `/rewind`
执行后：检查 diff，再决定是否提交

行动前保存已有内容，尤其是高风险改动前，先建立 Git 记录或可靠备份。这样即使离开了这次会话，也有恢复办法。

05 按任务选验证方式

开始前先选好验证方式，用实际结果判断目标是否达成，也为失败后的分析提供方向：

可以要求 Claude Code：

请先告诉我这个任务最合适的验证方式。
如果项目里已有测试命令，请优先使用现有测试。
如果没有自动测试，请给出人工检查步骤。

空状态截图提供的是无数据时的显示证据，有数据时列表是否正常，要另外检查。根据改动影响补查相关状态，记录实际执行的步骤与结果；人工检查要真正做过，才算验证。

06 人工审查看五件事

Claude Code 改完代码后，同时查看它的总结和实际改动。至少检查五件事：

1. 改动是否解决了原来的问题？
2. 是否只改计划范围，有没有无关重构或新依赖？
3. 代码逻辑是否正确，是否符合项目已有约定？
4. 验证是否实际执行，结果能证明什么？
5. 是否触碰高风险区域或暴露敏感信息？

可以让它帮你总结 diff：

请结合 `git status`、未暂存与已暂存的 diff，以及新增文件总结：
1. 修改了哪些文件
2. 每个文件改了什么
3. 是否有超出计划的改动
4. 是否存在潜在风险
5. 下一步建议怎么验证

把它的解释当作检查线索，再去看实际差异，具体读法可以看对照 diff 的验收方法。最终判断由你完成，尤其是它说“没问题”的地方，也得有证据。

任务完成前，还可以让它用审查者视角再查一次：

请不要继续修改。现在请只做代码审查：
1. 对照原计划检查当前 diff
2. 找出是否有超范围改动
3. 找出是否有明显 bug 或遗漏验证
4. 只报告影响正确性的问题，不要提出风格优化

在同一会话中换成审查语气，用的仍是此前的上下文，算不上独立审查。自查能提供线索，最终还要核对实际差异与验证证据。

07 说清保护覆盖不到的部分

保护措施要对应具体后果。拿首页空状态的小改动来说：先保存已有内容，核对执行权限；改动后检查实际 diff，并验证无数据和有数据两种状态。如果用 checkpoint 撤回，还要确认哪些编辑被追踪了，其他文件和外部状态要单独核对。

判断安全与否时，说明具体对象、可能后果、已有保护和没覆盖的部分。需要独立审查的改动，再请相应的审查者核对；同一会话里的自查，承担不了这份职责。