前言

「才幾個系列而已，每天發了什麼、還缺什麼，憑印象應該記得住吧？」

一兩個系列確實靠印象就能記住。但當並行系列數量來到十幾個，每個系列各自有不同的開賽日、各自算到第幾天、哪幾天已經發文成功、哪幾天還沒發，靠印象追蹤很快就會出錯——不是記錯進度，就是漏掉某個系列今天該發的文章。這篇要講的是，用一份結構化的狀態檔案取代印象，讓進度這件事變得可以隨時查詢、而不是靠記憶。

今日目標

• 理解憑印象追蹤進度，在系列數量增加後會在哪裡出錯
• 看到一份進度狀態檔該記錄哪些欄位，才足以支撐後續的自動化查核
• 學會分辨「狀態檔該記錄什麼」跟「狀態檔不該記錄什麼」
• 建立習慣：任何需要持續追蹤的多線程任務，先想清楚要記錄哪些欄位再開始執行

憑印象追蹤,問題出在哪裡

多系列並行時，每個系列的開賽日通常不一樣——有些系列一開始就上線，有些系列是報名截止前才臨時決定加開的。這代表「今天是第幾天」這個問題，答案因系列而異，沒辦法用同一把日期尺量。如果只靠印象，很容易發生「以為某個系列今天該發第 20 天，其實應該是第 18 天」這種計算錯誤，尤其是系列一多，這種錯誤不會立刻被發現，可能要到事後對照才注意到。

一份夠用的進度狀態檔要記錄什麼

• 每個系列各自的開賽日——因為每個系列的「第幾天」是相對於自己的開賽日計算，不能共用同一把日期尺

• 每一天的發文狀態——是已經發布、還是尚待發布，讓查詢的當下能立刻知道還缺哪些

• 已發布文章對應的識別碼——用來之後需要更新內容時，能準確找到該更新哪一篇，而不是重新用標題去搜尋比對

• 內容的指紋（例如雜湊值）——用來判斷這篇文章的內容跟上次記錄的版本相比有沒有變動，如果沒變動就不需要重複處理，如果變動了才觸發對應的更新流程

• ❌ 只記錄「發了多少篇」這種籠統數字：狀態檔只寫「ai-refactor 已發 15 篇」，遇到需要判斷「今天該不該發、發文內容有沒有變動需要更新」這類問題時，這份記錄完全派不上用場

• ✅ 記錄到足以支撐自動化判斷的顆粒度：每個系列、每一天都是獨立的記錄單位，包含日期、狀態、識別碼、內容指紋，讓後續的自動化流程可以直接讀這份檔案做判斷，不需要人工介入計算

進度狀態檔的目的不是「留一份紀錄給人看」，是讓後續的自動化流程可以直接依賴它做判斷。 顆粒度不夠細，狀態檔就只是一份好看的紀錄，沒辦法真正取代人工追蹤。

今日思考題

如果你手上也有一個需要持續追蹤進度的多線程任務，你現在用的追蹤方式，記錄的顆粒度夠不夠支撐自動化判斷，還是只是一份給人看的摘要？

今日重點回顧

• 系列數量一多，各自不同的開賽日會讓「今天是第幾天」變成因系列而異的計算，靠印象容易算錯
• 進度狀態檔至少要記錄：各自的開賽日、每天的發文狀態、對應的識別碼、內容指紋
• 記錄的顆粒度要夠細，才能支撐後續自動化流程直接依賴它做判斷，而不只是給人看的摘要
• 這是任何多線程長期任務都適用的原則，不限於寫作系列

明日預告

Day 18 會用一個真實案例，講發文自動化流程裡，一個系列的設定如果漏掉會發生什麼事——這個案例發生在這篇文章寫成的前一天。

寫在最後

設計進度狀態檔的時候，最容易犯的錯是只想著「我現在需要記錄什麼」，而不是「未來的自動化流程需要讀到什麼」——這兩個問題聽起來很像，但答案常常不一樣。