Day 16：程式碼生成的正確性保證機制 結尾留下一句明確的懸念，如果寫作代理人不記得自己前幾天已經寫過什麼、用過哪些版本的範例，即使每一段程式碼在當下都是正確的，系列整體還是可能出現前後版本不一致或重複雷同的問題。

今天要正面回答這個問題。

程式碼是對的，但系列記得住自己說過什麼嗎

Day 16 已經把程式碼範例的正確性保證機制定案，查詢與執行驗證兩道防線並存，缺一不可。但這道保證機制回答的是單一段程式碼在當下這一刻站不站得住腳，沒有回答另一個層次的問題。

寫作代理人如果不記得自己前幾天已經寫過什麼、用過哪些版本的範例，即使每一段程式碼在當下都是正確的，系列整體還是可能出現前後版本不一致或重複雷同的問題。

今天要正面回答這個問題。答案的方向是，跨篇一致性不能靠寫作代理人自己記得，而是需要一套狀態管理機制撐起來。

在往下走之前，先把今天的任務範圍畫清楚。今天只定義狀態管理機制本身的設計原則，不涉及審查代理人的角色，也不做完整跑一次流程的實戰示範，這些都留給後面的天數處理。今天要交出的，是這套狀態管理機制究竟是什麼、它與系列已經定案過的哪一個機制有關、以及寫作代理人該怎麼具體使用它。

內容漂移沒有消失，只是換了一種面貌出現

先回答一個更根本的問題，為什麼寫作代理人記不記得前幾天寫過什麼，值得單獨拿出來討論。

Day 01：為什麼傳統的「一鍵生成」寫不出好的長篇技術文章？ 所說的內容漂移病灶，確切定義是前段內容在整個上下文中所佔的相對權重隨長度增加而被稀釋，模型逐漸退回訓練資料中最常見、最保守的預設寫作模式，逐漸偏離一開始被設定的風格與深度。這個病灶原本談的，是單篇文章內部前後語氣或深度不一致的問題。

Day 01 當時還留下另一句話，這個問題對單篇文章已經是麻煩，但把場景換成連續 30 天不間斷產出系列文章，殺傷力會被放大到另一個層級。這句話當時聚焦的是語氣與深度的漂移，今天要指出的是，同一種放大效應還有另一種具體型態，發生在概念定義與範例版本這類具體內容上。系列裡不同天數之間對同一個概念、同一個工具版本，可能給出前後矛盾或重複雷同的描述，這正是 Day 01 談過的內容漂移在跨篇尺度上會具體現形的地方。

換句話說，內容漂移這個病灶沒有因為進入寫作階段就消失，只是換了一種更難察覺的面貌出現。原本是單篇內部的語氣落差，讀者一路讀下去就能察覺，現在變成跨篇尺度上概念與版本的矛盾，讀者必須前後對照才會發現，暴露的門檻更高，但殺傷力並沒有比較小。

35 個各自為政的寫作代理人，會發生什麼事

把這個延伸型態的病灶具體攤開來看。如果每一天的寫作代理人都是各自獨立展開的一次工作，不帶著前面任何一天實際寫過的內容進場，會發生什麼事。

第一種具體症狀，同一個概念在不同天被重複定義兩次。假設系列第 12 天的文章，為了鋪陳當天主題，完整解釋了一次某個快取機制的運作原理，第 22 天的文章因為主題也牽涉到快取，寫作代理人在完全不知道第 12 天已經解釋過的情況下，又把同一個機制重新完整解釋一遍。兩天各自單獨看都通順，讀者前後對照閱讀，卻會感覺到一種不必要的重複，更麻煩的是，兩次定義的措辭或範圍還可能略有出入，讀者甚至會開始懷疑，這兩天說的是不是同一件事。

第二種具體症狀，第 10 天用某個版本的範例，第 20 天卻用另一個不同版本的範例。假設系列第 10 天的程式碼範例，採用了某個函式庫舊版本的呼叫方式，這個寫法在當時查詢與執行驗證都通過，第 20 天的文章因為需要用到同一個函式庫，寫作代理人在不知道第 10 天用過哪個版本的情況下，查到了該函式庫的最新版本並依此撰寫範例。兩篇文章各自單獨看都正確，程式碼也都個別驗證過，但放在系列裡前後對照，讀者會感受到版本認知上的落差，甚至懷疑系列本身有沒有校對過。

這兩種症狀有一個共同點，值得特別點出來。即使單篇內部風格一致，Day 16 定案的查詢與執行驗證兩道防線也都確實發揮作用，35 天累積下來，系列整體依然可能是不一致的。這證明了一件事，單篇層級的正確性保證，無法自動疊加成系列層級的一致性，這是兩個完全不同維度的問題。

全域錨點檔案的延伸，今天最核心的定案

讀到這裡，一個疑惑可能會冒出來，今天要講的狀態管理，聽起來像是要再引入一套全新的機制，是不是又要多學一套東西。答案是否定的。

