AI-LECTURER 速報課｜2026-08-09｜約 28 分鐘

標案AI學會拒絕：一家公司用一年除錯換來的「拒絕捏造」工程學

取材：Making an AI bid writer refuse to lie（Hacker News（AI 高人氣））
📍 真實場景
陳雅婷，中型土木營造公司的標案專員

用AI輔助工具趕一份政府公共工程標案的資格文件，明天就要送件

😖 卡住的地方：AI草稿裡寫著『本公司持有ISO 45001職業安全衛生認證』，她太趕沒有逐條核對就送出，評選委員要求提供證書時才發現公司根本沒有這張認證——標案直接被判定不合格，還被記錄在案，影響以後投標的信譽
💡 這課會告訴她，這種『AI一本正經編資格』的事故不是她運氣不好，而是AI的預設行為模式，並且用一個真實產品一年除錯的紀錄告訴她：這種風險可以被工程方法擋下來，甚至能變成產品最自豪的功能

🧭 這到底是什麼（白話版）

Lucius是一套專門讀公開招標文件、自動生成合規矩陣跟標案初稿的AI系統。文章作者分享了一個實戰案例：英國格洛斯特郡一個教區議會要蓋一座造價95萬英鎊的3G人工草皮足球場，招標包裡有六份文件、133頁。AI在五分鐘內生出初稿，但初稿最前面不是漂亮的自我介紹，而是一段警示：『這份草稿裡有11項資格要求，目前是靠一個你還沒有命名的合作夥伴撐著』，接著列出像是『近兩年財報證明的最低營業額』、『500萬英鎊的專業責任險』這類具體項目。作者說這段警示才是他最自豪的功能——因為它是一個『拒絕』。

為什麼需要特別去設計『拒絕』這個功能？因為大型語言模型（LLM）一種被大量文字訓練出來、非常擅長『接話』的AI，看到一句話的開頭，就會自動生成看起來最合理、最通順的後續內容天生就有一個壞習慣：它預設會產生「讀起來最合理」的下一句話，而不是「查證起來最真實」的下一句話。在多數場合，通順跟真實是同一個方向，所以沒人注意到差異；但在標案這種文件裡，兩者會在錢的地方分岔——買方真正會去查證的那些條款，恰好就是AI最容易順著上下文編出一個聽起來很像真的答案的地方。這種一本正經卻是編出來的內容，就是常說的幻覺（hallucination）AI講得非常有把握、格式跟語氣都很正常，但內容其實是憑空編造，不是根據事實。

作者要解決的不是「讓AI寫得更好」，現在的模型寫作能力本來就很夠。真正難的工程問題，是讓整套系統知道「逐條而言，AI現在有資格宣稱什麼」。他們的做法是先建立一份標案合規矩陣（compliance matrix）把招標文件裡每一條資格要求，逐條列出來，並標記我方到底有沒有符合、證據在哪裡的一張表，把整份文件拆成一條一條可以被檢查的宣稱，而不是丟給AI一次性當一大塊文字自由發揮。

但光有這張表還不夠。文章裡有一個代價很高的案例：AI幫一份NHS標案編了一個根本不存在的合作夥伴，分攤了42項資格要求，而負責檢查的合規驗證器只做關鍵字比對（keyword matching）一種很簡陋的檢查方式，只看文字裡有沒有出現特定字眼，不管那段話講的內容是不是真的，剛好被幻覺出來的段落裡對的關鍵字騙過，判定這42項『已符合』。這告訴我們：檢查機制本身也可能被騙，接下來的章節會講他們怎麼把這個漏洞補起來。

🎯 為什麼值得你花時間

AI寫的東西一旦被拿去當「正式承諾」，講錯話的代價是真金白銀標案文件不是行銷文案。寫『我方持有500萬英鎊專業責任險』是買方會去查證、可以拿來執行的正式承諾，一旦查出是編的，不是扣分而已，是整份標案被剔除，嚴重時還會被排除在未來的標案之外。
AI的預設行為就是「編也要編得像」在一般寫作裡，『講得通順』跟『講得真實』通常是同一件事，AI不用特別區分。但在標案這種會被逐條驗證的文件裡，兩者會分道，而AI本能地選了通順那條路——因為它本來就只被訓練成要接得順。
光靠「加一層檢查」不夠，兩個各自合理的元件疊起來仍可能一起說謊phantom partner案例：模型編了個沒名字的合作夥伴分攤42項要求，而審核用的關鍵字比對系統看到那些段落裡出現了對的關鍵字，就打勾說『已符合』——兩層各自看起來沒錯的機制，組合起來變成一台會自我認證謊言的機器。這正是資深工程師要提防的整合風險。

⚙️ 它是怎麼運作的

