看見數字之後，我希望使用者也能立刻理解它。1,088–1,228 筆是怎麼形成的？位置 2–35／78 包含哪些比較資料？切換月份後，文字會怎麼更新？這次我把「解釋結果」做成產品的一部分，讓畫面同時呈現數字、條件與它們的關係。

ChatGPT 協助我整理讀者可能會問的問題，Codex 則把事實資料和說明規則實作進系統。完成的版本採用本機、確定性的說明機制：相同資料和選擇，產生相同文字。使用者開啟產品，就能直接閱讀由這份報告整理出的解釋。

先建立事實，再組成句子

我將每項可引用結果整理為 fact，包含識別、數值、單位和適用範圍。個人活動總數是一項事實，目標藝人活動上下界是一項，固定集合的位置則另有自己的事實。持有人、藝人、期間和來源條件，會跟著這些資料一起保存。

以我的八月 UTC 活動為例，報告記錄 2,215 筆總活動、1,088 筆確認、987 筆排除與 140 筆待確認。說明讀取這些欄位，寫出目標活動為 1,088–1,228 筆，接著交代上界由確認與待確認相加而成。讀者因此能一口氣理解結果和算法。

核心句子再整理為 claim，引用相應的 fact。例如 fact.v1.personal_records 保存個人活動計算，claim.v1.personal_records 引用它，並指回報告裡的總數與分類欄位。這個連結讓一段普通文字也有自己的資料依據。

原件中的「未知」分類也有自己的事實欄位。說明可以告訴讀者，這些活動目前保留在待確認範圍，並解釋它們如何進入上界。資料欄位沿用原始狀態，句子則用容易理解的方式串起它們，數字和閱讀體驗因此可以兼顧。

程式驗證時，會依照同一份報告重建說明，再核對事實、主張和問答。數字、文字和引用關係因此一起受到檢查。這讓產品的說明可以重現，也方便追查某一句話使用了哪些欄位。

把範圍寫進正常敘述

我希望說明讀起來像有人把結果講清楚。與其只放「位置 2–35」，畫面會一起交代八月 UTC、固定正值帳戶和活動筆數。讀者看到 78 份紀錄，就能理解這份結果的比較集合。範圍直接跟著結果出現，閱讀流程也更順。

同樣的方式可以介紹活動比例。我的目標活動佔保留紀錄 49.12%–55.44%，meze 為 28.63%–37.35%；說明可以指出，前者下界高於後者上界，這兩份資料的目標活動組成有清楚差異。文字沿用「活動佔比」這個量尺，讓句子和計算緊密相連。

我也把查證情境接進說明。在擴展集合中，若本人 140 筆待確認活動全部取得支持，且外部界線保持原值，固定正值模式的最差位置會從 35 調整到 31，全部帳戶模式則從 41 調整到 36。這項條件情境能協助我理解，繼續查證本人資料可能帶來什麼效果。

情境計算也綁定名冊。原 35 個帳戶基線有自己的結果，擴展 113 個帳戶有另一份；說明會引用當前選定的報告。這讓資料集擴展之後，文字和數字能夠一起更新。

當前選擇，形成當前說明

使用者切換持有人、藝人或月份時，系統會重新建立對應事實，再產生文字。選我的資料，就讀我的活動；選朋友的資料，就讀該持有人的播放欄位。比較集合和期間是否相容，也會在這一步一併核對。

這件事讓畫面更有連續性。選擇欄、統計卡、位置和問答都依同一份當前報告運作。使用者改了一個條件，整份內容跟著改，會知道現在讀到的就是剛才選定的資料。

我把這條路徑理解成報告的閱讀介面：計算層先產生結果，說明層整理它們的關係，問答再從相同事實回答常見問題。這幾個地方共用當前報告，修改條件之後就能一起更新。維護時也有清楚入口，計算規則變動先檢查結果，再核對對應說明。

保存之後，文字有穩定版本

正式快照進一步把說明綁到固定原始資料前綴和報告 SHA。按下保存後，這份文字就解釋當時被保存的資料；來源繼續新增時，既有快照仍有穩定的版本。匯出 HTML、JSON 和 CSV，也帶著相同報告與條件。

快照同時保存規則與機制版本。重新打開時，可以沿著報告找到這次使用的資料前綴，再核對計算和說明。這是一個很實用的版本單位：某天完成的回顧，可以當作當天的成果保存；下一次資料增加，再建立下一份快照，兩次結果有各自的依據。

查詢保存成果時，系統會核對報告和 manifest 的完整性。這讓「當時算出什麼、為什麼這樣說」可以在日後重新打開檢查，從一次畫面結果變成可以帶走的成果。

我很滿意這個分工。ChatGPT 和 Codex 協助研究、設計與開發，產品執行時則由本機計算和明列規則提供說明。每一句核心結果都有資料依據，每次切換都有對應更新，每份快照都有穩定版本。數字被整理成能讀懂的文字，也就成了產品真正可以使用的一部分。