系列：從現場踩坑到 AI 工具 — IT Diagnostic Agent 開發實錄
最終篇
三十天的終點，這個專案的實際狀態：
| 項目 | 數字 |
|---|---|
| GitHub Stars | 27 |
| Forks | 23 |
| Watching | 0 |
| Issues（全部已結案） | 2 |
| 有硬證據的真實使用者 | 2 |
| 企業部署回饋 | 0 |
index.html 行數 |
3203 |
| 檔案數 | 1（單檔） |
| 後端 | 無 |
| 系列期間修正的缺口 | 3 |
| 仍未解決的問題 | 4 |
沒有一個數字是好看的。
我把它們完整列出來，因為 Day 15 那篇文章的教訓就是把假設當成事實是最容易犯的錯，而一個漂亮的收尾往往就是從美化數字開始的。
文章發布大約一個月後，我收到一封 email。
寄件人是 iThome 的產品經理。她看到我在 iT 邦幫忙分享的那篇《用 Claude AI 做了一個開源的 IT 故障排除工具》，說對「結合實務經驗、AI 與離線部署」這個組合印象深刻。
她來信的目的不是稱讚，是做平台研究。iThome 當時在思考如何讓「專案開發實戰」這類內容有更多被看見與交流的機會，所以想問幾個問題：
我回了信，她也回了謝。這件事就自然結束了，沒有後續。
因為它是一個跟 Star、Fork、Watch 完全不同種類的訊號。
Day 27 的結論是：49 個訊號，2 個確認的使用者。而那 49 個訊號全部都在回答同一個問題——有多少人注意到這個工具。
這封信回答的是另一個問題：這件事有沒有被認真對待。
它沒有告訴我任何人部署了工具。它告訴我的是：文章落地了。 一個平台的產品經理讀完之後，判斷這類內容值得投入資源去研究。
而這兩件事必須分開看，不能混為一談：
| 證明了什麼 | 沒有證明什麼 | |
|---|---|---|
| 27 Stars / 23 Forks | 工具被注意到 | 有人在用 |
| 2 個 Issue | 2 個人真的在用 | 有多少人在用 |
| 這封 email | 寫作被認真對待 | 工具有價值 |
我特別要強調第三列的第二格：這封信不是對工具的驗證。
如果我把它當成「我的專案得到 iThome 認可」，那我就又在做 Day 27 那件事了——為一個好看的訊號找一個對我有利的解釋。
她讚賞的是那個組合（實務經驗 + AI + 離線部署）作為一篇內容的價值。她沒有裝過這個工具，沒有跑過決策樹，也沒有評估過它能不能解決故障。
分清楚「內容被肯定」和「產品被驗證」，是我在寫完 Day 27 之後學到的紀律。
這是我覺得最值得記錄的部分。
她問的第三題裡有一個選項：「缺乏找到測試者、使用者或合作夥伴的管道」。
而 Day 27 整篇文章的結論，用我自己的話說是：
我不知道有多少人在用，而且我選的架構讓我永遠不會知道。
一個平台產品經理在做研究時列出的痛點清單，和我在盤點自己數據時發現的空白，是同一個東西。
她是從平台端看到這個問題（很多人分享專案，但找不到真實使用者），我是從創作者端撞到它（26 個 Star，2 個確認的使用者）。
兩邊獨立指認同一個缺口，這件事本身就是證據——它說明這不是我一個人的問題，是一個結構性的問題。
而這也讓我對這個缺口的性質有了新的理解：
Day 27 我把它歸因於自己的架構選擇（零後端、零追蹤，所以永遠不會知道）。那是真的，但不完整。
因為就算我做了追蹤，我也只會知道「有人打開了」，不會知道「他修好了他的問題嗎」。
而後者需要的不是技術，是一個能讓開發者和使用者真的對話的管道。
那個東西目前不存在——不在 GitHub 的 Star 數裡，不在我的 localStorage 裡，也不在任何一個平台的機制裡。
這大概是這三十天下來，我唯一發現的一個「不是我能自己解決」的問題。
它真的能用。兩個陌生人在自己的環境裡跑起來，撞到了只有真的在用才會撞到的 bug（Day 26、Day 27）。
它做到了我一開始想要的：在故障當下，引導一個不需要深厚背景的人，一步一步找到下一個該做的動作。
它也有明確的天花板：樹外無路、單檔到 3201 行、沒有自動化測試。這些是我刻意接受的代價（Day 14、Day 21）。
Evidence-driven Dialogue 的五條規則和決策相關性測試（Day 12、Day 13）。
規則不是我發明的——它們來自一次跟 GPT 的對話，我原本的版本比較差。我提供的是判斷它們在真實服務台上撐不撐得住。
而最有價值的發現不是規則本身，是稽核結果：我的靜態決策樹早就在結構上滿足了這五條，因為節點是人寫的，紀律由程式碼強制執行，不依賴 LLM 自律（Day 14）。
這幾條我認為是可以被別人直接拿走用的東西。
這是我覺得這篇最該寫的部分。
1. Day 15 那兩行還沒改 → 已修正（commit d2455c0）index.html 第 983 和 1098 行的 sys: 字串，五條規則一條都沒有，而且那三句「先給診斷關鍵問題、依嚴重程度排列、結尾加預防建議」是在往反方向推。現在五條規則和決策相關性測試都寫進去了，中英各一份。
2. Ollama 確認 modal 少了 → 已補上（同一個 commit）OLLAMA_ORIGINS
Issue #2 的根因是 CORS。README 早就補了，modal 的 checklist 拖到寫這個系列時才發現沒補。本機和區網兩份清單都加上了。
3. 小模型在 AI 對話路徑上到底行不行，沒測過 → 已初步驗證gemma3:12b 三輪對話，五條規則加 PS 測試全數守住。但範圍要標清楚：這是 12B 的結果，更小的模型在哪一條先失守還不知道。
4. 企業版零驗證
四個假設，一個已驗證的技術限制（Day 28）。而我一直在完善文件，沒有去問任何一家企業願不願意做第一階段驗證——因為完善文件是舒適的那一半。
5. GSD 在 Windows 上的 bash hook 錯誤cannot execute binary file。判定為非阻斷性，忽略中（Day 21）。
6. 我不知道有多少人在用，而且我選的架構讓我永遠不會知道
零後端、零追蹤、資料不出使用者瀏覽器——這是承諾，也是代價（Day 27）。
7. 介面切英文時，模型仍用中文回答
語言切換綁的是介面語系，不是輸入語言。這是測試過程中發現的，而它的性質跟第 1 項是同一個模式——又是一個例外路徑。
上面那份清單，原本六項全是紅字。
寫這個系列的過程中，前三項被解決了。而解決它們的順序很有意思：
Day 15 稽核發現 systemPrompt 缺口
Issue #2 暴露 modal 缺口
↓
一次修正，兩個缺口（commit d2455c0）
↓
規則進到 Prompt 之後，Day 20 那個測試才做得了
↓
gemma3:12b 三輪測試，六項規則全守
第 3 項之所以能解決，是因為第 1 項先被解決了。 在規則進到 systemPrompt 之前，我根本沒有東西可以測——要測的紀律不在那段 Prompt 裡。
而第 1 項之所以被發現，是因為我請 Claude 去稽核自己的程式碼（Day 15）。
這條鏈上的每一步，都是被「寫下來」這個動作推動的。
而剩下的第 4 到第 7 項，全部都還在。我沒有要假裝它們不重要。
三十天下來，程式相關的東西我確實學了一些：CSS 變數、i18n、混合內容政策、四家 LLM API 的差異。
但那些不是重點，因為那些可以查。
真正改變我的是三件事。
Day 21 講過我的實際流程：GSD 提問 → 我截圖給 Claude → Claude 分析 → 我判斷 → 回答 GSD。
我在那個迴路裡是決策者，不是實作者。
而我做決策的依據，是二十年的現場經驗告訴我「哪種壞法我承受不起」。
Phase 3 那個「不重寫靜態樹 HTML」的決定最能說明這件事：200 行改動、沒有自動化測試、動的是主要路徑。Claude 可以分析技術風險，但「使用者在柬埔寨工廠現場點開一個空白節點」的代價有多重——那個判斷是我的，因為那個現場我待過。
我原本以為「不會寫程式」是我做工具的障礙。實際上障礙在別的地方，而那個地方剛好是我二十年來累積的東西。
Day 24 列了五個修正，Day 25 做了完整交代。而那五次修正有一個共同模式：
AI 錯的方向，全部都是「讓故事更符合常規敘事」。每一個錯誤都比真相更合理。
而每一次改成真相，文章都變好了。五次，零例外。
這件事在 Day 27 又發生了一次：我在六月看到 Fork > Star，為它找了一個對我有利的解讀，還寫了 LinkedIn。兩個月後模式反轉了，而那個一直是 0 的 Watching 我從來沒看。
誠實不是道德選擇，是方法論。 因為造假的版本會讓你看不見下一步該去哪裡。
Day 13 那條決策相關性測試，我後來發現它的適用範圍遠超過 IT 診斷。
寫 Day 28 的時候我用它問自己：關於企業版，哪個問題的答案最能改變我接下來做什麼？
不是定價、不是規模化——是「有沒有任何一家企業，願意讓我做第一階段驗證？」
而我還沒去問。
這條測試最有用的地方，不是幫我篩掉該問別人的問題，是幫我看到自己一直在迴避的那個問題。
Day 25 提過，我想在最後再說一次，因為三十天下來我還是沒想清楚。
如果我的貢獻主要是判斷力，那判斷力是怎麼來的？
我的判斷力來自二十年的現場——親手 ping 過的 gateway、換過的網路線、凌晨三點修過的伺服器。來自我曾經做過那些現在可以被外包的工作。
那麼一個從一開始就把實作交給 AI 的人，他的判斷力從哪裡來？
我不知道。
我確定的只有一件事：我今天能有效地使用 AI，是建立在我曾經沒有 AI 的二十年上面。 而這件事不可複製。
這不是在說年輕人不行。他們會發展出我想像不到的能力——就像我這一代發展出了上一代想像不到的能力。
但我不會假裝我知道那條路長什麼樣，也不會假裝我的路還走得通。
按決策相關性排序，不按舒適度排序：
1. 找出小模型的失守邊界
12B 通過了，但那不是「最低規格」。要往下測 7B、4B、3B，逐條檢查五條規則在哪一個尺寸開始失守。
最先撐不住的那條規則，就是小模型能力的真實邊界。 而那個數字可以直接寫進 README 和企業導入文件——「本工具最低建議規格為 X」 這種話，比任何論述都有說服力。
2. 去問第一家企業
一個客戶，一次本地模型驗證。這是最不舒適但最該做的一件事。
而現在比一個月前有底氣一點了——至少我可以說「本地模型跑得起來，而且診斷紀律守得住，這是三輪測試記錄」，而不是「理論上應該可以」。
3. 修掉語言路徑那個問題
介面切英文但模型回中文。小問題，但它是 Day 15 那個模式的重演，我不想再讓一個例外路徑躺在那裡。
4. 什麼都不做，接受它就是一個小工具
這一項是真的選項，我沒有排除它。
一個純靜態、零後端、發出去就失去聯繫的工具，本質上就是一把螺絲刀。而一把好用的螺絲刀不需要商業模式。
Day 29 講的那個道理我要用在自己身上：「這個市場被忽略」可能不是別人的疏忽，是別人算過之後的選擇。 而我還沒算過。
至於那個「找不到使用者」的結構性問題——我沒有把它列進待辦，因為它不在我能解決的範圍內。
我能做的只有最小的那一步：在 README 加一句「如果你部署了，歡迎開個 Discussion 說一聲」。
這是一個很弱的解法。 它把責任推給使用者的主動性，而一個工具最不該依賴的就是使用者願意多做一件事。
但在有更好的機制出現之前，這是我唯一能做的。
三十天前的 Day 01，我寫的是「如果今天重做一次，我不會先寫程式」。
三十天後我想補一句：如果今天重做一次，我會更早開始寫這些文章。
因為這三十篇裡有四個缺口，是寫的時候才發現的。
我原本以為寫作是把已經想清楚的東西記錄下來。
實際上寫作是逼你發現你以為想清楚了、但其實沒有的地方。
而這件事，AI 幫不了你。它可以把你的想法寫得很流暢——這三十篇的草稿就是它寫的。但它不知道那天到底發生了什麼事，也不知道你在迴避哪個問題。
只有在現場的人知道。
第一章｜問題其實不在程式
Day 01 不會先寫程式 · Day 02 太會回答卻不會排障 · Day 03 Runbook 文化 · Day 04 經驗變決策樹 · Day 05 不是聊天機器人
第二章｜純靜態架構與人機協作的第一次翻車
Day 06 純靜態 HTML · Day 07 GitHub Pages 踩坑 · Day 08 自製 i18n · Day 09 淺色模式文字消失 · Day 10 手機版跑版
第三章｜Prompt 就是產品
Day 11 瀏覽器直呼 API · Day 12 五條規則 · Day 13 決策相關性測試 · Day 14 結構取代自律 · Day 15 稽核找到反向指令
第四章｜多模型與本地部署
Day 16 Adapter Pattern · Day 17 八個維度全不同 · Day 18 相容只保證快樂路徑 · Day 19 資料落地是否決條件 · Day 20 需要多大的模型
第五章｜Claude 不只寫程式
Day 21 GSD 工作流 · Day 22 規格層贏過對話層 · Day 23 保護強度對應不可逆性 · Day 24 我是事實的來源 · Day 25 誠實揭露
第六章｜開源之後與從工具到產品
Day 26 兩個 Issue · Day 27 那個 0 · Day 28 零驗證的商業計畫 · Day 29 母語寫的節點 · Day 30 本篇
專案連結
richchang0721-boop.github.io/it-diagnostic-agent
github.com/richchang0721-boop/it-diagnostic-agent
如果你部署了，歡迎開個 Discussion 說一聲。畢竟根據 Day 27，我對這件事知道得非常少。
謝謝看到這裡的每一位。
特別謝謝 tskerpnext 和 kuang1963——你們是這三十篇裡我唯一有硬證據的兩個使用者，而你們告訴我的都是我自己不可能發現的東西。
也謝謝那位來信的 iThome 產品經理。你問的第三個問題，我當時回答得不夠好，因為我還沒想清楚。三十篇寫完之後我才知道那是整件事裡最難的一題。
作者：Rich Chang | IT 基礎建設工程師 | 越南・柬埔寨・台灣
iThome鐵人賽
看影片追技術
看更多