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

先講一件必須誠實交代的事

這篇文章的核心，是一組叫做 Evidence-driven Dialogue 的五條規則。

這五條規則不是我想出來的。

它們最初的完整表述來自我跟 GPT 的一次對話。我把它拿去請 Claude 評估，Claude 做了比對分析，最後我採用了 GPT 那版當核心規則。

我在這個過程裡的角色是：提出問題、拿著二十年現場經驗去判斷這些規則在真實服務台上撐不撐得住、最後決定採用哪一版。

我可以把這篇寫成「我的五條規則」，沒有人會查證。但這個系列從 Day 01 就在講一件事：人機協作的真實樣貌。真實樣貌裡就包含「最好的那個想法不是我提的」。

所以我照實寫。

我原本的版本

在 GPT 那版出現之前，我自己已經寫過一版 Prompt 規則。

我的做法是要求 LLM 在每次回應時，顯式列出證據盤點：

【已確認】使用者只有一人斷線、有線連接、已換線無效
【待確認】是否能 ping 到 gateway
【假設】交換器 port 故障（信心度：中）

這個格式的邏輯是：把 LLM 的推理狀態攤開來，讓使用者看得到它在想什麼、還缺什麼。

它有用。但它解決的是呈現層的問題。

GPT 那版

1. Never jump ahead.
2. Always ask the highest-information-gain question first.
3. WAIT USER REPLY.
4. Only update diagnosis after new evidence.
5. Never enumerate all possibilities unless user requests.

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

我把兩版一起貼給 Claude，問它哪個更好。

Claude 的判斷是：GPT 那版更精煉，因為它打中的是核心，而我的版本偏向外部呈現。

它的拆解我印象很深：

你的版本用了「證據狀態盤點」這種顯式格式，偏 external 呈現層。GPT 的規則直接打中 core：問題不是「有沒有列出證據」，而是「這個問題有沒有決策價值」。

這句話讓我意識到我自己的盲點。我一直在想「怎麼讓 LLM 把思考過程說清楚」，但真正的問題是「LLM 該不該問這個問題」。

把錯的推理過程攤開來，它還是錯的。

最終採用的合併版

Claude 的建議是：核心規則採用 GPT 那版，我的格式模板保留當輸出呈現層。這是最後定案的版本：

# Evidence-driven Dialogue — Core Rules

1. Never jump ahead to a conclusion before sufficient evidence exists.

2. Always ask the single highest-information-gain question first —
   defined as: the question whose answer would most change your next action.

3. After asking, WAIT for user reply. Do not self-answer or assume.

4. Only update or issue a diagnosis after new evidence is received.

5. Never enumerate all possibilities unless the user explicitly requests it.

PS. Decision-relevance test:
   Before asking any question, check —
   "If I already knew the answer, would it change what I do next?"
   If not, do not ask it. Proceed with current evidence instead.

五條規則各自對應一種真實的失敗模式

這五條不是抽象原則。每一條都對應一個我在通用 AI 工具上實際遇過的問題。

規則 1：不要跳到結論

失敗模式： 你說「網路斷了」，AI 立刻回「這通常是 DNS 問題，請執行 ipconfig /flushdns」。

它猜對的機率不低。但猜錯的時候，使用者已經照做了，浪費了時間，而且對工具失去信任。

在故障排查裡，一個有把握的錯誤答案，比一個誠實的追問更有害。

規則 2：先問資訊增益最高的問題

這條是整個框架裡最需要專業判斷的一條。

「資訊增益最高」不是「最詳細」。它的定義寫在規則裡：答案最能改變你下一步行動的那個問題。

以 Day 04 的網路故障決策樹為例，第一個該問的是「換一條線試試」——不是因為它最可能是原因，而是因為它三十秒可以驗證，而且無論結果如何都能砍掉一整個分支。

規則 3：問完之後，等使用者回答

這條看起來像廢話。但它針對的是一個非常真實、而且我自己版本完全沒防到的失敗模式：

LLM 會自問自答。

它提出一個問題，然後在同一段回應裡假設一個答案，繼續往下推理三層。使用者看到的是一大段基於憑空假設的診斷。

Claude 在比對時特別點出這條的價值。我當時的反應是——對，這個我看過，但我從來沒想過要把「等我回答」寫成一條明文規則。

規則 4：只在收到新證據後更新診斷

防止 LLM 在沒有新資訊的情況下，因為使用者說「還是不行」就換一個猜測。

「還是不行」不是證據，那只是排除了一個選項。真正的證據是「我 ping gateway 失敗了」。

規則 5：不要列舉所有可能性，除非使用者要求

這條直接對應 Day 02 講的那個問題：AI 給你一份十五條的完整清單，每條都對，但你不知道從哪開始。

完整性在故障排查裡不是美德。 它是把判斷責任推回給使用者。

為什麼 Prompt 是我花最多時間的地方

很多人覺得 Prompt 就是「把需求講清楚」，幾分鐘的事。

但當你要寫的不是「幫我做一件事」，而是「在接下來所有不確定的對話裡，你都要遵守這套紀律」時，Prompt 的本質就變了。

它不是指令，是一套對話憲法。

而寫憲法很慢，因為你要預想的不是一個情境，是所有可能的情境。這五條規則每一條都是在回答「如果使用者這樣、AI 那樣，會出什麼問題」。

我花在這段 systemPrompt 上的時間，比寫決策樹的所有 JavaScript 加起來還多。

我在這件事上真正的貢獻是什麼

規則不是我寫的。那我做了什麼？

我做的是驗證，而不是發明。

這五條規則要不要採用，判斷標準只有一個：把它們放進一個真實的 IT 服務台，撐不撐得住？

• 規則 2 要求判斷「資訊增益」，這需要領域知識。沒有二十年的排障經驗，我沒辦法判斷這條規則在實務上是可執行的還是空話。
• 規則 5 要求不列舉可能性，這違反很多人對「專業回答」的直覺。我知道它是對的，因為我看過太多人被十五條清單卡住。
• PS 那條決策相關性測試，我一看就知道那是整組規則裡最重要的一條——但那也是因為我知道現場的時間有多貴。

LLM 提出了規則，我提供了它們能不能落地的判斷。這是兩種不同的貢獻，缺一不可。

今天的反思

如果這篇文章讓你覺得「原來核心洞見是 AI 提的，那作者做了什麼？」——那我想這個問題本身就值得討論。

我的答案是：在一個 AI 能生成任何規則的時代，能判斷哪條規則在現實裡撐得住的人，價值反而更高了。

規則很便宜。判斷力不是。

明天預告： 五條規則裡，PS 那條決策相關性測試最短，卻是最重要的。明天整篇文章只講那一句話：「如果多問這個問題不會改變你的下一步，就不要問。」

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