Steam 遊戲時數視覺化實測：把客戶端日誌攤成一年作息熱力圖

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

你電腦裡的 Steam 客戶端，自己就在寫一份比個人頁面更細的遊戲紀錄：哪一天、幾點開始、開了哪一款、什麼時候收工，全部記在安裝目錄下的兩份文字檔裡。Steam Log Visualizer 做的事情，就是給這兩份日誌一雙眼睛。它是一個放在 GitHub Pages 上的靜態網頁，把日誌拖進去，瀏覽器當場重建每次遊玩的起訖時間，畫成月曆熱力圖、遊戲時數長條圖與時數佔比圓餅圖。為了確認它算得準不準，我照它的解析規則造了一組假日誌丟進官網實測：四段遊玩時段，事前手算總時數 3.83 小時，畫面回報 3 小時 50 分，一分不差。整個實測過程與它的能見邊界，下面從源頭講起；先記住一個事實：這是一個 2025 年 10 月之後就沒再動過的一次性專案。

這些圖不是工具變出來的，Steam 本來就在記

先弄清楚資料從哪裡來。Steam 客戶端平時會在 logs 資料夾裡寫一堆日誌，這個工具讀其中兩份：content_log.txt 記的是遊戲狀態變化，某款遊戲什麼時候進入執行、什麼時候回到安裝完成的狀態，一行一行帶著時間戳；connection_log.txt 記的是帳號層的動態，誰幾點登入、幾點登出。兩份都是純文字，用文字編輯器就打得開，Steam 不只不加密，連藏在哪都不算秘密。

工具的解析邏輯就建立在這兩種行的字面格式上。每行開頭都有一個帶到秒的時間戳，長得像「[2025-10-03 20:00:00]」，接著才是事件內容。我在原始碼裡看到，它認的是「AppID 730 state changed : Fully Installed,App Running」這種行：看到這行，代表一款遊戲（這裡的 730 是《絕對武力 2》的編號）開始跑了，記為時段起點；之後同一個 AppID 出現只寫到「Fully Installed」結尾的行，代表狀態歸位，時段結束。兩個時間戳相減，就是你玩這款遊戲的這一段時長。帳號那邊則是盯著登入完成與登出的行，前後夾出這個帳號上線的區間。這套解析直接比對日誌的字面格式，並沒有走任何官方資料介面，這個前提後面會再回來。

值得先記住的一點：這份紀錄的細緻度，其實超過 Steam 個人頁面給你的總時數。個人頁只看得到一款遊戲的累積小時，日誌裡卻是逐次起訖的原始軌跡，幾點開工、跨沒跨過午夜、中間隔多久再開，都算得出來。類似的「別的軟體替你記了一堆你從沒看過的行為資料」處境，我在讀硬碟裡 AI 工具 session 紀錄來對帳的 CodeBurn 那篇也遇過，差別只在 Steam 記的是娛樂，AI 工具記的是帳單。

三小時五十分是怎麼對上的

實測的方法很直接：造一份假 content_log.txt 和一份假 connection_log.txt，時段全部手工安排，總時數先算好，再丟進官網比對。我安排了四段遊玩時段，AppID 用真的，時間是假的。

第一段 20:00 到 21:30 一個半小時，第二段 21:40 到 21:45 只有五分鐘，第三段故意壓過午夜，22:00 開始、隔天 00:15 結束，第四段 09:00 開始、不給結束行，模擬日誌在遊戲還跑著的時候就被切斷的情況。手算閉合時段合計 1.5 加 0.083 加 2.25，等於 3.83 小時。

官網畫面給出的答案：Sessions 4、總時數 3h 50m、Games 4、Accounts 2。全部對上。跨過午夜的那段，工具的彙總邏輯是把每個時段沿著日期線逐日切開、分別歸帳，總數一分不差，代表切分沒有漏掉或重複計時間。第四段沒有結束行的時段，時長留空、不計入總數，所以 Games 是 4 但時數停在 3h 50m，這個處理方式誠實，比硬猜一個結束時間好。

帳號那欄出現 2 個，是我特意安排的第二個檢查點。我的假 connection_log 裡帳號在最後一段開始前就已經登出，結果那段沒被掛在真帳號名下，帳號篩選器裡多出一個 UNKNOWN。也就是說，日誌裡落在登入區間外的遊玩時段，工具會如實標成未知帳號。家裡 Steam 是多人共用、每個人輪流登入自己帳號的人，看到篩選器出現未知項先別以為是算錯，回頭對一下登出入時間通常就有答案。

圖表本身分成幾塊：各遊戲時數長條圖、時數佔比圓餅圖、按月彙總長條圖，再加上一張把一年攤開的每日熱力圖，下方還能挑單一款遊戲往下鑽，看它自己的月份分佈與每日分佈。丟檔之後遊戲名稱也自動換好了，四個真實遊戲的編號分別顯示成 Counter-Strike 2、Baldur’s Gate 3、Terraria 和 Hades，名稱對照靠的是隨網站附的一份約 17MB 的靜態對照表，細節後面再談。

Pin

「不上傳」這句話，我盯著網路請求驗過

介面上有一行英文聲明，寫著處理全程在你的瀏覽器裡完成、沒有任何東西被上傳。這種話聽聽不夠，我讓瀏覽器在載入與丟檔的全程記錄每一個發出去的網路請求。結果很乾淨：除了同一個網站自己的 JavaScript、樣式表、兩個在背景跑解析與彙總的 worker，以及兩份隨頁面附上的資料檔，沒有任何對第三方的請求，沒有分析追蹤腳本，也沒有去呼叫 Steam 的官方介面。日誌內容留在本機，這件事在行為層成立，而且它連可以做遙測的依賴都沒裝，整個專案的第三方套件只有畫圖用的 ECharts、做星圖的 Three.js 和一份讀 CSV 的工具。

