在發佈前驗證 AI 輸出：3 個檢查 AI 準確性的提示

每一個你使用的 AI 回答最終都會落地到某處：設定檔、遷移、團隊成員會信任的文件。在未經驗證的情況下發佈，就等於把它的錯誤也一起發佈出去——而且是用你的名義。本文是我在發佈 AI 輸出前用來驗證的實務流程：三個可複製貼上的提示，用來檢查 AI 準確性，每個提示各司其職，組合起來只需幾分鐘，而非一整個下午。

前兩個提示——幻覺掃描與 AI 事實查核提示——來自本系列較早的文章（下方附有連結，各有各自的測試運行紀錄）。第三個提示——根據風險等級建立驗證清單——是本文的新內容，已在下方具陷阱的範例上進行過測試。

驗證 AI 輸出實際需要做什麼？

三個步驟，依序執行，每個步驟回答不同的問題：

1. 掃描 — 這裡有哪些主張？哪些看起來是捏造的？ 範圍廣但深度淺，涵蓋整個回答。
2. 壓力測試 — 這個承重的主張是否真的正確？ 範圍窄但深度深，針對可能改變決策的主張。
3. 清單 — 根據風險等級，這段文字應該接受哪些完整的檢查？ 這個步驟能把「我檢查了一些東西」變成「我檢查了正確的東西」。

大多數人只會本能地執行步驟 1 的簡化版。最終進入正式環境的錯誤，通常都出現在步驟 2 和 3。

提示 1：掃描回答中的幻覺

精簡版本：

Audit the text below for hallucinations.
List every factual claim as a numbered line; label each
VERIFIABLE, SUSPECT, or FABRICATION-PATTERN (named
source/study/number with no citation).
End with the 3 claims most likely to be wrong, ranked.
Text: [PASTE THE AI ANSWER]

Enter fullscreen mode Exit fullscreen mode

在第一部分的測試運行中，此模式成功找出範例回答裡全部三個植入的錯誤——包含一項虛構的 Stanford 研究。代價是它只回傳標籤而非判決，而且隨著文字長度增加，標記數量也會快速上升。

提示 2：對即將採取行動的主張進行壓力測試

簡短版本：

Stress-test this claim. Do not assume it is true.
State what evidence would prove it wrong, the 2-3 conditions
it silently depends on, and the likeliest confounder.
Verdict: SUPPORTED / UNCLEAR / DOUBTFUL, one line why,
plus the single fastest check a human should run.
Claim: [PASTE ONE CLAIM]

Enter fullscreen mode Exit fullscreen mode

此設計刻意採用對抗式寫法——它建立反對該主張的論據，而非邀請同意。在第二部分的測試運行中，此事實查核提示將「使用 ORM 可防止 SQL 注入」從程式碼審查 folklore 轉為 DOUBTFUL 判決，並指出確切的例外情境。

提示 3：根據風險等級建立驗證清單

全新提示，完整版本——這個步驟決定這段文字值得接受多少檢查：

Build a verification checklist for the AI-generated text below.
1. State the stakes: LOW / MEDIUM / HIGH, and why in one line.
2. List 3 checks for LOW stakes, 6-8 for MEDIUM or HIGH — each
   check names what to verify and the fastest way to verify it.
3. Order checks so the most damaging-if-wrong claim comes first.
4. End with the one claim that invalidates everything if wrong.
Text: [PASTE]

Enter fullscreen mode Exit fullscreen mode

依損害程度排序是重點。清單若從最危險的主張開始，即使你只執行第一個檢查，也等於做了正確的事。

驗證清單提示真的能找出重點嗎？

我餵給它四句看似合理的 AI 式升級建議——「使用 pg_upgrade 就地將 PostgreSQL 12 升級到 16，停機時間不到一分鐘，用 pg_dumpall 備份，之後執行 ANALYZE，擴充套件會自動升級，因此不需要手動步驟」——最後那句主張就是植入的陷阱：流暢、安撫人心，卻是錯誤的。只執行一次，Claude Sonnet，新上下文。回傳結果如下：

• 風險等級：HIGH，理由正確——在正式資料庫上執行此操作，會在備份視窗關閉後產生無聲的資料存取失敗風險。
• 植入的陷阱被排在檢查 #1——被標記為 blanket claim 錯誤，並清楚寫出最快的檢查方式（SELECT * FROM pg_extension;，再查閱每個擴充套件的相容性說明）。
• 同一主張被列為會使整體失效的主張——此次執行的結尾語句：若依賴此主張，你可能「以為升級已成功」而完成程序，事後才發現功能已損毀且無法復原。
• 額外涵蓋我未植入的項目：它指出「停機時間不到一分鐘」靜默依賴 --link 模式、未經測試還原的備份不能算是備份、12→16 的多版本跳躍本身需要驗證，以及文字完全沒有回滾計畫——共八項檢查，且已依損害程度排序。

最後這點正是驗證清單步驟真正的價值：它不只審核已存在的句子，還能找出文字「應該提到卻沒有提到」的檢查項目。

免費驗證清單提示的限制在哪裡？

在同一次執行中可看出三道牆：

• 事實優先的涵蓋範圍。 檢查項目圍繞文字中已有的主張。只有當文字恰好暗示邏輯錯誤、邊緣案例或合規風險時，這些問題才會浮現——沒有人會問「誰會因此告我們？」
• 依直覺判斷風險等級。 LOW/MEDIUM/HIGH 只用一行文字說明，屬於氛圍檢查。這次判斷正確，但無法保證對更細微的輸入也能做出相同判斷。
• 結構會漂移。 檢查數量、深度與用詞在每次執行中都會變化——適合單次使用，但作為日常依賴的例行程序則顯得薄弱。

針對日常使用的版本，我已將完整提示維護為付費產品：PromptBase 上的 AI Verification Checklist Builder。它依據風險等級評量表而非單行猜測來決定清單規模，將檢查延伸至邏輯、邊緣案例與法律審查，而非僅止於事實，並以相同方式結束每次執行——指出若出錯將使其他一切失效的承重主張。

這三個提示如何搭配使用？

組合規則很簡單：

高於這三個提示的唯一規則：模型的審核是地圖，而非領土。每一個判決與每一項清單項目，最後仍需由人類執行檢查——grep、文件頁面、測試還原。這些提示不會取代驗證；它們只是確保你花在驗證上的時間，能落在真正可能傷害你的主張上。

本文由 AI 協助撰寫。本文中的清單測試運行是依照所述方式執行——一次通過、Claude Sonnet、新上下文——並忠實記錄；先前提示的測試運行則記錄在各自的文章中。若要重現本次測試：輸入文字已在上方引用。

完整清單版本已在上方章節附上連結。若你的瓶頸在提示本身而非輸出，我也有維護 Optimizer: Diagnose & Rewrite。本系列先前文章：捕捉 AI 幻覺 與 事實查核 ChatGPT。