AI研究
Helper CTO 系列文章 14｜網站掛了，誰會先知道：小產品也需要的監控最小組合
網站掛了，第一個發現的往往是客戶，不是你。本文用一張對照表說明小產品該有的監控最小組合：它還活著嗎、有沒有在報錯、主機撐得住嗎，以及最容易被忽略的前提——通知發出來之後誰負責看。
「我叫它修結帳，它修好了，可是登入壞了；叫它修登入，結帳又壞回去。」每來回一次就多賠一天的訂單，最後你乾脆不敢改，產品停在「能用，但誰都不敢碰」。你不是指令下得不好，而是這個產品缺一份「改完要重新檢查什麼」的清單。以下四件事，從原因講到怎麼補。
修好 A，壞了 B：你不是一個人
這個現象有固定的樣子，你可以對照看看自己走到哪一步了：
- 第一階段：產品很順，功能一個接一個長出來，改什麼都很快。
- 第二階段：開始出現「改 A 壞 B」，你以為只是運氣不好。
- 第三階段：每次改完都要自己把所有功能手動點一遍，越點越久。
- 第四階段：乾脆不改了，產品還能用，但誰都不敢碰。
這不是 AI 特有的問題，任何沒有測試的程式碼都會走到這裡，只是 AI 讓你更快抵達——它產出程式碼的速度遠超過任何人檢查的速度。能 demo 不等於能上線那篇講過五件常缺的事，這篇專講最會讓人越改越怕的那一件。
為什麼會這樣：沒有「改完要重新檢查」的清單
想像一間餐廳改了一道菜。廚房要確認：新做法跟原本的食材相容嗎、上菜順序會不會變、外送包裝裝不裝得下。這是一份「改完要確認的事」的清單。程式碼也一樣，只是牽連更看不見：
- 結帳和登入看起來無關，卻可能共用同一段「確認使用者是誰」的程式。
- AI 修結帳的時候動了那一段，登入就壞了，而它完全不會知道。
- 因為沒有人告訴它：改完這裡，要順便確認登入還打得開。
- 當初哪些東西彼此牽連，只存在那幾次對話裡，對話關掉就沒了。
測試就是那份清單，只是機器幫你跑
「自動化測試」聽起來很技術，其實就是把那份清單寫成程式，每一條都是「做這件事，應該得到這個結果」：
| 做這件事 | 應該得到的結果 | 沒測到會怎樣 |
|---|---|---|
| 用正確的帳號密碼登入 | 順利進到首頁 | 改完權限沒人發現大家登不進去 |
| 購物車放兩樣東西結帳 | 金額是兩樣的加總 | 折扣改壞，少收或多收都不知道 |
| 付款中途失敗 | 訂單不成立，也不出貨 | 沒收到錢卻照樣出貨 |
| 上傳超過大小限制的圖 | 看到錯誤訊息 | 整頁掛掉，使用者以為網站壞了 |
| 按「忘記密碼」 | 收到重設信 | 信寄不出去，全部變成客服電話 |
每次改完，機器把整份清單跑一遍，哪一條不對就立刻說。壞掉的地方會在上線前被抓到，不是客戶告訴你。
先從會賠錢的那條路開始
不需要一次幫所有功能寫測試，那樣太貴，也永遠寫不完。先問一句：哪條路徑壞掉，我會直接賠錢？然後照這個順序補：
- 會賠錢的主流程：註冊到付款、下單到出貨、登入到看報表，一條一條從頭走到尾。
- 過去被改壞過的地方：壞過一次的地方會再壞，先替它補一條。
- 跟外部服務接的地方：金流、簡訊最容易因為對方改了什麼而突然出事。
- 其他的先放著：不急的功能壞了頂多難看，不會讓你今天少收一筆錢。
你可以叫 AI 工具「幫這個功能寫測試」，它寫得很快。但要有人判斷它測的是不是重要的事。
沒有人幫你補測試的時候
補測試最難的地方不是寫，是判斷：
- 哪條路徑最重要：這件事要懂你的生意，不是只懂程式碼就做得到。
- 有沒有測到點上：看起來全部綠燈，其實測的都是無關緊要的地方。
- 失敗時是誰錯：是測試寫錯還是程式真的壞了，判斷錯就會養成忽略警告的習慣。
- 什麼時候該停：測試也要維護，補到夠用就好，不是越多越好。
沒有這樣的人，產品就停在「越改越脆」，直到某次改壞的剛好是會賠錢的那條路。這也是Vibe Coding 與真正系統架構的落差那篇的核心：AI 生得出功能，生不出責任。在測試補起來之前，至少先確認網站掛了有人先知道，那是比測試更便宜的第一道保險。
恩梯科技怎麼把那條路圍起來
- 先圍會賠錢的路徑：接手之後先替主流程補上測試，再談繼續開發。
- 同一組人從頭顧到尾：寫測試的人就是後面維護的人，不會寫完就走。
- 錯誤有人接：你回報有錯誤，2 個工作日內回覆評估。
- 紀錄留給你：測試和文件都是你的，換人接手也看得懂。
測試不是給工程師交的功課，是讓你敢繼續往前改的保險。
AI 改壞的地方，需要有人替它記住哪裡不能壞。恩梯科技以 Helper CTO 的角色接手你的 AI 產品，先把會賠錢的路徑圍起來再繼續開發。第一步是 60 分鐘的系統健檢：讓我們看得到程式碼就好，不需要正式環境的帳號密碼，3～5 個工作天內你會拿到一頁看得懂的報告。如果你的產品已經進入「能用但不敢碰」的狀態，先讓我們看看它到底哪裡不能碰：Helper CTO：系統維運方案。
