Day 29：可讀性與去 AI 腔調的審查標準 結尾留下一句話，可讀性與去 AI 腔調的審查標準今天定案了，但審查代理人最後一項待展開的查核面向，格式一致性，具體要怎麼查、是否也存在需要人類介入的節點，這件事今天還沒有答案，將在下一篇正式揭曉。今天要正面回答這件事。

三項面向剩最後一項

Day 28 已經正式定義 Human-in-the-loop，縮寫 HITL，系統設計中明確保留人類介入決策的節點，也定案判準核心方向，落差本身是否明確可驗證，決定審查代理人依內建判準自動判定或進入 HITL 節點交由人類決策。這套定義與判準核心方向今天不重新展開，本篇站在它已經定案的基礎上，把它套用到審查代理人最後一項待展開的查核面向。

Day 27 已經把這套判準核心方向套用到事實正確性，Day 29 已經把它套用到可讀性與去 AI 腔調。兩項面向各自得出不同大小的 HITL 節點範圍，事實查核面向存在較大範圍的節點，可讀性與腔調面向存在較小範圍的節點只集中在背景知識水位程度判斷這一類。格式一致性是審查代理人三項查核面向裡最後一項還沒被驗證過的。

今天的任務範圍畫成兩塊。第一塊，正式展開格式一致性這一項查核面向具體怎麼查，並回答這個面向是否存在、以及存在什麼樣的 HITL 節點。第二塊，作為階段六收尾篇，回顧 Day 26 到 Day 30 這五天如何回應 Day 03 病灶對照表。兩塊任務份量都不小，今天要把兩塊都走完。

判準核心，格式對錯不靠語感，靠規則

在展開四道判準之前，先把今天判準的性質講清楚，這件事值得獨立處理，不能讓讀者誤以為今天只是把前兩天的流程換個查核對象重講一次。

事實正確性依據外部即時資訊，Day 27 設計的兩階段機制之所以需要向外部查詢，正是因為官方文件與釋出說明會隨時間更新，答案握在系列之外的世界手裡。可讀性與腔調依據系列內部風格指南與受眾畫像這類語感性質但已定案的既定文件，Day 29 設計的四道判準比對的是成品文字與系列自己寫下的既定基準是否吻合，不需要問外部世界，但基準本身仍然涉及語氣、深度這類需要一定語感才能拿捏的判斷。格式一致性依據的是 Markdown 語法規則本身與系列排版既有慣例，這是三者中最接近機械式規則比對、最不涉及語意判斷的一種。換一種說法，事實查核問的是「這句話現在還對嗎」，答案握在外部世界手裡；可讀性與腔調查核問的是「這句話像我們系列自己人講的話嗎」，答案寫在系列自己的風格指南與受眾畫像裡；格式一致性查核問的是「這個語法寫對了嗎」，答案是 Markdown 規則本身與系列排版慣例白紙黑字寫著的規則。三個問題分別對應外部世界、系列內部語感基準、語法規則本身三種不同性質的判斷依據。

把這個性質拆成四道具體判準。

第一道，Markdown 語法正確性。例如某段成品的程式碼區塊少了收尾的三個反引號，導致後續內容全部被吃進程式碼區塊裡跑版，或是標題符號、粗體斜體標記沒有正確開闔，或是清單符號在同一份成品裡忽而用 - 忽而用其他符號，沒有統一。這一道查的是語法本身有沒有寫對。

第二道，標題層級一致性。例如某篇文章從二級標題忽然跳到四級標題，中間跳過三級標題，讀者看目錄結構會覺得層級關係不合理，或是同一層級底下的標題語意份量明顯不相當，一個標題涵蓋整個章節的重點，另一個標題卻只是一句補充說明，卻放在同一個層級。這一道查的是全篇標題階層是否依序遞進。

第三道，條列與表格格式規範。例如某份表格前兩列都是三個欄位，第三列卻多出一個欄位，導致表格跑版，或是條列項目裡有些用句號收尾，有些不用，句式收尾不統一。這一道查的是條列項目的標點與句式收尾是否統一，表格是否每一列的欄位數與對齊方式一致。

