why

代码体现的是机制，而非动机：代码做什么，一目了然；代码为何存在，则记录在记录中——提交、PR、工单、文档、聊天和遥测，所有这些记录都不完整，有时还互相矛盾。根据这些记录回答是什么塑造了代码，并说明记录到哪里为止。

1. 明确问题

目标是问题所涉及的代码：一段代码、一种模式，或一个有名称的设计决策。目标含糊时，根据对话上下文（打开的文件、近期修改、刚刚讨论的内容）确定，并用一行说明你的理解，然后继续。

问题中若包含自己的答案（“我猜这是为了提升性能？”），就提供了一个假设。把它记在问题旁边，作为综合分析器要检验的一个候选答案。

完成标准：目标和问题各用一行写明；如果问题包含假设，也将其写在问题旁边。

2. 绘制覆盖范围

列出本会话中的 MCP 服务（mcp__<server>__ 工具前缀），并将每个服务归入以下七种来源之一：源代码管理（始终通过 git 和 gh 覆盖）、工单、文档、聊天、可观测性、错误、分析。若一个服务符合两种来源，则归入与其主要证据相符的来源：同时跟踪错误的产品分析服务归入分析；同时保存事故记录的监控服务归入可观测性。没有历史记录的服务——例如浏览器、文件系统、工作树工具——不归入任何来源。将结果记录为覆盖范围图。

完成标准：覆盖范围图中的每个来源都标记为已覆盖（有对应服务；源代码管理则由 git 和 gh 覆盖）或已跳过，并附上一行跳过原因：没有可用服务，或对于此目标已排除（构建时脚本没有错误跟踪）。仅仅对某来源有所怀疑，不足以将其标记为已覆盖。

3. 锚定

派遣锚定器（subagent_type: Explore）。提示中包含：references/anchor.md 的路径，该文件说明了 git 和 gh 的调用方式，以及各部分需要记录的内容；目标；问题及其假设。完成标准：锚点中的每个部分都已填写，并明确标注防御性读取为是或否。

4. 调查

在一条消息中，为每个已覆盖来源各派遣一名调查员。每条提示都包含：

• references/investigator.md 的路径，并要求先阅读
• 对应来源操作手册的路径 references/sources/<source>.md（源代码管理对应 source-control.md），并要求随后阅读
• 锚点
• 问题及其假设
• 若锚点标注为防御性：提供 references/incident.md 的路径，以便在执行操作手册的同时进行跨来源事故排查

完成标准：每个已覆盖来源都有一名独立调查员；调查员没有合并；每名调查员都已按简报的各部分返回调查结果；且每条提示都包含上述全部内容。

5. 综合

所有调查员都返回结果后，派遣综合分析器，提供 references/synthesizer.md 和 references/epistemics.md 的路径，并附上：

• 每位调查员的完整调查结果，原文照录
• 锚点
• 问题及其假设
• 覆盖范围图及跳过原因

完成标准：报告已返回，且“已查阅来源”部分涵盖全部七种来源。

6. 呈现

转述综合分析器的报告，保留其置信度表述；在有助于读者理解时补充对话上下文。完成标准：用户收到报告，其中每个层级标签、引文和 Unknown 均与综合分析器的原文一致。