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 中描述的方法——在撰寫第一個頁面之前，先閱讀該指南。不可妥協的要點：

先有入門簡介。 根頁面介紹主題頁面所需的所有領域概念，每個概念搭配一個具體的隱喻（例如「釋出 (release) 就像影印；一個正在執行的任務 (job) 會鎖定一個影本」）。隱喻只用一次，然後在所有地方重複使用相同的說法。不要對一個概念使用兩個不同的隱喻。
將每個主題建立在執行時期之上。 每個主題頁面以「這段程式碼何時執行？」的故事開頭：2 到 4 個參與者步驟（使用者執行 X → 系統執行函式 Y → 其中的小型任務）。使用程式碼字型顯示實際的函式名稱，同時——而不是取代——以淺白的語言描述故事。
將變更顯示為差異對比。 以紅色/綠色的差異區塊顯示舊程式碼與新程式碼，標題中包含檔案路徑，只保留關鍵部分，並附上 1 到 3 個行內註解，指出為什麼——而不是敘述是什麼。
量化「為什麼」。 禁止使用「慢」這個詞；「每個請求數百 KB，其中約 99% 的時間浪費在無意義的事情上」才是標準。風險也是同樣：具體指出哪個輸入/狀態以及錯誤的結果。
區分 Bug 與決策。 如果某件事是合理的產品選擇而非缺陷，則應將其視為帶有取捨的決策來呈現，而不是錯誤。
在根頁面結尾加上計分板：一個狀態表格，列出每個項目（已完成 / 已提案 / 暫緩），並標明其在程式碼庫中的位置。

複製 references/site-template.html 作為每個頁面的起點——它包含設計標記、側邊欄，以及每個元件的實際範例（故事區塊、提示區塊、差異區塊、狀態表格、標籤）。然後：

保持每個頁面完全自包含（所有 CSS 內嵌在頁面中）。側邊欄會複製到每個頁面，並將目前的項目標記為 class="on"。
遵循 references/design-system.md 中的標記和元件規則。保持指定的調色板、間距和字體比例，讓多頁面網站看起來像同一個系統。範本中附帶一個淺色/深色切換開關和一個可折疊的側邊欄——請將兩者都帶入每個頁面，而不是捨棄它們。
除了範本中已包含的 Google Fonts 連結外，沒有其他外部依賴（字型堆疊在離線時也能優雅降級），也沒有除範本的主題切換片段之外的任何 JS。

開啟或渲染根頁面以及至少一個主題頁面（或重新閱讀它們），檢查：每個側邊欄連結是否正確解析、文章中提到的每個程式碼識別碼是否在程式碼庫中存在且拼寫完全正確、每個差異區塊在概念上是否能對應實際檔案進行編譯，以及計分板的狀態是否為最新。然後告知使用者資料夾路徑，如果環境允許，為他們開啟根頁面。