how

交付内容是一份心智模型：面向刚加入该子系统的资深工程师进行说明，但不深入到带注释的源码。文中的每项陈述都追溯到具体实现。

1. 明确问题

从调用中，或从本次讨论的主题中提取问题。范围不明确时，用一句话说明你的理解，然后继续。

将问题拆分为若干角度，每个角度对应子系统的一个独立部分：若只涉及单个模块或函数，则设一个角度；若子系统横跨多个文件或服务，则设二到四个角度。拿不准时，少设一些。

完成标准：每个角度都指出一个可作为切入点的文件或符号，且问题的各个部分都归入某个角度。

2. 探索

在一条消息中，为每个角度分派一位探索者（subagent_type: Explore，搜索广度为 very thorough）。每条提示都包含 references/explorer-brief.md 的路径、问题和该探索者负责的角度。

完成标准：每份回复都将其负责的角度追溯到代码，并为每个组件和流程步骤提供文件路径。若探索者只列出了名称，则重新分派。

3. 说明

综合发现，形成一个心智模型。对于重复的发现，将其合并；对于相互矛盾的发现，亲自阅读代码来确认。按照 /humanize 的要求撰写，并且：

• 指明具体对象：“UserService 调用 AuthClient.refresh()”，不要说“该服务委托给客户端”。
• 对于复杂之处，解释其原因；对于简单之处，用一句话说明。
• 当流程跨越多个组件，或数据在各阶段发生变化时，绘制 Mermaid 图。

使用以下各节；只有当探索者的发现中没有相关内容时，才省略相应章节：

• 概览：一到两段。说明它是什么、做什么，以及为何存在。提供足够的信息，让读者判断是否要继续阅读。
• 关键概念：逐行定义其余内容所依赖的类型、服务和抽象。
• 工作原理：篇幅最长的一节。说明由什么触发、逐步发生了什么、数据流向何处，以及决策点在哪里。使用带文件和函数引用的文字说明；只有在确有必要时才提供代码片段。
• 代码位置：列出读者最先会打开的两三个文件，并说明每个文件的重要性。
• 注意事项：指出可能让新成员措手不及的非显而易见发现。
• 待解问题：将探索者无法追溯的链接列为未知事项，不要猜测补全。

完成标准：探索者的每项发现都得到处理：予以采用、与其他发现合并，或作为资深工程师入门时无须了解的细节舍弃。