系列：從現場踩坑到 AI 工具 — IT Diagnostic Agent 開發實錄
這篇文章講的是一個還沒被驗證的商業計畫。
我必須在第一段就說清楚：
關於企業部署，我手上的實際回饋是零。
沒有企業告訴我他們裝了。沒有人回報部署過程。沒有付費、沒有詢價、沒有導入案例。
我有的只是一份規劃、一份導入文件、一個一頁式商業簡介，以及 Day 19 那些從實際接觸中觀察到的需求形狀。
所以這篇不是「我怎麼做成企業生意」，是「我為什麼認為這條路比 SaaS 合理，以及我還不知道自己對不對」。
如果你在找商業化成功案例，這篇會讓你失望。如果你想看一個決策的推理過程和它的空白處，繼續往下看。
一般在討論「SaaS 還是授權」的時候，是在比商業模式的優劣。
但在我這個專案裡，這個選擇早就被架構決定了。
回顧一下這個工具是什麼（Day 06、Day 11）：
localStorage
SaaS 需要什麼？
這兩份清單沒有任何交集。
要做 SaaS，我不是「增加功能」，是從零重寫。而且重寫之後，這個工具會失去它現在所有的優勢：
| 現在 | 變成 SaaS 之後 |
|---|---|
| 下載一個檔案就能跑 | 需要註冊 |
| 可以完全離線 | 需要連線 |
| 資料不出使用者瀏覽器 | 資料進我的資料庫 |
| 沒有帳號、沒有追蹤 | 有帳號、有記錄 |
| 我不需要維護任何東西 | 我要維運一個服務 |
而最後一行是致命的。 我是一個在柬埔寨管工廠 IT 的人，不是一個能提供 24/7 服務等級保證的公司。
我做不到 SaaS 該有的可靠性。而做不到的東西，不該賣。
Day 19 講過，企業對本地模型的三個理由裡，資料落地是否決條件，不是加分條件。
一段 IT 診斷對話會包含什麼？內網網段、伺服器主機名、AD 結構、軟體版本、錯誤日誌。
如果我做 SaaS，那些東西全部會經過我的伺服器。
也就是說：我會親手把這個工具，變成它自己想解決的那個問題。
一個為了「資料不出公司」而支援本地模型的工具，如果主要交付形式是 SaaS，那整個設計哲學就自相矛盾了。
架構上做不到，價值主張上也不該做。兩個理由指向同一個結論。
規劃是一個三階段的導入模型。我寫成文件是為了給我的主管看，也為了自己想清楚順序：
先確認技術上通得過，再談其他。
在客戶自己的環境裡把 Ollama 架起來，接上工具，跑幾個真實的故障情境。
為什麼這是第一階段？因為 Day 19 那條否決條件——如果資料落地這關過不了，後面全部不用談。
先驗證否決條件，再談加分條件。這個順序不能反。
（而這裡有一個我在 Day 20 已經承認的問題：小模型在 AI 對話路徑上到底行不行，我還沒有測過。 所以這個第一階段，我自己都還沒有真正走完。）
決策樹的節點內容換成客戶自己的環境：他們的網段、他們的伺服器命名規則、他們的 SOP、他們的升級路徑。
這一階段用得上 Phase 3 那個表單編輯器（Day 21）——它存在的理由就是讓非技術人員能改診斷內容，不用碰程式碼。
而 Day 23 那條「內容與介面分離」原則，在這裡是關鍵：客戶可以改診斷內容，但不能改 UI 字串。 這讓客製化有邊界，不會變成無底洞。
放到客戶自己的內網，交給他們的 IT 部門維護。
然後我就退出了。
這是授權模式跟 SaaS 最大的差別：我的責任有終點。
我不想只講它的好處。這個模式有幾個明顯的問題：
授權是一次性的。SaaS 是每個月的。
從商業角度看，一次性收入的模式難以規模化、難以預測、難以支撐持續開發。
這是實話，而我沒有解法。
第二階段的內容客製是人工的。每個客戶的網段、命名規則、SOP 都不一樣。
十個客戶就是十次客製。而我只有一個人，還有一份正職。
這跟 Day 27 那個問題是同一件事。交付出去、退出之後，我不知道它有沒有真的在跑、有沒有幫上忙。
如果客戶三個月後就棄用了，我不會知道。 而在 SaaS 模式裡，登入數字會告訴我。
上面三個代價，都是「如果這個模式跑起來」之後的問題。
而現在的狀態是：零個企業客戶，零個部署回饋，零筆收入。
我在規劃一個還沒有第一個客戶的商業模式的規模化問題。這件事本身就有點荒謬，我很清楚。
核心 vs 外部
核心是「這個工具要能在企業環境裡真的解決問題」。收費模式是外部。
而外部的選擇被核心限制住了——因為核心要求資料不出公司，SaaS 就被排除了。
可控 vs 不可控
我控制得了：交付形式、導入流程、文件品質。
我控制不了：有沒有企業願意買、市場的接受度、我有多少時間投入。
而我目前為止只做了可控的那一半。 不可控的那一半，我連測試都還沒開始。
已成立 vs 假設
| 狀態 | |
|---|---|
| SaaS 在現有架構上不可行 | 已成立（技術事實） |
| 資料落地是企業的否決條件 | 已成立（來自實際需求接觸） |
| 企業願意為這個工具付費 | 假設，零驗證 |
| 三階段導入模型可行 | 假設，第一階段我自己都還沒走完 |
| 授權模式能支撐持續開發 | 假設，且我知道它有結構性問題 |
四個假設，一個已驗證的技術限制。這就是目前的真實比例。
用 Day 13 那條決策相關性測試來想：哪個問題的答案，最能改變我接下來的行動？
不是「授權該定價多少」——那要等有人想買才有意義。
不是「怎麼規模化客製」——那要等有第二個客戶。
是：「有沒有任何一家企業，願意讓我做第一階段的驗證？」
一個客戶，一次本地模型驗證。這個答案會改變之後所有的事情：
而這個問題我還沒去問。 我一直在完善文件和規劃，而那是舒適的部分。
寫這篇文章讓我意識到這件事。
這篇是這三十天裡我最沒把握的一篇。
前面二十七天，我講的都是已經發生的事——寫過的程式、踩過的坑、收到的 Issue、被推翻的解讀。那些東西有事實可以核對。
企業版沒有。它到目前為止只是一份寫得很整齊的計畫。
而我在 Day 15 學到的教訓是：把假設當成事實是最容易犯的錯。
所以這篇文章的價值，可能不在於它提出的模式對不對，而在於它把「已驗證」和「還沒驗證」的界線畫清楚了。
一份誠實標註了自己空白處的計畫，比一份看起來很完整的計畫有用。因為前者知道下一步該去哪裡。
明天預告： 這兩個 Issue 都是用繁體中文寫的。這件事看起來很小，但它是我認為這個工具最被低估的一個定位選擇。
作者：Rich Chang | IT 基礎建設工程師 | 越南・柬埔寨・台灣
iThome鐵人賽
看影片追技術