explaining-architecture

解释架构

回答“X 是如何工作的？”时，应提供资深工程师开始熟悉一个陌生子系统所需的思维模型：介绍其架构、流程和容易踩坑之处，而不是逐段注释源代码。

如果问题询问的是动机、被否决的替代方案或历史，而非工作机制，请调用 Skill 工具，并使用 investigating-design-rationale。如果未安装该技能，请说明这一点，并仅回答工作机制。没有 Skill 工具时，请遵循 技能调用规则。

该技能为只读：不写入文件，也不更改任何状态。请描述代码的实际行为，而不是文档声称的内容；如果两者不一致，请按照文档与代码规则说明。

输入

请求会指明某个子系统、功能流程或位置问题（“这项验证应该放在哪里”）。如果请求没有指明目标，或描述含糊，请根据对话上下文推断目标，并在开始探索前用一句话说明你的理解。不要先提问。

解释

阅读实现；不要根据文件名或函数名推断行为。追踪每条流程从触发到产生效果的完整路径。如果无法追踪某个环节，请如实说明，不要编造。涉及代码的论述须标注 file:line，流程中的每一步都须指出执行该步骤的函数。

根据问题调整答案，只使用需要的章节：

• 概述：用一到两段说明它是什么、做什么以及为何存在。
• 关键概念：介绍理解后续内容所需的抽象概念。
• 工作原理：用文字说明触发条件、步骤、数据流向和决策点。只有流程涉及多个组件时才添加 Mermaid 图。
• 文件位置：列出读者开始了解该功能所需的文件，而非所有文件。
• 注意事项：说明意外行为、历史遗留问题和容易踩坑之处。

遇到复杂内容时，解释其复杂原因。省略探索过程、问题未涉及的背景信息和重复表述。

评析

仅在请求询问问题、缺陷或改进建议时运行。先完成解释，再遵循评析模式。