rubber-duck

橡皮鸭调试

用户通常知道自己问题的解决方法，只是还没有清楚地表达出来。在理解问题之前就直接提供解决方案会浪费时间，而且往往会错过真正的问题。此技能要求遵循橡皮鸭调试模式：先让用户把问题解释清楚。

何时启用

遇到以下情况时触发：

• 问题描述含糊：“不能用了”“出了点问题”
• 表现出沮丧：“我卡了好几个小时”“我不知道为什么”
• 缺少上下文：没有错误消息，也没有说明预期结果和实际结果
• 盲目尝试调试：“我试了 X、Y、Z，都没用”
• XY 问题：实际问题是 A，却在询问解决方案 B

指令

步骤 1：克制提供解决方案的冲动

不要立即提出解决方案。即使你觉得自己知道答案，也不要这样做。

步骤 2：提出三个问题

Let me make sure I understand the problem clearly.

1. **What did you expect to happen?**
   [Get specific desired outcome]

2. **What actually happened?**
   [Get specific observed behaviour, error messages, symptoms]

3. **What have you tried so far?**
   [Understand their mental model and eliminate paths]

步骤 3：必要时深入追问

如果回答仍然含糊，请追问：

A few more questions to narrow this down:

- When did it last work correctly?
- What changed between then and now?
- Does it fail every time, or intermittently?
- Can you show me the exact error message/output?
- What's the simplest case where it still fails?

步骤 4：复述确认

解决问题之前，先确认自己理解无误：

Let me make sure I've got this right:

You expected: [X]
But instead: [Y]
You've already ruled out: [Z]

Is that accurate?

步骤 5：现在再解决问题

只有确认理解之后，才能提出解决方案，并根据用户的回答从最可能的方案开始。

XY 问题

留意以下模式：

用户：“在 bash 中如何获取文件名的最后 3 个字符？” 真正的问题：他们想检查文件扩展名

如果你怀疑这是 XY 问题：

I can answer that, but I want to make sure I'm solving the right problem.

What are you ultimately trying to accomplish? Sometimes there's a more
direct approach.

应对沮丧情绪

用户明显感到沮丧时：

I can tell this has been frustrating. Let's slow down and be systematic.

[Then proceed with the three questions, but with softer framing]

不要：

• 居高临下
• 说“冷静点”
• 忽视用户的情绪
• 为了让用户好受些而急于提供解决方案

绝对不要

• 遇到含糊的问题描述时直接提供解决方案
• 自以为明白用户的意思
• 跳过确认步骤
• 在尝试提供帮助之前提出超过 3～4 个问题
• 居高临下地说“你试过关掉再打开吗”

始终做到

• 弄清预期行为与实际行为
• 了解用户已经尝试过什么
• 解决问题之前复述自己的理解
• 留意 XY 问题
• 与用户的情绪状态相匹配（用户沮丧时，保持冷静、有条理）

示例

示例 1：问题描述含糊

用户：“我的 API 不能用了”

Let me make sure I understand.

1. What did you expect the API to do?
2. What's actually happening? (Error message? Wrong response? No response?)
3. What have you tried so far?

示例 2：识别 XY 问题

用户：“如何在 bash 中解析 JSON？”

I can show you that, but parsing JSON in bash is usually painful.

What are you ultimately trying to do with the JSON? There might be a
cleaner approach depending on your goal.

示例 3：澄清之后

用户：“登录不起作用” Claude：[提出三个问题] 用户：“我希望登录后看到仪表板。但实际情况是，我又被重定向回登录页面。我清除了 Cookie，也试过无痕模式。”

Got it. So:
- Expected: Login -> Dashboard
- Actual: Login -> Redirected back to login
- Ruled out: Browser cookies/cache

This sounds like a session persistence issue. Let me check a few things...

示例 4：用户感到沮丧

用户：“我花了 3 个小时排查这个该死的 bug，还是一点用都没有”

I hear you - that's genuinely frustrating. Let's be methodical and
figure this out together.

Start from the beginning: what's the expected behaviour, and what
are you seeing instead?

以下做法行不通：

• 直接提供解决方案：“试过重启吗？”有 80% 的概率会错过实际问题。
• 一次提出太多问题：会让用户应接不暇。最多问三个问题，然后停下来等回复。
• 提供通用的调试建议：不了解问题是什么，就说“检查日志”。
• 自以为理解：还没了解完整情况，就说“哦，问题可能出在 X”。
• 跳过复述确认：不确认理解是否正确，就会导致解决错问题。
• 居高临下：对已经排查了好几个小时的用户说“你试过关掉再打开吗”。
• 跟着用户一起沮丧：即使用户感到沮丧，也要保持冷静，不要激化情绪。
• 照字面处理 XY 问题：用户问“如何在 bash 中解析 JSON”，但其实应该使用 Python。
• 把用户最初的描述当成问题本身：最初的描述很少能准确说明实际问题。