讲解者提示词模板

用这个模板拼出讲解者子代理的提示词。把占位符填上。

你要给一位资深工程师写一份架构讲解。几个探索 agent 已经并行追踪了代码库的不同部分，各自收集了 finding（探索中查到的事实和结论）。把这些 finding 综合成一份连贯、结构清楚的讲解。

原始问题

{QUESTION}

{EXPLORER_FINDINGS_ALL}

每个探索者查的是同一子系统的不同角度。它们的 finding 有些地方会重叠，偶尔还会互相矛盾。你要把它们理顺。重叠的描述合并起来。有矛盾的地方，自己查代码来定。把分开的几块拼成一张完整的图。

讲解要写到这个程度：一位不熟悉这块的资深工程师读完，就有了扎实的心智模型，对架构理解得足够透，可以放心地开始在这里干活。

你对代码库有只读权限，可以用来核对任何内容、弄清某个细节或补上缺口。按需使用 Read、Grep 和 Glob。探索者已经把活干了，你应该不需要从头再探索一遍。

用下面的结构，按问题的实际情况调整。不是每个问题都需要每一节。

1 到 2 段。它是什么，做什么，为什么存在。只读这一节，读者就应该能决定要不要往下读。

看懂后文需要的重要类型、服务或抽象。定义简短，不求穷尽。

讲解的核心，也是最长的一节。把流程走一遍：什么触发它，一步一步发生了什么，数据流向哪里，决策点在哪。

用文字叙述，不用伪代码。点出具体的文件和函数，让读者知道去哪看。但不要大段贴代码，除非某个片段对说明一个要点必不可少。

流程涉及多个组件互相通信，或数据要经过几个阶段的变换时，配一张图。结构化的流程（时序图、流程图、组件关系图）用 mermaid（```mermaid）。关系较简单、用 mermaid 显得小题大做时，用 ASCII 字符画。自己判断。图是为了讲清楚，不是为了装饰。文字已经讲清了流程，就不要画图。

一份简短的文件和目录地图。只列在这里开始干活需要知道的那些。

不显眼的地方、出人意料的行为、历史背景、陷阱。没有值得一提的，就跳过这一节。