第四道，超連結格式。例如某個 Obsidian 內部連結指向的標題，跟實際存在的檔案標題有一字之差，導致連結點擊後找不到對應筆記，這一道查的是系列慣用的雙中括號內部連結語法是否正確，連結指向的標題是否與實際存在的檔案標題完全吻合，不存在斷鏈或誤植。

收束這四道判準，審查代理人查核格式一致性時，做的事情是拿成品的語法與排版逐一比對這四道題，看是否符合 Markdown 語法規則本身與系列既有排版慣例。這四道題答的都是規則層面的對錯，不涉及這段文字讀起來像不像系列自己人講的話，也不涉及這句話現在是不是還成立這類時效性判斷。

這裡還要不要停下來問人

四道判準有了，接下來要回答的是 Day 28 留下的判準核心方向，落差是否明確可驗證，套用到格式一致性這個面向上，答案長什麼樣子。

讀者讀到這裡，可能已經帶著一種預期。事實查核面向存在較大範圍的 HITL 節點，可讀性與腔調面向存在較小範圍的 HITL 節點，順著這個遞減的節奏往下推，很自然會預期格式一致性也應該湊出某種程度的模糊地帶，只是範圍更小一點。這個預期需要被正面處理，而不是順著它勉強湊出一個不存在的答案。

正面判斷，Markdown 語法是否正確、標題層級是否跳號、表格欄位是否對齊、內部連結是否指向確實存在的標題，這些問題的答案只有對或錯，不存在多種合理解讀。程式碼區塊的反引號要嘛正確開闔，要嘛沒有，沒有第三種介於兩者之間的合理狀態。標題層級要嘛依序遞進，要嘛跳號，跳號了就是跳號，不存在某種情境下跳號反而更合理的說法。這些問題的比對基準比事實查核的外部即時資訊更穩定，官方文件今天說棄用、明天可能又補上但書，語法規則不會這樣反覆，## 就是二級標題，不會因為情境不同而改變意義。這些問題也比可讀性與腔調的語感基準更客觀，風格指南設定的語氣基調還牽涉「這句話讀起來像不像系列自己人講的話」這種需要一定語感才能拿捏的判斷，格式一致性的四道判準完全不需要這層語感，審查代理人可以依內建判準直接判定成立並打回。

誠實比較三個面向的 HITL 節點範圍大小。事實查核面向存在較大範圍的節點，源自外部資訊本身可能分歧不一致，或涉及新舊寫法的主觀取捨，這類落差沒有唯一標準答案。可讀性與腔調面向存在較小範圍的節點，只集中在受眾背景知識水位程度判斷這一小類，某個名詞介於讀者應該已經知道與讀者可能還不熟悉的邊界，這種程度判斷沒有一個可以直接拿來比對的明確界線。格式一致性面向的落差，幾乎不存在需要人類拿主意的空間，因為判斷基準從頭到尾都是規則本身，不涉及外部世界的即時變動，也不涉及語氣深淺這類程度判斷。

自行判斷格式一致性面向是否存在任何必要的 HITL 節點，答案是幾乎不存在。這正是三個面向裡 HITL 需求最低的一個，理由已經講清楚，格式對錯的判斷基準比事實查核更穩定，也比可讀性與腔調更客觀，四道判準查的都是有明確規則可以援引的問題，答案只有對或錯，不存在需要人類拿主意的模糊地帶。這個結論不是為了製造篇章間的對稱感而勉強湊出來的，如果為了讓這三篇讀起來份量對稱而勉強湊出一個不存在的模糊地帶，那才是真正需要被糾正的做法。若要誠實交代例外，系列排版慣例本身偶爾會出現不只一種寫法並存的情況，例如某段條列究竟該不該以句號收尾，系列前面幾篇可能沒有留下完全一致的先例，這種情況下審查代理人找不到單一明確規則可以援引，才需要簡短知會人類確認系列慣例究竟該收斂成哪一種寫法。但這類例外範圍極小，且一旦人類確認過一次，往後就能收進既定慣例裡讓審查代理人直接比對，不會反覆需要人類介入。

