Day 15：結合即時查證，讓寫作代理人自己查資料 結尾留下一句明確的懸念，光靠 ReAct 模式的查詢動作，是否就足夠保證程式碼真的能跑、版本真的正確。今天要正面回答這個問題，答案是否定的。

查詢有了，程式碼真的能跑嗎

寫作代理人已經具備 ReAct 模式，知道什麼時機該查、查到之後怎麼跟撰寫交錯進行，這是 Day 15 留下的成果。但查詢動作是否就足夠保證程式碼真的能跑、版本真的正確，Day 15 沒有回答，只留下這個問題等今天揭曉。

今天對這個問題的正面回答，答案是否定的。

查詢動作確實能降低程式碼過時或錯誤的機率，這是昨天已經確立、今天不會推翻的成果，但查詢動作不足以構成完整的正確性保證。查詢到的資訊本身仍可能被誤用、拼裝錯誤，或者查詢者本身沒有能力判斷查詢結果是否真的適用於當下情境。

在往下走之前，先把今天的任務範圍畫清楚。今天只處理程式碼範例的正確性保證機制本身，不涉及審查代理人這個角色，也不涉及長篇論證或公式推導這類非程式碼內容的撰寫策略，這些是後面天數的範疇。今天要交出的，是程式碼範例在查詢之上還需要疊加哪一層機制，才稱得上真正被保證正確。

程式碼沒有模糊地帶，對或錯立刻現形

先回答一個更根本的問題，為什麼程式碼範例值得被特別拿出來，單獨討論一套正確性保證機制。

技術文章裡有很多不同類型的內容，比方說：一段對架構取捨的說明、或一句對設計理念的評論。這些內容的正確與否，往往存在一定的模糊解讀空間。讀者可能同意，也可能有不同看法，但很難用一個簡單的動作立刻判定對錯。程式碼範例完全不是這麼一回事。它有明確的可執行或不可執行、對或錯的二元判準，不像其他技術描述可能存在模糊解讀空間。

這個二元判準帶來一個直接的後果，讀者只要把範例貼進自己的開發環境跑一次，對或錯立刻現形。這是所有技術內容類型裡驗證門檻最低、暴露速度最快的一種，錯誤不會被讀者的主觀解讀消化掉，而是直接以報錯訊息的形式呈現在讀者眼前，沒有任何模糊地帶可以閃躲。

這裡要扣回 Day 01：為什麼傳統的「一鍵生成」寫不出好的長篇技術文章？ 定案的注意力稀釋病灶。它的確切定義是，長篇技術文章需要同時處理宏觀邏輯推理與微觀細節，查證兩種性質完全不同的認知任務。模型的注意力被迫在兩者之間反覆切換，實務上常見的結果是模型傾向犧牲微觀細節、保全宏觀結構。程式碼範例正屬於這裡說的微觀細節。當模型的注意力被迫做出取捨，程式碼範例往往是第一批被犧牲的對象，一個函式庫版本演進導致舊語法與新語法混雜於同一範例的情境，正是 Day 01 談過的注意力稀釋會在程式碼上具體現形的地方。而程式碼範例的特殊之處在於，這種犧牲不會像其他微觀細節那樣悄悄潛伏，它會被讀者立刻、親手驗證出來，是這個病灶最具體、最容易被讀者親手驗證出來的受害戰場。

正因為程式碼的正確性判準如此明確、如此容易被讀者親手驗證，它才理應是全系列在正確性保證這件事上，投入最嚴格機制的一類內容。

查詢解決了一半，另一半還沒有答案

先肯定 Day 15 定案的 ReAct 模式查詢動作的價值。遇到版本號、API 語法、時效性技術細節時主動查詢，確實能大幅降低程式碼過時或錯誤的機率，這是昨天已經確立的成果，今天不推翻這個成果。

但查詢動作有它的侷限。第一個侷限，查詢到的資訊本身仍可能被誤用。舉個情境，寫作代理人查到了某個函式最新版本的正確參數順序，這個查詢結果本身完全正確，但寫作代理人在範例另一處呼叫同一個函式時，沿用了舊的參數順序，兩處寫法互相矛盾，整段範例組合起來無法執行。查詢結果本身沒有錯，錯的是拼裝的過程。

第二個侷限，查詢者本身沒有能力判斷查詢結果是否真的適用於當下情境。舉個情境，查詢到的資訊來自某個特定執行環境或特定版本組合的文件，但套用到範例當下設定的環境或版本組合時，其實並不適用。查詢動作本身只負責把資訊找回來，無法自動偵測這種適用性落差，查詢者若沒有能力判斷這一層落差，錯誤就會被原封不動地帶進範例裡。

