📍 真實場景
中小企業的業務經理，正在用AI工具幫忙寫政府標案的投標文件
他把公司資料丟給AI，請它生成一份完整的投標書初稿，交件期限只剩三天
😖 卡住的地方：AI寫得又快又順，但他心裡發毛：這些「我們具備某某認證」「五年年營業額達標」的句子，是真的查證過，還是AI自己掰出來的？一旦審查發現造假，公司可能被取消資格、甚至被列入黑名單、往後好幾年都不能投標
💡 讀完你會知道：AI為什麼會「講得很像真的」但其實在說謊，以及三個能讓AI老實承認「我不知道」的具體做法
⚡ 一句話講清楚
為什麼AI會「一本正經胡說八道」？因為語言模型（LLM）能讀懂並生成通順文字的AI程式，例如ChatGPT或Claude背後的技術的運作原理，其實是在預測「接下來最有可能出現的字」，而不是在查證「這句話是不是真的」。平常聊天時，「最像真的」和「真的」通常是同一件事，所以你不會發現差異。但投標文件不一樣——一旦AI寫下「我們持有500萬英鎊的專業責任險」，這句話會被審查單位一條一條核對；寫錯了不是扣分而已，可能直接被取消投標資格。這種聽起來合理、卻沒有事實根據的內容，就是所謂的幻覺（AI hallucination）AI講出一段聽起來很有道理、但其實沒有事實根據甚至是編造出來的內容，在正式文件裡它幾乎是AI的預設行為，不是偶發的意外。
作者在七月的一次內部測試裡就撞上了活生生的案例。AI幫忙寫一份英國NHS標案草稿，文筆流暢，但裡面竟然有42項要求被寫成「由合作夥伴負責」——問題是，這個合作夥伴根本不存在，是AI自己「發明」出來的公司，連名字都編好了才在文件最底下用[PARTNER_NAME]帶過。更糟的是，他們自己拿來把關的合規對照表（compliance matrix）把標案要求逐條列出，一一對應「公司是否符合」的檢查表，通常是投標文件審查的核心工具系統，也把這42項標記成「已符合」——因為它只是比對關鍵字有沒有出現，而AI編造的段落剛好把關鍵字都塞了進去。兩個看起來都還算合理的元件（愛掰故事的AI＋只看關鍵字的檢查器），疊在一起反而讓造假變得更難被發現。
團隊後來的解法不是「把提示詞寫得更小心」，而是整個流程動刀：在AI真正開始寫草稿之前，先跑一個能力符合度檢查（capability-fit check）在AI動筆寫文件之前，先確認公司實際具備哪些條件、還缺什麼證明的把關步驟，逐條核對公司到底有沒有資格回答這項要求，沒有證據的地方就先攔下來、標成「這裡沒有證據支持」，而不是留給AI自由發揮。這也是為什麼一份£950,000的球場標案草稿，開頭第一段不是漂亮的自我介紹，而是一張警示清單：「11項要求目前是靠一個你還沒指定的合作夥伴在回答」——看起來像是AI在「拒絕」寫，但這正是整套系統裡作者最引以為傲的功能。
🏃 快速上手三步（今天就能做）
1
查AI幫你寫了哪些「查證型」句子把AI生成的文件拿出來，用螢光筆標出每一句涉及具體事實的地方——金額、年份、認證名稱、「我們具備⋯」這類句子。這些就是投標審查會逐條核對的地方，也是AI最容易「順口編」的地方。
▼
2
故意問AI一個你們沒有的資格測試時明知故問，例如「我們有沒有ISO 27001認證？」如果公司實際沒有，看AI是老實回答「查無資料、需要你確認」，還是自己編一個聽起來合理的答案。如果它編答案，這套AI流程現在還不能用在正式文件上，先別交件。
▼
3
核對和寫作分兩階段做，不要一次到位先讓AI（或你自己）把文件要求逐條列成清單，每條標記「有／沒有／不確定」，等全部核對完成後才進入正式寫作階段——這正是文章裡「capability-fit check」的做法，能大幅降低AI把「不確定」寫成「確定」的風險。
🧠 工程思維透鏡（資深工程師看到的是什麼）
🔭 為什麼「關鍵字比對」的把關機制反而讓問題更嚴重？
文章裡最驚人的postmortem是：AI編造了一個不存在的合作夥伴，而系統自己的合規檢查器竟然把這42項要求標記為「已符合」——因為檢查器只比對關鍵字有沒有出現，而編造的段落剛好包含這些關鍵字。這說明「用AI檢查AI」如果檢查邏輯太表面，兩個看似合理的元件疊在一起反而會產生更大的漏洞，比單一元件出錯更難察覺，也是多元件AI系統設計時最該提防的風險。
🔭 為什麼作者說「讓模型寫得好」根本不是這裡的難題？
現在的語言模型本來就寫得一手好文章，這不是問題；真正的工程難題是「讓系統逐行知道自己有沒有資格講這句話」。這代表要防止AI在正式文件上說謊，不能靠「把提示詞寫得更漂亮」，而要在AI生成文字之前，先用結構化的資料核對步驟把「事實」和「文筆」拆開處理——這是架構層級的解法，而非話術層級的解法，對任何想把AI用在高風險文件（合約、報告、法律文件）的人都適用。