下午四點多，Support 群組有人丟了一句：

「幫我把剛才那個帳號權限問題補上最新進度。」

這種要求以前要先問是哪一張 Ticket。

現在 AI 可以自己找。

它用使用者名稱、關鍵字和最近時間去搜尋，很快只回來一筆：

Account access issue after role change
Status: In Progress

只有一筆。

標題也很像。

流程於是準備把剛才的新進度加進去。

就在 Write 前，系統多讀了一次完整 Summary。

旁邊的 Requester 不是剛才那個人。

時間也早了一天。

同一個部門剛好有兩張很接近的權限問題。

如果那一步沒有停下來，後面的 Comment 會完全合法地寫進另一張 Ticket。

API 不會報錯。

權限也沒有問題。

整個 Automation 甚至會回：

Update completed

只是工作做錯了 Object。

Search 找到的，是 Candidate，不是 Identity

搜尋系統的工作，是幫你縮小範圍。

它可以告訴你：

這幾筆很像你要找的東西。

但「很像」和「就是它」之間，中間還有一步。

尤其企業系統裡，同類型工作本來就會大量長得很像。

Account access issue
Account access issue after role update
Cannot access system after permission change

如果使用者自己有 Ticket ID，問題很簡單。

但真實工作裡，人更常說的是：

剛才那張。
那個權限問題。
昨天 PM 提的那一筆。

AI 很適合把這些自然語言拿去找 Candidate。

問題出在：

搜尋命中率不能直接升格成 Object Identity。

如果後面只是 Read，拿錯一筆頂多回答錯。

如果後面接的是 Write，風險就變成改錯正式資料。

後面的每一步都可能是對的

這種錯誤特別難察覺，因為它不一定會產生 Error。

假設 AI 找到錯的 Ticket 之後：

1. 正確取得目前狀態。
2. 正確讀到 Comment 欄位。
3. 正確生成要追加的內容。
4. 正確呼叫 Update。
5. 正確得到成功回應。

每一層都可能完全正常。

真正錯的是最前面那個：

Candidate
被當成
Target

這也是 Work Integrator 很容易忽略的地方。

我們常把「Search → Result」看成完成定位。

但如果後續 Action 依賴一個明確 Object，真正需要的是：

Search
→ Candidate
→ Identity Check
→ Target
→ Action

不是每個 Search 都要人工確認。

但系統至少要知道自己現在拿到的是 Candidate，還是已經有足夠資訊把它視為 Target。

他們沒有要求所有人記 Ticket ID

有人建議最簡單的辦法：

「以後使用者一定要貼 ID。」

這當然很安全。

但也等於把系統原本可以處理的解析工作重新丟回使用者。

最後團隊保留自然語言入口。

只在 Search 後多做最小 Identity Check。

例如拿到候選後，再核對：

Summary
Requester / Target
Current context

如果仍然有兩筆都合理，就回來問人。

如果唯一候選在關鍵資訊上不吻合，就不因為 Search Rank 第一名而硬接著做。

這不是讓 AI 變保守。

只是不要把「我找到了很像的東西」說成「我知道你指的是哪一個」。

下一次，AI 多回了一行

幾天後又有人說：

「把昨天那張登入問題切成 In Progress。」

AI 找到兩張相近的 Ticket。

這一次它沒有先動。

畫面上出現：

I found 2 possible matches.
Need target confirmation before update.

使用者看了一眼，選了第二張。

後面的 Status Update 只花幾秒。

真正多出來的工作，其實只有前面那一小步。

但從那天開始，Search Result 不再自動等於「就是這一張」。