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 说不行，先别信。看看它漏了什么。 这是人排查问题的本能，也是人机协作的安全底线。