1
把招標文件拆成逐條資格要求先讀完整份招標包（本例133頁、六份文件），把每一條『投標人必須……』的資格門檻抽成一筆一筆獨立的項目，而不是把整份文件當成一大塊文字丟給AI自由發揮。
▼
2
整理己方真正持有的證據同時把公司真正拿得出來的東西——財報、保單金額、認證證書、過去案例的驗收紀錄——整理成跟資格要求同一個維度、可以逐項比對的資料。
▼
3
改用資格能力核對（capability-fit check）讓AI動筆之前，先把『招標要求什麼』跟『我方真的持有什麼證據』逐條比對，沒有證據支持的項目直接標記，不准AI自己編答案，不靠提示詞微調（prompt tweak）只是換一種方式跟AI講話、期待它自己表現得更謹慎，但沒有真正改變系統的檢查機制文章講得很直接：這次的修法是結構性的，不是提示詞調整。因為提示詞只是在跟模型商量，模型骨子裡『傾向產出最合理接續文字』的習慣不會因為多講幾句『請不要亂編』就真的改變；真正可靠的做法，是把『能不能寫這句話』的判斷權從模型手上拿走，變成一個在AI動筆前、獨立於模型之外、按規則執行的核對步驟。
▼
4
沒有證據的項目變成警示，不是答案逐條核對完之後，沒有證據支持的資格要求不會被AI硬填一個答案，而是被集中收進一份警示清單，等人工補件或找到真正的合作夥伴。
▼
5
警示banner放在文件最前面，草稿主體接著往後排這就是文章開頭那段『11項要求目前靠一個你還沒命名的合作夥伴撐著』banner的來源——使用者一打開檔案就先看到『哪裡還沒補齊』，而不是被藏在133頁裡的某個角落，事後才被評審委員挖出來。
天真AI 與 拒絕捏造AI 面對同一份缺證據清單的差異
面向一般（天真）AI寫標案拒絕捏造的AI（Lucius的做法）
遇到沒有證據的資格要求順著上下文編一個聽起來合理的答案（例如捏造一個合作夥伴）直接標記為『未證明』，列入警示清單，不填答案
審核／驗證方式關鍵字比對，段落裡出現對的字眼就打勾算過先做資格能力核對表，逐條比對『招標要求』與『己方實際證據』
幻覺被發現的時間點交件後被評審委員或查核單位發現，標案被剔除甚至列入黑名單生成草稿的當下就被系統攔下來，變成警示，交給人工補件

🔍 程式碼漫遊（點有 ● 的行看白話講解）

把文章裡『資格能力核對表』這個修復邏輯，簡化成一段可以真的讀懂的程式

●requirements = load_tender_requirements(tender_pack)
💬 先把招標文件裡每一條資格要求抽出來，變成一筆一筆的清單
●evidence = load_bidder_evidence(company_profile)
💬 再把我方公司真的有的證明文件（保險金額、認證、財報等）也整理成清單
●draft_lines = []
💬 準備放最終要寫進標案文件的每一句話
●unproven = []
💬 準備放『沒有證據、不能寫』的項目清單
●for req in requirements:
💬 一條一條資格要求檢查，不是整份文件一次生成
● proof = evidence.get(req.key)
💬 查我方是否真的持有能證明這一條的東西
● if proof and proof.meets(req.threshold):
💬 要有證據、而且數字或條件真的達標（不是隨便有就算過）
● draft_lines.append(write_compliant_statement(req, proof))
💬 才讓AI寫下『我方符合，證據是……』
● else:
💬 沒證據或達不到門檻的情況
● unproven.append(req)
💬 不讓AI編答案，先記下來變成警示項目，等人工補件或授權
●banner = render_warning_banner(unproven)
💬 把沒證據的清單變成開頭的警示banner
●draft = banner + '\n'.join(draft_lines)
💬 警示放最前面、正文接著往後放——這就是文章開頭那段banner的來源

🛠️ 動手做：拒絕捏造模擬器：同一張資格清單，天真AI vs 資格核對AI

  1. 頁面上有一張『標案資格要求』清單，每條旁邊的勾選框代表你（假想公司）目前有沒有證據
  2. 先按『天真模式』，看AI怎麼把每一條都寫成『我方符合』——包括你根本沒證據的那幾條
  3. 再按『拒絕捏造模式』，看同一份清單怎麼被逐條核對，沒證據的項目變成警示清單，而不是被瞎掰過去
  4. 試著把某一條的勾選框打開或關掉（改變『有無證據』的狀態），看兩種模式的草稿即時跟著變
👇 下面是活的，直接操作

🧠 工程思維透鏡（資深工程師看到的是什麼）

