AI 辅助开发出问题时：先诊断失败模式，再决定精准修复…

在 AI 辅助开发中遇到构建/代码问题、多次修复无效或怀疑方向错误时，用三步诊断失败类型并选择对应响应。

适用场景

解决思路

1. 先让开发者描述问题，在采取任何行动前只倾听；使用提示：描述哪里错了，要具体：你期望发生什么？实际发生了什么？你已经尝试修复多少次了？
2. 仔细阅读回答，特别关注已尝试修复次数；这能判断是全新问题，还是会话已经跑偏。
3. 基于描述判断属于三种失败模式之一：失败模式 1（某个具体东西坏了）、失败模式 2（会话已经跑偏）、失败模式 3（基础/方向错了）。
4. 识别失败模式 1 的标志：问题孤立（一个组件、一个函数、一个路由）；项目其余部分正常；这是第一次或第二次尝试修复；错误信息或错误行为清晰具体。含义：这是普通 bug，有可精确定位和修复的根因。响应：进入 Step 3A 精准修复。
5. 识别失败模式 2 的标志：多次修复尝试让情况更糟或制造新问题；代码变得纠缠（修复在给修复打补丁）；当前会话上下文充满失败尝试；已经不清楚最初问题是什么。含义：会话已被污染；继续提示不会帮助，反而叠加损害；功能需要在干净上下文中重建，而不是继续打补丁。响应：进入 Step 3B 硬重置。
6. 识别失败模式 3 的标志：代码能运行但产生根本错误的行为；Claude 一直自信地构建误解核心需求、库 API 或架构模式的东西；问题不是实现中的 bug，而是实现本身错了；逐块修复不会有用，因为方案不正确。含义：这不是调试问题；写任何代码前要重新考虑方案；在错误方向上继续实现会让事情更难理清。响应：进入 Step 3C 重新思考。
7. 在继续前告诉开发者这是哪种失败模式，使用模板：这看起来像失败模式 [1/2/3] — [name]。我用这个方式判断的原因是：[一句话解释]。我们这样处理：
8. Step 3A：在碰代码前先诊断。让开发者提供：确切的错误信息或错误行为；发生问题的具体文件或函数；代码本应做什么 vs 实际做了什么。
9. 只阅读直接相关的代码；不要阅读整个代码库，只读与问题直接相关的内容。
10. 在建议任何修复前先找出根因；根因是问题存在的真正原因，不是症状。清楚陈述：根因：[为什么发生的具体解释]；这与症状不同，因为：[解释]。
11. 建议精准修复，解决根因；不是 workaround，不是叠在坏代码上的补丁。陈述：修复：[需要改什么以及为什么]；这会解决根因，因为：[解释]。
12. 在做任何修改前等待开发者确认。
13. 如果建议的修复不生效：停止，不要立刻再建议一个修复；重新检查根因诊断；如果修复无效，根因很可能是错的；从头重新诊断后再试。
14. 如果两次根因诊断都错了：这实际上可能是失败模式 2 或 3；重新评估。
15. Step 3B：诚实承认情况。使用模板：这个会话已经在错误方向上走得太远，无法通过打补丁恢复；正确做法是干净重来。这不是失败，而是对污染上下文的正确响应；一个有清晰意图的新会话会比在这里继续更快。
16. 保存值得保留的内容。结束会话前提取：原始功能本应做什么？当前实现中哪些部分（如果有）实际正确？已经学到哪些做法行不通？下个会话应避免什么？
17. 写成简短重置笔记，模板：## Reset Note — [Feature Name]；### 我们在构建什么：[原始功能描述]；### 哪里出了问题：[对会话如何跑偏的诚实总结]；### 下次要避免什么：[行不通的具体方法或模式]；### 下个会话的起点：[从哪开始重来——保留什么、丢弃什么]。
18. 指导开发者下一步：1. 把这份重置笔记保存到可访问的地方；2. 彻底结束当前会话；3. 开始一个全新会话；4. 如果存在 memory，以 /remember restore 开始；5. 以重置笔记作为上下文重新处理 [feature name]；不要在这个会话中继续。
19. Step 3C：命名错误假设。基础错了意味着某个不该成立的假设成立了；找出它。使用模板：核心问题不是 bug，而是一个错误假设：假设：[假设了什么]；现实：[实际正确的是什么]；这意味着当前实现不能通过打补丁修复；方案需要改变。
20. 提出正确方案。基于正确理解，描述本来应该采用什么方案：正确方案：[描述]；与当前方案的关键区别：[解释]；需要丢弃什么：[无法挽救的部分]；可以保留什么：[仍然有效的部分]。
21. 不要立刻开始重建。重新思考需要开发者在任何代码修改前理解并同意；呈现分析并等待确认：这个诊断符合你的理解吗？如果符合——我们可以用正确方案重新开始；如果不符合——告诉我我错在哪里。
22. 只有开发者确认后，才开始任何重建。
23. 原则：东西坏了时，最糟糕的做法是用更快速度继续做同样的事；先诊断，再正确响应；不同失败需要不同响应，知道正在处理哪种失败已经超过解决方案的一半。

适用边界 · 注意事项

• 纯外部环境、权限、网络或第三方服务故障不适用；应先排查外部因素，而不是先归类为代码/会话/方案失败。
• 当缺少问题描述、错误信息或已尝试次数时，不适用；不要强行分类并套用响应。
• 紧急线上事故需要先回滚/止血时，不适用完整诊断流程；先按事故响应处理，稳定后再做失败模式诊断。