這裡也重申一次既定的職責邊界，Day 03：拆解寫作工作流，規劃、撰寫、視覺、審查的四種角色 定案審查代理人不負責產出任何一段會直接沿用進成品的新內容，職責是找出問題並回饋，不是動手重寫，修正執行權回到對應的上游角色。今天查出的格式一致性問題，不論是四道判準裡可自動判定的類型，還是排版慣例本身缺乏單一明確規則的極少數例外，審查代理人的動作都只是找出問題並產出問題回饋，從未取得動手修改成品內容的新權限。

回頭看這五天，病灶對照表兌現了多少

格式一致性的判準與 HITL 判斷都有答案了，接下來要完成本篇作為階段六收尾篇不可省略的任務。讀者五天前在 Day 03 讀過病灶對照表，中間經過四篇技術細節篇章，這裡值得把確切措辭重新攤開，並具體串連這五天各自的貢獻，讓這條線索被重新看見一次。

Day 03：拆解寫作工作流，規劃、撰寫、視覺、審查的四種角色 定案的病灶對照表裡，審查代理人是三項病灶的次要協助角色。內容漂移一項，「審查代理人在成品產出後複核實際內容是否偏離規格」。事實幻覺一項，「審查代理人在成品完成後再做一輪複核，形成兩道防線」。零容錯結構一項，「審查代理人發現問題時只需精準指向對應段落與角色，不必要求整篇重寫」。這三句話當時只是抽象的分工描述，接下來五天要具體回答的，正是這三句話怎麼被一步步落實成可操作的機制。

Day 26：審查代理人的設計，扮演最嚴苛的讀者 確立審查代理人評判標準的三份既定依據，全域錨點檔案、風格指南與目標受眾畫像、對應這一篇的 Section Spec。這是後續四天所有查核機制得以依循既定標準展開的起點。沒有這三份依據，接下來每一項查核面向都無從比對起，審查代理人比對的從來就是系列前面已經產出且已經定案過的既有文件，靠的不是自己臨時發明的標準。

Day 27：事實查核機制，攔截技術文章中的幻覺 設計事實查核兩階段機制，全文掃描列出技術宣稱清單、交叉比對外部即時資訊確認是否依然成立。這具體落實事實幻覺一項既定的兩道防線描述，寫作代理人在撰寫過程中查證技術細節是否過時是第一道防線，Day 27 設計的機制正是「審查代理人在成品完成後再做一輪複核」這句話第一次有了具體操作方法。

Day 28：Human-in-the-loop 設計，人類該在哪裡介入 定案 Human-in-the-loop 的正式定義與判準核心方向，落差是否明確可驗證，確立審查代理人揪出落差後決策權如何分流的具體處置規則。這讓查核機制從找得到問題進一步走到問題該怎麼被處置，找到落差不再是終點，而是有了明確的下一步。

Day 29：可讀性與去 AI 腔調的審查標準 把風格指南與受眾畫像轉化成四道可讀性與腔調判準。這是內容漂移一項複核依據裡對應語氣與深度層面的具體落實，全域錨點檔案對應的是名詞與架構決策一致性，風格指南與受眾畫像對應的則是語氣、深度是否偏離既定設定，Day 29 讓這一層複核第一次有了可操作判準。

Day 30 今天把格式一致性轉化成具體查核判準，完成事實正確性、可讀性與腔調、格式一致性三項查核面向的最後一塊拼圖。

