使用者問：

「有沒有可以 Reset Network 的功能？」

AI 開始 Search。

找到幾個很接近的東西：

reset_adapter
restart_network_service
restore_network_config

沒有任何一個名稱完全叫 reset_network。

它又往幾個 Specialist 裡找。

最後回：

Not Found. No reliable implementation was identified for network reset.

這個回答很安全。

至少沒有硬拿一個相近 Function 當答案。

但使用者看完後問：

「我只是要重新啟動 Network Service，不是把設定 Reset 掉。」

AI 剛才其實早就找到 restart_network_service。

它不是沒找到功能。

而是「Reset Network」這句話本來就有兩種可能意思。

Not Found 也需要證據

大家通常比較擔心 AI 亂說「有」。

所以一個很自然的防守方式是：

找不到精確命中，就回答 Not Found。

這比硬猜安全很多。

但 Not Found 本身仍是一個 Claim。

它表示：

在問題已經被釐清之後，查過應查的 Source，仍沒有可靠 Implementation。

如果 Request 還是 Ambiguous，這個結論其實下得太早。

因為現在不知道的是：

Repository 裡沒有？

還是：

使用者的「Reset」到底指哪一種 Operation？

兩者下一步完全不同。

相近功能不能直接當相同功能，但也不能全部丟掉

Package 裡的 Function Search Rule 同時限制兩個方向。

第一個方向：

不得把相近功能直接當成同一功能。

因為 restart service 和 restore configuration 的後果可能完全不同。

另一個方向：

如果 Request 有歧義、Repository 又存在合理候選，先 Clarify，不要直接 Not Found。

也就是：

Ambiguous request
+ plausible candidates
→ Clarification

Clarified request
+ no reliable implementation
→ Not Found

這個差別很小。

卻決定了 Search Skill 是在判斷「系統有沒有能力」，還是在猜「使用者剛才那個詞到底指什麼」。

問一個問題，有時比多查十份文件更便宜

這個 Case 裡，AI 已經查了很多地方。

問題不是 Search 不夠完整。

如果它再多查五個 Repository，仍然無法知道使用者說的 Reset 是：

restart runtime service

還是：

restore settings to default

這種缺口不是 Evidence Gap。

而是 Intent Gap。

所以最小的下一步其實只需要一句：

你要的是重新啟動 Network Service，還是還原 Network 設定？

使用者選完後，Search Space 立刻縮小。

這也符合 Intent-first 的精神：

不要因為底層 Search 很強，就讓 Search 代替需求釐清。

後來，Not Found 前多了一個 Gate

團隊沒有要求 AI 每次 Search 前都追問。

如果 Request 已經很明確，就直接查。

只在這種情況停一下：

Request 有多種合理解讀
+
Search 找到相近但不等價的候選

這時候回答不是：

Not Found

而是：

Need clarification

幾天後，又有人問：

「有沒有可以清掉 Cache 的功能？」

AI 找到兩種不同 Scope 的 Cache。

它沒有選一個，也沒有說沒有。

只回：

「你要清的是 Application Cache，還是整個 Service Cache？」

使用者回答後，Function 很快就找到了。

這一次，Repository 沒有變得更完整。

只是 AI 終於分得出：找不到答案，和問題還沒問清楚，是兩件不同的事。