瀏覽器端處理敏感檔案這件事，近年在PDF 塗黑工具的原始碼驗證那篇討論過，宣稱本地處理與實際行為之間常有縫隙，值得每次都重新驗。這次的結論是正向的：它沒有後端，GitHub Pages 上就是一堆靜態檔，想上傳也沒有對象。附帶一提，同樣是記錄個人使用行為的工具，macOS 選單列的鍵鼠計數器 KeyStats 曾被原始碼驗出啟動就送遙測，兩相對照，這個網頁的乾淨不是理所當然。

星圖很漂亮，但它看的不是你的紀錄

網站還有第二個分頁叫 Star Map，打開是一整片可以旋轉縮放的三維星點，每顆星是一款遊戲，大小由評論數決定、顏色由好評率換算，位置則用資料集預先算好的座標，資料是隨專案附的 18,608 款遊戲資料集，檔案本身約 5.7MB。這個分頁視覺上很吸睛，但要說清楚：它消費的是那份公開資料集，跟你的日誌無關，你的遊戲時數不會變成星圖上的任何一顆星。把它當成獨立的小玩具看比較準。

Pin

遊戲名稱的對照也是同一套靜態快照的邏輯。你的日誌裡只有 AppID 數字，工具靠一份約 17MB 的名稱對照表把數字換成遊戲名，這份表同樣是隨網站附的快照，打開頁面時從同一個網址載入。好處是不必每次去問 Steam 的伺服器，代價是表是新鮮度固定的：剛上市幾天的新遊戲如果還沒進快照，名稱預期會以編號原樣呈現，屬於可預期的邊角情況。

想看多遠，日誌保留多久說了算

工具能畫出多久的歷史，決定權不在它手上。Steam 的客戶端日誌屬於會輪替的暫存性質檔案，工具自己的介面也放了警告，大意是受限於 Steam 日誌的大小限制，資料可能被截斷。換句話說，它讓你看到的是日誌目前還留著的那段時間的作息切面，通常偏向近期，想要回推三年前的暑假在玩什麼，多半翻不到。把它定位成近段時間的作息檢視器，期待會比較準。每日熱力圖這邊的處理倒是貼心：選定年份後整年的格子都會畫出來，沒玩的日子就是零，誠實的空白讓爆量的那幾天更顯眼。

還有兩個小地方值得知道。介面語言只有英文和簡體中文兩種，沒有繁體中文，選單切到中文後顯示的是簡體字串。另外翻譯檔裡留了一個匯出 CSV 的字串，但實際頁面上找不到任何匯出按鈕，功能在檔案裡看得到、用不到，想要資料帶走得自己想辦法。

一次性專案的保鮮期

現在講那個一開始就該知道的事實。這個專案的生命週期很短：2025 年 9 月 22 日第一個 commit，10 月 18 日最後一個 commit，前後四個星期、14 個提交全部出自同一人之後，就完全停更了。到現在為止的成績是 17 顆星、1 次 fork、0 個 issue、0 個 release，官網頁面的最後更新時間也停在 2025 年 10 月 18 日，跟最後一個提交同一天。它不是死了，是凍著：因為整站是靜態頁，放在 GitHub Pages 上不會壞，今天實測也一切正常，但也不會再長任何新東西。

這帶出一個具體的依賴風險。前面提過，解析靠的是對日誌字面格式的正規式比對，Steam 客戶端哪天改了輸出格式，工具就會靜默地漏算或算錯，不會跳錯誤，只會圖變得怪怪的，而停更的專案不會有人跟進修正。授權倒是寬鬆的，repo 裡有實體 MIT 授權檔，可以自由使用、修改、自己架一份，只是授權聲明行的著作權人只寫了「Copyright (c) 2025」，連名字都沒填，很有隨手做完就丟出來的氣息。

真想長期依賴它，把原始碼 clone 下來自己留一份，是這個處境下最實際的自保動作。專案是 TypeScript 寫的，套件定義齊全，本機要有 Node.js 18 以上才能跑起來，照說明文件走是 clone、裝依賴、開發伺服器三個指令的事；部署也不神秘，repo 裡的自動化流程是在收到更新時自動建置並推上 GitHub Pages，只是那條流程自 2025 年 10 月後就再也沒被觸發過。留下原始碼等於把「Steam 改格式還有人修」的機會至少握在自己手上，修不修得動看個人，但選項在那裡。

想試的話，第一步只是找對資料夾

實際門檻很低：不用安裝、不用帳號，打開網頁，把 Steam logs 資料夾裡最新的 connection_log.txt 和 content_log.txt 一起選起來丟進去就好。資料夾在 Windows 是 Steam 安裝目錄下的 logs，macOS 的完整路徑在家目錄下的資源庫裡，接著 Application Support、Steam、logs 一路點進去，Linux 則在 ~/.steam/steam/logs/。兩個檔案要一起備齊，解析入口少了任一個都會被擋下。圖出來之後，月曆熱力圖看作息密度，長條圖看哪款吃掉最多時間，帳號篩選器記得瞄一眼有沒有未知項，挑單一款遊戲可以看它自己的時間分佈。

適合的人很明確：想看看自己近期的遊戲作息長什麼樣、家裡 Steam 是多人共用想分帳號看、或單純對「原來 Steam 一直在記這些」感到好奇的人。不適合的場景也一樣明確：想稽核完整歷史、要正式的統計報表、或需要長期穩定維護的單位用途。它是個把現成資料變漂亮的透明小鏡片，鏡片本身沒問題，問題永遠在資料還剩多少、以及那個不再更新的解析器還認不認得明天的日誌。