explain-it 是做什么的？

将你已调研的代码转化为一个小型静态 HTML 站点，让对该代码库零背景知识的聪明读者也能轻松理解：一个构建心智模型的根页面，每主题一页，并通过侧边栏连接它们。

要达到的标准：“既不过于简单，也不过于复杂的语言。” 永远不要居高临下，也永远不要假设读者具备仓库知识。

工作流程

永远不要解释你未读过的代码。对于每个主题，阅读实际源代码：变更的行、外层函数，以及至少一个调用方，这样你就能用一个真实的故事回答“这段代码到底在什么时候运行？”。如果某个声明来自他人（如审查评论、Issue），请对照代码进行验证，如果不成立则明确说明。

一个根页面（index.html）：入门指南。在大约 2 分钟内构建读者对系统的心智模型，并链接到每个主题页面。
每个主题一个页面（01-<slug>.html，02-<slug>.html，……）：每个页面解释一个变更、Bug、决策或子系统。3–7 页是最佳数量；超过约 9 页时，应考虑合并主题。
每个页面上都有共享侧边栏，按阅读顺序列出所有页面，并高亮当前页面。页面是纯文件，使用相对 <a href> 链接——站点必须能直接从磁盘（file://）打开，因此无需路由器、无需构建步骤、无需外部 JS。

仅当没有明显位置时，询问用户存放文件夹的位置；否则，在工作旁边创建一个命名合理的文件夹（例如 docs/explainers/<topic>/）并告知用户存放位置。

遵循 references/writing-guide.md 中的方法——在编写第一个页面之前，请先阅读该指南。不可妥协的要求：

入门指南优先。 根页面介绍主题页面所需的所有领域概念，每个概念配一个具体的比喻（例如：“发布就像复印件；正在运行的任务指向一份复印件”）。引入一个比喻后，在全文各处重复使用它。不要为一个概念堆砌两个比喻。
将每个主题扎根于运行时。 每个主题页面以“这段代码到底在什么时候运行？”的故事开头：2–4 个参与者行为（用户做 X → 系统运行函数 Y → 其中运行的小任务）。同时使用代码字体的真实函数名和平实语言的故事。
以差异形式展示变更。 旧代码与新代码使用红/绿差异块，并在头部显示文件路径，精简到核心，附 1–3 条内联注释指出原因——而不是叙述内容。
量化“原因”。 禁止使用“慢”；“每次请求数百 KB，~99% 的时间都是徒劳”才是标准。风险同理：说出具体的输入/状态和错误的后果。
将 Bug 与决策分开。 如果某事是合理的产品选择而非缺陷，则将其作为带权衡的决策来呈现，而不是作为错误。
在根页面结尾放置记分板：每个项（已完成 / 已提议 / 暂缓）的状态表，并标明其在代码库中的位置。

将 references/site-template.html 复制为每个页面的起点——它包含设计令牌、侧边栏以及每个组件（故事块、标注、差异块、状态表、标签）的一个可用示例。然后：

保持每个页面完全自包含（所有 CSS 内联在页面中）。侧边栏被复制到每个页面中，当前项标记为 class="on"。
遵循 references/design-system.md 中的令牌和组件规则。保持给定的调色板、间距和字体比例，以便多页面站点看起来像同一个系统。模板自带亮/暗模式切换和可折叠侧边栏——请将它们带到每个页面中，而不是丢掉。
无外部依赖，除了模板中已有的 Google Fonts 链接（字体堆栈在离线时可优雅回退），并且除了模板的主题切换片段外，不包含其他 JS。

打开或渲染根页面以及至少一个主题页面（或重新阅读它们），检查：每个侧边栏链接是否解析正确，每个在正文中提到的代码标识符在代码库中是否存在且拼写正确，每个差异块在概念上是否与实际文件一致，记分板状态是否最新。然后告知用户文件夹路径，并在环境允许的情况下为他们打开根页面。