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