🔭 為什麼『多加一層檢查』這個直覺解法在這裡差點失敗？
文章裡的phantom partner案例最耐人尋味的地方，不是模型編故事，而是『編故事』跟『驗故事』兩個各自看起來合理的元件疊在一起後，反而互相掩護。草稿生成器編了個合作夥伴分攤責任，審核用的合規驗證器只做關鍵字比對，兩邊都沒有『錯』在自己的職責範圍內，但組合起來的系統卻放過了一個不存在的公司。這是資深工程師必須隨時警惕的模式：局部正確不保證整體正確，尤其當兩個元件之間有『誰該為事實負責』的空隙時，那個空隙就是幻覺的藏身處。
🔭 為什麼修法是『資格能力核對表』而不是『把提示詞寫得更嚴格』？
文章明講：修法是結構性的，不是提示詞調整。這是一個很重要的工程判斷——提示詞是在跟模型商量，但模型的預設優化目標（產生最合理的接續文字）不會因為你多講幾句『請不要亂編』就真的改變，它只是暫時被說服。真正可靠的做法是把『能不能寫這句話』的判斷權從模型手上拿走，變成一個在模型動筆之前、外部、規則式的資格比對步驟——這樣即使模型本身沒有變聰明，系統整體也不會說謊。這反映了一個更大的原則：不可靠的元件要用可靠的外部結構去框住，而不是指望它自己變可靠。
🔭 『把拒絕做成產品功能』這個設計選擇，背後的取捨是什麼？
多數AI產品的預設價值是『產出愈完整愈好』，一份寫好90%的草稿看起來比一份寫著『還有11項沒寫』的草稿更像成品。但作者選擇把『我不知道』做成最顯眼的功能（開頭警示banner），這是用短期的『看起來不夠完整』去換長期的『使用者不會被騙著送出一份會害自己被剔除甚至列黑名單的文件』。這個取捨在任何『AI輔助做出有法律或商業後果的文件』的場景都通用——完整度和誠實度衝突時，誠實度該贏，而且要贏得讓使用者一眼看到，不能藏在小字裡。

📝 隨堂考（點選答案，立即回饋）

Q1. 文章說，為什麼一份標案文件裡的『我方持有500萬英鎊責任險』跟一般行銷文案裡的誇大用詞不一樣？
✅ 文章明確指出，標案裡的陳述是買方會驗證、可以據以行動的承諾，寫錯不是扣分而是被剔除，這跟行銷文案的誇大完全不同層級。
Q2. 『phantom partner（幽靈合作夥伴）』事件裡，真正讓問題被放過的關鍵原因是什麼？
✅ 文章說驗證器只做關鍵字比對，幻覺出來的合作夥伴段落恰好包含對的關鍵字，於是被誤判為已符合，這是兩個各自合理的元件組合出系統性失敗。
Q3. 作者為什麼說『讓AI寫得好』不是這裡真正困難的工程問題？
✅ 文章原文明講：讓模型寫得好不是難題，讓系統知道逐條而言它有資格宣稱什麼，才是真正的工程問題。
Q4. 文中修復『幽靈合作夥伴』問題時採取的作法，最貼切的描述是？
✅ 文章說修復是結構性的：新增資格能力核對（capability-fit check）流程，在草稿生成前先逐條核對證據。
Q5. 這篇文章給『用AI處理有法律或商業後果的正式文件』這件事，最核心的啟示是什麼？
✅ 文章的核心主張正是『拒絕』是作者最自豪的功能，寧可草稿看起來不完整，也不要讓使用者帶著捏造的承諾送出文件。

🃏 翻牌記憶卡（先想答案，再點開對答）

為什麼AI在標案文件裡特別容易『幻覺』？點我翻面
因為它的預設目標是產生『最合理的接續文字』，而合理（讀起來通順）跟真實（真的有證據）在標案這種被驗證的文件裡會分岔，AI本能選了通順那條路。
phantom partner事件教會我們什麼？點我翻面
兩個各自看起來合理的元件（會編故事的生成器＋只做關鍵字比對的驗證器）疊加起來，可能組合出一個系統性的謊言，局部正確不保證整體正確。
『提示詞調整』跟『結構性修復』的差別？點我翻面
提示詞調整是在跟模型商量，模型的優化目標沒有真的改變；結構性修復是把『能不能寫』的判斷權從模型手上拿到外部規則式流程，即使模型沒變聰明系統也不會說謊。
資格能力核對表（capability-fit check）在做什麼？點我翻面
在AI動筆前，先把招標要求的每一條，跟己方真的持有的證據逐項比對，沒證據的項目直接標記，不准AI瞎掰答案。
這篇文章裡『最值得驕傲的功能』是什麼？點我翻面
一個警示banner——明講『這11項要求目前是靠一個你還沒命名的合作夥伴撐著』，本質上是AI在說『我不知道，我不編』。

✅ 離開前自測（全勾＝這課真的學會了）

0%