Answer Coverage 量測方法：AI 回答重點覆蓋檢查

Answer Coverage 的量測方式，是先把使用者的問題拆成 3 到 7 個可核對要點，再逐點判斷回答做到什麼程度：complete、partial、absent、misplaced，或是資料不足的「尚未判定」。這適用於題目本身帶著明確資訊需求的觀測，例如比較題、方法題與決策題；題目或要點規格只要改版，那一輪就開新版本另存，別覆蓋舊紀錄。本文提供的是可以直接拿去用的規格：拆要點的方法、五種狀態各自的判定條件、可複核的資料欄位、兩種摘要公式，以及分母怎麼寫才不會把「還沒讀完」講成「內容已經完整」。

這件事很像改申論題。學生寫得文情並茂，老師還是得對著評分標準看：題目要的四個要點，他答到幾個？丟一句「寫得不錯，85 分」，下次要告訴他哪裡該補，就說不出口了。

AI 回答也一樣。題目問「適合哪種團隊、怎麼導入、有哪些限制」，回答洋洋灑灑列了三個品牌、附了產品頁連結，讀起來很完整——回頭對要點才發現，導入限制一個字都沒提。有品牌提及、有引用來源，覆蓋仍然只是部分。

先定義：Coverage 和品牌提及不同

四種判讀各自回答一個問題：品牌提及問「名字有沒有出現」，引用問「回答有沒有呈現來源」，推薦問「品牌有沒有進入選擇情境、有沒有條件或理由」，Coverage 問「這個回答有沒有處理使用者指定的資訊要點」。四者可以同時成立，也可以各自成立。

拿上面那個例子攤開來看。題目是：「請比較適合 20 人 B2B 團隊的 AI 搜尋觀測工具，說明主要觀測內容、資料保存方式、導入限制和適用情境。」回答提到 Otlex，附了一個產品頁來源——這代表品牌事件和來源事件都成立。至於資料保存方式和導入限制沒有說明，Coverage 就停在 partial；來源看起來正式，跟要點有沒有被處理是兩件事。

Coverage 不是平台公開的固定欄位。本文提出的狀態和計算方法，是為了讓回答審核一致而採用的工作規則。它量的是「回答有沒有處理指定範圍」，內容正不正確、會不會影響排名，都要另外查。

還有一個容易混掉的地方：本文說的 Coverage 專指「回答內容要點覆蓋」，分母是已判定且適用的要點。另一份報告若要回答「預定觀測有多少次成功拿到可判讀回答」，那是執行覆蓋，要用有效完成執行數除以預定執行數。兩個名字一樣、分母完全不同，合在一起就沒人看得懂了。

Answer 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 不能代替正確性審核

Google Search Central 現行指南說明，生成式 AI 搜尋仍和可抓取、可索引、可在一般 Search 顯示 snippet 的條件有關，也提醒沒有保證一定出現。這支持網站維持 SEO 基礎的做法，跟某一題的 Coverage 是兩回事。Google 也說 AI Overviews 和 AI Mode 可能使用不同模型與技術，回答及連結集合會變動，所以報告要保留介面和觀測條件。

Google 現行指南建議使用 Search Console 的 Generative AI performance report 了解內容如何透過 Google 生成式 AI 功能被發現。那份報告不會替你保存每個 prompt 的回答要點判讀——Coverage 得回到回答原文與要點規格，流量報告替代不了。

Coverage 與使用者滿意度、商業轉換、搜尋排名或推薦排名屬於不同觀測層。它做的事情很窄：把「回答有沒有處理預先指定的範圍」變成留得下證據的判讀。要追蹤品牌提及、引用與推薦，另看已公開的 AI Visibility 指標方法，別把所有事件塞進一個完整度分數。

常見問題

Answer Coverage 和品牌提及率有什麼不同？

兩個問題不同。品牌提及率問的是品牌名字有沒有出現在回答文字裡，Answer Coverage 問的是回答有沒有處理題目指定的資訊要點。一段回答可以提到品牌卻漏掉限制和適用條件，也可以一個品牌都沒提、卻完整回答了一個方法題。兩者分開保存與計算。

一個要點只被回答一半，要算有還是沒有？

標成 partial，並寫清楚缺的是哪一段、回答有沒有達到這題的最低需求。團隊若真的需要單一完整率，可以把 partial 當成未完整處理，明細裡仍然保留 partial 的數量——不然下次要補內容時，就看不出「差一點」和「完全沒寫」的差別。

看見來源 URL，就能把相關要點標成 complete 嗎？

要再核對兩件事：回答文字有沒有真的處理那個要點，以及來源支不支持那一段內容。URL 只證明回答呈現了來源。OpenAI 也提醒搜尋引用可能不完整或錯誤，重要資訊要打開原始頁檢查。

題目有五個要點，回答只處理三個，Coverage 是 60% 嗎？

要同時滿足四個條件才寫得成 3/5：五個要點權重相同、三個狀態都是 complete、另兩個確實是 absent、分母規則事先寫好。裡面只要摻了 partial、尚未判定、不可適用或不同權重，就先呈現狀態分布與分母，再決定要不要用百分比。

可以用 AI 自動判讀 Coverage 嗎？

可以拿來做整理或初篩。本篇沒有證據支持自動判讀在所有引擎、題型與語言下都可靠，所以規則、樣本、人工覆核與錯誤修正都要留下；重要報告交給一個沒驗證過的分類器，風險在於你不知道它錯在哪一類題目上。

查證邊界

本文外部文件查閱日期為 2026-09-21，使用 Google Search Central AI features、生成式 AI 搜尋指南與更新紀錄，以及 OpenAI ChatGPT Search 說明。要點拆解、coverage 狀態和公式是本文提出的方法，不是平台官方排名或品質分數。文中的 20 人團隊、100 個要點、85 分等數字都是說明用的假設情境，不是實測結果；遇到證據不足時應保留尚未判定。

AI 回答有沒有答到重點？Answer Coverage 量測方法