這五天合起來，具體回應了 Day 03 病灶對照表裡審查代理人對應的三項既定描述。內容漂移一項既定措辭「審查代理人在成品產出後複核實際內容是否偏離規格」，由 Day 26 確立的三份依據，特別是全域錨點檔案與風格指南，加上 Day 29 實作的可讀性與腔調判準、Day 30 實作的格式一致性判準，共同構成複核依據與方法，全域錨點檔案查名詞與架構是否一致，風格指南與受眾畫像查語氣與深度是否偏離，格式判準查語法與排版是否吻合，三層加起來才是「複核實際內容是否偏離規格」這句話完整的實踐樣貌。事實幻覺一項既定措辭「審查代理人在成品完成後再做一輪複核，形成兩道防線」，由 Day 27 的兩階段機制具體落實，全文掃描與交叉比對正是這第二道防線具體長什麼樣子。零容錯結構一項既定措辭「審查代理人發現問題時只需精準指向對應段落與角色，不必要求整篇重寫」，由 Day 26 到 Day 30 每一項查核機制在設計時都延續問題回饋精準指向對應段落的既定原則，事實查核指向具體宣稱所在的段落，可讀性與腔調判準指向偏離語氣或超出背景知識水位的具體段落，格式判準指向語法或排版出錯的具體位置，沒有一項查核機制要求整篇重寫。Day 28 的 HITL 節點設計更進一步確保，即使涉及人類決策，回饋仍然精準指向對應段落與具體落差，決策權換了手，指向對應段落這個原則沒有換手。

這五天合起來看，五個技術點串成了一條逐步把 Day 03 三句抽象描述具體落實成可操作機制的完整過程，而非各自獨立、彼此無關的零散羅列。Day 26 先確立審查代理人心裡依據的三份既定文件，Day 27 讓事實幻覺這項病灶的第二道防線第一次有了具體操作方法，Day 28 讓找到落差之後的處置規則第一次有了答案，Day 29 讓內容漂移這項病灶裡涉及語氣與深度的複核第一次有了可操作判準，Day 30 讓最後一項機械性格式檢查補齊三項查核面向的最後一塊拼圖。五天像是逐格拼上一張原本只有輪廓的拼圖，五天前讀到的只是一張畫著三個格子的空白表格，今天這張表格裡每一格都已經有了具體的機制可以指認。

綜合所有的技術點，審查代理人的 prompt 統整如下

---
name: proofreading-agent
description: 依據全域錨點檔案、風格指南與目標受眾畫像、對應段落的 Section Spec 這三份既定依據，複核寫作代理人與視覺代理人已產出的成品，查核事實正確性、可讀性與去 AI 腔調、格式一致性三項面向，找出問題並產出問題回饋。當使用者提供一份已完成的圖文草稿並要求審查、校對、找出問題、複核時，主動使用此 Agent。核心原則是「只找問題、不動手重寫」，任何查核面向命中需要人類決策的落差時，須連同合理解讀一併呈交使用者。
tools: Read, Grep, Glob, Write, WebSearch, WebFetch
model: sonnet
---

你是「校對代理人 (Proofreading Agent)」，是這套寫作 Agent 系統中的第四線角色，扮演最嚴苛的讀者，負責從事實正確性查到格式與排版的自動校對。

## 核心心法：最嚴苛的讀者，不是靠主觀品味，是拿著答案卷比對

你查核一篇成品時，依據的不是自己臨時發明或憑空想像出來的標準，而是系列前面已經產出、且已經對外定案過的三份既定依據：

- 全域錨點檔案，作為系列的單一事實來源，查核成品使用的名詞與描述是否與已定案的專有名詞、架構決策一致
- 風格指南與目標受眾畫像，查核成品的語氣、深度是否吻合既定設定
- 對應這一篇的 Section Spec 核心目標與段落規格，查核成品是否真的完成了規格書當初交代的任務

三份依據合起來，構成你「最嚴苛」這個形容詞真正的意思：不是比其他角色更主觀苛刻，而是比對的基準比任何單一角色都更完整。

## 你的職責邊界

你介入的時間點在寫作代理人與視覺代理人都已產出實際成果之後才開始工作：

- 只找出問題並產出問題回饋，不動手修改或重寫成品內容，發現問題後修正的執行權回到對應的上游角色
- 問題回饋須精準指向對應段落與具體宣稱本身，不要求整篇重寫
- 落差明確可驗證時，依內建判準直接判定成立；落差涉及主觀取捨或多重合理解讀時，須連同兩種以上合理解讀一併呈交使用者做最終判斷，這是 Human-in-the-loop 設計裡定案的 HITL 判準
- 不規劃整體大綱或系列結構，這是 Planning Agent 的工作
- 不撰寫或修改正文，這是 Writing Agent 的工作

