這件事很像改申論題。學生寫得文情並茂，老師還是得對著評分標準看：題目要的四個要點，他答到幾個？丟一句「寫得不錯，85 分」，下次要告訴他哪裡該補，就說不出口了。
這篇給你可以直接拿去用的規格：怎麼拆要點、五種狀態的判定條件、要留哪些欄位、兩種摘要公式，以及分母怎麼寫才不會把「還沒讀完」講成「內容已經完整」。
要把回答要點接進整套可見度指標，可看AI 可見度資料契約。
拿一題來看。使用者問「台灣 SEO 公司怎麼選？」AI 回答提到了三個品牌，卻沒有說明服務範圍、怎麼確認成果、資料有什麼限制。只算品牌有沒有出現，這題看起來完成了；拆成四個要點，可能只有「有列候選」是 complete，其餘是 absent 或 partial。有品牌提及、有引用來源，覆蓋仍然只是部分。
先定義：Coverage 和品牌提及不同
四種判讀各自回答一個問題：品牌提及問「名字有沒有出現」，引用問「回答有沒有呈現來源」，推薦問「品牌有沒有進入選擇情境、有沒有條件或理由」，Coverage 問「這個回答有沒有處理使用者指定的資訊要點」。四者可以同時成立，也可以各自成立。
拿上面那個例子攤開來看。題目是：「請比較適合 20 人 B2B 團隊的 AI 搜尋觀測工具，說明主要觀測內容、資料保存方式、導入限制和適用情境。」回答提到 Otlex，附了一個產品頁來源——這代表品牌事件和來源事件都成立。至於資料保存方式和導入限制沒有說明，Coverage 就停在 partial；來源看起來正式，跟要點有沒有被處理是兩件事。
Coverage 量的是「回答有沒有處理指定範圍」；內容正不正確、會不會影響排名，要另外查。
還有一個容易混掉的地方：這篇說的 Coverage 專指「回答內容要點覆蓋」，分母是已判定且適用的要點。另一份報告若要回答「預定觀測有多少次成功拿到可判讀回答」，那是執行覆蓋，要用有效完成執行數除以預定執行數。兩個名字一樣、分母完全不同，合在一起就沒人看得懂了。
回答覆蓋應逐點保留完整、部分、缺漏與尚未判定狀態。
拆解問題：怎麼把一句 prompt 變成要點
先找問題中的任務動詞
先圈出問題要求的動作：定義、比較、選擇、列出、解釋、估算或提出步驟。不同動作要的要點不一樣——「比較 A 與 B」要的是共同比較面向，「如何導入」要的是步驟、前置條件與限制。
要避開的捷徑是拿文章標題當覆蓋規則。標題通常沒把使用者的條件寫完整，照標題拆出來的要點會漏掉最關鍵的那幾項。
再找名詞、條件和輸出格式
把問題拆成四類欄位：
| 類型 | 要問的問題 | 例子 |
|---|---|---|
| 主題 | 回答在談什麼 | AI 搜尋觀測工具 |
| 條件 | 什麼情況下才適用 | 20 人 B2B 團隊、繁中、台灣 |
| 比較面向 | 必須比較哪些事 | 觀測內容、資料保存、限制 |
| 輸出要求 | 回答要用什麼形式 | 先給結論、再列步驟與取捨 |
每個欄位不必都變成一個要點，但要先決定哪些不可缺。舉例來說，「台灣」若只是題目的語境、不是要比較的條件，就把它留在 prompt metadata 裡，別列成要點——否則審核者會以為回答漏了一項。
用最小可核對單位，不要做無限細的清單
判斷要點切得對不對，有個簡單的檢驗：換一個審核者，他能不能用一句話回答「有、部分、沒有，還是看不出來」？
一個要點包了五件事實，兩個人判出來會不一樣；每個句子都拆成一點，分數就被文字細節牽著走。實務上先做 3 到 7 個要點，重複審核幾輪之後再修規則，版本變更留日期。
Answer Coverage 量測方法：完整、部分、錯置與尚未判定
建議使用五種狀態
| 狀態 | 判定條件 | 是否算有覆蓋 | 審核記錄 |
|---|---|---|---|
| complete | 回答直接處理要點，內容與題目條件一致 | 是 | 摘錄相關句或段落 |
| partial | 只處理要點的一部分，或缺一項必要條件 | 部分 | 說明缺哪一段 |
| absent | 可讀回答沒有處理該要點 | 否 | 留下要點與回答位置 |
| misplaced | 有相關文字，但回答指向不同問題或條件 | 否，另列錯置 | 說明為何不符合 |
| 尚未判定 | 回答截斷、來源或上下文不足，無法判定 | 不納入已判定分母 | 記錄缺失原因 |
misplaced 就是答非所問：你問「怎麼導入」，回答花了一整段講價格方案。有文字、看起來也相關，判讀上和沒寫一樣，但要另外列，因為它反映的是題目或內容的方向偏了。
absent 和「尚未判定」的分別更關鍵。回答完整可讀、就是沒提導入限制，那是 absent；回答只拿到一段截斷文字，後文有沒有講不知道，那是尚未判定——像考卷第二頁影印糊掉，你不能當作他沒寫。把尚未判定算成 absent 會誇大缺口，算成 complete 則是虛增覆蓋。
規則要寫成可審核句子
「回答得不錯」複核不了。改寫成這樣才行：
若回答明確說明資料保存方式，且沒有把保存期限或保留位置誤寫成另一項功能，標記為 complete；只提到可觀測、未交代保存，標記為 partial。
一條可用的規則要有三件事：通過條件、排除條件，以及遇到資料不足時該落在哪個狀態。
內容完整不等於事實正確
一篇作文四段都答到題目，其中一段的年份寫錯了——結構完整，事實有誤。回答也會這樣：四個要點全部 complete，其中一項數字是錯的。
Coverage 量的是回答有沒有處理指定範圍，事實查核要另有來源與審核欄位。來源連結存在，也不自動保證每一句話都被那個來源支持；OpenAI 的 ChatGPT Search 說明提醒 citations 可能不完整、過時或錯誤，重要資訊仍要打開原始頁核對。
實作：建立可複核的 coverage 表
第一步，固定 prompt 和要點版本
給每個題目一個 prompt_id 和 prompt_version，再建立 coverage_spec_version。題目或要點改過就開新版本，舊紀錄留著。資料列至少包含：
answer_id 這筆回答的編號
prompt_id 題目編號
prompt_version 題目版本
coverage_spec_version 要點規格版本
engine 哪個引擎
observed_at 觀測時間
answer_status 這次有沒有拿到可讀回答
point_id 要點編號
point_text 要點內容
coverage_status complete／partial／absent／misplaced／尚未判定
evidence_excerpt 支持這個判讀的原文摘錄
reviewer_note 審核者備註一個回答有五個要點，就會產生五筆 point-level 判讀，再在回答層保留一個整體狀態。這樣報表既算得出回答層的完整覆蓋，也追得到是哪一個要點最常 absent 或 partial，後者才是拿去改內容的線索。
第二步，先讀問題，再遮掉品牌名稱做初判
論文審查會匿名，道理一樣。先只看問題與要點規格，把判定條件寫下來，再去讀回答，可以減少品牌印象的干擾。
實際會遇到兩種情況：回答列了一串知名品牌、卻漏掉條件，仍照要點狀態標；回答一個品牌都沒提、方法解釋得很完整，Coverage 仍然可以是 complete。
第三步，逐點標記並保留短證據
每個 point 留一段最短的可核對原文位置，或寫明「回答未提及」，不要只填一個總分。
來源 URL、回答原文和人工註記分開存。混在一起最常見的後果，是一個來源連結被當成所有要點的支持證據。
第四步，產生回答層摘要
可以先用一套保守規則：必要要點全部 complete 才算回答完整；至少一個 partial 且沒有 absent，標記部分；出現 absent，標記不完整；有尚未判定就另列待補。
題目若允許某個要點不適用，要在規格裡先寫 not_applicable。事後為了讓比例好看而把它刪掉，等於改了分母又沒留紀錄。
報告：怎麼比較不同回答
用要點矩陣找真正缺口
一張矩陣比單一總分更能說明下一步要改什麼：
| 要點 | complete | partial | absent | misplaced | 尚未判定 | 可執行下一步 |
|---|---|---|---|---|---|---|
| 適用團隊 | 補受眾條件 | |||||
| 核心觀測內容 | 檢查服務頁段落 | |||||
| 資料保存方式 | 補流程或限制 | |||||
| 導入限制 | 補邊界說明 |
表格中的空白是「尚未填入」，不是 0。輸出時至少同時顯示回答數、要點數、已判定要點數與尚未判定數。不同 prompt 的要點數不一樣時，把各答案的要點分數相加來比較，加出來的是兩把不同的尺。
兩種可用的摘要方式
第一種是回答完整率：
回答完整率 = 所有必要要點均為 complete 的有效回答數 ÷ 已完成要點審核的有效回答數第二種是要點覆蓋率：
要點覆蓋率 = complete 要點數 ÷ 已判定且適用的要點數兩種摘要都要把 partial、absent、misplaced 和 unknown 分開保存。報表至少同列四個數字：已判定且適用要點數、全部適用要點數、complete 數、尚未判定數。讀者才知道那個百分比描述的是哪一段資料。
這裡有個很容易出事的情況。假設題目規格有 100 個適用要點，目前只判了 1 個，而且那一點是 complete，另外 99 個還是 unknown。這時可以寫「已判定覆蓋率為 1/1，也就是 100%，尚有 99 個要點未判定」；寫成「整份題目已達 100% 覆蓋」就是把還沒讀完當成內容完整。正式摘要長這樣：
| 欄位 | 數值 | 讀法 |
|---|---|---|
| 全部適用要點 | 100 | 題目規格要求檢查的總數 |
| 已判定且適用 | 1 | 目前真的完成審核的分母 |
| complete | 1 | 已判定分母中的完整要點 |
尚未判定（unknown） | 99 | 仍缺回答上下文或人工判讀 |
| 已判定覆蓋率 | 1/1 = 100% | 只描述已判讀部分，不代表整體完成 |
要把尚未判定排除在外，就得在報表上寫出這條排除規則。另一種更保守的做法：尚未判定數大於零時只顯示狀態分布，不輸出「整體覆蓋率」，等所有適用要點都有狀態了，再算 complete ÷ 全部適用要點。
從缺口回到內容修改假設
「導入限制」在多數題目都是 absent 時，可以提出一個內容假設：服務頁缺少可引用的限制段落。
這是假設，不是 Coverage 表證明的原因。真正的檢查方式是改完內容後，用同一組 prompt、新的觀測日期重跑一輪，另外記下修改範圍，再看那一格的狀態有沒有動。
Coverage 量不到的東西
Coverage 做的事情很窄：把「回答有沒有處理預先指定的範圍」變成留得下證據的判讀。使用者滿不滿意、有沒有轉換、搜尋排名怎麼樣，都是另外的觀測層。要追蹤品牌提及、引用與推薦，看 AI Visibility 指標方法，別把所有事件塞進一個完整度分數。
Google 的文件說生成式 AI 搜尋仍然和可抓取、可索引、可顯示 snippet 這些基本條件有關，也提醒沒有保證一定出現；AI Overviews 和 AI Mode 用的模型與技術可能不同，回答和連結會變動。所以報告要記下介面和觀測條件，網站的 SEO 基礎也要顧，這跟某一題的 Coverage 是兩回事。
Search Console 的生成式 AI 成效報表能看到內容怎麼被 Google 的 AI 功能發現，但它不會替你保存每個 prompt 的要點判讀，Coverage 還是要回到回答原文和要點規格。
我們的 Otlex 是 EthorX 開發的 AI 搜尋優化平台，觀測 ChatGPT、Google AI Overview、Google AI Mode、Gemini、Grok、Perplexity、Claude 七個引擎回答中的提及、引用與推薦，並整理內容缺口。它幫你把回答原文和來源留下來核對；要點規格和判讀規則仍然是你自己定的。
接下來可以看什麼
還在整理事件欄位的，先看品牌提及和引用 FAQ；要決定固定的一組問題和觀測條件，看 AI 搜尋監測 prompt 選擇 FAQ。這兩頁分別處理事件分類與問題設計，這篇只管回答有沒有處理要點。
常見問題
Answer Coverage 和品牌提及率有什麼不同？
兩個問題不同。品牌提及率問的是品牌名字有沒有出現在回答文字裡，Answer Coverage 問的是回答有沒有處理題目指定的資訊要點。一段回答可以提到品牌卻漏掉限制和適用條件，也可以一個品牌都沒提、卻完整回答了一個方法題。兩者分開保存與計算。
一個要點只被回答一半，要算有還是沒有？
標成 partial，並寫清楚缺的是哪一段、回答有沒有達到這題的最低需求。團隊若真的需要單一完整率，可以把 partial 當成未完整處理，明細裡仍然保留 partial 的數量——不然下次要補內容時，就看不出「差一點」和「完全沒寫」的差別。
看見來源 URL，就能把相關要點標成 complete 嗎？
要再核對兩件事：回答文字有沒有真的處理那個要點，以及來源支不支持那一段內容。URL 只證明回答呈現了來源。OpenAI 也提醒搜尋引用可能不完整或錯誤，重要資訊要打開原始頁檢查。
題目有五個要點，回答只處理三個，Coverage 是 60% 嗎？
要同時滿足四個條件才寫得成 3/5：五個要點權重相同、三個狀態都是 complete、另兩個確實是 absent、分母規則事先寫好。裡面只要摻了 partial、尚未判定、不可適用或不同權重，就先呈現狀態分布與分母，再決定要不要用百分比。
可以用 AI 自動判讀 Coverage 嗎？
可以拿來做整理或初篩。我沒有證據說自動判讀在所有引擎、題型與語言下都可靠，所以規則、樣本、人工覆核與錯誤修正都要留下；重要報告交給一個沒驗證過的分類器，風險在於你不知道它錯在哪一類題目上。