Vibe Coding 的價值不是讓人跳過工程紀律，而是把自然語言變成可驗證、可回復、可累積的技術決策。
一場依賴安裝失敗的修復案例說明：修對規則，往往比重複修改個別程式碼更重要。
▋ Belief：快速寫程式，不等於快速猜答案
當 AI 能在幾秒內產生程式碼，最危險的迷思也隨之出現：只要不斷描述錯誤、接受修改，系統最後總會自己恢復。實務上，沒有診斷框架的高速迭代，只會讓錯誤更快擴散，甚至把原本單純的環境問題改造成多處程式碼問題。
V103 通訊攻堅案例提供了清楚的對照。先前版本在安裝 libsignal-node 相關依賴時，反覆碰到 SSH 權限問題。關鍵判斷不是「某一行業務邏輯寫錯」，而是依賴取得方式仍有 ssh:// 協議漏網。修復策略因此從逐點補丁，提升為強制 Git 使用 HTTPS 的全域規則；當 npm install 通過，才證明問題類別被正確處理。
成熟的 Vibe Coding，不是讓 AI 多寫十個補丁；而是先問：這是程式錯誤、環境錯誤、規則漏洞，還是服務生命週期的正常狀態？
這個分類非常重要。若把規則漏洞誤判為程式錯誤，團隊會浪費時間修改無關模組；若把冷啟動期間的 503 一律視為故障，又可能在服務即將就緒前啟動不必要的回滾。快速不是省略觀察，而是縮短「假設—實驗—證據—決策」的迴圈。
503 不只是一個數字，它需要時間脈絡
案例中，Cloud Run 已成功啟動，但核心仍在暖機，暫時回傳 503。這不代表所有 503 都可以忽略；正確做法是先建立判讀條件：部署是否完成、容器是否持續運行、初始化日誌是否前進、健康檢查是否在預期時間內轉為 200，以及逾時後是否出現明確例外。
同一個狀態碼，在不同生命週期可能代表不同事情。剛部署後短暫出現，可能是冷啟動；超過既定暖機上限仍未恢復，則應視為故障。沒有時間界線的「再等等」是拖延，沒有日誌證據的「立刻重建」則是賭博。
▋ Desire：我們要的不是一次修好，而是下一次更容易修
非技術背景的管理者可以把軟體系統想成餐廳。顧客沒有拿到餐點，原因可能是食譜錯了、瓦斯沒開、食材供應商進不了後門，或廚房正在預熱。若每次都先改食譜，不但解決不了門禁與設備問題，還會破壞原本正常的菜色。
企業真正需要的是一套可重複的診斷秩序：先確認現象，再縮小範圍；先看錯誤日誌，再提出假設；每次只改一個關鍵變因，最後用實際輸出驗證。這套秩序能讓 AI 成為加速器，而不是把猜測大量自動化的放大器。
從成本來看，工程浪費通常不只發生在雲端帳單。更大的隱性成本包括：開發者反覆等待建置、主管追問狀態、錯誤回滾造成服務中斷，以及問題解決後沒有留下紀錄。評估修復方案時，至少應同時看模型與雲端費用、人工等待時間、失敗重試次數、回復難度。
▋ Intention：建立一條可驗證的 Vibe Coding 戰鬥迴圈
第一步：把錯誤現象寫成可反駁的句子
1，分開事實與推測：「安裝命令回傳 SSH 權限錯誤」是事實；「套件壞了」只是推測。先保留完整錯誤位置、發生階段與最近一次變更，避免 AI 被情緒化描述帶偏。
2，定義成功訊號：若目標是解決依賴問題，成功訊號應是建置與安裝真正通過，而不是 AI 說已修改完成。若目標是服務上線，則還要包含健康檢查轉為 200，以及核心功能實際可用。
第二步：依層級診斷，不跨層亂改
- 依賴層：套件來源、鎖定檔、協議與權限是否一致？
- 建置層：映像是否成功建立，產物是否包含必要檔案？
- 執行層：容器是否啟動，程序是否持續存活？
- 服務層：健康檢查、路由與核心功能是否回應？
- 治理層：此次修復是否能防止同類錯誤再次發生？
V103 的關鍵價值就在治理層：不是只替單一依賴改網址，而是建立 HTTPS 全域規則，處理整類 SSH 來源漏洞。這種修法的投資報酬率通常更高，因為它降低未來相同問題的重現機率；但全域規則影響範圍也更大，因此必須配合建置測試與差異審查。
第三步：為暫時狀態設定明確停止條件
3，設定暖機視窗：依服務歷史紀錄設定合理等待時間，在期間內監看日誌與健康狀態。超過時間仍未恢復，就停止等待並進入故障調查。
4，先驗證核心，再驗證周邊：服務轉為健康後，依序測試主要回應、Telegram 回覆與 Raindrop 自動收藏等功能。不要只看首頁或單一狀態碼，就宣稱整個系統完成。
5，固化知識：將症狀、根因、無效嘗試、最終規則、驗證命令與回滾方式寫入技術手冊。真正的勝利不是這次終於成功，而是下一位接手者不用重走數十次彎路。
管理者可以追問的五個問題
- 目前看到的是原始錯誤，還是團隊的推測？
- 這次修改處理單點症狀，還是一整類根因？
- 什麼真實輸出可以證明修復完成？
- 如果狀態沒有改善，何時停止等待或重試？
- 這次經驗是否已成為可搜尋、可重用的組織知識？
Vibe Coding 的核心不是「感覺對了就發布」，而是用自然語言指揮一個有證據的工程迴圈。規則負責防止同類錯誤，測試負責阻止錯誤答案，日誌負責讓判斷回到事實。三者都在，速度才是資產；缺少其中任何一項，速度就可能成為風險。
如果您的 AI 專案常在「建置成功、服務卻不可用」之間反覆卡關，歡迎與蔡教練聊聊您的數位轉型需求，一起把零散修補升級成可治理的技術流程。
