适合探索
- 全新功能（没有现有模式可循）
- 架构决策（影响大、难以逆转）
- 多种可行方案（需要知情选择）
- 不熟悉的领域（不知道自己不知道什么）
- 团队意见分歧（需要中立分析）
探索式开发
在动手编码之前，先让 Claude 提供多种方案和权衡分析。这可以避免锚定偏差 — 即固着于第一个被提出的方案而忽略更优选择。
- 描述问题（不带代码、不预设方案）
- 要求 3-5 种方案，附带权衡分析
- 要求量化比较
- 选择方案
- 然后再实现
探索模式详解
Section titled “探索模式详解”第一步：只描述问题
Section titled “第一步：只描述问题”用问题开始，而不是方案方向：
我需要在 Node.js API 中处理用户会话。需求：- 支持 1 万并发用户- 会话数据：用户 ID、权限、偏好- 必须在服务器重启后存活第二步：要求多种方案
Section titled “第二步：要求多种方案”给我 4 种不同的方案来解决这个问题。每种方案包含：- 架构概述- 优缺点- 性能特征- 实现复杂度第三步：量化比较
Section titled “第三步：量化比较”现在用 1-10 分对这些方案打分：- 延迟（越低越好）- 可扩展性（从 1 万到 10 万用户）- 运维复杂度- 开发时间第四步：选定后实现
Section titled “第四步：选定后实现”我选择方案 B（JWT + Redis 混合方案）。现在按照我们 src/auth/ 中的现有模式来实现。反锚定提示技巧
Section titled “反锚定提示技巧”LLM 可能会固着于自己的第一个建议。以下提示词可以对抗这种倾向：
| 提示类型 | 模板 | 效果 |
|---|---|---|
| 全新出发 | ”忽略之前的想法。生成 4 种全新的 [X] 方案” | 强制多样性 |
| 反思循环 | ”生成 3 个选项，然后逐一批评，最后推荐” | 自我纠正 |
| 量化权衡 | ”按 [指标1]、[指标2]、[指标3] 打分 1-10” | 客观比较 |
| 魔鬼代言人 | ”反对你推荐方案的最有力论据是什么？“ | 暴露隐藏的权衡 |
| 约束变换 | ”用相反的约束来解决同一问题” | 扩展方案空间 |
反锚定提示词示例
Section titled “反锚定提示词示例”我需要为一个有 100 万+ 记录的 REST API 做分页。
重要：不要首先建议基于偏移的分页。生成 4 种不同的分页策略，至少包含一种非常规方案。每种方案说明：
1. 工作原理（2-3 句话）2. 最适合的场景3. 最不适合的场景4. 在 100 万记录时的性能
然后推荐一种，解释为什么它在我的场景中胜出。反思循环提示词
Section titled “反思循环提示词”对于实现实时通知：
阶段 1：生成 3 种方案（WebSockets、SSE、长轮询）阶段 2：每种列出 2 个生产环境可能出错的点阶段 3：基于阶段 2，哪种方案最具韧性？
展示每个阶段的推理过程。何时使用探索式开发
Section titled “何时使用探索式开发”跳过探索
- Bug 修复（通常从症状就能判断方案）
- 只有一种可行方案
- 紧急热修复（速度优先）
- 遵循已有模式（决策已定）
- 微小变更（开销不值得）
与 Claude Code 集成
Section titled “与 Claude Code 集成”配合计划模式
Section titled “配合计划模式”探索发生在进入计划模式之前：
# 第 1 步：探索（还不在计划模式中）我需要给 API 添加缓存。有哪些方案？
# Claude 给出 4 种方案
# 第 2 步：选择我们用方案 C（Cloudflare 边缘缓存）。
# 第 3 步：规划（按 Shift+Tab 两次进入计划模式）使用 Cloudflare Workers 实现边缘缓存。遵循现有中间件的模式。配合 CLAUDE.md
Section titled “配合 CLAUDE.md”在项目配置中添加探索触发规则：
## 工作流偏好
### 新功能开发前实现新功能时，先探索 3-4 种方案及其权衡，然后再确定实现方向。使用 1-10 分的量化比较：- 性能- 可维护性- 实现时间"我想用 Redis 做缓存。怎么设置？"在探索之前就排除了 90% 的方案。
"我需要给 API 响应做缓存。有哪些方案？""Redis 和 Memcached 哪个好？""比较 Redis、Memcached 和进程内缓存：- 50MB 缓存大小- 读密集型负载（95% 读）- 单服务器部署包含延迟、内存开销和运维复杂度。""直接告诉我最好的方案""选方案 A 而不是 B，我会放弃什么？什么场景会让我后悔这个选择？"为一个简单功能探索 10 种方案设定上限："给我你的前 3 种方案，不要更多"做出决定，需要时再迭代用户：我需要在 React 仪表盘中实现实时更新。 仪表盘显示约 50 个指标，每 5 秒更新一次。 目前使用轮询，但用户抱怨数据过时。
Claude：这里有 4 种方案：
A) WebSockets- 全双工，服务器随时推送- 优点：延迟最低，真正的实时- 缺点：连接管理复杂，扩展有挑战- 最适合：亚秒级更新，双向通信
B) Server-Sent Events (SSE)- 单向服务器 → 客户端流- 优点：简单、基于 HTTP、自动重连- 缺点：仅单向，浏览器连接数有限- 最适合：仪表盘数据流、通知
C) 长轮询- 客户端保持请求直到数据就绪- 优点：兼容性最好，简单的降级方案- 缺点：延迟较高，服务器负载较大- 最适合：遗留系统兼容
D) GraphQL Subscriptions- 基于 WebSocket 的 GraphQL 订阅- 优点：类型安全，选择性更新- 缺点：需要 GraphQL 基础设施- 最适合：已有 GraphQL API 的项目用户：为我们的场景（React、50 个指标、5 秒刷新、 团队没有 WebSocket 经验）打分。
Claude：评分（1-10，越高越好）：
| 方案 | 延迟 | 复杂度 | 团队适配 | 可扩展性 ||------|------|--------|---------|---------|| WebSockets | 10 | 4 | 3 | 7 || SSE | 8 | 8 | 8 | 8 || 长轮询 | 5 | 9 | 9 | 5 || GraphQL Subs | 9 | 3 | 2 | 7 |
推荐：SSE简单性和实时能力的最佳平衡。团队一天内就能实现，轻松处理 50 个指标 x 5 秒更新。如果后续需要双向或亚秒级更新，再升级到 WebSockets。
用户：就用 SSE。现在开始实现。