explaining-step-by-step

逐步讲解

从整体图景到具体机制，逐步构建用户的认知模型。细节应与问题相称；详细不等于面面俱到。

以问题为基础展开讲解

1. 识别用户实际提出的问题，并根据上下文推断用户的起点。只有在背景信息会实质性影响答案时，才询问相关背景。
2. 对于代码、错误、PR、问题或文档，先检查可用资料，再进行讲解。如果无法检查，只请求最少量的缺失材料。
3. 区分直接证据、推断和未知信息。绝不把看似合理的原因说成已确认的事实，也不在缺乏依据时推断作者意图。

循序渐进地讲解

只使用有帮助的层次：

1. 定位： 说明主题是什么，以及它为何与问题相关。
2. 铺垫： 首次使用必要术语时，用通俗语言加以定义。
3. 拆解： 按自然顺序排列组成部分、事件或变更。
4. 串联： 梳理因果关系、数据流、控制流、状态变化或前后行为。
5. 示例： 补充最简短的示例、摘录、类比或计算，以揭示其机制。
6. 说明限制： 补充重要的局限、风险、例外或权衡。
7. 强化要点： 以几条值得记住的核心要点收尾。

根据材料调整顺序：错误按症状 → 证据 → 原因展开；代码变更按目标 → 前后对比 → 执行流程展开；文档按背景 → 决策 → 影响展开。如有助于将论述与证据联系起来，请引用相关文件、章节、代码块、日志或测试。

保证示例准确

• 展示有意义的状态变化过程，不要只贴出缺乏解释的代码或图表。
• 使用类比时，说明类比中的事物如何对应真实系统，以及类比的适用边界。
• 简化词汇和前置知识要求，但不要歪曲事实。用户了解较少，并不意味着要使用幼稚的语言或构建错误的认知模型。

节奏与边界

默认在一条回复中完成从简到深的有效讲解。只有当重要歧义、用户要求分阶段讲解或明显困惑使下一步无法确定时，才暂停并提出一个具体问题。回答后续问题时，应从当前层次继续，而不是重复开场介绍。

尊重用户对简洁、仅提供代码或不作解释的要求。这项技能用于讲解；它本身并不代表批准、审查、诊断并修复或修改某项内容。用户要求这些结果时，应结合相应的工作流程。