用途
该技能用于 AI 辅助开发过程中出错时的处置决策。它的前提判断是：当 AI 辅助开发出现问题，本能反应往往是继续提示——描述问题、要求修复、得到又一个坏版本、再描述、再要求修复，结果会话越来越长、上下文被污染、代码越来越差。该技能认为问题不在代码，而在于没有分清当前面对的是哪一类失败。因此它把流程拆成两个不可互换的步骤：先诊断失败类型，再按类型开出对应的应对方案。
主要能力
技能内置三种失败模式的识别标准与对应处置流程。
失败模式 1——某个具体的东西坏了。 识别迹象：问题孤立，局限在一个组件、一个函数或一条路由；项目其他部分正常；这是第一次或第二次尝试修复；错误信息或错误行为清晰具体。含义是这是一个普通 bug，存在可被精确定位和修复的根因。应对方式为「定向修复」。
失败模式 2——这次会话已经跑偏。 识别迹象：多次修复尝试让事情更糟或制造了新问题；代码变得纠缠，修复在给修复打补丁；本次会话的上下文充满失败尝试；已经说不清最初的问题是什么。含义是会话已被污染，继续提示不会有用，只会叠加损害，该功能需要在干净上下文中重建而非继续打补丁。应对方式为「硬重置」。
失败模式 3——地基是错的。 识别迹象：代码能运行但产生从根本上错误的行为；AI 一直在自信地构建某些误解了核心需求、库 API 或架构模式的东西；问题不是实现中的 bug，而是实现本身就不对；单独修各个部件没有用，因为整体方向不正确。含义是这不是调试问题，在写任何代码之前需要重新考虑方案，在错误方向上继续实现只会让局面更难收拾。应对方式为「重新思考」。
在继续之前，技能要求先明确告知开发者这属于哪一种失败模式，并用一句话解释判断依据。
使用方式
第一步，描述出了什么问题。 技能先倾听。它要求开发者具体说明：你期望发生什么？实际发生了什么？你已经尝试修复过几次？尝试修复的次数很关键，它决定了这是一个新问题，还是一次已经跑偏的会话。
第二步，识别失败模式。 根据描述判定属于上述三种中的哪一种，并向开发者说明判断结果。
第三步 A，定向修复（对应失败模式 1）。 先诊断再碰代码：请开发者提供确切的错误信息或错误行为、发生的具体文件或函数、代码本应做什么与实际做了什么；只读与问题直接相关的代码，不读整个代码库。然后定位根因——根因是问题存在的真正原因，而非症状，需明确陈述根因及其与症状的区别。接着提出针对根因的精确修复方案，说明要改什么、为什么，以及为何这能解决根因；在开发者确认之前不做任何改动。若修复无效：停下来，不要立刻再提一个修复，应重新审视根因诊断——如果修复无效，很可能根因判断本身就错了，需从头重新诊断；若两次根因诊断都错，可能实际上属于失败模式 2 或 3，需要重新评估。
第三步 B，硬重置（对应失败模式 2）。 先诚实承认现状：这次会话已在错误方向上走得太远，无法靠打补丁恢复，正确做法是干净地重新开始；这不是失败，而是对污染上下文的正确反应，带着清晰意图的新会话会比继续下去更快。然后保存值得保留的东西，在会话结束前，从当前状态中提取有价值的信息：原本这个功能要做什么？当前实现中哪些部分（如果有）实际上是正确的？关于「什么不可行」学到了什么？下一次会话应避免什么？将这些写成一则简短的 Reset Note，包含「我们在构建什么」「哪里出了问题」「下次要避免什么」「下次会话的起点」几个小节。最后给出明确指示：把 Reset Note 保存在可访问的地方、完全结束本次会话、开启新会话、如有记忆则从 /remember restore 开始、带着 Reset Note 作为上下文重新处理该功能，不要继续在本次会话中工作。
第三步 C，重新思考（对应失败模式 3）。 先点出错在哪里的假设：地基错了，意味着某个不该被假定的东西被假定了，要找出它，明确写出「假定的是什么」与「实际为真的是什么」，并说明当前实现无法靠打补丁修复、方案需要改变。然后基于正确理解提出应有的方案：描述正确做法、与当前做法的关键差别、哪些必须丢弃、哪些仍可保留。此时不要立刻开始重建——重新思考需要开发者先理解并认可，展示分析后等待确认；只有开发者确认之后才开始重建。
适用场景
适用于使用 AI 编码助手进行功能开发时出现故障的任意阶段，尤其是：问题局限于单一组件或函数、信息明确的新鲜 bug；经过多轮修复后代码越改越乱、上下文被污染的会话；代码可运行但行为从根本上不符合需求、属于架构或需求理解层面的错误。
限制
资料中未说明该技能支持的平台、安装命令、收费方式、依赖条件或与其他技能的集成方式，这些信息暂未提供。该技能本身不包含具体代码修复建议，实际修复内容取决于使用时的具体项目与上下文。