系列：從現場踩坑到 AI 工具 — IT Diagnostic Agent 開發實錄
本篇為系列核心篇之一

一句話，一整篇文章

昨天列出的五條規則後面，有一句 PS：

If additional evidence cannot change your next action, do not ask for it.

如果額外的證據不會改變你的下一步行動，就不要索取它。

它是整組規則裡最短的一句，也是我認為最重要的一句。

今天整篇文章只講這一句話。

為什麼一句話值得一整篇

因為它把一個模糊的直覺，變成了一個可以執行的測試。

「不要問太多問題」是廢話——太多是多少？「問重要的問題」也是廢話——什麼叫重要？

但這句 PS 給了一個明確的判準：

問之前先自問：「如果我現在就知道答案，這會改變我接下來做什麼嗎？」
如果不會，就不要問。用現有的證據往下走。

這是一個二元判斷。它可以被檢驗、可以被爭論、可以在具體案例上驗證對錯。這就是它跟一般 Prompt 原則的差別。

Evidence 與 Information 的分界

這句 PS 真正劃出的界線，是「證據」和「資訊」的差別：

• Information（資訊） = 任何可以被收集的東西
• Evidence（證據） = 會改變行動的資訊

所有的證據都是資訊，但大部分資訊都不是證據。

「Evidence-driven」這個名字，關鍵不在 Evidence，在那個排除——它明確地不是 Information-driven。

多收集資訊不等於多收集證據。一個問了二十個問題才給答案的診斷流程，不會比問三個問題的更嚴謹，它只是更慢。

具體例子：哪些問題是證據，哪些只是資訊

我用真實的 IT 情境來對照。

情境：使用者說「我不能連公司內部伺服器」

❌ 資訊，不是證據

「請問您的作業系統版本是？」

先套用測試：如果我現在就知道他用 Windows 10 還是 Windows 11，我的下一步會不一樣嗎？

不會。無論哪個版本，我下一步都是叫他 ping 伺服器 IP。

這個問題純粹是好奇心，或是「表現得很專業」的儀式感。它花掉使用者三十秒，換來零決策價值。

✅ 證據

「其他同事現在連得上嗎？」

如果答案是「連不上」→ 問題在伺服器或網路，我去查伺服器。
如果答案是「連得上」→ 問題在他的電腦或他的網路路徑，我去查他那端。

兩個答案導向完全不同的行動。這是證據。

情境：印表機離線

❌ 資訊

「這台印表機是什麼型號？」

除非型號會改變處理步驟（有些機型有特殊的重置流程），否則在「離線」這個階段，無論什麼型號我下一步都是先確認電源和網路。

✅ 證據

「印表機面板上有顯示 IP 位址嗎？」

有 IP → 網路層是通的，往驅動或佇列查。
沒有 IP → 網路連線根本沒建立，往線材或 DHCP 查。

一個微妙的例子

「請問您上次成功使用是什麼時候？」

這個問題看情況。

如果答案只會是「昨天」或「上禮拜」，而我的處置不因此改變 → 資訊。

但如果答案可能是「今天早上還可以，中午之後就不行了」，而公司中午剛做過網路變更 → 這是證據，而且是高價值證據，它直接指向變更管理紀錄。

同一個問題，在不同脈絡下可能是證據也可能是雜訊。這就是為什麼這個測試必須是動態判斷，不能寫成固定清單。

為什麼 LLM 天生會違反這條規則

這不是模型的缺陷，是訓練目標的必然結果。

LLM 被訓練成要「有幫助」，而「有幫助」在大量的訓練文本裡長得像詳盡。一份完整的十五點分析，讀起來就是比一句「先去 ping 一下」更像專業回答。

於是它的預設行為是最大化完整性（maximize completeness），而不是取得下一個最高價值的證據。

這兩個目標函數在大部分情境下不衝突。但在故障排查的當下，它們是對立的：

PS 那條測試，就是把目標函數從左邊換到右邊的那個開關。

現場的時間成本，是這條規則的真正理由

我為什麼一看到這句話就知道它是對的？

因為我算過現場的成本。

故障發生時，你面對的通常是一個焦慮的使用者，或是一個正在停線的產線。每一個你問出去的問題，成本包含：

• 使用者理解問題的時間
• 使用者去確認答案的時間（可能要走到機器旁邊）
• 你等待的時間
• 使用者對「你到底知不知道在幹什麼」的信任損耗

最後一項最貴。

一個問了五個無關問題才進入正題的工程師，即使最後解決了問題，使用者對他的評價也會是「搞很久」。

而一個第一個問題就切中要點的人，會被認為「一看就知道」。差別不在知識量，在問題的選擇。

結構化地看這條規則

用靜態 / 動態的角度拆：

我原本的版本是靜態的。 我寫過一條例外條款：「如果使用者要求快速回答，就跳過證據盤點。」這是一條 if-else，事先寫死。

PS 這條是動態的。 每一個問題都要現場評估「這會不會改變行動」。沒有事先寫死的清單，只有一個每次都要跑一遍的測試。

這個差別很關鍵。因為現場的情況組合是無限的，任何靜態規則都會漏。而一個動態的判準，可以套用到你沒預想過的情境。

好的原則不是列舉所有情況，是給出一個能生成正確判斷的測試。

這條規則對人一樣有效

寫到這裡我意識到一件事：這條規則的原始適用對象是 LLM，但它對人的效果一樣好。

它其實就是資深工程師和菜鳥的差別。

菜鳥會問很多問題，因為他不確定哪個重要，所以全部都問。
資深的人問得少，因為他知道哪些答案不會改變他的下一步。

我做了二十年，如果要我用一句話總結我跟二十年前的自己的差別，大概就是這句。

只是我從來沒有把它寫下來過，直到一個 LLM 幫我寫出來。

今天的反思

我一直以為排障能力是「知道很多可能的原因」。

寫完這篇我更確定：排障能力是知道哪些問題不用問。

前者是知識，可以查、可以背、AI 比你強。
後者是判斷，來自於你真的在現場等過那三十秒。

明天預告： 五條規則和決策相關性測試都定案了。但接下來有一個更根本的問題——你要怎麼確保 LLM 真的遵守？我的答案是：不要靠它自律，靠結構。

作者：Rich Chang | IT 基礎建設工程師 | 越南・柬埔寨・台灣