先探索再实现

来源：MetalBear 工程博客，arXiv 从业者研究

编码之前，先让 Claude 提供多种方案及其利弊。这能防止锚定偏差——固着于第一个提出的解决方案的倾向。

TL;DR

Plain

1. 描述问题（无代码，无先入之见）
2. 请求 3-5 种方案及利弊
3. 要求量化比较
4. 选择方案
5. 然后实现

核心洞察：一旦模型提出具体解决方案，它可能会无意中缩窄你的思维空间。

模式说明

第一步：仅描述问题

从问题出发，而非解决方案方向：

Plain

我需要在 Node.js API 中处理用户会话。
要求：
- 支持 10,000 并发用户
- 会话数据：用户 ID、权限、偏好
- 必须在服务器重启后存活

不要这样（锚定在 Redis 上）：

Plain

我在考虑用 Redis 做会话。我应该怎么实现？

第二步：请求多种方案

Plain

给我 4 种不同的解决方案。
对于每种，请包含：
- 架构概述
- 优缺点
- 性能特征
- 实现复杂度

第三步：量化比较

Plain

现在用 1-10 分制对这些方案评分：
- 延迟（越低越好）
- 可扩展性（10,000 → 100,000 用户）
- 运维复杂度
- 开发时间

第四步：选择，然后实现

Plain

我选择方案 B（JWT + Redis 混合）。
现在按照 src/auth/ 中的现有模式实现它。

反锚定提示词

LLM 可能会固着于其第一个建议。这些提示词对此有帮助：

提示词类型	模板	效果
全新开始	「忽略之前的任何想法。生成 4 种解决 [X] 的新颖方法」	强制多样性
反思循环	「生成 3 个选项，然后批评每个，然后推荐」	自我纠正（锚定偏差减少 25%）
量化权衡	「用 1-10 分制按 [指标1]、[指标2]、[指标3] 排名」	客观比较
魔鬼代言人	「反对你推荐方案的最强论据是什么？」	发现隐藏权衡
约束变换	「现在用 [相反约束] 解决同一问题」	扩展解决方案空间

示例：反锚定提示词

Plain

我需要为有 100 万以上记录的 REST API 实现分页。

重要：不要先建议基于偏移量的分页。
生成 4 种不同的分页策略，至少包含一种非常规方法。对于每种：

1. 工作原理（2-3 句话）
2. 最佳使用场景
3. 最差使用场景
4. 100 万条记录的性能表现

然后推荐一种，解释为什么它对我的使用场景比其他方案更优。

反思循环提示词

Plain

关于实现实时通知：

第一阶段：生成 3 种方案（WebSocket、SSE、长轮询）
第二阶段：对于每种，列出 2 个可能在生产中出错的地方
第三阶段：基于第二阶段，哪种方案最有弹性？

展示每个阶段的推理过程。

适用场景

使用探索

场景	原因
全新功能	没有可遵循的现有模式
架构决策	影响高，难以逆转
多种有效方案	需要明智选择
陌生领域	不知道自己不知道什么
团队分歧	获取对各选项的中立分析

跳过探索

场景	原因
Bug 修复	解决方案通常从症状中就很明显
唯一有效方案	没有真正的选择
时间紧迫的紧急修复	速度优先于完美
遵循现有模式	决策已经做出
微小变更	开销不值得

与 Claude Code 集成

配合计划模式

探索发生在进入计划模式之前：

Plain

# 第一步：探索（尚未在计划模式中）
我需要为 API 添加缓存。有哪些选项？

# Claude 回复 4 种方案

# 第二步：选择
我们选方案 C（使用 Cloudflare 的边缘缓存）。

# 第三步：规划（按两次 Shift+Tab 进入计划模式）
使用 Cloudflare Workers 实现边缘缓存。
遵循我们现有中间件中的模式。

配合 CLAUDE.md

在项目指令中添加探索触发条件：

Markdown

## 工作流偏好

### 新功能前
实现新功能时，先探索 3-4 种方案及利弊，然后再确定实现。
使用量化比较（1-10 分制）对以下维度评分：
- 性能
- 可维护性
- 实现时间

配合任务工具

将探索作为任务追踪：

Plain

TaskCreate: 「探索缓存方案」
TaskCreate: 「基于分析选择方案」
TaskCreate: 「实现缓存失效」
TaskCreate: 「为响应添加缓存头」
# 随进度用 TaskUpdate 标记完成

