星期三下午，一位工程師問內部 AI：

「這個 Interface 支援自動重試嗎？」

AI 很快查了幾份文件和 Source。

沒有找到明確設定。

也沒有找到一個可以直接指向 Retry 的實作位置。

但幾秒後，它還是回了：

這類 Interface 通常具備 Retry 機制，應可在暫時性失敗時自動重試。

句子很合理。

語氣也不算絕對。

工程師於是把設計文件裡的一項 Fallback 拿掉。

理由是：

底層已經會 Retry。

隔天測試失敗。

真正回頭查 Local Source 時，大家才發現：

這個 Repository 裡根本沒有可靠 Evidence 證明這件事。

AI 沒有找到答案。

只是它沒有停在「沒找到」。

LLM 很擅長把空白補成完整句子

如果只是聊天，這通常是優點。

人問一個概念，模型可以根據大量一般知識整理出合理說明。

但在工作現場，有一類問題不是在問：

一般來說會怎麼設計？

而是在問：

我們現在這個系統，真的有嗎？

這兩句差很多。

前者可以接受一般知識。

後者需要 Evidence。

如果 Source of Truth 是 Local Repository，那麼沒有找到可靠實作時，最重要的不是生成一句更像答案的文字。

而是保留目前的 Evidence State。

Package 裡把這個原則寫得很直接：

Implemented
Platform-dependent
Unknown
Not found

這些狀態不能因為模型「知道一般情況」就被壓成一個 Yes / No。

Unknown 不是回答失敗

很多 AI 介面會讓人不自覺追求一件事：

每次都要給答案。

所以當證據不夠時，模型很容易改用語言的流暢度把空白補起來。

但 Work Integrator 真正需要的，往往不是「有沒有一句話可以交差」。

而是：

我現在能確定到哪裡？

例如同一個問題，可以回成：

Result: Unknown

What was checked:
- local source
- current documentation

What is missing:
- reliable implementation evidence

這個答案看起來比較不聰明。

卻比一個沒有證據的「應該有」更能讓後面的工作繼續。

因為下一個人知道自己缺的是 Evidence，不是缺一個更好的 Prompt。

「找不到」也不能亂用

Fail Closed 不代表只要沒看到就直接說 Not Found。

Not Found 本身也是一個結論。

它意味著：在已經釐清問題、查過應查的 Source 後，仍沒有可靠實作。

如果現在只是 Source 不完整、Platform 還沒確認，或 Request 本身有歧義，更合理的狀態可能是：

Unknown

或：

Platform-dependent

所以真正要保留的不是悲觀。

而是 Evidence 和 Claim 之間的界線。

他們最後拿掉了一句「應該」

團隊後來沒有禁止 AI 使用一般知識。

只是在需要回答 Local Implementation 的 Search Skill 裡，改了一條規則：

沒有 Local Source Evidence，就不要用一般知識補成 Implemented Claim。

同一位工程師幾天後又問：

「這個 Platform 支援另一個操作嗎？」

AI 查完後回：

Result: Platform-dependent

Current evidence is insufficient to confirm support on this target.

他沒有直接拿這句話去做設計。

而是先去補 Platform 資訊。

這次 AI 沒有給出一個漂亮答案。

但它把真正還不知道的地方，完整地留了下來。