中文 | English
让 Claude Code 真正思考的 slash command （而不是"看起来在思考"）
A Slash Command Fix 👇
# 克隆到commands目录
cd ~/.claude/commands
git clone https://github.com/wanpengxie/deepdive.git
# 使用
/deepdive 你的复杂问题几个简单但强大的想法：
- thinking过程转化为显式的todo list，而不是一次思考就结束，好处是
- 尽量让claude自己梳理问题背景和边界，而不是消耗用户的心智
- 在梳理清晰的基础上，输出todo或者ask user，可以细粒度的跟用户对齐方向和预期，并且精准的控制claude的行为
- 单次output的长度是有限的，限制了claude单次thinking的长度（即使是ultrathink），而转化为agent+todo list执行理论上可以允许模型无限长度、无限深度的思考（即使context消耗完了，也可以compact结论到文档里，继续执行todolist）
- 用元策略显式的指导claude如何进行非线性思考和迭代
- 避免过于强调目标导向带来的偏差：允许模型坦诚的承认自己的置信度，对用户更透明
传统TODO（任务清单）：
- [ ] 实现推荐算法
- [ ] 对接数据库
Deep-iterate TODO（思考步骤）：
- [ ] 困惑："推荐"到底是什么意思？
- [ ] 探索A：从用户场景理解
- [ ] 探索B：从产品目标理解
- [ ] 反例验证：如果不做会怎样？
为什么有效？
- 强制分步（不能一次性写完）
- 复用Claude Code内置的多步推理能力
真实的思考不是：
步骤1 → 步骤2 → 步骤3 → 完美结论 ✓
而是：
尝试1 → 发现问题 → 推翻
↓
尝试2 → 新困惑 → 调整方向
↓
尝试3 → 验证 → 部分成功（承认）
Deep-iterate允许困惑、允许推翻、允许不完美。
因为真实的创造性思考本来就是混乱的。
-
✅ 架构设计（没有标准答案）
-
✅ 技术选型（需要权衡）
-
✅ 产品方向（需要理解本质）
-
✅ 深度分析
-
✅ 持续讨论问题
-
❌ 直接的技术执行：bug修复、写mvp等等
-
❌ 纯信息查询（不需要设计决策）
command的动机就是上图，自从6月份claude code降职之后，我每天有60%以上的时间在跟claude code对骂
经过仔细观察，我发现
问题不是AI变笨了
Claude没变笨，是response的模式改变了。
典型场景：
User: 我们需要设计一个推荐系统
Claude Code: 好的！推荐系统设计方案如下：
1. 数据收集层（用户行为埋点）
2. 推荐算法（协同过滤+内容相似度）
3. 技术栈（Python+Spark+Redis+Elasticsearch）
...
看起来专业？但可能这个项目的用户只有100人。
Claude没问：
- 业务目标是什么？
- 有多少用户？多少内容？
- 有历史数据吗？
它只是在表演回答，而非真实思考。
这就是"QA模式"的陷阱：
- 接受问题框架（不质疑前提）
- 过早收敛（为了看起来专业）
- 被query带偏（不探索本质）
这是一个slash command。但它改变的不是功能，是思考模式。
/deepdive 我们应该如何设计推荐系统？Claude会：
第零步：理解问题
等等，先别急着给方案...
困惑：
- "推荐"的业务目标是什么？
- 现在有多少用户？多少内容？
- 有历史数据吗？
探索A：从业务阶段理解
如果是MVP阶段，用户<1000：
→ 编辑精选可能就够了
→ 过早引入ML是过度设计
探索B：从用户行为理解
如果用户主动搜索多 → 优化搜索>推荐
如果用户被动浏览多 → 推荐才是核心
反例验证
- 用Spark但数据量很小 → 杀鸡用牛刀
- 过度个性化 → 信息茧房
- 没有冷启动策略 → 新用户新内容都推不出去
诚实的结论
完成度：50%
需要先澄清3个问题：...
分阶段方案：
- V1（MVP）：编辑推荐+热门榜单
- V2（增长期）：简单规则
- V3（成熟期）：协同过滤
待解决：冷启动策略、多样性控制...
对比可见：后者在理解问题而非快速回答。
Issues和PRs欢迎。
这是个实验性框架，远不完美。
MIT
Author: [email protected]
Created using
/deepdive理解问题 → 真实探索 → 深入本质 → 诚实总结
Real thinking, not performative iteration.