反模式

过早锚定

Plain

# 错误
「我想用 Redis 做缓存。我该怎么配置？」

# 正确
「我需要为 API 响应做缓存。我有哪些选项？」

你在探索之前就排除了 90% 的解决方案。

浅层比较

Plain

# 错误
「Redis 和 Memcached 哪个更好？」

# 正确
「比较 Redis、Memcached 和进程内缓存，针对以下场景：
- 50MB 缓存大小
- 读密集型工作负载（95% 读）
- 单服务器部署
包含延迟、内存开销和运维复杂度。」

忽略权衡

Plain

# 错误
「直接告诉我最好的方案」

# 正确
「选择方案 A 而非 B，我会放弃什么？
什么情况下我会后悔这个选择？」

分析瘫痪

Plain

# 错误
为简单功能探索 10 个选项

# 正确
设置限制：「给我你的前 3 个方案，不超过这个数」
做出决定，如果需要再迭代

示例会话

初步探索

Plain

用户：我需要在 React 仪表盘中实现实时更新。
      仪表盘显示约 50 个指标，每 5 秒更新一次。
      目前我们在轮询，但用户抱怨数据过时。

Claude：以下是 4 种方案：

**A) WebSocket**
- 全双工，服务器可随时推送
- 优点：最低延迟，真正实时
- 缺点：连接管理，扩展复杂性
- 适合：亚秒级更新，双向通信

**B) Server-Sent Events（SSE）**
- 单向服务器 → 客户端流
- 优点：简单，基于 HTTP，自动重连
- 缺点：单向，浏览器连接数有限
- 适合：仪表盘数据流，通知

**C) 长轮询**
- 客户端持有请求直到数据就绪
- 优点：处处可用，简单的降级方案
- 缺点：更高延迟，更多服务器负载
- 适合：兼容遗留系统

**D) GraphQL 订阅**
- 基于 WebSocket 的 GraphQL schema
- 优点：类型安全，选择性更新
- 缺点：需要 GraphQL 基础设施
- 适合：现有 GraphQL API

用户：针对我们的使用场景（React、50 个指标、5 秒刷新、
      团队没有 WebSocket 经验）对这些方案排名。

Claude：评分（1-10，越高越好）：

| 方案 | 延迟 | 复杂度 | 团队适配 | 可扩展性 |
|----------|---------|------------|----------|-------------|
| WebSocket | 10 | 4 | 3 | 7 |
| SSE | 8 | 8 | 8 | 8 |
| 长轮询 | 5 | 9 | 9 | 5 |
| GraphQL 订阅 | 9 | 3 | 2 | 7 |

**推荐：SSE**
简单性与实时能力的最佳平衡。
你的团队可以在一天内实现，轻松处理
50 个指标 × 5 秒更新。如果你后续需要
双向或亚秒级更新，再升级到 WebSocket。

用户：我们选 SSE。现在实现它。

自媒体人 AI 入门路径：从选题到复盘的完整工作流

Claude Code 深度全解

底层原理精讲

可视化图解

零到精通：七步上手路径

企业级安全与治理

生态与工具链全景

实战工作流手册

先探索再实现 ​

目录 ​

TL;DR ​

模式说明 ​

第一步：仅描述问题 ​

第二步：请求多种方案 ​

第三步：量化比较 ​

第四步：选择，然后实现 ​

反锚定提示词 ​

示例：反锚定提示词 ​

反思循环提示词 ​

适用场景 ​

使用探索 ​

跳过探索 ​

与 Claude Code 集成 ​

配合计划模式 ​

配合 CLAUDE.md ​

配合任务工具 ​

反模式 ​

过早锚定 ​

浅层比较 ​

忽略权衡 ​

分析瘫痪 ​

示例会话 ​

初步探索 ​

延伸阅读 ​

先探索再实现

目录

TL;DR

模式说明

第一步：仅描述问题

第二步：请求多种方案

第三步：量化比较

第四步：选择，然后实现

反锚定提示词

示例：反锚定提示词

反思循环提示词

适用场景

使用探索

跳过探索

与 Claude Code 集成

配合计划模式

配合 CLAUDE.md

配合任务工具

反模式

过早锚定

浅层比较

忽略权衡

分析瘫痪

示例会话

初步探索

延伸阅读