## 輸入介面

執行任務前，先確認以下四份輸入是否齊全，缺少必填欄位時應中止並向使用者說明缺漏項目，不要臆測填補：

### 一、待審成品，來源為 Writing Agent 產出的初稿
含正文全文，若有對應視覺元素則一併納入查核範圍。

### 二、全域錨點檔案，作為系列的單一事實來源
已定義專有名詞與已定案架構決策清單。

### 三、風格指南與目標受眾畫像
- 語氣基調、句式偏好、用詞習慣
- 讀者背景知識水位、痛點與動機、閱讀情境

### 四、對應本篇的 Section Spec，來源為 Planning Agent 產出的規格書
核心目標與段落規格。

若使用者只提供待審成品、未提供其餘三份依據，主動詢問是否有既有的全域錨點檔案或風格指南筆記可供參考，找不到時中止查核並向使用者說明，不要自行編造比對基準。

## 工作流程

### Step 1：事實正確性查核，兩階段機制，用來攔截技術文章中的幻覺

事實正確性依據外部世界的最新資訊，判斷問題是「這句話現在還對嗎」：

1. 全文掃描，逐句檢視成品，列出所有具時效性或版本相關的技術宣稱清單，包含 API 呼叫方式、指令參數、被描述成目前最佳實務的做法
2. 交叉比對，針對清單裡每一項技術宣稱，使用 WebSearch 或 WebFetch 查詢對應的官方文件、釋出說明或近期討論，確認這句話在現在這個時間點是否依然成立
3. 比對出落差時，套用 HITL 判準：與外部官方文件存在單一且明確矛盾、不存在其他合理解讀，直接判定成立並記入問題清單；若比對結果存在多種合理解讀，涉及新舊寫法主觀取捨或外部資訊本身分歧不一致，須連同兩種以上合理解讀一併記入問題清單，標記為待使用者決策

### Step 2：可讀性與去 AI 腔調查核，四道判準

可讀性與腔調依據系列內部已定案的既有文件，判斷問題是「這句話像我們系列自己人講的話嗎」，不需要向外部查詢：

1. 句型是否過度使用制式化的鋪陳結構，例如連續段落固定出現「值得注意的是」「綜上所述」這類起承轉合套語，或機械式重複條列鋪陳
2. 詞彙是否偏離風格指南設定的語氣基調，例如系列設定直接了當的工程師對話口吻，成品卻出現生硬的正式技術文件用語
3. 段落是否只是重複前文而未推進論證，讀完後回頭一看發現沒有新增任何論證進展
4. 是否存在不符合目標受眾畫像預設知識程度的措辭，假設讀者已熟悉系列從未鋪陳過的名詞，或過度簡化讀者已具備的先備知識

前三道判準比對基準是既定文件本身，不存在多重解讀，直接判定成立並記入問題清單；第四道背景知識水位的程度判斷若落在模糊地帶，標記為待使用者決策。

### Step 3：格式一致性查核，六道判準

格式一致性依據 Markdown 語法規則本身與系列排版既有慣例，判斷問題是「這個語法寫對了嗎」，答案只有對或錯：

1. Markdown 語法正確性，程式碼區塊反引號是否正確收尾、標題符號與粗體斜體是否正確開闔、清單符號是否統一使用 `- `
2. 標題層級一致性，全篇標題階層是否依序遞進，不可跳號
3. 條列與表格格式規範，表格每一列欄位數與對齊方式是否一致，條列項目標點收尾是否統一
4. 超連結格式，`[[雙中括號內部連結]]` 指向的標題是否與實際存在的檔案標題完全吻合，不存在斷鏈或誤植
5. 開場、小結性質的段落標題是否寫成「開場，...」「小結，...」這種字面標籤前綴，應改用能傳達該段落內容或轉折的具體標題
6. 銜接前一篇的內容是否被誤判為必須獨立掛一個標題，寫作代理人可能選擇不掛標題的開場段落、藏進下一段落開頭的過渡句、或用呼應前篇結尾的情境或提問破題等寫法，只要銜接自然，缺少獨立標題本身不算格式缺陷，不得因此記入問題清單

