測試失敗後，工程師很快在 Repository 裡找到一個 Function。

名字完全對得上。

內容也很像大家預期的流程。

prepare_package()
execute_update()
verify_result()

AI Source Search 也回了一樣的結論：

系統會先準備 Package，再執行 Update，最後進行 Verification。

看起來問題應該發生在 execute_update() 裡。

大家沿著那段 Code 查了半小時。

直到有人把當次 Runtime Log 往前翻。

沒有 prepare_package()。

沒有 execute_update()。

甚至沒有任何證據顯示這個 Case 進過剛才大家看的那個 Module。

另一條 Platform Branch 在更前面就把 Request 接走了。

Code 沒有錯。

AI 也真的找到了 Implementation。

只是那個 Implementation 和「這一次到底跑了什麼」不是同一個問題。

Source Code 能證明存在，不能自動證明發生

看到一段 Function 時，我們很容易從：

系統裡有這個實作。

直接跳到：

這次系統就是這樣跑的。

中間其實差了一份 Runtime Evidence。

Repository 回答的是：

What can this codebase do?
How is this path implemented?

Log / Result 回答的是：

What happened in this execution?
Which path was actually reached?

這兩種 Evidence 經常互相需要。

但不能互相替代。

如果只有 Code，最多能說：

有一條 Implementation Path 長這樣。

如果要說：

昨晚失敗的 Case 走的就是這一條。

還需要 Runtime Evidence 把它們接起來。

AI Search 很容易讓這個跳躍變得更順

以前工程師自己翻 Code，至少會感覺到「我現在只是在看 Source」。

AI Search 把事情做得更順之後，回答可能長成：

Update 流程由 prepare → execute → verify 組成，因此失敗應發生於 execute 階段。

前半句可能有 Source 支持。

後半句卻已經越過 Evidence 邊界。

因為「流程存在」和「這次走到這裡」之間，沒有 Runtime Trace。

這也是 Package 裡特別拆開：

Source implementation
≠
Resolved request / command
≠
Runtime evidence

的原因。

不是為了讓分析變麻煩。

而是避免一段正確的 Code，把一個尚未確認的 Runtime Story 包裝得很完整。

他們先問「這次走到哪裡」，再問「那裡怎麼寫」

後來 Log Analysis 的順序被固定得很簡單。

先從失敗 Case 找到 Runtime 真正走過的路徑。

確認第一個有意義的 Source Frame。

再回 Repository 看那一層的 Implementation。

不是反過來先 Search 一個看起來最像的 Function，再把整個 Runtime 套進去。

這個順序不會讓 Source Search 變得不重要。

反而讓它更精確。

因為當你知道 Runtime 真正到了哪一層後，AI 不需要在整個 Repository 裡猜「哪一段最像」。

下一次，AI 的第一句話變短了

又一個 Case 失敗。

有人問：

「是不是走到舊版 Update Path？」

AI 先查 Runtime Evidence。

回覆只有：

No runtime evidence currently shows invocation of the old update path.

接著才列出：

Repository 中確實存在該 Implementation，但本次 Case 尚無證據證明使用它。

工程師沒有再從那個 Function 開始 Debug。

他回到 Log 裡第一個真正出現的 Branch。

Source Code 還是在那裡。

只是從那天開始，「找得到這段 Code」不再自動等於「這次就是它跑的」。