当Claude Code和DeepSeek V4 Pro说不行时千万不要轻信他们的否定结论

一、背景

在使用 Docker Compose 项目时，一次误操作执行了 down && up 命令，导致所有容器被删除并重建。运行时数据——包括会话记录、记忆、技能和知识库——全部丢失。在这种情况下，需要让 Claude Code 连接服务器并尝试恢复关键数据。

本次实验使用的模型为 DeepSeek V4 Pro。

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

二、AI 的三次“不行”

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

第二次，让它换个思路，寻找备份或尝试恢复容器。

第三次，明确指示无论什么方案，必须恢复数据。

每次回复“不行”时，AI 都给出了详细的搜索过程和看似充分的理由。到第三次，它甚至让人感觉确实已经尽力了、所有方法都试过了——后来才意识到，它只是在自己已知的范围内反复打转。

三、问题分析：全程仅在本机环境内打转

回顾整个过程，每次它说“不行”时，背后执行的其实都是本地命令。

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

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

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 无残留——在它已知的范围里，这个结论确实正确。

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

这次它扩大范围，深入到 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 自己做不到的。AI 不会审视自己遗漏了什么，它只会在已知范围内穷举。 而你能站在外面，看到它漏了什么，然后补上那一句。

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

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

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

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

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

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

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

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