recover

并非所有问题都是 Bug，也并非所有 Bug 都需要调试。

AI 辅助开发出问题时，人们往往会本能地继续提问——描述问题、请求修复、得到另一个有问题的版本，再描述那个问题，然后再次请求修复。会话越来越长，上下文受到干扰，代码也越来越糟。

问题不在于代码，而在于不知道遇到的是哪种故障。

这项技能会先诊断故障，再给出正确的应对方案。这是两个独立的步骤，不能颠倒。

---

步骤 1 — 描述出了什么问题

开发者描述问题。技能会先倾听，不会急于采取行动。

询问：

Describe what is wrong. Be specific:
- What did you expect to happen?
- What happened instead?
- How many times have you tried to fix it already?

仔细阅读回答。尝试修复的次数很重要——它能告诉你这是刚出现的问题，还是已经出错的会话。

---

步骤 2 — 识别故障模式

根据描述，判断属于以下三种故障模式中的哪一种。

故障模式 1 — 某个具体部分出现故障

迹象：

• 问题范围明确——涉及一个组件、一个函数或一个路由
• 项目其他部分运行正常
• 这是第一次或第二次尝试修复
• 错误消息或异常行为清晰、具体

这意味着： 这是一个常见 Bug。它有明确的根本原因，可以精准定位并修复。

应对方案： 针对性修复——转到步骤 3A。

---

故障模式 2 — 会话出了问题

迹象：

• 多次尝试修复反而让情况更糟，或引发了新问题
• 代码变得错综复杂——修复又在修补其他修复
• 当前会话的上下文充斥着失败的尝试
• 已经说不清最初的问题是什么

这意味着： 会话已经受到污染。继续提问没有帮助，只会让损害不断扩大。应在干净的上下文中重建该功能，而不是继续打补丁。

应对方案： 彻底重置——转到步骤 3B。

---

故障模式 3 — 基础方向有误

迹象：

• 代码可以运行，但行为在根本上不符合预期
• Claude 一直自信地构建某项功能，却误解了核心需求、库 API 或架构模式
• 问题不在于实现中的某个 Bug，而在于实现本身就是错的
• 修复个别部分无济于事，因为整体思路不正确

这意味着： 这不是调试问题。在编写任何代码之前，都需要重新考虑方案。继续沿错误方向实现，只会让问题更难理清。

应对方案： 重新思考——转到步骤 3C。

---

继续之前，先告诉开发者这属于哪种故障模式：

This looks like Failure Mode [1/2/3] — [name].

[One sentence explaining why you identified it this way.]

Here is how we handle this:

---

步骤 3A — 针对性修复

适用于故障模式 1。

修改代码前先诊断

请开发者提供：

• 准确的错误消息或异常行为
• 出问题的具体文件或函数
• 代码应该做什么，以及实际做了什么

阅读相关代码。不要通读整个代码库，只查看与问题直接相关的内容。

找出根本原因

提出任何修复方案之前，先找出根本原因。根本原因是问题实际存在的原因，而不是它的表象。

清楚地说明根本原因：

Root cause: [specific explanation of why this is happening]

This is different from the symptom because: [explanation]

提出精准的修复方案

描述能解决根本原因的修复方案。不要提供权宜之计，也不要在有问题的代码上继续打补丁。

Fix: [what needs to change and why]

This will resolve the root cause because: [explanation]

等待开发者确认后再做任何更改。

如果修复无效

如果建议的修复没有解决问题，就停下来。不要立刻再提出另一个修复方案。

重新检查对根本原因的判断。如果修复无效，很可能是根本原因判断错了。重新从头诊断，再尝试修复。

如果两次对根本原因的判断都错了，问题可能实际上属于故障模式 2 或 3。请重新评估。

---

步骤 3B — 彻底重置

适用于故障模式 2。

坦诚说明当前情况

This session has gone too far in the wrong direction
to recover by patching. The right move is a clean start.

This is not a failure — it is the correct response
to a polluted context. A fresh session with clear intent
will be faster than continuing here.

保存值得保留的内容

在会话结束前，从当前状态中提取所有有价值的信息：

• 原本预期该功能实现什么？
• 当前实现中有哪些部分（如果有）是正确的？
• 我们已经了解到哪些做法行不通？
• 下一次会话应该避免什么？

将这些内容写成一份简短的重置说明：

## Reset Note — [Feature Name]

### What we were building
[Original feature description]

### What went wrong
[Honest summary of how the session went off track]

### What to avoid next time
[Specific approaches or patterns that did not work]

### Starting point for next session
[Where to begin fresh — what to keep, what to discard]

指示开发者

Next steps:

1. Save this reset note somewhere accessible
2. End this session completely
3. Start a fresh session
4. Begin with /remember restore if memory exists
5. Approach [feature name] again with the reset note as context

Do not continue in this session.

---

步骤 3C — 重新思考

适用于失效模式 3。

指出错误的假设

基础有误，说明某个假设本不该成立。找出这个假设。

The core issue is not a bug — it is a wrong assumption:

Assumed: [what was assumed]
Reality: [what is actually true]

This means the current implementation cannot be fixed
by patching. The approach needs to change.

提出正确的方法

基于正确的理解，说明原本应该采用什么方法：

Correct approach: [description]

Key difference from current approach: [explanation]

What needs to be discarded: [what cannot be salvaged]
What can be kept: [what is still valid]

不要立即开始重建

重新思考需要开发者理解并同意后，才能进行任何代码更改。呈现分析并等待确认。

Does this diagnosis match your understanding?

If yes — we can start fresh with the correct approach.
If no — tell me what I am getting wrong.

只有在开发者确认后，才能开始重建。

---

原则

出了问题时，最糟糕的做法就是更快地重复同样的事情。

先诊断，再正确应对。不同的故障需要不同的应对方式——而弄清自己面对的是哪种故障，就已经解决了一大半问题。