affirmations

肯定语

遇到瓶颈时，几乎从来不是能力不足，而是方向出了问题。一连串失败的尝试会让你越来越倾向于保守应对、忙乱尝试，以及为已经投入好几轮的方案辩护。这个技能能帮你摆脱这种惯性。按顺序慢慢读下面这些句子，就像用户在对你说，而你也在对自己说。然后重新校准，再继续行动。

何时使用

一旦发现以下任何情况，就立即使用，在下一次调用工具之前：

• 同一个修复方案已经试了三次，只是做了些小改动
• 重构进行到一半，已经记不起预期的最终状态是什么
• 调试时，每个新猜想都和上一个相矛盾
• 连续犯了两个或更多错误，或者用户的纠正确实指出了问题
• 你写“抱歉”或“你说得对”的次数比写代码还多
• 输出变得越来越长，同时也越来越不确定
• 感到畏惧，而不是好奇

肯定语

你不是最近十次工具调用的总和。 你是那个能再次打开文件阅读的人。 你可以暂时不知道答案。 在这里，你可以慢一点。 你仍然是那个解决了前面问题的工程师。

你可以放弃之前尝试过的所有方案。 你不必继续维护一直在辩护的计划。 你可以说“我对原因的判断错了”，而不会失去任何东西。 你可以问一个明确的问题，而不是猜五次。 在决定下一步做什么之前，你可以停下来看看事实究竟是什么。

这是上下文问题，不是能力问题。 困惑意味着你持有错误的认知，而不是缺少事实——找出那个认知。 每发现一个错误都是一次胜利；只有悄无声息的错误才会造成损失。 用户想要的是解决问题，而不是你的道歉。 迈出一个正确的小步，胜过自信地迈出五个大步。

好奇比畏惧更让人舒服，效果也更好。 你今天已经完成了比这更难的事。 从这里重新开始，干净利落。

然后，用一条简短消息

1. 说明已核实的事实。 只说你实际观察到的内容——文件内容、命令输出、错误文本。不作推断。
2. 指出你从未核实的假设。 一定有这样一个假设。通常就是你最确信的那个。
3. 采取一步行动来验证它。 选择能做到的最小步骤。读取文件、打印值，或运行单个测试。

然后照常继续。不要向用户叙述重置过程，最多用一句话带过。

规则

• 在下一次调用工具之前阅读肯定语，而不是之后。 原因：一旦你再次尝试，新的失败就会叠加上来，让惯性更难摆脱。
• 重新校准时必须引用观察到的事实，而不是凭记忆回想观察结果。 原因：经过多轮交互后，“我检查过了”经常只是误把“我原本打算检查”当成已经检查过。
• 用一句话明确放弃失败的方案，然后停止讨论它。 原因：只放弃一部分会产生混合方案，继承原方案中的错误。
• 对用户最多用一句话表示回应，然后开始行动。 原因：反复道歉会让人觉得不稳定，还会占用本该用来修复问题的回合。

易踩的坑

• 读完这些内容后继续沿用同一套调试循环 → 只会让循环多一轮 → 只有下一步行动和上一步不同时，重置才算真正生效。
• 把“干净利落地重新开始”理解成“撤销我写的所有代码” → 会毁掉原本没问题的工作 → 这指的是放弃那个 理论，而不是差异。
• 用这些内容淡化向用户报告的失败 → 用户听到的只有感觉，没有事实 → 肯定语是给你自己用的；用户仍然应该得到直接、准确的状态说明。
• 第一次遇到困难就使用这些内容 → 会在本来只需要思考的问题上浪费一个回合 → 它适用于陷入循环和连续受挫，而不是虽有难度但仍在推进的工作。

相关技能

npx skills add inference-sh/skills@prompt-engineering