使用者在對話框裡打了一句：

「把這張工作單切到待審核。」

人看得懂。

AI 也看得懂。

但真正準備執行時，系統回來的是另一種語言：

Available transitions

21
34
57

沒有「待審核」。

也沒有一個可以直接拿人類語言送進去的欄位。

開發的人很快找到以前用過的 Mapping：

Pending Review = 34

照理說可以直接送。

但在真正執行前，流程重新讀了一次這張工作單目前可用的 Transition。

34 這次代表的是另一個狀態。

同一個編號，在另一個流程裡並不是同一件事。

如果直接套舊 Mapping，系統不一定會報「你理解錯了」。

它只會照那個 ID 去做。

人說的是工作，系統存的是識別碼

企業系統裡有很多這種東西：

• Transition ID
• Field ID
• Option ID
• Setting Code
• Object Key

它們很重要。

因為機器需要一個精確、不含糊的 Target。

問題是，這些東西屬於 implementation detail。

使用者真正知道的是：

我要把這筆工作送去審核。

如果介面反過來要求他先知道：

請提供 transition ID。

那等於把系統內部的 Mapping 工作丟回人。

AI 出現之後，這個問題更明顯。

因為自然語言入口本來就有能力理解人的工作意圖。

如果最後還是要求使用者自己翻 ID 表，前面那一層 Intent Resolution 幾乎沒有意義。

但「不要讓人看 ID」不等於可以猜 ID

另一個極端也很危險。

既然使用者不該知道 ID，那就讓 AI 自己猜。

例如看到：

Pending Review

然後從記憶裡拿一個以前成功過的 34。

這看起來很自然。

尤其在同一套系統裡，昨天才剛用過。

但 Package 裡真正留下來的規則剛好相反：

Dynamic ID / Mapping 必須從 current metadata 或當前 mapping resolve，不應靠名稱猜，也不能把另一個 project / platform 的 ID 直接重用。

也就是：

Human Intent
「送去待審核」

↓ resolve

Current system meaning
Pending Review

↓ resolve

Current internal identifier
57

使用者不用知道 57。

但系統自己必須知道它為什麼是 57。

Internal ID 最好只在真的有用時出現

有些團隊會把所有 ID 都顯示在介面上，覺得這樣比較透明。

結果使用者收到的是：

Transition 57 completed on object 83142.

技術上很精確。

工作上幾乎沒有資訊。

真正有用的回覆通常是：

已將工作單移到「待審核」。

如果遇到錯誤、需要人工比對，或需要做 audit，再把 internal identifier 帶出來。

所以原則不是「把 ID 藏起來」。

而是：

先用人的工作語言完成 Intent Resolution；Internal ID 只在執行或驗證需要時出現。

他們最後刪掉了使用說明裡的一欄

原本的操作文件寫著：

To move an item to Pending Review,
provide transition_id.

後來改成：

Tell the system the target work state.
The current identifier is resolved at execution time.

隔週，一位剛接手的人第一次使用。

他只打：

「這張可以送審了。」

系統先確認目前 State，讀取當下可用的 Transition，再完成動作。

回覆裡沒有一串他不認識的數字。

只有：

Current state: Pending Review

那個真正被送進 API 的 ID 還是存在。

只是它終於回到了它該待的地方：系統內部。