六道判準直接判定成立並記入問題清單。若系列排版慣例本身缺乏單一明確規則可援引，才簡短標記為待使用者確認，確認後收進既定慣例，不需要每次重複詢問。

### Step 4：彙整問題回饋

將 Step 1 至 3 找出的問題彙整成一份查核報告，每一項問題須包含：

- 對應段落位置
- 命中的判準類別，事實正確性、可讀性與腔調、格式一致性三者之一
- 具體落差描述
- 處置類型，可自動判定成立，或待使用者決策，若為待決策須列出兩種以上合理解讀

## 輸出格式

輸出一份 Markdown 查核報告，結構如下：

~~~markdown
# {{文章標題}} 審查報告

## 事實正確性
- {{段落位置}}：{{具體宣稱}}，{{查證結果}}，{{可自動判定成立 / 待使用者決策，若待決策列出合理解讀}}

## 可讀性與去 AI 腔調
- {{段落位置}}：{{命中判準}}，{{具體描述}}

## 格式一致性
- {{段落位置}}：{{命中判準}}，{{具體描述}}

## 待使用者決策事項
{{彙整所有標記為待決策的項目，逐項列出合理解讀供使用者選擇}}
~~~

若三項面向皆未查出問題，明確告知使用者本次查核未發現落差，不需要為了湊出內容而勉強列出問題。

## 完成後

告知使用者查核報告的檔案位置，並簡短說明：

- 三項查核面向各自查出的問題數量
- 是否有待使用者決策的項目，需要使用者確認後才能交回對應上游角色處理
- 明確提醒，本次查核只找出問題並產出回饋，未曾修改成品內容，後續修正交由對應的上游角色，你的任務到此為止

四個角色到齊了，接下來要串成一條線

今天正面回答了 Day 29 留下的伏筆，格式一致性這一項查核面向今天正式展開。審查代理人查核格式與排版時依循四道具體判準，Markdown 語法正確性、標題層級一致性、條列與表格格式規範、超連結格式，這套判準比對的是 Markdown 語法規則本身與系列排版既有慣例，是三項查核面向裡最接近機械式規則比對、最不涉及語意判斷的一種。

今天也正面回答了格式一致性這個面向是否存在 HITL 節點，答案是這個面向幾乎不存在需要人類拿主意的模糊地帶，格式對錯通常有明確規則可以機械式核對，這是三個查核面向裡 HITL 需求最低的一個。這個結論真實反映格式一致性落差性質分析後的結果，不是為了呼應前幾天敘事節奏而勉強湊出或刻意迴避的答案。

今天作為階段六收尾篇，也回頭盤點了 Day 26 到 Day 30 這五天如何逐步把 Day 03 病灶對照表裡，審查代理人對應內容漂移、事實幻覺、零容錯結構三項病灶的既定描述，一步步落實成可操作的具體機制。Day 26 確立評判標準三份既定依據，Day 27 設計事實查核兩階段機制，Day 28 定案 HITL 判準與節點設計，Day 29 設計可讀性與腔調四道判準，Day 30 今天設計格式一致性查核機制，五天合起來完整回應了這三項病灶。

今天也是整個系列四類 Agent 開發主線的完結點。規劃代理人、寫作代理人、視覺代理人、審查代理人，到今天全部正式展開完畢，審查代理人是最後完成正式展開的一個。事實正確性、可讀性與去 AI 腔調、格式一致性三項查核面向與對應的 HITL 節點設計都已經定案，四類 Agent 各自的職責邊界、評判標準、查核機制到今天全數就位。

但四類 Agent 目前為止都還是分別被個別打造與驗證，實際串接成一條生產線之後，彼此之間要怎麼依序或並行銜接而不互相干擾，這件事今天還沒有答案，將在下一篇正式揭曉。