change-explainer

变更说明

面向初次阅读者讲解：假设他们了解常见编程和 Git，但不了解该项目或文档的用途、领域、架构、术语或布局。如果明确说明了读者背景，则以该说明为准。

按以下层次搭建说明：

整体 → 区域 → 具体问题 → 变更 → 机制

讲解系统发生了什么变化，而不是语言语法、补丁操作细节或每一行修改。

输出要求

• 在最终回复中直接使用 Markdown 完整地给出说明。
• 不要创建、保存或打开 HTML 页面、Markdown 文档、图表文件、.change-explainer/ 目录或任何其他说明产物。
• 工作流程应保持只读。调用此技能仅授权检查，不授权修改仓库或正在比较的文档。
• 除非有助于消除用户请求中的歧义，否则不要提及未生成说明产物。
• 仅在有助于理解时使用标题、项目符号、表格、简短代码摘录或紧凑的文本图示。不要输出原始 HTML，也不要依赖可折叠的界面。

说明原则

1. 先交代基线，再讲变化。 在指出变更之前，说明项目或文档的用途、变更子系统或章节的作用，以及它在整体中的位置。只阅读还原基线所需的最近一层概览、架构索引、入口点或上下文段落。
2. 先讲具体情况，再讲抽象概念。 先举一个真实的运行、请求或故障示例，展示旧行为及其代价。读者能想象这个示例后，再概括所有权、生命周期、契约或其他抽象概念。
3. 每个术语都要有依据。 先定义项目特有的名词、缩写和代码标识符，再使用它们。先介绍角色，再给出名称，例如“运行器的构建函数 buildProject”，而不是只写“buildProject”。每个概念使用一个通俗术语，并仅在首次出现时说明源码中的同义名称。
4. 围绕一条主线展开。 选择解释行为变化所需的 1 到 4 个核心概念。说明相关辅助修改，但不要让迁移范围、机械性修改、文档和测试清单与核心内容占据同等篇幅。
5. 按阅读顺序逐步深入。 开篇要点和具体情境应足以支持快速理解。将机制和维护者相关细节放在后面。
6. 仅在必要时展示关系。 只有在文字难以表达时，才使用 Markdown 表格或紧凑的文本图示来展示流程、顺序、结构、所有权或对比。标签应使用读者已经理解的词语。
7. 在说明中附上证据。 只有当来源位置有助于核实内容时才提及，并将其附在相关机制或维护说明旁，而不是单独汇总成一个章节。
8. 将说明与评价分开。 保持客观。只有涉及重要的正确性、回归、契约、安全或数据问题，或长期设计问题时，才指出隐患。对推断出的意图或权衡应明确标注为推断。

响应形式

根据改动调整回答篇幅，而不是填充固定模板。保持以下学习顺序：

1. 先给出要点。 用两到四句话说明整个项目或文档是什么、改动部分的作用、之前发生了什么、现在发生了什么，以及这种差异为何重要。若读者明确是专家，可简要介绍项目背景。
2. 讲述一个具体的“之前 → 现在 → 结果”案例。 选择一个真实的输入、请求、工作流或策略场景。对于很小的改动，可将案例融入开头段落。
3. 解释其工作原理。 按学习顺序讲解一到四项概念变化。将每种机制与具体案例联系起来，并以其重要性收尾。在本节之前定义反复出现的必要术语，或在文中就近解释只出现一次的较小术语。
4. 适时说明需要记住的内容。 对于非平凡的说明，可使用简洁的 之前、现在 和 原因 提示。若只是重复一个简单答案，则省略。
5. 仅在有帮助时补充审查和维护细节。 在主要说明之后介绍决策、兼容性、测试、权衡、迁移范围和未来修改规则。只有存在实质性问题时才添加 问题 一节。

对于很小的改动，压缩回答，同时保留 背景 → 示例 → 变化 → 依据。对于较大的改动，优先给出简洁概述，再按行为而非文件划分重点章节。

工作流程

1. 确定比较对象。 使用用户指定的差异、提交、范围、PR 补丁或文件对。在 Git 仓库中未指定目标时，使用 git status --short 检查未提交的工作、暂存和未暂存的差异，以及相关的未跟踪文件。如果工作区干净或目录不是 Git 仓库，请询问比较目标。
2. 为初次阅读者搭建背景框架。 先检查差异，再查看最低限度的相关概述、架构或章节导航、入口点、相邻实现或说明，以及测试或辅助依据。回答以下问题：整体功能是什么？这部分起什么作用？之前发生了什么？现在发生了什么？读者、用户或维护者为何会在意？
3. 选择学习主线。 考虑每个差异区块，但只重点讲解一到四个能够说明行为或含义变化的要点。将辅助差异区块放入维护细节。
4. 围绕对话撰写。 先用通俗语言说明结果，再根据改动需要添加相应结构。确保不依赖源代码路径也能理解主要内容。
5. 进行初次阅读者检查。 只阅读开头、具体案例、概念性标题和记忆提示。确保每个名词、缩写和标识符对普通程序员来说都是常见用语、在同一句中有定义，或已在前文定义。反复修改，直至这些可见内容能够回答背景框架中的五个问题。
6. 直接作答。 将说明作为最终回答。不要编写或打开任何辅助文件。

沟通规则

• 主要内容应优先帮助理解和记忆，而不是逐项覆盖差异；将辅助细节保留在后文。
• 介绍架构名称或比喻之前，先说明新增的具体能力或消除的故障。
• 段落要简短，每段最多引入一个新概念。
• 仅在用户要求审查模式时使用审查术语。