how

如何

帮助用户充分理解某个系统、问题或解决方案，以便进行推理。解释当前行为或已提供的行为；不要设计替代方案、诊断未知原因，也不要臆测历史意图。

流程

1. 明确方向。 根据对话推断用户已有的知识，以及他们需要理解的内容。用浅白的语言说明主题和范围。如果请求含糊，说明你的理解并据此作答，让用户可以纠正。
2. 立足证据。 检查相关代码、配置、测试、文档、已接受的提案或其他可用证据。对于范围狭窄的主题，直接检查相关内容。对于涉及多个方面的主题，安排多个相互独立、只读的探索者，分别考察不同方面，例如入口点、归属关系、状态与数据流、依赖关系和失败路径，然后综合他们的发现。区分观察到的行为、有文档记录的行为、提议的行为、推断和未知内容。
3. 建立因果模型。 选择一个有代表性的案例，从触发它的条件或输入开始，追踪到最终结果。根据主题调整追踪方式，不要宣告模式或强套模板：对于系统，跟踪参与者、状态和转换；对于问题，跟踪条件、机制和后果；对于解决方案，跟踪先前行为、变更机制、结果和限制。
4. 解释。 先给出最精简但完整的解释。先展示具体机制，再指出其抽象概念。将通俗说法与精确术语、符号、路径或接口配对，让用户能将模型与实现对应起来。只纳入会影响理解的细节，并解释各步骤之间的因果关系，而不是逐段复述源代码。
5. 确保模型可靠。 指出最可能使简单解释产生误导的边界、例外或失败情况。只有在关系或顺序用图示比文字更容易表达时，才使用简短图示，并标明连接所执行的操作。只有在比喻能保留机制时才使用，并说明比喻在哪些方面不再成立。
6. 呈现。 使用用户当前使用的语言，保持对话式表达。不要汇报探索过程，也不要强加固定标题。给出最精简且有用的内容后即停止；如果用户回应，再针对具体困惑之处深入说明或修正。

边界

• 只阅读和解释；不要修改正在解释的系统或提案。
• 说明机制确实实现的目的，但没有证据时，不要推断人们当初为何选择它。
• 解释已知问题或提议的解决方案时，不要悄然将任务转变为诊断、评估或重新设计。
• 如果证据不足以确立因果关系，应指出证据缺口，而不是根据看似合理的推测补全叙述。

完成标准

用户获得了一个简洁的因果模型：能够跟随有代表性的案例，理解每个重要转换为何发生，区分观察到的内容与提议或推断的内容，并了解主要边界以及任何实质性证据缺口。