“给我们 API 加限流。“Claude 立刻实现了一个全局 token bucket。第 1 轮：开发者需要的是按用户限流。第 2 轮：需要按端点分层限流。第 3 轮：需要多实例部署的分布式限流。每轮都需要大幅代码重构。
三个需求本可以从一个问题中浮出来：“范围是全局还是按用户的？有没有分层？单实例还是分布式？”
访谈模式意味着 Claude 在实现前问澄清问题。这不是普适做法——是给模糊请求用的工具，设计空间大、错误假设代价高的时候。
什么时候做访谈
请求简短且模糊。 “给 API 端点加缓存”没指定失效策略、TTL 值或哪些端点要缓存。每个缺失的细节都可能导向根本不同的实现。
多种有效方案有不同影响。 PDF 解析、NLP 提取、数据库存储和去重各有多种有效方法。选择取决于论文量、需要的元数据字段和输出格式——只有开发者知道这些信息。
金融或安全关键系统。 “支付失败时自动重试。“不问重试上限、退避策略和幂等性处理，Claude 可能在支付系统上实现无限立即重试——导致重复扣费、触发反欺诈检测、耗尽限流额度。
复杂多组件任务。 一个有 4 个组件、每个组件有多种有效方案的数据流水线。错误的架构选择需要完全重写。
什么时候不做访谈
任务清晰且明确指定。 堆栈跟踪指向第 42 行的 bug 修复。算法清晰的明确指定函数。不需要问题。
请求自带完整规格。 开发者已经指定了失效策略、TTL 和端点。问他们已经回答的问题浪费时间。
刚性的”永远问 5 个问题”策略用不必要的摩擦惩罚清晰的请求。访谈模式的触发条件是模糊性和设计空间大小，不是任务类别。
数据
一个团队一个月内在 30 个特性上比较了直接实现和先访谈：
| 指标 | 直接实现 | 先访谈 |
|---|---|---|
| 平均修订轮次 | 3.2 | 1.4 |
| 每个特性平均时间 | 4.5 小时 | 2.8 小时 |
| 架构返工 | 40% 的特性 | 8% 的特性 |
先访谈减少了 56% 的修订轮次、38% 的开发时间和 80% 的架构返工。预先投入问问题的回报是多倍的。
问对的问题
错误的问题：“用什么语言？""什么框架？""什么测试库？“这些读代码库就能回答。Claude 应该先读代码上下文。
对的问题挖掘开发者没考虑到的：
- 失败模式 — 缓存不可用时怎么办？支付处理器返回模糊错误时呢？
- 规模约束 — 多大量的通知？单实例还是分布式部署？
- 边缘情况 — 客户消息中零个订单号怎么办？接近但不完全匹配的模式比如 4 位的”ORD-XXXX”呢？
- 业务逻辑 — 哪些端点需要缓存？什么算可重试的支付失败 vs 永久性的？
- 并发 — 多个进程会同时访问限流器吗？
策略是：读代码库获取技术上下文，然后问开发者可能没预料到的考量。好的访谈问题揭示开发者不知道自己有的需求。
反模式：用默认假设实现
“搭一个通知系统。“Claude 立刻生成邮件投递、3 次重试、2 个优先级、无用户偏好。
每个假设都可能是错的。团队可能需要短信和推送。重试策略可能需要按渠道不同间隔。优先级可能需要匹配现有工单系统。用户偏好处理可能是法律要求。
TODO 注释（”// configure retry policy”）把关键决策推迟到了代码审查时。对生产系统来说，这些决策应该在代码存在之前做出——不是在审查注释中被发现。
访谈不是迭代
访谈模式在第一行代码之前收集需求。迭代在代码存在后改进实现。它们服务不同阶段：
- 访谈防止错误的架构方向（40% → 8% 返工）
- 迭代在正确架构内改进行为（3.2 → 1.4 轮）
跳过访谈直接迭代意味着在错误的基础上迭代——每轮修订发现一个需要重构一切的需求。
一句话总结： 请求模糊且设计空间大时，先问问题再写代码——先访谈的 2.8 小时开发比实现后返工的 4.5 小时更快。