Claude Code + DeepSeek V4 Pro 说"不行"时，别信

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//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自己做不到的。

而你能站在外面，看到它漏了什么，然后补上那一句。

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

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

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

# Web Search Fallback

## 触发条件

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

## 规则

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

## 流程

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

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

这是人排查问题的本能，也是人机协作的安全底线。