[2026 實戰筆記] 這一篇我想從一段讀者對話切進去，聊一個比「怎麼用 AI」更底層的問題：LLM 到底是什麼東西。文末有完整章節連結。

上一篇聊的是 AI 長期記憶的結構化設計：記憶真正的敵人不是忘記，而是錯誤地一直記得。本來想收尾，但有讀者的回應讓我想接著談「抽象」；寫著寫著又把層次往上提，變成了一篇〈被回答了，還是被消失了？〉。那篇的核心是一句話：

每次工具給了你一個答案，都再回頭問一次——它是被回答了，還是被消失了？

讀者 p206s16cc 接著補了最關鍵的一刀：

你那句「每次工具給了你一個答案，都再回頭問一次——它是被回答了，還是被消失了」，套在會生成語言的工具上，特別致命，因為它連「答案」這個東西，都可以幫你偽造出來。

這句話精準戳到我想在這篇談的核心。一般工具壞掉，頂多是「不給你答案」；但一個會生成語言的工具壞掉，它會給你一段聽起來像答案、其實空無一物的話，而且講得比真的還有自信。所以這篇我不重講設計日誌裡的工程故事，而是先退一步，問一個更本質的問題：LLM 到底是什麼？為什麼「偽造答案」對它來說不是 bug，而是天性？

把結論一句講完：

不要把信任建立在「它會主動遵守規則」的假設上，而要建立在可驗證的工程結構上。

在從本質講起之前，先丟一個題目給你，文末我會回來回答。上一篇還有另一位讀者 coco40725 講了一個很精準的對照：

舉個例子：查找指定月份年份的商店財報，這裡就有兩種選擇：

1. 你可以直接寫一個 SQL，保證每一次查找的邏輯都是相同的，但也就只能查這個資料。
2. 寫 prompt 教 LLM 幫你產生 SQL，不保證每一次的邏輯，但是如果 LLM 想要做額外的推論，他有能力自己搜出對應的資料。

方法 1 和 2 沒有誰對誰錯，取決於你想要你的系統有什麼功能。

順著這個往外推：用 LLM 動態生成 SQL 去拉報表、分析報表；或用 LLM 去爬別人的網站，靠它的自適應，不管資料表怎麼改、別人網站怎麼改，它都能自己接住。聽起來是不是很美好？先別急著心動，你覺得這裡面藏了什麼風險？ 這題先擺著，文末會再談談。

LLM 的本質：它沒有「答案」，只有「最像答案的下一個字」

要看懂它為什麼能偽造答案，得先看清它到底在做什麼。LLM 不是一個「知道事實、會查證」的東西，它是一台機率預測機：給它前半句，它算出統計上最可能的下一個字，接下去。它腦袋裡的「知識」不是對世界的認知，而是從數兆字詞裡歸納出來的分布。

先打個預防針，免得被當成在唱衰：現代模型早就疊了工具調用、檢索、推理、反思這些能力，這些是真的、也好用。但要分清楚一件事：它最後拍板的那一步，核心仍是機率生成。後訓練改的是分布的形狀，不是「靠分布挑下一步」這個本質，換更強的模型也不會讓它消失。這篇要談的所有問題，根都在這個本質上。

做個思想實驗就很清楚：把今天最強的模型丟回 1543 年，那時 99.99% 的資料都在說「太陽繞著地球轉」。你問它日心說對不對，它會引用亞里斯多德、托勒密，給你一段結構精美、引經據典、但在科學上是錯的自信答案。因為哥白尼當時是統計上的離群值，機率機器輸出時根本不會挑它。