把這兩個侷限收束成一句明確的區分，查詢解決的是這個寫法是否符合目前版本的官方建議，但不保證這段程式碼實際上能不能跑，這是兩個不同層次的問題，Day 15 的查詢動作只回答了前者。

追求可驗證的正確性，執行驗證這個方向

查詢只回答了一半的問題，今天要提出的解方方向是，程式碼範例應該追求可驗證的正確性，而非僅止於查詢到的資訊。查詢到的資訊終究只是參考依據，真正能證明一段程式碼是對的，只有讓它實際被驗證過一次。

具體可以朝執行驗證的方向設計。程式碼片段在納入正文前，應該經過某種形式的實際執行或語法檢查，而不是單靠查詢結果就直接採信。這裡不規定具體要用哪一種沙箱、哪一種執行環境或工具，交由實作時依當下條件決定，今天只定案這個原則方向，全篇維持在原則與工作模式層級論證。

這個驗證步驟該長在哪裡同樣重要。它不是額外獨立於既有流程之外的新環節，而是應該內建在寫作代理人逐段展開程式碼片段的流程裡，鑲嵌在 Day 14：寫作代理人的架構設計，從規格到草稿 定案的逐段展開架構與 Day 15：結合即時查證，讓寫作代理人自己查資料 定案的 ReAct 模式之上運作。

具體描述這個鑲嵌的樣貌。寫作代理人依序讀取每一則段落規格、只針對這一段要求的重點與前提展開內容，這是 Day 14 已經定案的節奏。當這一段的展開內容涉及程式碼片段，寫作代理人除了視情況觸發 ReAct 模式的查詢動作之外，在這段程式碼即將納入正文之前，會多一道確認這段程式碼是否真的站得住腳的關卡。通過這道關卡，撰寫才繼續往下走進入下一段，沒有通過，就回頭調整這段程式碼，直到它真正站得住腳為止。這個關卡發生在同一個段落展開的節奏裡，不是撰寫完成後另外跑一輪獨立於逐段展開之外的檢查流程。

查詢與驗證，缺一不可的兩道防線

查詢與執行驗證各自解決不同的問題。查詢解決的是這個寫法是否符合目前版本的官方建議，執行驗證解決的是這段程式碼實際上能不能跑。兩者是互補關係，不是彼此可以取代的關係。

只做查詢為什麼不夠。查詢到的寫法可能完全符合官方最新建議，但寫作代理人在組裝這段程式碼時，可能還是會出現變數命名衝突、語法拼接錯誤等問題。查詢無法攔截這類拼裝過程中產生的錯誤，因為查詢動作查的是單點的資訊是否正確，不是整段程式碼組合起來是否真的能跑。

只做執行驗證為什麼也不夠。一段程式碼即使能夠成功執行，也不代表它是官方建議的寫法。某個已被明確列為不建議使用的舊寫法，在語法層面往往依然可以正常執行，只做執行驗證會讓這類問題完全被放過。讀者跟著範例照做，程式碼確實能跑，但已經在使用一個隨時可能被棄用或存在潛在風險的寫法，這正是 Day 01 定案的一鍵生成同樣會踩到的陷阱，單一次推理、從指令直接到成品交付、過程中沒有任何檢查點，只是這裡換成了另一種形式的零檢查點，執行得動就當作沒問題。

兩者疊加才構成完整的正確性保證，缺一不可。這也是今天正面回答 Day 15 懸念的最終結論，光靠查詢動作不足以保證程式碼真的能跑、版本真的正確，還需要在查詢之上疊加執行驗證這一層。

程式碼有了把關，但系列記憶還是空白

今天正式回答了 Day 15 留下的懸念。程式碼範例是所有技術內容中最需要嚴格保證正確性的一類，正是注意力稀釋病灶最容易被讀者親手驗證出來的受害戰場。Day 15 的查詢動作能降低過時或錯誤的機率，但不足以保證程式碼真的能跑，還需要在查詢之上疊加執行驗證，這個驗證步驟鑲嵌在逐段展開架構與 ReAct 模式之上運作，而非額外獨立的流程。

今天完成的事，是把程式碼範例的正確性保證，從單靠查詢結果就直接採信，推進到查詢與執行驗證兩道防線並存的具體工作模式。查詢解決的是這個寫法是否符合目前版本的官方建議，執行驗證解決的是這段程式碼實際上能不能跑，兩者互補，缺一不可。

程式碼正確性今天有了保證機制，但如果寫作代理人不記得自己前幾天已經寫過什麼、用過哪些版本的範例，即使每一段程式碼在當下都是正確的，系列整體還是可能出現前後版本不一致或重複雷同的問題。這個問題今天還沒有答案，將在 《Day 17：狀態管理，讓寫作代理人記得前幾天寫過什麼》 正式揭曉。