一位工程師問 AI：

「這個操作有支援嗎？」

AI 搜 Repository。

很快找到一個名稱完全吻合的方法。

裡面甚至有完整參數和執行流程。

回答因此很乾脆：

Supported. The function is implemented in the current source.

工程師照著往下接。

到了測試環境，Function 卻沒有出現。

換另一台機器也一樣。

大家一開始以為是 Deployment 問題。

後來才發現，那段 Implementation 只存在某個 Platform Branch。

Repository 裡「有」，是真的。

這台 Target「不能用」，也是真的。

錯的不是其中一邊。

錯的是把 Implemented 直接翻譯成了 Universally Supported。

Implementation 是一種 Evidence，不是完整 Support Claim

當我們問「有沒有這個 Function」時，很容易把幾個問題混在一起：

Repository 裡是否有實作？

這個 Platform 是否走這份實作？

目前這台 Target 是否能使用？

第一題只需要 Source Evidence。

後兩題則可能還需要 Platform / Mapping / Current Environment。

Package 裡因此沒有只留下 Yes / No，而是明確區分：

Implemented
Platform-dependent
Not found

這個分類看起來只是多幾個字。

實際上是在阻止一個很常見的跳躍：

Found in source
→ Supported everywhere

AI 越會找 Code，這個問題反而越容易發生

以前工程師自己翻 Repository，看到 Platform Branch 時通常還會順手讀旁邊的 Condition。

AI Search 很快，只要使用者問：

支援 X 嗎？

它可能直接把最像答案的 Method 找出來。

如果回答只引用那個 Method，整段文字會非常有說服力。

甚至比「可能支援」更像有證據。

但證據支持的是：

有 Implementation。

不是：

你的 Target 現在可以用。

所以 Source Search 的結果需要保留 Support Scope。

如果 Platform 尚未確定，最精確的答案反而可能是：

Implemented, but platform-dependent.

這不是模糊。

是把 Evidence 能支持的範圍說完整。

他們沒有建立一張所有平台的永久支援表

有人提議乾脆把每個 Function × 每個 Platform 做成 Matrix。

理論上最清楚。

但這樣很快又會遇到另一個問題：

Mapping 會變。

Source 會改。

Platform 分支也會演進。

最後團隊只要求 Function Search 在回答時，不得把 Implemented 當成完整 Support 結論。

如果使用者沒有提供 Platform，就先說明：

Implementation found.
Platform support still needs resolution.

如果已知 Target，再去確認當下 Mapping。

只有確認後，才把答案升格成：

Supported on this target.

下一次，答案多了一個限制

又有人問：

「這個操作能不能在我們現在的 Target 上跑？」

AI 先找到 Implementation。

接著確認 Platform。

最後回：

Implemented: Yes
Target support: Platform-dependent
Current target: Not confirmed

這比一句「有支援」長了一點。

但工程師沒有再拿 Repository 裡的一個 Function，直接當成所有環境的能力清單。

同一段 Code 還是在那裡。

只是它終於只證明自己真正能證明的事。