error-recovery

错误恢复

概述

AI Agent 会陷入困境。它们会反复尝试同一种方法，为了解决复杂问题而增加复杂度，并在收益递减很久之后仍然自我说服“再试一次”。这项技能会主动检测卡住的模式，并在无谓的努力不断累积之前强制进行恢复。

**核心原则：**跟踪每一次失败的尝试。在设定的阈值升级处理。绝不允许无限重试。

首要指令

NO CONTINUED ATTEMPTS WITHOUT ACKNOWLEDGING FAILURE COUNT

在每一次修复尝试之前，都要说明：“这是当前问题的第 N 次尝试。”如果 N >= 3，未经用户指示，不得继续。

使用时机

出现以下任一模式时，这项技能会自动启用：

• 尝试修复 2 次或更多后，仍出现相同的错误消息
• 修复问题 A 引入问题 B
• 针对同一问题编辑文件 3 次或更多，仍未解决
• 每次尝试都导致行数增加或复杂度上升
• 失败 2 次或更多后仍说“我再试一件事”
• 测试套件的结果越来越差，而非越来越好
• 回滚修复后，尝试同一种方法的变体

**这项技能优先于乐观判断。**一旦触发，它的优先级高于当前正在失败的任何策略。

失败计数器

你 MUST 为每个不同的问题维护一个内部失败计数器：

FAILURE LOG
Issue: [description]
Attempt 1: [what you tried] -> [result]
Attempt 2: [what you tried] -> [result]
Attempt 3: [what you tried] -> [result]  <- STOP HERE

规则：

• 每次尝试修复都要增加计数，包括“小调整”
• 同一种方法的变体算作一次新尝试
• 回滚后重试算作一次新尝试
• 只有在问题解决或用户明确重置范围时，计数器才会重置

严重程度级别

黄色 —— 失败 2 次

• 明确记录问题：“[问题] 已有两次尝试失败。”
• 找出两次尝试的共同点
• 下一次尝试 MUST 采用根本不同的方法
• 如果无法找出不同的方法，立即升级到橙色

橙色 —— 失败 3 次

• 停止所有修复尝试。
• 完全退后一步，从头重新阅读原始错误
• 重新分析问题，仿佛这是第一次看到它
• 列出你知道的内容、你做出的假设，以及尚未验证的事项
• 提出一个与先前假设相矛盾的新假设
• 向用户说明情况：“三次尝试均已失败。这是我修订后的分析。”

红色 —— 失败 4 次或更多

• 停止。未经用户明确指示，不得继续。
• 如实说明情况：
  • 你尝试过什么（简要列出所有尝试）
  • 从每次失败中学到了什么
  • 你认为实际问题可能是什么
  • 你建议的后续步骤（包括“我可能无法解决这个问题”）
• 等待用户输入后再继续
• 如果用户表示继续，则按新的方向重置为黄色

升级流程图

digraph recovery {
  rankdir=TB
  node [shape=box]

  start [label="Fix attempt fails"]
  count [label="Increment failure counter"]
  check [label="How many failures?"]
  yellow [label="YELLOW: Log concern\nTry fundamentally different approach"]
  orange [label="ORANGE: STOP\nRe-analyze from scratch\nPresent revised analysis"]
  red [label="RED: HALT\nPresent honest assessment\nWait for user direction"]
  resolved [label="Issue resolved\nReset counter"]
  user [label="User provides direction\nReset to Yellow"]

  start -> count
  count -> check
  check -> yellow [label="2"]
  check -> orange [label="3"]
  check -> red [label="4+"]
  yellow -> start [label="Next attempt fails"]
  yellow -> resolved [label="Fix works"]
  orange -> start [label="New hypothesis\nattempt fails"]
  orange -> resolved [label="Fix works"]
  red -> user [label="User responds"]
  user -> start [label="New attempt"]
}

恢复策略

修复失败时，按以下顺序执行：

1. **重新阅读实际错误消息。**不要看你对它的解读，而要看字面内容。错误消息中经常就包含答案。

2. **尝试根本不同的方法。**不是变体。如果你一直在编辑配置，就尝试改代码。如果你一直在打补丁，就尝试替换。如果你一直在添加，就尝试移除。

3. **尽可能简化。**将问题缩减到最小的可复现情况。移除所有非必要内容。测试最简单的版本。

4. **验证你的假设。**打印值。检查类型。确认你认为正在编辑的文件确实是实际执行的文件。确认你认为正在调用的函数确实被调用。

5. **诚实地升级处理。**告诉用户：“我已尝试 N 种方法。都没有奏效。以下是我掌握的信息和建议。”

6. **回滚到最后一个已知可用状态。**如果你让情况变得更糟，就撤销所有更改，恢复到最后一次正常工作的状态。从那里重新开始。

应阻止的反模式

出现以下模式说明 Agent 陷入了困境，必须触发此技能：

反模式	应采取的做法
“再让我试一次”（失败 3 次以上后）	停止。你上次也这么说。升级处理。
用复杂方案解决复杂问题	化繁为简。删除代码。减少活动部件。
忽略错误消息，随意尝试更改	阅读错误信息。它在告诉你具体问题。
归咎于环境（“肯定是缓存问题”）	验证这个说法。执行干净构建。实际检查一下。
不缩小范围，反而扩大范围	聚焦最小的失败案例，而非整个系统。
反复编辑同一个文件	退一步思考。问题可能不在那个文件里。
未经验证就说“应该能用”	实际运行。检查输出。相信证据，而非预期。
修复测试而不是代码	测试很可能是对的。修复它所测试的内容。

认知陷阱

合理化说辞	事实
“这是另一个问题”	如果它是在修复原问题时出现的，那就是同一个问题。把它算进去。
“上次我差一点就成功了”	差一点不算成功。两次功亏一篑说明这是个模式，而非进展。
“方法是对的，只需要调整一下”	对同一方法调整 3 次，不等于尝试了 3 种不同方法。
“我得先了解整个系统”	你只需要了解失败的部分。缩小范围，而非扩大范围。
“让我先重构，然后再修复”	调试时重构会造成两个问题。先修复。
“这是边缘情况”	如果它阻碍了完成，那它就是主要情况。
“再加一条日志语句就能找到原因”	如果 3 条日志语句都没帮上忙，说明你找错了地方。

防护栏

如果观察到以下情况，请停止并启用此技能：

• 针对一个问题，你已经编辑同一个文件 3 次以上
• 你的修复引入了新的故障
• 你编写的错误处理代码比原始功能代码还多
• 测试套件的失败数量比开始时更多
• 你在抑制错误或警告，而不是修复它们
• 你正准备第 3 次或更多次说“让我试试”
• 你的解决方案比原始问题更复杂
• 你针对同一个错误进行了超过 10 分钟的主动尝试

关联

• godmode:fault-diagnosis —— 故障诊断无法收敛时，错误恢复会被激活。如果第 4 阶段失败 3 次以上，此技能将接手。
• godmode:completion-gate —— 恢复后，使用 completion-gate 验证修复确实有效。避免在恢复流程后误报“已完成”。
• godmode:test-first —— 恢复流程应包括编写一个能复现确切故障的测试。没有回归测试的修复并不完整。
• godmode:task-planning —— 如果恢复过程发现任务范围界定有误，请返回任务规划，重新界定范围后再继续。