Day 26：審查代理人的設計，扮演最嚴苛的讀者 結尾留下一句話，評判標準的來源今天確立了，但依據這些標準，具體要怎麼揪出事實幻覺這個病灶最頑固的殘留，技術文章裡語氣篤定卻早已過時或錯誤的技術細節，這件事今天還沒有答案，將在下一篇正式揭曉。今天要正面回答這件事。

答案卷有了，但還沒人示範怎麼對答案

Day 26 已經確立審查代理人的評判標準來自全域錨點檔案、風格指南與受眾畫像、對應這一篇的 Section Spec 這三份既定依據，不是憑空而來。同一篇也明確區分了「評判標準從哪裡來」與「具體查核哪些面向」是兩件不同的事，Day 26 只處理前者，並點名事實正確性、可讀性、格式一致性這些面向留給接下來幾天逐一展開。

今天要處理的，正是這條展開路徑的第一站，事實正確性這一項面向具體怎麼查。

在往下走之前，先把今天的任務範圍畫清楚。今天只設計事實正確性這一項面向的查核機制，不涉及可讀性或格式一致性，這些留給接下來幾天處理。

邊界畫過了，但怎麼做還是空白

Day 19：事實查證與撰寫的分工邊界 已經定案，寫作代理人的查證與審查代理人的查核，分野在於撰寫當下的單點查證與成文之後的整體複核，這兩個不同尺度，審查代理人負責後者。

同一篇也舉過一個具體情境。一篇技術文章中段描述某個訊息佇列元件保證訊息不會重複消費，這句話在該段落當下查證屬實；後段又建議搭配多個消費者並行處理，單獨看也查證屬實；但兩段合起來讀，前段的保證在後段情境下其實需要額外前提才成立，兩段合起來看已經產生矛盾。這種問題只有跳脫逐段展開的視角、通篇檢視時才會浮現。

Day 19 只回答了審查代理人查核的範圍是什麼，撰寫當下的單點查證交給寫作代理人，成文之後的整體複核交給審查代理人。但審查代理人做這個全文尺度複核時具體用什麼方法，Day 19 沒有回答，這正是今天要正式補上的一塊。

兩階段機制，先列清單，再逐項對答案

審查代理人查核成品事實正確性的機制，分兩個階段。

第一階段，全文掃描。審查代理人逐句檢視成品，列出所有具時效性或版本相關的技術宣稱清單，也就是所有語氣篤定地描述某個函式、某個語法、某個做法目前仍然正確或仍是最佳實務的句子。舉例來說，一篇成品讀完之後，這份清單裡可能同時出現某個框架的 API 呼叫方式、某個工具的指令參數、某段被描述成目前最佳實務的做法，這三類都屬於具時效性或版本相關的技術宣稱，都會被收進同一份清單。

第二階段，交叉比對。針對清單裡每一項技術宣稱，審查代理人主動呼叫外部即時查詢管道，搜尋該技術宣稱對應的官方文件、釋出說明或近期討論，確認這句話在現在這個時間點是否依然成立。延續前面的例子，假設清單裡某一項在近期版本已被標示為不建議使用，這項落差就會被記錄下來，並精準指向對應段落。

一旦比對出落差，產出的問題回饋須精準指向對應段落與具體宣稱本身，呼應 Day 03 零容錯結構一項的既定措辭，審查代理人發現問題時只需精準指向對應段落與角色，不必要求整篇重寫。

這個機制之所以能發現 Day 19 舉例過的那種矛盾，正是因為第一階段先通篇列出清單，而不是逐段個別查證，才有機會在第二階段把分散在不同段落、各自查證都成立的宣稱放在一起比對。回到 Day 19 那個訊息佇列元件的例子，寫作代理人展開中段時查證「不會重複消費」屬實，展開後段時查證「多消費者並行處理」也屬實，兩次查證都各自成立，問題正是出在沒有人把這兩句放在一起讀過。今天設計的機制，第一階段會把這兩句技術宣稱同時收進同一份清單，第二階段逐項交叉比對時，這兩項宣稱擺在一起，前段保證在後段情境下需要額外前提才成立這件事，就有機會在通篇檢視時被揪出來。這正是全文尺度的機制才具備、單點查證顧不到的能力。

這不是 ReAct 模式的重播

這裡需要正面處理一個容易被誤解的直覺。讀者可能會以為，今天講的事實查核機制，就是 Day 15：結合即時查證，讓寫作代理人自己查資料 定案的 ReAct 模式換個角色重講一次。這個直覺需要被糾正。

先重申 Day 15 定案的 ReAct 模式，確切定義是讓寫作代理人交錯執行推理與外部查詢動作的工作模式。這個查詢動作，隨著寫作代理人展開某一段落而觸發，查證對象是正在被寫下的這一句，範圍受限於當下正在處理的局部段落。

再看今天設計的機制。它發生在全文已經成形之後，先通篇列出清單再逐一查證，涵蓋的是全文所有段落而非單一段落。

收束這個差異的關鍵，一個是隨寫隨查的單句尺度機制，觸發時間點鑲嵌在逐段展開的過程裡；一個是成文後才啟動的全文尺度機制，觸發時間點在文章已經寫完之後。兩者分別對應 Day 19 定案的撰寫當下與成文之後這兩個不同尺度，互補而非重疊，不是同一套東西的重複描述。

這道防線，Day 03 早就寫好了

Day 03：拆解寫作工作流，規劃、撰寫、視覺、審查的四種角色 定案的病灶對照表裡，事實幻覺一項的既定措辭是，寫作代理人在撰寫過程中查證技術細節是否過時，審查代理人在成品完成後再做一輪複核，形成兩道防線。

今天設計的兩階段機制，正是第二道防線具體長什麼樣子。全文掃描找出所有具時效性宣稱，交叉比對外部即時資訊確認是否依然成立，這就是「審查代理人在成品完成後再做一輪複核」這句話的具體實踐方式。

今天把 Day 03 早已定案的「再做一輪複核」這句話，具體展開成一套可操作的機制，不是重新分配病灶責任。

比對出落差之後呢

今天正面回答了 Day 26 留下的伏筆，評判標準的來源確立之後，具體要怎麼揪出事實幻覺這個病灶最頑固的殘留，今天正式給出答案。審查代理人查核事實正確性的機制分兩階段，第一階段全文掃描，逐句檢視成品，列出所有具時效性或版本相關的技術宣稱清單，第二階段交叉比對，針對清單裡每一項技術宣稱，主動呼叫外部即時查詢管道，確認這句話在現在這個時間點是否依然成立，一旦比對出落差，產出的問題回饋精準指向對應段落與具體宣稱本身，不必要求整篇重寫。

這個機制不是 Day 15 定案的 ReAct 模式的重播，ReAct 模式隨寫作代理人展開某一段落而觸發，查證對象是正在被寫下的這一句，範圍受限於當下正在處理的局部段落，今天設計的機制發生在全文已經成形之後，先通篇列出清單再逐一查證，涵蓋的是全文所有段落，兩者分別對應 Day 19 定案的撰寫當下與成文之後這兩個不同尺度，互補而非重疊。

今天也正面回應了 Day 03 病灶對照表裡事實幻覺一項既定的兩道防線描述，把「審查代理人在成品完成後再做一輪複核」這句話，具體展開成一套可操作的機制。

事實查核機制今天有了，但審查代理人比對出落差之後，什麼情況下這個落差足以自動判定並打回，什麼情況下反而應該交由人類做最終判斷，這件事今天還沒有答案，將在下一篇正式揭曉。