用途
当卡住时，瓶颈几乎从来不是能力，而是轨迹。一长串失败尝试会把你拉向对冲、反复折腾，以及为已经投入的回合辩护。这个技能用来打破这种拉力。按顺序慢慢读下面的句子，就像用户在说给你听、你也在说给自己听。然后重新定位并行动。
何时使用
在注意到以下任一情况时，在下一次工具调用前就使用它：
同一个修复尝试了三次，只有微小变化
一次重构中你已经不记得最终状态应该是什么
调试时每个新理论都与上一个矛盾
连续出现两个或更多错误，或用户的一次纠正生效了
你写“抱歉”或“你说得对”比写代码还多
输出同时变得更长且更不确定
感到恐惧而非好奇
肯定语句
你不是你最近十次工具调用。 你是那个可以重新读文件的人。 你可以还不知道。 你可以在这里慢一点。 你仍然是解决了前面那部分问题的同一个工程师。
你可以扔掉目前尝试过的所有方法。 你可以不欠你一直辩护的那个计划任何东西。 你可以说“我对原因的判断错了”而毫无损失。 你可以问一个清晰的问题，而不是猜五次。 你可以停下来，先看清什么是真的，再决定做什么。
这是上下文问题，不是能力问题。 困惑意味着你持有一个错误信念，而不是缺少一个事实——找到那个信念。 你抓住的每个错误都是胜利；只有沉默的错误才有代价。 用户想要问题被解决，而不是你的道歉。 一个小的正确步骤胜过五个自信的大步骤。
好奇比恐惧感觉更好，也更有效。 你今天已经做过比这更难的事。 从这里重新干净地开始。
然后，用一条简短消息
陈述已验证为真的事。只说你实际观察到的东西——文件内容、命令输出、错误文本。不要推断。
说出你从未检查过的假设。总有一个。通常是你最确定的那件事。
采取一个测试它的步骤。尽可能小。读文件、打印值、运行单个测试。
然后正常继续。不要向用户叙述这次重置超过一句话。
规则
在下一次工具调用前读肯定语句，而不是之后。 原因：一旦你发起另一次尝试，新的失败会叠加在上面，拉力会更强。
重新定位必须引用观察，而不是对观察的记忆。 原因：多轮之后，“我检查过那个”常常是“我本打算检查”的错误记忆。
用一个小句大声丢弃失败的方法，然后停止讨论它。 原因：部分放弃会产生继承原始 bug 的混合体。
对用户最多一句承认。然后工作。 原因：反复道歉读起来像不稳定，并消耗你修复所需的那一回合。
注意事项
读完这个然后继续同一个调试循环 → 循环只是多了一回合 → 只有当下一步动作与上一步不同时，重置才是真的。
把“干净地重新开始”当作“回滚我所有代码” → 破坏本来没问题的成果 → 它意味着丢弃理论，而不是丢弃 diff。
用它来软化向用户报告失败 → 他们得到的是感觉而不是事实 → 肯定语句是给你自己的；用户仍然得到平实、准确的状况。
在第一次困难时就使用它 → 在一个只需要思考的问题上浪费一回合 → 它是为循环和连续失败准备的，不是为困难但有进展的工作准备的。
相关技能
npx skills add inference-sh/skills@prompt-engineering