先回顧 Day 05：系列的單一事實來源，打造全域錨點檔案 已經定案的內容。全域錨點檔案是記錄系列中所有已定義專有名詞與已定案架構決策的獨立檔案，作為所有 Agent 共享的單一事實來源。Day 05 當時也已經指出，寫作代理人查證用詞時，理論上也可能需要查閱同一份檔案。

今天要正式定案的判斷是，狀態管理就是這份全域錨點檔案在寫作代理人手上的延伸使用，同一份單一事實來源被賦予了新的用途，並非另立一套與它無關的全新機制。兩者服務的是同一個目標，讓系列裡所有角色查到的都是同一份權威版本，而不是各自持有一份可能不同步的理解。

延伸的具體內容是什麼。全域錨點檔案原本定義的兩類記錄，已定義專有名詞與已定案架構決策，是規劃代理人視角下最需要的內容，服務的是規劃層級的一致性。但寫作代理人在實際展開段落時，真正會遇到的操作性狀態還有第三類，前幾天已經使用過的具體案例、已經定義過的名詞在正文裡具體怎麼呈現、已經使用過的程式碼版本或範例情境。這是原本兩類記錄尚未涵蓋，但精神上完全一致的自然延伸，同樣是為了讓後續查閱者不必自己重新措辭或憑印象轉述，同樣是為了避免同一份理解在不同天數之間悄悄走樣。

今天做的事，是把寫作代理人視角下需要的第三類內容，納入同一份共享記錄的延伸範圍，全域錨點檔案的格式本身維持原樣。系列裡依然只有一份單一事實來源，這個原則沒有被打破，只是這份記錄現在同時承接規劃層級與寫作層級各自需要查閱的內容。

寫作代理人怎麼用這份記錄，查閱與回填的迴圈

釐清了關係之後，接下來要具體定義，寫作代理人在逐段展開內容時，應該如何查閱與回填這份共享記錄。

動筆前有兩個查閱動作。第一個，寫作代理人在逐段展開某一段落、涉及具體案例時，先查閱這份共享記錄，確認同樣的概念或案例是否已經在前面某一天被使用過，避免重複定義。第二個，涉及程式碼版本或範例情境時，同樣先查閱這份共享記錄，確認前面天數採用的是哪一個版本或情境，確保今天要寫的內容與過去採用一致的版本，而不是各自憑當下的判斷選一個看起來合理的版本。

完稿後有一個回填動作。當這一段內容引入了新的案例、新的具體範例情境，寫作代理人應該把這些內容回填進這份共享記錄，供後續天數查閱。這個回填動作，與 Day 05 定案的持續累積精神完全一致，全域錨點檔案本來就是隨系列進展持續累積、持續被查閱與回填的常駐檔案，不會隨某一天產出而結案。

值得具體描繪一下這個查閱與回填的動作嵌入在什麼節奏裡。寫作代理人展開某一段落，準備寫下一個具體案例之前，先確認這個案例或版本是否在前面某一天已經出現過，確認過後才動筆，寫完之後順手把新引入的內容記一筆，再繼續往下一段走。這整個查閱與回填的動作，鑲嵌在 Day 14：寫作代理人的架構設計，從規格到草稿 定案的逐段展開節奏裡運作，寫作代理人在展開涉及具體案例或程式碼範例的段落時，順勢查閱、順勢回填，維持在同一個段落展開的節奏裡完成，屬於既有節奏內部的一個動作，不是額外獨立於外的另一套流程。

這裡可以簡短點名 Day 16 定案的查詢與執行驗證兩道防線作為對照。

那兩道防線保證的是單一段程式碼在當下這一刻的正確性，今天的查閱與回填動作保證的是這一刻的內容，與過去 35 天裡其他天數的內容不矛盾、不重複。兩者處理的是不同維度的問題，缺一不可，一個負責讓每一段內容站得住腳，一個負責讓所有段落放在一起依然是同一個系列在說話。

狀態記得住了，但還有一種內容特別難寫

今天正式回答了 Day 16 留下的懸念。寫作代理人前幾天已經寫過什麼、用過哪些版本的範例，這類跨篇一致性問題，是 Day 01 定案的內容漂移病灶在寫作階段的延伸型態，同一個病灶從單篇內部的語氣落差，放大成跨篇尺度上概念與版本的矛盾。

今天最核心的判斷是，跨篇一致性要靠 Day 05 已定案的全域錨點檔案這份共享記錄的延伸使用撐起來，而非仰賴寫作代理人自己記得。寫作代理人在逐段展開的節奏裡，動筆前查閱過去已使用的案例與版本，完稿後把新引入的內容回填進這份共享記錄，形成一個持續累積的迴圈。這與規劃代理人已經走過的同一種錯覺被破除的路徑相同，只是這次發生在寫作代理人身上。

架構、查證、程式碼正確性、跨篇狀態記憶，到今天都已經各自有了具體的機制。但還有一種特別難處理的內容類型尚未討論，篇幅較長或邏輯層次較深的段落，寫作代理人要如何維持論證的緊密度不鬆散，這個問題今天還沒有答案，將在下一篇正式揭曉。