聯繫我

如果有任何問題或建議，歡迎隨時聯繫我：

• Email

前言

第三階段走到最後一天，把最現實的問題留到現在講：再會設定 effort、再會寫 prompt，Claude 還是有可能講出聽起來很有把握、但其實是編出來的內容。 這個現象叫「幻覺」（hallucination）——不是模型在說謊，是它在填補自己也不確定的空白時，選擇了一個聽起來合理但不一定真實的答案。

今天的做法不是什麼玄妙的技巧，反而是幾個聽起來很樸素的原則：允許它說不知道、要求它先引用再下結論、讓它自己驗證自己。 Day 18 提過的「先摘錄引句、再產生結論」的 XML 技巧，正是今天內容的雛型，今天把它完整展開。

本篇降低幻覺的技巧與範例，對照 Reduce hallucinations 官方文件查證。

目錄

一、基礎技巧一：明確允許它說「不知道」

官方的說法很直接：「Explicitly give Claude permission to admit uncertainty. This simple technique can drastically reduce false information.」——明確給 Claude 承認不確定的許可，能大幅降低錯誤資訊。

反直覺的地方在於：如果你的 prompt 只要求「回答問題」，模型面對自己也沒把握的地方，傾向於硬生出一個答案，而不是承認自己不知道。加一句明確的許可，能改變這個傾向：

作為我們的併購顧問，分析這份關於 AcmeCo 收購 ExampleCorp 的報告。

<report>
{{REPORT}}
</report>

請聚焦在財務預測、整合風險與法規障礙。如果你對任何部分沒有把握，
或報告缺乏必要資訊，請說「我沒有足夠的資訊可以有把握地評估這一點」。

這句許可不會讓模型變得消極——它只是把「不確定時該怎麼辦」的選項，從「編一個答案」換成「誠實回報」。

二、基礎技巧二：長文件先引用，再回答

這一招 Day 18 已經預告過。官方的建議明確給了一個 token 門檻：

"For tasks involving long documents (>20k tokens), ask Claude to extract word-for-word quotes first before performing its task."

超過 20k token 的長文件任務，先要求 Claude 逐字摘錄相關原文，再進行分析。這個順序讓回答「有跡可循」——你可以直接對照摘錄的引句是不是真的存在於原文裡。

作為我們的資料保護官，審查這份更新過的隱私權政策是否符合 GDPR 與 CCPA。

<policy>
{{POLICY}}
</policy>

1. 摘錄政策中與 GDPR、CCPA 合規性最相關的原文引句。如果找不到相關引句，
   請說明「未找到相關引句」。
2. 依據摘錄的引句分析各部分的合規性，並用引句編號引用來源。
   分析僅能基於摘錄出來的引句進行。

這裡呼應 Day 7、Day 11 講過的 tokenizer 知識：20k token 這個門檻，對中文內容來說，換算成的字數會比英文更少——因為中文的切字效率不同，用 Day 7 教的實測法量出自己內容的門檻，會比套用這個通用數字更準。

三、基礎技巧三：要求逐項引用驗證，找不到就退回結論

比「先引用再回答」更嚴格的做法，是讓每一個結論都附上可驗證的來源：

"Make Claude's response auditable by having it cite quotes and sources for each of its claims. You can also have Claude verify each claim by finding a supporting quote after it generates a response. If it can't find a quote, it must retract the claim."

官方的新聞稿範例展示了這個「先寫、再驗、驗不過就撤回」的流程：

只用這些產品簡介與市場報告的資訊，起草我們新的資安產品
AcmeSecurity Pro 的新聞稿。

<documents>
{{DOCUMENTS}}
</documents>

起草完成後，逐條檢視新聞稿裡的每一項主張。針對每一項主張，
從文件中找出一句直接支持它的引文。如果找不到支持的引文，
把這項主張從新聞稿中移除，並在原本的位置用空括號 [] 標記。

這個流程的價值在於「找不到引文」本身就是一個明確的訊號——不是靠模型自己判斷「這句話聽起來對不對」，而是有一個具體、可執行的檢查步驟：有沒有找到對應的原文。找不到，直接刪，而不是留著一句沒有根據的宣稱。

四、進階技巧：讓模型自己驗證自己

除了三個基礎做法，官方也列了四個更進階的驗證手法：

① 思維鏈驗證（Chain-of-thought verification）：在給最終答案前，要求 Claude 逐步說明推理過程。「這能揭露有問題的邏輯或假設」——很多幻覺不是憑空出現，是推理過程中某一步跳得太快，把推理過程攤開來，錯誤的跳躍會變得容易被發現。

② Best-of-N 驗證：對同一個 prompt 跑好幾次，比較每次的輸出。「輸出之間的不一致，可能就是幻覺的訊號」——如果同一個問題，Claude 每次給出的關鍵事實都不一樣，這代表模型對這個事實本身沒有穩定的把握，值得進一步查證。這個做法的代價是多次呼叫的成本（呼應 Day 2 的「呼叫次數」乘數），適合用在高風險、值得多花一點錢換取信心的場景。

③ 迭代精煉（Iterative refinement）：把 Claude 的輸出當成下一輪 prompt 的輸入，要求它驗證或延伸前面說過的內容。這能在後續輪次裡抓到並修正前後不一致的地方。

