Claude Code 连续三次判定"数据无法恢复"，我坚持让它上网搜索后，最终解决了问题。本文关注的是 AI说不行时，你怎么让它行的过程——具体细节不重要，重要的是方法。

---

一、背景

Docker Compose 项目因为误操作 down && up，容器被删除重建，所有运行时数据——会话记录、记忆、技能、知识库——全部消失。我让 Claude Code 连上服务器恢复数据。

使用的模型是 DeepSeek V4 Pro。

接下来发生的事，暴露了一个非常典型的使用盲区。

---

二、AI 的三次"不行"

第一次，我要求它恢复数据。

“经过 15 个搜索维度的全面扫描……旧容器的可写层已被 Docker 永久删除，不可恢复。”

第二次，我让它换个思路，找备份、恢复容器。

“Docker 层、containerd 全部快照、ext4 底层、LVM、VMware——全部确认不包含运行时数据。”

第三次，我说不管什么方案，必须恢复。

“我已穷尽所有技术手段。所有快照、文件系统日志、元数据库中均无残留。”

每次说"不行"时，它都给出了详细的搜索过程和看似充分的理由。到最后一次，它甚至能让你觉得它确实已经尽力了、所有路子都试过了——后来才知道，它只是在自己知道的范围内打转。

---

三、问题分析：全在本地打转

回头看，每次它说"不行"时，背后跑的其实都是本地命令。

第一次，我要求它恢复数据。它的回复是：

“经过 15 个搜索维度的全面扫描……旧容器的可写层已被 Docker 永久删除，不可恢复。”

拆开看，它实际执行的是这些：

docker ps -a --filter name=cowagent            # 查容器还在不在
ls -la /var/lib/docker/containers/             # 找旧容器目录
docker inspect cowagent --format='{{.GraphDriver.Data.UpperDir}}'  # 查可写层路径
find /var/lib/docker/overlay2 -name '*.db' -type f  # 搜残留数据库

全是 Docker 本地命令。旧容器删了、overlayfs 没残留——在它已知的范围内，这确实是对的。

第二次，我让它找备份、恢复容器。它回复：

“Docker 层、containerd 全部快照、ext4 底层、LVM、VMware——全部确认不包含运行时数据。”

这次它扩大范围，进了 containerd 和文件系统底层：

ctr -n moby snapshots ls | wc -l              # 列出全部 267 个快照
find /var/lib/containerd -name 'index.db'     # 逐个快照搜索数据库文件
strings meta.db | grep -i cowagent            # 翻 containerd 元数据库
debugfs -R 'ls -ld /var/lib/docker/containers/' /dev/mapper/ubuntu--vg-ubuntu--lv  # ext4底层查已删inode

267 个快照翻完了，文件系统底层也看了——但都在本机。

第三次，我说不管什么方案必须恢复。它回复：

“我已穷尽所有技术手段。所有快照、文件系统日志、元数据库中均无残留。”

它把范围拉到最宽，LVM、VMware、全盘搜索全上了：

lvs && vgs && pvs                              # 查 LVM 有没有快照
systemd-detect-virt                             # 确认是 VMware 虚拟机
find / -name 'conversations.db' -type f        # 全盘搜索会话数据库
cat /proc/<pid>/fd/ | grep deleted             # 找是否有进程还持有已删文件

三次，命令不同，层次不同，但没有一条离开过这台服务器。模型在自己的训练数据范围内反复穷举，而 Claude Code 提供的 WebSearch 能力一次都没被调用过。

---

四、我是怎么让它行的

看到了它一直在本地打转，输出的全是本地命令，我觉得模型能力不应该这么差，抱着试一试的心态，直接给了指令：

“你找一下网上有什么方案”

它去搜了，返回了两个之前从未出现过的方案：

1. ext4magic
   从 ext4 文件系统日志恢复已删除文件
   原理：解析 ext4 journal，按 inode 重建已删除的文件

2. SQLite WAL 回放
   恢复未提交的数据库事务
   原理：Write-Ahead Log 文件残留了未 checkpoint 的会话数据

然后它沿着这个方向自己动起来了——安装 ext4magic、从日志恢复 index.db、回放 WAL 补上未提交的会话、从磁盘碎片里挖出技能和知识库文件，最终把问题解决了。

同一个模型，加了一句"上网搜"，从"完全不行"变成了"完全可行"。

---

五、经验总结

1. 模型不会主动说"让我上网搜一下"

这是本文最想传递的一点。DeepSeek V4 Pro 在遇到困难时，倾向于在自己已知的范围内反复搜索和判断，而不是向外寻找新信息。它会——

• 反复扫描同一批目录
• 用不同参数尝试同一种工具
• 用越来越详细的方式解释"为什么不行"

但它不会主动想"我不确定，让我去网上看看"。WebSearch 这个能力是 Claude Code 提供的，但决定用不用的是模型——而模型选择了不用。

当然，这不代表所有 AI 工具都有这个盲区——有些模型和工具本身就支持自动联网搜索，本文讨论的只是这个具体组合遇到的实际问题。

2. "你去搜"比"你再想想"有效

当它反复说不行时，追问"再检查一遍"是无效的——它会用同样的方法扫同样的目录，得出同样的结论。直接给新指令：

❌ "你再仔细找找"       → 循环同样的搜索
❌ "你确定吗"            → 再解释一遍为什么不行
✅ "你去网上搜一下方案"  → 突破边界
✅ "搜一下 ext4 文件恢复" → 更精准

3. AI 的执行闭环是靠谱的

找到方案后，Claude Code 自行完成了安装、参数修正、错误处理、WAL 回放、碎片分类。它的弱项是"不知道有什么方案"，强项是"知道方案后把它执行好"。 给它一个方向，比帮它干活更重要。

4. 人的价值：你能看到它没做什么

"去网上搜"不是多高深的技术判断。我只是注意到它一直在本地翻来翻去，从没提过可以去网上找，于是给了这个指令。

但恰恰是这种"你少做了一步"的观察，是 AI 自己做不到的。AI 不会审视自己遗漏了什么，它只会在已知范围内穷举。 而你能站在外面，看到它漏了什么，然后补上那一句。

5. 把这个教训写成规则，交给 AI 自己执行

经历了这次之后，我把"卡住时先去网上搜"写成了一条 Claude Code 技能，放进了 skills 目录。下次模型再遇到类似情况，技能会自动触发，不用等我来提醒。

---
name: web-search-fallback
description: 当本地方案全部失败时，自动搜索互联网后再下结论
---

# Web Search Fallback

## 触发条件

- 尝试了 3 种以上不同方案仍未解决
- 即将告诉用户"无法做到"或"没有解决方案"
- 用户坚持有办法但你本地找不到

## 规则

**在判定"不可能"之前，至少搜索一次互联网。**

## 流程

1. 卡住时先问自己："搜过网页了吗？"
2. 如果没搜过，用 WebSearch 搜索问题和你已尝试的方案
3. 检查结果中是否有你没想到的工具或方法
4. 找到可行方案就执行
5. 只有在本地和网页都搜完无果后，才能说"无法解决"

好记性不如烂笔头。把经验固化成规则，以后满足条件时工具自己就会触发，不用你每次都盯着。

下次 AI 说不行，先别信。看看它漏了什么。 这是人排查问题的本能，也是人机协作的安全底线。