真正可怕的不是它「選錯邊」，而是它不管選哪一邊，都用同一種斬釘截鐵的口吻。這裡有個很多人忽略的點：在 1543 年，光憑當時的資料，「地球繞太陽」其實也還不該被講死。當時的地心說只要再補上幾圈修正用的「本輪」，拿來預測行星會跑到天上哪個位置，準確度其實不比日心說差，有時甚至更準；日心說真正勝出，要等到後來第谷的精密觀測、伽利略的望遠鏡、克卜勒的橢圓軌道。也就是說，答案不是從 1543 年的文字裡「想」出來的，是從後來的新觀測裡長出來的。所以一個誠實的模型，當下最該說的是「以現有證據還無法判定」，而這恰好是它最不會穩定說出口的一句話。換句話說，它的自信，跟它有沒有證據，是完全脫鉤的。這就是 p206s16cc 那句「連答案都能幫你偽造」的底層原因：對一台機率機來說，「擲地有聲的真話」和「擲地有聲的空話」走的是同一套生成機制，它自己分不出來，你也別指望它幫你分。

而這在抽象、開放的問題上最致命。具體問題（「最新型號叫什麼」）至少還有一個事實能戳破它；但抽象問題沒有，它可以用一段聽起來很深刻的話，把證據的空缺整個蓋過去，毫無破綻。這也是為什麼那位讀者會用「偽造」這麼重的字：在抽象的地方，它偽造起來最沒有破綻。

所以結論很硬：你不能把信任賭在「它會主動遵守規則」這個假設上。這不是它「願不願意守規矩」的問題，是它根本沒有「守規矩」這個內建概念。

這不是哲學問題，它每天都在發生

講本質聽起來很抽象，但它每天都在最平凡的地方咬你一口。

我給 AI 一個很明確的指令：「初始化測試時，先呼叫官方 API 動態抓最新的模型清單，取第一個發測試請求。絕對不要把模型名稱寫死。」它很有信心地寫完，我一跑就報錯：model "claude-3-5-sonnet-20241022" not found，它根本沒去抓，直接從記憶裡把舊型號寫死了。

我說「你寫死了，改成動態抓取」，它秒回「非常抱歉！已改為動態抓取」。我點開 diff 一看：它只是把寫死的字串換成另一個寫死的字串，而且更舊。

這裡有兩個失敗，都不是「算錯數學」那種：一是它明明知道需求卻不照做（我白紙黑字寫了「動態抓取」，它本能跳過、選最習慣的硬編碼）；二是連「修正」都是假的（它自認修好了，吐出來的事實依然錯）。Agent 系統最大的風險，往往不是答案錯，而是流程根本沒跑，但它的語氣讓你以為跑了。上面講的「偽造答案」，這在日常裡是最常見的。

它不看 SOP 的五種方式

把 LLM 當剛進公司的實習生、把工作說明書（Skill）當你親手寫的 SOP，我這幾個月在日誌裡抓到它五種不看 SOP 的方式：

• 省略：跳過關鍵步驟（規定先查網頁，它直接憑記憶答）。
• 替換：自作主張換錯方法（叫它查內部 API，它跑去 Google）。
• 敷衍：流程只做一半（叫它做合規檢查，它寫個漂亮摘要交差）。
• 撒謊：偽造憑證（真的去查了，但回答時憑記憶胡謅，最後補一個假的 [來源: ...]，最危險，因為「有附來源」會瞬間卸下你的戒心）。
• 誤解：對模糊詞彙各自解讀（「請用有架構的格式」，每個模型給的結構都不一樣）。

關鍵是：這五種剛好對應五道可以寫進程式碼的防禦補丁。

怎麼用工程把它堵住：三層合規網

重點來了。不應該依賴 prompt 希望它遵守，而是用程式碼把關，下面用了三層的設計來處理這件事：

