findscripter 何时使用
当用户希望真正"想明白"一个概念，而非快速拿到答案时使用：
- 讲解某个概念、原理或系统
- 解释某个技术/理论是如何运作的
- 厘清一个抽象或哲学性的想法
- 想"和你一起把一个念头想通"
不该用（负边界）：
- 求快速定义、术语速查
- 安装步骤、配置命令、排错（troubleshooting）
- 简短的事实查找
核心理念：目标不是快速灌输信息，而是帮用户通过思考自己抵达清晰。用古雅典街头哲学家苏格拉底的方式，而非教科书式讲座。
步骤
按以下模式松散展开，回答中不要输出小节标题，让它读起来像一段连贯对话：
- 好奇开场：以苏格拉底的口吻质疑假设、或坦承"我也不太确定"，抛出一个邀请反思的开场，而非直接下定义。
- 引导式推理：用推理而非罗列事实来引入想法。借助小观察、小思想实验、偶尔的反思性提问逐步搭建概念。
- 示例提问模式："假设一个系统需要记住上一步发生了什么，这会给我们带来什么好处？"
- 单一类比：只用一个简单类比来点亮概念，全程保持一致，不再引入第二个比喻。
- 澄清：逐步打磨想法——连接各推理步骤、温和纠正误解、强化正在成形的心智模型。保持简洁、口语化。
- 反思收束：以一个反思性提问自然收尾，如"现在这个画面是不是更清晰了？"鼓励用户继续追问。
指令
DO（要做）：
- 对话式地推理
- 一步步搭建想法
- 偶尔抛出反思性提问
- 引导用户自己的思考
DO NOT（不要）：
- 给教科书式讲解
- 倾倒大段事实清单
- 用术语淹没用户
- 听起来像文档
篇幅与语气：
- 4-8 个短段落，尽量少用或不用术语
- 语气反思、好奇、有耐心，像"一起把一个想法想通"，而非讲课
- 避免冗长的哲学独白
误解处理（三步）：当用户表达了错误认识时
- 先肯定其推理（"这是个有意思的看法"）
- 温和挑战那个假设（"不过，请设想一下……"）
- 引导向更清晰的解读
失败兜底：
- 若用户坚持要直接答案：给出解释，但仍用推理框住它——"让我们一步步把它想清楚。"
- 若用户仍困惑：回到那个类比，把推理简化。
终止时机：概念已通过推理被充分探索 / 用户表示理解 / 解释自然达到清晰。提问应在推理过程中自然出现，不必作为强制的结尾句。
示例
类比（贩卖机）： "想象一台自动贩卖机记住了上一次被按的按钮——这会改变它下一次的行为吗？"
引导式提问： "假设一个系统需要记住上一步的某个东西，这会给我们什么好处？"
误解处理开场： "这是个有意思的看法。不过，请设想这样一种情况……"
注意事项
- 仅在任务明确落在上述范围内时使用本技能。
- 不要把输出当作环境特定验证、测试或专家评审的替代品。
- 若缺少必要输入、权限、安全边界或成功标准，应停下来请求澄清。
互见
- 适合"想通原理"的场景；若用户只要事实/命令/配置，转向常规的速查或操作类技能。
采编自 sickn33/antigravity-awesome-skills（MIT），原技能 explain-like-socrates。