④ 限制只用外部知識（External knowledge restriction）：明確指示 Claude 只能使用你提供的文件內容，不要使用它自己的一般性知識。這對「答案必須完全基於這份特定文件」的場景特別重要——沒有這句限制，模型可能會不自覺地把自己訓練時學到的一般知識，跟文件裡的具體內容混在一起講。

五、官方的但書：這些技巧會降低，不會消除

官方在文件最後特別提醒：

"While these techniques significantly reduce hallucinations, they don't eliminate them entirely. Always validate critical information, especially for high-stakes decisions."

這些技巧能顯著降低幻覺，但不能完全消除。 高風險的決策，永遠需要人工驗證關鍵資訊。這句話值得放在心上——今天教的做法是把「幻覺發生的機率」壓低，不是把「幻覺發生的可能性」歸零。系統設計上，越是高風險的應用（醫療、法律、財務決策），越應該把「人工複核」設計成流程的一部分，而不是完全信任模型的自我驗證。

六、跟前面幾天串起來：三個容易踩的坑

① 不要過度信任摘要。 Day 12 提過 Compaction 會自動摘要長對話的舊內容——摘要本質上就是「壓縮資訊、可能漏掉細節」的過程。如果你的應用場景需要對「很早之前對話裡的具體事實」做精確引用，被摘要過的內容可能已經遺失了原始的精確措辭，這時候今天教的「要求引用原文」技巧，效果會受限於原文是不是還完整保留在 context 裡。

② 「找不到就說不知道」的成本，要放進 Day 2 的三乘數框架看。 今天教的技巧（先引用、驗證、Best-of-N）多數會增加 output token（更長的推理過程）或呼叫次數（多次驗證），這是為了換取正確性的合理支出，但值得依任務的風險程度決定要用到哪個強度——不是每個任務都需要 Best-of-N。

③ XML 標籤是今天技巧的載體，不是額外的東西。 Day 18 教的 <quotes>、<info> 標籤結構，就是今天「先引用再推理」原則的具體實作方式——兩天的內容是同一件事的兩個角度：Day 18 講「怎麼用標籤讓結構清楚」，今天講「為什麼要用這種先引用後推理的順序」。

Before / After：一份會被拿去做決策的分析報告

❌ Before：直接問，模型自由發揮

根據這份財報，分析公司的財務健康狀況，給我結論。

✅ After：允許不確定、要求先引用、要求可驗證

根據這份財報，分析公司的財務健康狀況。

<report>
{{REPORT}}
</report>

1. 先從財報中摘錄與財務健康狀況最相關的具體數字與原文段落，放進 <quotes> 標籤。
   如果某個面向報告中沒有提及，明確說「報告未提及」而不要推測。
2. 根據摘錄的引句給出結論，每個結論都要標明對應第幾條引句。
3. 如果你對某項判斷沒有足夠把握，明確說明「這部分需要人工複核」。

Before 版本把「分析」跟「下結論」的過程整個交給模型自由發揮，你拿到的是一段讀起來很有自信、但沒有辦法逐條檢查的文字。After 版本強制模型先攤開證據（<quotes>）、再對應著證據下結論、並且明確標記出沒有把握的地方——這份報告不會因此變得完全沒有錯誤，但每一個結論都變得可以被追溯查證，這正是官方文件開頭那句「auditable」的意思。

本篇自我挑戰

• 今日挑戰：挑一個你目前用 Claude 處理、結果會影響實際決策的任務，套用今天的「先引用、再推理、可驗證」結構重寫一次 prompt，比較前後的可信度——具體做法是隨機抽查幾條結論，看引用的原文是否真的存在、是否真的支持該結論。

• 反思：「允許 Claude 說不知道」這個技巧之所以有效，某種程度上反映了一件事——我們的 prompt 常常在無意間傳達「我要一個答案」的壓力，而不是「我要一個正確的答案」。 你在跟人溝通、交辦任務時，有沒有類似的情況：因為只問結果、沒給對方「可以說不確定」的空間，反而逼出了不夠可靠的答案？

總結

第三階段在這裡收尾。降低幻覺沒有一勞永逸的開關，官方給的是一套組合技：允許說不知道降低硬湊答案的傾向；長文件先引用（20k token 以上）讓回答有跡可循；逐項引用驗證把「找不到根據就撤回」變成明確的流程；進階則有思維鏈驗證、Best-of-N、迭代精煉、限制外部知識四種手法，依風險程度選用。

最重要的一句提醒留到最後：這些技巧顯著降低幻覺，但不會完全消除，高風險決策永遠需要人工複核。

本日關鍵字回顧

• 允許說不知道：明確給予承認不確定的許可，是降低幻覺最簡單有效的技巧。
• 20k token 門檻：官方建議超過此長度的文件任務，先要求逐字摘錄引句再進行分析。
• 可驗證性（Auditable）：要求每個結論附上支持引句，找不到引句就撤回該結論。
• Best-of-N 驗證：對同一 prompt 多次執行並比較輸出，不一致處可能是幻覺訊號。
• 降低而非消除：官方明確聲明這些技巧無法完全消除幻覺，高風險決策仍需人工驗證。

第三階段「設定與調校」到這裡結束。從 effort、adaptive thinking、prompt 骨架、XML 標籤、system prompt，到今天的降低幻覺，這七天建立的是判斷框架，不是一次性的操作步驟。

明天進入第四階段——開發者實戰。第一站是 Claude Code：從安裝到跑完第一個任務，把前面三個階段學到的東西，真正放進日常開發流程裡用。

Day 21，Claude Code 安裝與第一次使用完整教學。