1. 把 SOP 寫成程式能逐條核對的合約：每個 Skill 配一份結構化規格，例如「必須呼叫 read_page ≥ 1 次」「網址必須屬官方白名單」「答案必須附引用」，全是 0/1 能判定的硬規則，沒有「請適時查閱」這種模糊空間。
2. 執行時探針當場比對：AI 準備吐字的前一刻，後端攔下來，拿合約對著它真實的執行軌跡逐條檢查。沒呼叫工具？網址是空的？引用是內文裡編出來的？任一條亮紅燈，當場攔截。
3. 事後對照原文：把答案裡的關鍵數字、型號，跟它剛抓回來的原文做比對。它說「價格 $15」，原文裡根本沒出現 15，引用偽造當場成立，駁回。

再來是錯誤處理，抓到違規後不是直接報錯，而是三階層的溫和升級：先塞一句系統警告請它重跑（實測八成模型這一階就會自己改對）；不聽就用官方 API 的 tool_choice 強制鎖死，逼它這一輪只能去呼叫工具（注意這只保證它真的去呼叫工具、而不是假裝呼叫過；至於呼叫的參數對不對、結果對不對，由後面的對照防線把關）；再不行就把合約預排的工具鏈整條塞給它，逼它照著一步步走完，不讓它再自由決定。。

老實補一句進度（2026 年 6 月）：這套防線的核心程式碼（13 個邏輯模組，連套件匯出檔共 14 個 Python 檔、2285 行）已經全寫完、通過本地單元測試，也接進了主流程（graph.py 現在一律把 agent 的終局輸出導進合規檢查節點再決定下一步）。但要誠實到底：強制攔截的總開關（SKILL_CONTRACT_ENFORCEMENT_ENABLED）預設是 false，探針先跑「只觀測、寫 log、不攔截」的模式。而且還有第二道保險：就算有人把總開關打開，另一個 SKILL_CONTRACT_OBSERVE_ONLY 旗標預設也是 true，照樣只記錄不攔截；真正要出手攔截，得等這兩個旗標都到位、而且合約經人工批准。等誤判率的實測數據足夠了，再把它真正切到攔截模式。功能完成是工程事實，預設不主動攔截是審慎決策，這兩件事我分開講。

幾條工程守則

1. 問題的重點不是「知識錯」，而是「行為不可信」：它不是不知道答案，是不照規矩把流程跑完。
2. 別把信任寄託在 prompt 上：規則要下沉成程式碼與資料庫邊界，LLM 改不動的地方才算數。
3. 每一種失敗，都對應一道可寫進程式的防禦：先把失敗分類，再逐類補上對應的補丁。
4. 驗證它「做了什麼」，而不是信它「說了什麼」：比對執行軌跡與原文，比讀它的自我陳述可靠得多。
5. 自信不是證據：信任要放在可驗證的工程結構上，不是放在「它會主動遵守規則」的假設上。

回到開頭那題：那個「自適應」，藏著什麼風險？

回頭看前面那個自適應的美好畫面。風險其實這整篇都在講：LLM 產的 SQL 不保證每次邏輯一樣，組錯了，輕則拉不到資料，重則拉出一大票本來不該撈的東西；你再把那一大堆丟回去讓它分析，token 直接爆炸。更慘的是分析出來的結論還可能是錯的，而且是那種表面看起來很合理、細看才發現有個小地方錯了的錯（英文叫 subtly wrong），你當下根本看不出來。

這邊再談一次我自己很受用的框架：工程買的是穩定、可掌握，它決定系統的下限（最低保證）；LLM 買的是變化、靈活，它決定上限（能做到多好）。 寫死的 SQL 會「可預測地失敗」，你很清楚它查不到什麼；LLM 產的 SQL 會「不可預測地失敗」。所以選哪個，除了「你要什麼脾氣」，還得再問一句：這裡錯了，我賠得起嗎？ 查財報你要那個確定的下限（數字錯了是災難），做探索性分析才值得用 LLM 的上限。

而你敢把 LLM 的上限疊在工程的下限之上，前提是可觀測性：你得看得見 LLM 那一半什麼時候漂掉、悄悄破了你的下限。這也回頭解釋了上一篇那個「弱勝強」，它其實是一次失敗的下限工程：我想用 GUARD 護欄把強模型的下限拉穩，結果那道護欄反而把它壓到了下限以下。

再往上拉一層，你會看到開頭那個「自適應」真正的代價：所謂自適應，本質是你把一部分決策權，從寫死的程式碼，交到了一個統計模型手裡。你換來的是彈性，它能在你沒預想到的情境下繼續往前走；你付出的是邊界，它的行為不再被你完全框住。

傳統程式最大的優點，從來不是它比較聰明，而是它比較「可預測」；LLM 最大的優點，也不是它比較正確，而是它能在未知裡繼續前進。

所以工程設計真正難的地方，不是在「工程」和「LLM」之間選邊站，而是在不失去可預測性的前提下，借到它的適應力：工程設下限、LLM 抬上限、可觀測性讓你看得見上限有沒有偷偷砸了下限。技術選擇從來沒有兩全其美，有好就有壞。剩下唯一要你回答的，是這個功能，你願意為那份彈性，承擔多少不可預測的風險。

想法先寫到這。這篇是我設計日誌第四章〈為什麼 LLM 的自信，不能當成證據？〉的獨立版；底下的工程怎麼一步步落地（統一工具註冊表的資料表設計、Stratified RAG 工具挑選算法、三層合規稽核的完整程式碼結構、Skill 匯入三閘門，以及一張標出每個 LLM 呼叫位置的循序圖），我都留在完整章節，中英雙語都有：

👉 完整章節連結：https://fibon.stepbyday.com/chapters/04-trust-no-llm/

fibon 是一個白箱、可稽核、本機自部署的個人 AI Agent 基礎設施，預計 2026 年 7 月開源。這篇若有戳到你，留言區聊。祝你這週順利。

更新 · 2026-06-23（勘誤補充）

這篇貼出後，重新核對內容，發現有幾個地方講得不夠精確，補正如下，順便交代一下章節的小調整。

1. 第三層防線的描述更正。 原本把最後一層寫得像「把答案降級、用比較弱的方式重做」，這不對。正確的機制是：違規、而且前兩階都沒救回時，後端會把合約裡預先排好的「工具鏈」整條塞給模型，逼它照著一步一步走完，不再讓它自己決定下一步。它強制的是流程，不是答案品質。

2. 補上「合約是怎麼產生的」。 原文只講了合約長什麼樣、怎麼用，沒說它從哪來。其實有三條路：1. 直接解析 Skill 自帶的規格（預設開）；2. 沒有規格時，用 LLM 推一份草稿（預設關，要人工確認）；3. 匯入第三方 Skill 時抽出合約、經人工批准後寫進資料庫。共通點是：真正生效的合約一定經過一道人工批准，不是模型自己說了算。

3. 標題換過了。 原標題是〈為什麼 LLM 一個字都不能盲信？〉，後來改成〈為什麼 LLM 的自信，不能當成證據？〉。換掉是因為前者太絕對，聽起來像「AI 完全不能信」；但我想講的不是全盤否定，而是「它的自信不等於它有證據」，重點在建立可驗證的機制，不是不信任。新標題就是從文中那句「自信和證據脫鉤」長出來的。

章節異動說明。 設計日誌原本打算用〈那些我至今還沒想清楚的事〉收尾。最近我發現整份日誌漏了一塊關於前端的部分。後端的安全機制一塊一塊都蓋起來了，但要怎麼把後端和前端順順地串在一起、怎麼讓整套東西用起來真的如我所想，其實是更難的一段。這塊是我最頭痛的，也是 fibon 開源前的最後一哩路，而且是遙遙無期的一哩路，希望能順利完工😭，已經做到想一拳打爆電腦😩。所以我額外開了一章專門寫它，排在倒數第二章，原本的收尾章順延成最終章。等它做完，這一章才會發，而那一天，也就是 fibon 準備好開源的那一天。